AVR309 USB to UART protocol converter

Features:
USB protocol implemented in firmware low
cost USB solution for small devices
Supports ow Speed USB !"#$%&it's( in
accordance wit) USB"#" and USB*#0
+mplementation runs on ver, small AVR devices-
from *.B,tes and up#
/ 0nl, one e1ternal component re2uired for USB
connection !one resistor(
Ver, small footprint- startin3 from t)e S045
AT90S*3*3
+mplemented functions: 6irect +'0 pin control-
USB to RS*3* converter- 778R0% scratc) re3ister
User can implement own functions !USB to T9+
control- USB A'6 and 6'A converter- :(
Vendor customi;a&le device name !visi&le from
user side(
Full 8< side support: full documentation )ow to
access device !6 li&rar, functions(
/ 71amples for developers on )ow to
communicate wit) device !6elp)i- <==- Visual
Basic(
+ntroduction
The USB interface has become extremely
popular, especially for the end use due to its
simplicity for end user applications (Plug and
Play without restart) !or de"elopers, howe"er,
USB implementation into their de"ices has been
more complicated when compared to eg
#S$%$ &n addition there is need of software
support on P' side( de"ice dri"ers Because of
this, #S$%$ based communication is still "ery
popular among de"ice manufacturers This
interface is well)established and has good
operating system support, but recently the
physcal #S$%$ port has been remo"ed from the
standard P' interface, gi"ing ground to USB
ports
&mplementation of USB into external de"ices
is at present time sol"ed in two ways(
a) Using microcontrollers with hardware)
implemented USB interface &t is necessary
to *now how USB wor*s and write firmware
into microcontroller accordingly +dditionally,
it is necessary to create a dri"er on the
computer side (as long as the operating
system does not include standard USB
classes) The disad"antage (and this is the
main disad"antage for small "endors and
amateurs) is the lac* of a"ailability of this
*ind of microcontrollers and their high price
compared to simple ,#S$%$,
microcontrollers
b) Second option is to use some uni"ersal
con"erter between USB and another
interface This other interface will usually be
#S$%$, -)bit data bus, or T.& bus &n this
case there is no need for special firmware, it
isn/t e"en necessary to *now how USB
wor*s, and no dri"er writing is necessary as
the con"erter "endor will offer one dri"er for
the whole solution The disad"antage is the
higher price of the complete system, and the
greater dimensions of the complete product
The solution presented in this document is a
USB implementation into a low)cost
microcontroller through emulation of the USB
protocol in the microcontroller firmware The
main challenge for this design was obtaining
sufficient speed The USB bus is 0uite fast(
1owSpeed ) 234bit5s, !ullSpeed ) 2$4bit5s,
6ighSpeed ) 7-84bit5s The maximum speed of
a normal microcontroller is limited( +T-9'$832 )
$4&PS : $746;5(2$cycl5inst), P&'2<!-7 )
34&PS : $846;5(7cycl5inst), +T98S$%x% )
284&PS : 2846;5(2cycl5inst) There are higher)
perfomance microcontrolers around, but they
tend to ha"e poor a"ailability and high cost, as
well as being larger in si;e !or the reasons
described, +T98S2$885+T98S$%x% represent the
least expensi"e solution which is still able to
meet the hard speed re0uirements of 1owSpeed
USB The solution is not recommended for
higher USB speeds

T)eor, of 0peration
=xtensi"e details regarding physical USB
communication can be found at the website
wwwusborg This documentation is "ery
complex and difficult for beginners (ca <38
pages)
+ "ery good and simple explanation for
beginners can be found in the document USB in
a >utshell 4a*ing Sense of the USB Standard
written by Craig Peacock
('raigPeacoc*?beyondlogicorg) This
document can be found at
http(55wwwbeyondlogicorg or here( usb)in)a)
nutshellpdf This document is recommended
reading for understanding how USB wor*s (only
%8 pages)
&n this document the explanation is limited to
the scope of understanding the de"ice firmware
The USB physical interface consists of 7 wires( $
for powering the external de"ice (@'' and
A>B), and $ signal wires (B+T+C and B+T+))
The power wires gi"e approximately 3 "olts and
max 388m+ .e can supply our de"ice from
@cc and A>B The signal wires named B+T+C
and B+T+) handle the communication between
host (computer) and de"ice Signals on these
wires are bi)directional @oltage le"els are
differential( when B+T+C is at high le"el, B+T+)
is at low le"el, but there are some cases when
B+T+C and B+T+) are at the same le"el (=DP E
end of pac*et, idle state)
VSS
Si3nal pins
pass output
spec levels
wit) minimal
reflections and
rin3in3
0ne Bit
Time
!"#$%&'s(
6river
Si3nal 8ins
VS7 !ma1(
VS7 !min(
!igure 2 1ow Speed Bri"er Signal
.a"eforms
Therefore, in our firmware dri"en USB
implementation we must be able to sense or
dri"e both those signals

V V0 0> > ! !m mi in n( (
V VS S7 7 ! !m ma a1 1( (
V VS S7 7 ! !m mi in n( (
V V0 0 ! !m ma a1 1( (
V VS SS S
B Bu us s + +d dl le e
F Fi ir rs st t B Bi it t
o of f 8 8a ac c. .e et t

S S0 08 8
V0> !min(
VS7 !ma1(
VS7 !min(
V0 !ma1(
VSS
Bus 6riven
to +dle State
ast Bit
of 8ac.et
Bus +dle
Bus
Floats
708
Stro&e
Figure 2. Packet Transaction Voltage Levels
USB de"ice connection and disconnection is
detected based on the impedance sensed on the
USB line !or 1owSpeed USB de"ices (our case)
a 23*ohm pull)up resistor between B+T+) signal
and @'' is necessary (for !ullSpeed de"ices,
this resistor is connected to B+T+C)
F#S#'#S# USB
Transceiver
>ost or
>u& 8ort
Untwisted- Uns)ielded
R"
6=
64 64
6=
R"
Slow Slew Rate
Buffers
#S# USB
Transceiver
ow Speed Function
3 %eters ma1#
R"?"$@
R*?"#$@
R*
!igure % 1ow Speed Be"ice 'able and
#esistor 'onnections
Based on this pull)up, the host computer will
detect that some new de"ice is connected to
USB line
+fter the host detects a new de"ice it can
start communicating with it in accordance with
the physical USB protocol The USB protocol,
unli*e U+#T, is based on synchronous data
transfer Synchroni;ation of transmitter and
recei"er is necessary to carry out the
communication Because of this, the transmitter
will transmit a small header (sync pattern)
preceding the actual data This header is a
s0uare wa"e (282828), succeed by two ;eros
after which the actual data is transmitted

& &d dl l e e
S SF F> >' ' P P+ +T TT T= =# #> >
> ># #G G& & B Ba at ta a
= =n nc co od di i n ng g
P P& &B B8 8 P P& &B B2 2
!igure 7 Sync Pattern
&n order to maintain synchroni;ation, USB
demands that this sync pattern is transmitted
e"ery millisecond in the case of full speed
de"ices, or that both signal lines are pulled to
;ero in the case of low speed de"ices &n
hardware)implemented USB recei"ers, this
synchroni;ation is ensured by a digital P11
(phase loc*ed loop) &n our implementation, we
must synchroni;e data sampling time with the
sync pattern, then wait for two ;eros, and start
recei"ing data
Bata reception on USB must satisfy that
recei"er and transmitter are in sync at all times,
therefore it is not permitted to send a stream of
continuous ;eros or ones on the data lines The
USB protocol ensures synchroni;ation by bit
stuffing This means that, after < continuous
ones or ;eros on the data lines, one single
change (one bit) is inserted +s signal on USB
lines are >#G& coded, this means that one ;ero
bit is inserted into the logical data stream after <
contiguous logical ones
0 1 1 0 1 0 1 0 0 0 1 0 0 1 1 0
Data
NRZI
Idle
Idle
!igure 3 >#G& Bata =ncoding

6 6a at ta a 7 7n nc co od di in n3 3 S Se e2 2u ue en nc ce e: :
B Bi it t S St tu uf ff fe ed d 6 6a at ta a
R Ra aw w 6 6a at ta a
A AR RB B+ +
7 7n nc co od de ed d 6 6a at ta a
+ +d dl le e
S S, ,n nc c 8 8a at tt te er rn n
S S, ,n nc c 8 8a at tt te er rn n
S S, ,n nc c 8 8a at tt te er rn n
8 8a ac c. .e et t 6 6a at ta a
8 8a ac c. .e et t 6 6a at ta a
S St tu uf ff fe ed d B Bi it t
S Si i1 1 0 0n ne es s
8 8a ac c. .e et t 6 6a at ta a
!igure < Bit Stuffing
>otification of end of data transfer is made
by and =DP (end)of)pac*et) part =DP consists
of $ ;eros on both data lines (both physical
B+T+C and B+T+) are at low "oltage le"el) =DP
is succeeded by a short time of idle state (min $
periods of data rate) +fter this, the next
transaction can be performed
TP=#&DB
Bifferential
Bata 1ines
=DP
.idth
Bata
'rosso"er
1e"el
!igure H =DP .idth Timing
Bata between sync pattern and =DP is >#G&
coded communication between USB de"ice and
host The data stream is composed by pac*ets
consisting of se"eral fields( Sync field (sync
pattern), Pac*et&B (P&B), +ddress field (+BB#),
=ndpoint field (=>BP), Bata, and 'yclic
redundancy chec* field ('#') Usage of these
fields in different types of data transfer is
explained well in I8J USB describes four types of
transfer( 'ontrol Transfer, &nterrupt Transfer,
&sochronous Transfer, and Bul* Transfer =ach of
these transfers is dedicated for different de"ice
re0uirements, and their explanations can be
found in I8J
Dur de"ice is using 'ontrol transfer This
transfer mode is dedicated for de"ice settings,
but can also be used for general purposes
&mplementation of 'ontrol transfer must exist on
e"ery USB de"ice, as this mode is used for
configuration when the de"ice is connected
(obtaining information from de"ice, setting de"ice
address, etc) + description of the 'ontrol
transfer and its contents can be found in I8J and
I8J =ach 'ontrol transfer consists of se"eral
stages( Setup stage, Bata stage and Status
stage
Bata is in USB transferred in pac*ets, with
se"eral bytes each The pac*et si;e is
determined by each de"ice, but is limited by
specification !or 1owSpeed de"ices, pac*et
si;e is limited to - bytes This - bytes long
pac*ed C beginning and ending field must be
recei"ed into the de"ice buffer in one USB
transfer &n hardware)based USB recei"ers, the
"arious parts of the transfer are automatically
decoded, and the de"ice is notified only when
the entire message has been assigned for the
particular de"ice &n a firmware implementation,
the USB message must be decoded by firmware
after the entire message has been recei"ed into
the buffer This gi"es us the re0uirements and
limitations( The de"ice must ha"e a buffer for
storing the whole USB message length, another
buffer for USB transmitting (prepared data to
transmit), and administration o"erhead with
message decoding and chec*ing +dditionally, of
course, the firmware is re0uired to perform fast
and precise synchronous speed reception (from
physical pins to buffer) and transmission (from
buffer to pins) +ll these capabilities are limited
by microcontroller resources (speed and
program5data memory capacity), so the firmware
must be carefully optimi;ed &n some cases the
microcontroller computation power is "ery close
to the minimum re0uirements and therefore all
firmware must be written in assembly
<onnection
+ schematic diagram of microcontroller
connection to USB bus is shown in !igure - and
!igure 9 These schematics were made for the
specific purpose as USB to RS232 converter
The functions implemented by direct pin control
and ==P#D4 read5write
GND
VCC
+
C2
10u
XT1
12MHz
1
2
3
4
XC1
USB-A
RST
1
PD0/RXD
2
PD1/TXD
3
XTAL2
4
XTAL1
5
PD2/INT0
6
PD3/INT1
7
PD4/T0

PD5/T1
!
GND
10
VCC
20
ICP/PD6
11
AN2/PB0
12
AN1/PB1
13
PB2
14
"C1/PB3
15
PB4
16
M"SI/PB5
17
MIS"/PB6
1
SC#/PB7
1!
IC1
AT!0S2313-10 / AT$%&'2313
DATA+
DATA-
GND
VCC
VCC
C1
100&
GND
GND
GND
VCC
D0
D1
D2
D3
D4
D5
D6
D7
T(D
R(D
RS232 TTL
D1
3V6
D2
3V6
GND GND
R2
6R
R3
6R
R1
2)2
R2
4)7
VCC
!igure - USB interface with +T98S$%2% (as USB to #S$%$ con"erter with %$ byte !&!D C -)bit &5D
control C 2$- bytes ==P#D4)
GND
XT1
12MHz
T(D
R(D
PC6/RST
1
PD0/RXD
2
PD1/TXD
3
XTAL2/T"SC2/PB7
10
XTAL1/T"SC1/PB6
!
PD2/INT0
4
PD3/INT1
5
PD4/T0/XC#
6
PD5/T1
11
GND

AVCC
20
PD6/AIN0
12
PD7/AIN1
13
PB0/ICP
14
PB1/"C1A
15
PB2/SS/"CIB
16
PB3/M"SI/"C2
17
PB4/MIS"
1
PB5/SC#
1!
AR*+
21
GND
22
PC0/ADC0
23
PC1/ADC1
24
PC2/ADC2
25
PC3/ADC3
26
PC4/ADC4/SDA
27
PC5/ADC5/SCL
2
VCC
7
IC1
AT,-./
R1
2)2
+
C2
10u
1
2
3
4
XC1
USB-A
DATA+
DATA-
GND
VCC
GND
GND
VCC
VCC
C1
100&
GND
VCC
VCC
GND
RS232 TTL
D03
D04
D05
D06
D07 D12
D13
D14
D15
D20
D21
D22
D23
D24
D25 D26/RST
D1
3V6
D2
3V6
GND GND
R3
6R
R4
6R
R2
4)7
VCC
GND
!igure 9 USB interface with +Tmega- (as USB to #S$%$ con"erter with -88 byte !&!D C ==P#D4 C &5D
control C ==P#D4)
The USB data lines, B+T+) and B+T+C, are
connected to pins PB8 and PB2 on the +@#
This connection cannot be changed because the
firmware ma*es use of one +@# finesse for fast
signal reception( The bit signal captured from the
data lines is right shifted from 1SB (PB8) to carry
and then to the reception register, which collects
the bits from the data lines PB2 is used as input
signal because on -)pin +T98S$%$% this pin can
be used as external interrupt &>T8 (no additional
connection to &>T8 is necessary E the -)pin
"ersion of the +@# is the smallest pin count
a"ailable) Dn other +@#s, an external
connection from B+T+C to the &>T8 pin is
necessary if we want to ensure no firmware
changes between different +@# microcontrollers
!or proper USB de"ice connection and
signaling, the +@# acting as low speed USB
de"ice must ha"e a 23*ohm pull)up resistor on
B+T+)
The other components only pro"ide
functions for proper operation of the
microcontroller( 'rystal as cloc* source, and
capacitors for power supply filtering
This small component count is sufficient to
obtain a functional USB de"ice, which can
communicate with a computer through the USB
interface This is a "ery simple and cheap
solution Some additional components can be
added to extend the de"ice functions &f we want
to recei"e an &# signal, we can add the
TSDP2H%- infrared sensor &f we want to use the
de"ice as an USB to #S$%$ con"erter, we
should add the 4+K$%$ TT1 to #S$%$ le"el
con"erter &f we want to control 1=B diodes or
display, we connect them to &5D pins directly or
through resistors
+mplementation
+ll USB protocol reception and decoding is
performed at the firmware le"el The firmware
first recei"es a stream of USB bits in one USB
pac*et into the internal buffer Start of reception
is based on the external interrupt &>T8, which
ta*es care of the sync pattern Buring reception,
only the end of pac*et signal is chec*ed (=DP
detection only) This is due to the extreme speed
of the USB data transfer +fter a successful
reception, the firmware will decode the data
pac*ets and analy;e them +t first it chec*s if the
pac*et is intended for this de"ice according to its
address The address is transferred in e"ery
USB transaction and therefore the de"ice will
*now if the next transferred data are dedicated to
it USB address decoding must be done "ery
0uic*ly, because the de"ice must answer with an
+'L handsha*e pac*et to the USB host if it
recogni;es a "alid USB pac*et with the gi"en
USB address Therefore this is a critical part of
the USB answer
+fter the reception of this bitstream, we
obtain an >#G& coded array of bits with
bitstuffing in the input buffer &n the decoding
process we first remo"e the bitstuffing and then
the >#G& coding +ll these changes are made in
a second buffer (copy of the reception buffer), so
a new pac*et can be recei"ed while the first one
is being decoded +t this point, decoding speed
is not so important, because the de"ice can
delay the answer, but when the hosts as*s for an
answer during decoding, the de"ice must answer
immediately with >+L so that the host will
understand it is not ready yet Because of this,
the firmware must be able to recei"e pac*ets
from the host during decoding, decode whether
the transaction is intended for the de"ice, and
then send >+L pac*et if there is some decoding
in progress The host will then as* again The
firmware also decodes the main USB transaction
and performs the re0uested action (for example,
send char to #S$%$ line and wait for
transmission complete), and prepares the
corresponding answer Buring this process the
de"ice is interrupted by some pac*ets from the
host, usually &> pac*ets to obtain answer from
the de"ice To these &> pac*ets, the de"ice must
answer with >+L handsha*e pac*ets .hen the
answer is ready and the de"ice has performed
the re0uired action, the answer must go through
'#' field addition and then >#G& coding and
bitstuffing before being transmitted as an array of
bits >ow, when the host re0uests an answer, we
can transmit this bitstream to the data lines
according to the USB specification (from sync
pattern to =DP)
Firmware description
&n the following we describe the main parts
of the firmware The firmware is di"ided into
bloc*s( interrupt routines, decoding routines
(>#G& decoding, bitstuffing remo"al5addition, M),
USB reception, USB transmission, re0uested
action decoding, and performing re0uested
actions
User can add his own functions to the
firmware Some examples on how to ma*e
customer)specific functions can be found in the
firmware code, and user can write new de"ice
extensions according to the existing built)in
functions !or example T.& support can be
added according to the built)in function for direct
pin control
!igure 28 !lowchart of recei"ing routine
EXT_INT0
Interrupt
Service
Routine
2
INT0 3/%4%&. -0.-
*0.- 0-$-2$%5&
6/%$ 753 -&0 57 S"P
82 1%$4 /$ 4/,- 9-:-9;
S/,<9%&. $%,- $5 ,%009- 57 1%$
I&%$ USB 0/$/ 1%$4 3-2-%:%&.
S/,<9- DATA+=
DATA- $5 PB0= PB1
S>%7$ PB0 2/33'
S>%7$1u77-3 2/33'
PB0?PB1?0
@
S>%7$1u77-3
7u99@
S$53- S>%7$1u77-3 $5
%&<u$ 1u77-3
R-2-%:-0
1'$-4 A 3 @
1
2
*&0 57 INT0 %&$-33u<$
P/2)-$ $'<- 0-$-2$%5&
USB /003-44 0-$-2$%5&
8%7 &5 D/$/ </2)-$;
S-&0 /&4B-3 8%7 /&4B-3
<3-</3-0 %& 5u$ 1u77-3;
53 NAC# 8/&4B-3 %&
<35.3-44;
S-$ 4$/$- /22530%&.
3-2-%:-0 $'<- 57 </2)-$
I4 ,' USB
/003-44@
1
2
I4 S-$u< 0/$/
</2)-0@
S-&0 AC# </2)-$ 8/22-<$%&. 4-$u< 0/$/
</2)-$;C
C5<' 3-2-%:%&. 1u77-3 $5 %&<u$ 1u77-3C
S-$ 79/. 753 &-B 3-Du-4$ %& %&<u$ 1u77-3C
+%&%4> INT0 %&$-33u<$E
C9-/3 <-&0%&. INT0
R-4$53- 3-.%4$-34
2
The external
interrupt 8 is acti"e
all the time while the
firmware is running
This routine initiates
the reception of
USB serial data (an
alternati"e name
would be NUSB
receptionO) +n
external interrupt
occurs on a rising
edge on the &>T8
pin (a rising edge
mar*s the beginning
of the sync pattern
of a USB pac*et
see !igure 7) This
acti"ates the USB
reception routine
!irst, data
sampling must be
synchroni;ed to the
middle of the bit
width This is done
according to the
sync pattern (which
is a s0uare wa"e
signal) Because bit
duration is only -
cycles of the KT+1
cloc*s and interrupt
occurrence can be
delayed (C5) 7
cycles), edge
synchroni;ation in
sync pattern must
be carefully
performed =nd of
sync pattern and
begin of data bits
are detected
according to the last
dual low le"el bits in
sync pac*et (see
!igure 7)
+fter this, data
sampling is started
Sampling is
performed in the
middle of the bit
Because data rate
is 234bit5s
(2346;) and the
microcontroller
speed is 2$46;, we
ha"e only - cycles
for data bit
sampling, storing it
into the buffer byte,
shift the buffer byte,
chec*ing if the
whole byte has
been recei"ed,
storing this byte into
S#+4, and
chec*ing for =DP
This is perhaps the
most crucial part of
the firmwareP
e"erything must be
done synchronously
with exact timing
.hen a whole USB
pac*et has been
recei"ed, pac*et
decoding must be
performed !irst, we
must 0uic*ly
determine the
pac*et type
(S=TUP, &>, DUT,
B+T+) and recei"ed
USB address This
fast decoding must
be performed inside
the interrupt ser"ice
routine because an
answer is re0uired
"ery 0uic*ly after
recei"ing the USB
pac*et (the de"ice
must answer with
an +'L handsha*e
pac*et when a
pac*et with the
de"ice address has
been recei"ed, and
with >+L when the
pac*et is for the
de"ice, but when no
answer is currently
ready)
+t the end of
the reception
routine (after
+'L5>+L
handsha*e pac*et
has been sent) the
sampled data buffer
must be copied into
another buffer on
which the decoding
will be performed
This is in order to
free the reception
buffer to recei"e a
new pac*et
Buring
reception the pac*et
type is decoded and
the corresponding
flag "alue is set
This flag is tested in
the main program
loop, and according
to its "alue the
appropriate action
will be ta*en and
the corresponding
answer will be
prepared with no
regard to
microcontroller
speed
re0uirements
The &>T8 must
be allowed to *eep
its "ery fast
in"ocation time in all
firmware routines,
so no interrupt
disabling is allowed
and during other
interrupts/ execution
(for example serial
line recei"e
interrupt) &>T8 must
be enabled !ast
reception in the
&>T8 interrupt
routine is "ery
important, and it is
necessary to
optimi;e the
firmware for speed
and exact timing
Dne important issue
is register bac*up
optimi;ation in
interrupt routines
Main
progra
m loop
The main
program loop is "ery
simple &t is only
re0uired to chec*
the action flag( what
to do when some
recei"ed data are
present &n addition
it chec*s whether
the USB interface is
reset (both data
lines are at low le"el
for a long time) and,
if it is, reinitiali;es
the de"ice .hen
there is something
to do (action flag
acti"e), the
corresponding
action is called(
decoding >#G& in
pac*et, bitstuffing
remo"al and
preparation of the
re0uested answer in
the transmit buffer
(with bitstuffing and
>#G& coding) Then
one flag is acti"ated
to signal that the
answer is prepared
for sending
Physical output
buffer transmission
to the USB lines is
performed in the
reception routine as
answer to the &>
pac*et
Short
description
of used
firmare
su!routines
&n the following,
the firmware
subroutines and
their purposes are
described briefly
Reset"
&nitiali;ation of
the +@#
microcontroller
resources( stac*,
serial lines, USB
buffers, interrupts
Main"
4ain program
loop 'hec*s the
action flag "alue
and, if flag is set,
performs the
re0uired action
+dditionally, this
routine chec*s for
USB reset on data
lines and
reinitiali;es the USB
microcontroller
interface if this is
the case
Int0#andler"
The interrupt
ser"ice routine for
the &>T8 external
interrupt 4ain
reception5transmissi
on engineP
emulation from USB
data lines Storing
data to buffer,
decision of USB
pac*et owners
(USB address),
pac*et recognition,
sending answer to
USB host Basically
the heart of the USB
engine
M$Ne%S&'d
dress"
'alled from
&>T8 reception
routine if there is a
re0uest present to
change the USB
address The
address is changed
and its coded >#G&
e0ui"alent for
fastest address
decoding during
USB pac*et
reception is
prepared
(inishReceivin
g"
'opies coded
raw data from USB
reception pac*et to
decoding pac*et (for
>#G& and bitstuffing
decoding)
%S& reset"
&nitiali;es USB
interface to default
"alues (as the state
after power on)
Send)repared
%S&'nser"
Sends prepared
output buffer
contents to USB
lines >#G& coding
and bitstuffing is
performed during
transmission
Pac*et is ended
with =DP
Toggle*'T')I
*"
Toggles
B+T+P&B pac*et
identifier (P&B)
between B+T+8 and
B+T+2 P&B This
toggling is
necessary during
transmission as per
the USB
specification
+ompose,ero
*'T'-)I*'nser"
'omposes ;ero
answer for
transmission Gero
answer contains no
data and is used in
some cases as
answer when no
additional data is
a"ailable on de"ice
Init'+.&ufffer
"
&nitiali;es buffer
in #+4 with +'L
data (+'L
handsha*e pac*et)
This buffer is
fre0uently sent as
answer so it is
always *ept ready in
memory
Send'+."
Transmits +'L
pac*et to USB lines
InitN'.&ufffer"
&nitiali;es buffer
in #+4 with >+L
data (>+L
handsha*e pac*et)
This buffer is
fre0uently sent as
answer so it is
always *ept ready in
memory
SendN'."
Transmits >+L
pac*et to USB lines
+omposeST'/
/"
&nitiali;es buffer
in #+4 with ST+11
data (ST+11
handsha*e pac*et)
This buffer is
fre0uently sent as
answer so it is
always *ept ready in
memory
*ecodeNR,I"
Performs >#G&
decoding Bata from
USB lines in buffer
is >#G& coded This
routine remo"es the
>#G& coding from
the data
&itStuff"
#emo"es5adds
bitstuffing in
recei"ed USB data
Bitstuffing is added
by host hardware
according to the
USB specification to
ensure
synchroni;ation in
data sampling This
routine produces
recei"ed data
without bitstuffing or
data to transmit with
bitstuffing
ShiftInsert&uff
er"
+uxiliary routine
for use when
performing
bitstuffing addition
+dds one bit to
output data buffer
and thus increases
the buffer length
The remainder of
the buffer is shifted
out
Shift*elete&uff
er"
+uxiliary routine
for use when
performing
bitstuffing remo"al
#emo"es one bit to
output data buffer
and thus decreases
the buffer length
The remainder of
the buffer is shifted
in
MirrorIn&uffer
&$tes"
=xchanges but
order in byte
because data is
recei"ed from USB
lines to buffer in
re"erse order
(1SB54SB)
+hec0+R+In"
Performs '#'
(cyclic redundancy
chec*) on recei"ed
data pac*et '#' is
added to USB
pac*et to detect
data corruption
'dd+R+1ut"
+dds '#' field
into output data
pac*et '#' is
calculated
according to the
USB specification
from gi"en USB
fields
+hec0+R+"
+uxiliary routine
used in '#'
chec*ing and
addition
/oad*escripto
r(romR1M"
1oads data from
#D4 to USB output
buffer (as USB
answer)
/oad*escripto
r(romR1M,eroIns
ert"
1oads data from
#D4 to USB output
buffer (as USB
answer) but e"ery
e"en byte is added
as ;ero This is
used when a string
descriptor in
U>&'DB= format is
re0uested (#D4
sa"ing)
/oad*escripto
r(romSR'M"
1oads data from
#+4 to USB output
buffer (as USB
answer)
/oad*escripto
r(romEE)R1M"
1oads data from
data ==P#D4 to
USB output buffer
(as USB answer)
/oadXXX*escr
iptor"
Performs
selection for answer
source location(
#D4, #+4 or
==P#D4
)repare%S&1
ut'nser"
Prepares USB
answer to output
buffer according to
re0uest by USB
host, and performs
the re0uested
action +dds
bitstuffing to answer
)repare%S&'n
ser"
4ain routine for
performing the
re0uired action and
preparing the
corresponding
answer The routine
will first determine
which action to
perform E disco"er
function number
from recei"ed input
data pac*et E and
then perform the
re0uested function
!unction
parameters are
located in input data
pac*et
#outine is
di"ided into two big
parts(
- standard
re0uests
- "endor
specific
re0uests
Standard
re0uests are
necessary and are
described in USB
specification
(S=TQ+BB#=SS,
A=TQB=S'#&PTD
#, M)
@endor specific
re0uests are
re0uests that can
obtain "endor
specific data (in
'ontrol USB
transfer) 'ontrol &>
USB transfer is
used for this +@#
de"ice to
communicate with
host Be"elopers
can add into this
part their own
functions and in this
manner extend
de"ice "ersatility
The "arious
documented built)in
functions in the
source code can be
used as templates
on how to add
custom functions
Standard USB
functions (Standard
#e0uests)(
+ompose2ET_
ST'T%S"
+ompose+/E
'R_(E'T%RE"
+omposeSET_
(E'T%RE"
+omposeSET_
'**RESS"
+ompose2ET_
*ES+RI)T1R"
+omposeSET_
*ES+RI)T1R"
+ompose2ET_
+1N(I2%R'TI1N"
+omposeSET_
+1N(I2%R'TI1N3
+ompose2ET_
INTER('+E3
+omposeSET_
INTER('+E"
+omposeS4N
+#_(R'ME3
@endor USB
functions (@endor
re0uests)(
*oSetInfra&uff
erEmpt$"
*o2etInfra+od
e"
*oSet*ata)ort
*irection"
*o2et*ata)ort
*irection"
*oSet1ut*ata
)ort"
*o2et1ut*ata
)ort"
*o2etIn*ata)
ort"
*oEE)R1MRe
ad"
*oEE)R1M5r
ite"
*oRS676Send"
*oRS676Read"
*oSetRS676&
aud"
*o2etRS676&
aud"
*o2etRS676&
uffer"
*oSetRS676*
ata&its"
*o2etRS676*
ata&its"
*oSetRS676)a
rit$"
*o2etRS676)
arit$"
*oSetRS676St
op&its"
*o2etRS676St
op&its"
Bata structures
(USB descriptors
and strings)(
*evice*escrip
tor"
+onfig*escript
or"
/angI*String*
escriptor"
8endorString*
escriptor"
*evNameStrin
g*escriptor"
(ormat of
input
messa
ge
from
%S&
host
+s stated
abo"e, our USB
de"ice uses USB
'ontrol Transfer
This type of transfer
uses a data format
defined in the USB
specification
described in usb)in)
a)nutshellpdf I8J on
page 2% ('ontrol
Transfers) &n this
document the
details and
explanations on
how control transfer
wor*s, and
therefore how our
de"ice
communicates with
the USB host, can
be found The +@#
de"ice is using
control &> endpoint
+ nice example of
data communication
can be found on
page 23 of I8J
'ommunication
between host and
+@# de"ice is done
according to this
example
&n addition to
the actual control
transfer, the format
of the B+T+852 field
in the transfer
should be
discussed 'ontrol
transfer defines in
its setup stage a
standard re0uest,
which is - bytes
long &ts format is
described on page
$< of I8J (The Setup
Pac*et) There is
table with a
description of the
meaning of e"ery
byte The following
is important for our
purpose(
Standard setup
pac*et used for
detection and
configuration of
de"ice after power
on This pac*et
uses the Standard
Type re0uest in the
bmRequestType
field (bits B<)B3 :
8) +ll next fields/
(bRequest, wa!ue,
w"nde#, w$engt%)
meanings can be
found in the USB
specification Their
explanation can be
found on pages $H)
%8 in I8J (Standard
#e0uests)
="ery setup
pac*et has eight
bytes, used as
described in the
following table
Ofset Field Size Value Description
bmRequestType 1 Bit-map Characteristics of request
D7 Data xfer direction
0 = Host to device
1 = Device to host
D6..5 Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
D4..0 Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4..31 = Reserved
bRequest 1 Value Specifc request (refer to
source not found)
wValue 2 Value Word-sized feld that varies according to
request
wIndex 2 Index or
Ofset
Word sized feld that varies according to
request - typically used to pass an index or
ofset
wLength 2 Count Number of bytes to transfer if there is a
data phase
Table 1 : Standard setup packet fields (control
transfer)
wValue wIndex wLength Data
Feature
Selector
Zero
Interface
Endpoint
Zero None
Zero Zero One Confguration
Value
Descriptor
Type and
Descriptor
Index
Zero or
Language
ID
Descriptor
Length
Descriptor
Zero Interface One Alternate
Interface
Zero Zero
Interface
Endpoint
Two Device,
Interface, or
Endpoint
Status
Device
Address
Zero Zero None
Confguration
Value
Zero Zero None
Descriptor
Type and
Descriptor
Index
Zero or
Language
ID
Descriptor
Length
Descriptor
Feature
Selector
Zero
Interface
Endpoint
Zero None
Alternate
Setting
Interface Zero None
Zero Endpoint Two Frame Number
Table 2: Standard device requests
bRequest
87u&2$%5& &u,1-3;
wValue
8</3/,1;
wIndex
8</3/,2;
wLength
Data
FNCNumberDoSetInfraBuferEmpty None None 1 Status
FNCNumberDoGetInfraCode None None 1 Status
FNCNumberDoSetDataPortDirection DDRB
DDRC
DDRD
usedports
1 Status
FNCNumberDoGetDataPortDirection None None 3 DDRB
DDRC
DDRD
FNCNumberDoSetOutDataPort PORTB
PORTC
PORTD
usedports
1 Status
FNCNumberDoGetOutDataPort None None 3 PORTB
PORTC
PORTD
FNCNumberDoGetInDataPort None None 3 PINB
PINC
PIND
FNCNumberDoEEPROMRead Address None Length EEPROM
bytes
FNCNumberDoEEPROMWrite Address EEPROM
value
1 Status
FNCNumberDoRS232Send RS232
byte value
None 1 Status
FNCNumberDoRS232Read None None 2 Status
FNCNumberDoSetRS232Baud Baudrate
Lo
Baudrate
Hi
1 Status
FNCNumberDoGetRS232Baud None None 2 Baudrate
FNCNumberDoGetRS232Bufer None None Length RS232
bytes
from FIFO
FNCNumberDoSetRS232DataBits Databits
value
None 1 Status
FNCNumberDoGetRS232DataBits None None 1 Databits
value
FNCNumberDoSetRS232Parity Parity
value
None 1 Status
FNCNumberDoGetRS232Parity None None 1 Parity
value
FNCNumberDoSetRS232StopBits Stopbits
value
None 1 Status
FNCNumberDoGetRS232StopBits None None 1 Stopbits
value
Table 3: Vendor device requests used in
firmware as functions calls
N5$-E FNCNumberXXX :/9u-4 /3- 0-7%&-0 %&
DLLC
'ontrol Transfer is used for user
communication, implemented as custom
functions in the firmware, as well The endor
Type re0uest in the bmRequestType field (bits
B<)B3 : $) is used &n this case all succeeding
fields (bRequest, wa!ue, w"nde#) can be
modified according to the programmer/s
purposes &n our implementation, bRequest field
is used for function number and the next fields
are used for function parameters The first
parameter is in the wa!ue slot, the second at
the w"nde# location
+n example from the implementation is
==P#D4 writing bRequest : 9 is chosen as
function number The wa!ue field is used for
==P#D4 address, and the "alue to write
(==P#D4 data) is in the w"nde# field +ccording
to this, we obtain the following function(
&&PR'()rite*+ddress, a!ue,-
&f more user functions are re0uired, it is
enough to add function numbers and the body of
the re0uired function into the firmware The
techni0ue can be extracted from the built)in
function in the firmware (see source code)
USB host also communicates with de"ice
with &> control transfers 6ost sends an -)byte
&> data pac*et to the de"ice in the format
defined abo"e (function number and
parameters), and the de"ice then answers with
re0uested data The length of the answered data
is firmware limited in some cases up to $33
bytes, but the main limitation is on the de"ice
dri"er side on the host computer >ow this dri"er
supports -)byte length answers (in endor Type
re0uests
(irmare customi9ation
Users (de"elopers of de"ice) can add into
firmware new functions and extend de"ice
properties
&n firmware are prepared % examples how to
add user functions( BoUser!unctionK (K:8,2,$)
+ccording these examples can be added similar
extended functions !unctions content depends
only on de"ice re0uirements
&n firmware can be customi;ed also all
de"ice names E as de"ice appears in computer
side This names is located in firmware as
strings and can be changed to any string But
these names are recommended to change
together with USB P&B (product &B) and @&B
("endor &B) for correct recognition in system
@&B together with P&B must be uni0ue for
gi"en de"ice type Therefore is recommended
that if de"ice functionality is changed then is
modified P&B and5or @&B @endor &B depends
from "endor of USB de"ice and must be
assigned from USB organi;ation (see more
information on I2J) ="ery "endor has its own &B
and therefore this "alue can not be changed to
any unassigned "alue But product &B depends
only from "endor choice and purpose of P&B is to
recogni;e different de"ices from the same
"endor
<omputer side software
&n order to communicate with the de"ice we
need some software support on the P' side
This software is di"ided into % le"els(
2) Be"ice dri"er( Used for low)le"el
communication with the de"ice and for
installation into operating system
(.indows9-54=5>T5KP)
$) B11 library( Used for encapsulation of
de"ice functions and communication with
de"ice dri"er B11 simplifies the de"ice
function access from user applications, &t
includes some de"ice and operating
system related functions (threads, buffers,
etc)
%) User application( 4a*es user
interface for friendly communication
between user and de"ice Uses function
calls from B11 library only
*evice driver and installation
files
The first time we connect the USB de"ice to
the computer USB port, the operating system will
detect the de"ice and re0uest dri"er files This is
called de"ice installation !or the installation
process it is necessary not only to ma*e the
de"ice dri"er, but also an installation script in
which the installation steps are described
The de"ice dri"er for the de"ice described in
this document is made with .indows$888 BBL
(Bri"er Be"elopment Lit) The de"elopment of
the USB dri"er is based on one of the included
examples in the BBL E Iso%s! This dri"er was
modified for our purpose E +@# USB de"ice
communication &n the original source code,
parts ha"e been extended5added about the
&D'T1 communications, because our de"ice
communicates with the computer through these
&D'T1 calls To reduce the dri"er code si;e,
unused parts ha"e been remo"ed (read and
write routines) The name of the dri"er is
N+@#%89sysO and it wor*s as sender of
commands to the USB de"ice ('ontrol &>
transfers) The dri"er will wor* on all %$)bit
.indows "ersions except .in93
+n installation script written in an &>! file is
used during de"ice installation &n this &>! file the
"arious installation steps are described The file
N+@#%89infO was created in the notepad text
editor This file is re0uested by the operating
system during installation Buring the installation
process, the dri"er file is copied into the system
and the re0uired system changes are made The
&>! file ensures installation of the B11 library to
the system search path for easy reach from
"arious applications
Three files are necessary for de"ice
installation( &>! file N+@#%89infO, dri"er
N+@#%89sysO, and B11 library N+@#%89dllO
*// li!rar$
The B11 library communicates with the
de"ice dri"er and all de"ice functions are
implemented in this library This way,
programming of end)user applications is
simplified The B11 library ensures exclusi"e
access to the de"ice (seriali;es de"ice access),
contains system buffer for #S$%$ data reception,
and creates a single system thread for de"ice
#S$%$ data buffer reading
Seriali;ation in B11 ensures that only one
application5thread will communicate with the
de"ice at any gi"en time This is necessary
because of the possibility of mixing 0uestion and
answer from "arious applications at the same
time
System buffer for #S$%$ data reception
ensures that the data recei"ed from the de"ice/s
#S$%$ line is stored into one buffer that is
common to all applications This way, data
recei"ed by the de"ice will be sent to all
applications There is no danger that an
application will recei"e incomplete data because
some other application has read some of the
data before
Dnly one system thread exists for all
applications, and will periodically re0uest de"ice
for #S$%$ data The thread will then store
recei"ed data into the system buffer Dnly one
system buffer solution ensures small 'PU usage
(in comparison to e"ery application ha"ing their
own thread) and simplifies storing data into the
system buffer
+ll de"ice functions are defined in the B11
library, and they are exported in a user)friendly
form( not as function number and parameters,
but as tidy function names with parameters
Some functions are more complex internally, as
the function for #S$%$ buffer data read This
way, de"elopers of end)user applications can
rapidly write application using only the B11
interface There is no need to study the low)le"el
de"ice functions, as the B11 library separates
the application programmer le"el from the
hardware le"el
+ll functions exported from B11 are
described bellow The declaration is written for
the % mostly used programming languages(
Borland Belphi, 'CC (Borland or 4icrosoft) and
@isual Basic + more detailed description of
these functions can be found in the included help
file +@#%89QB11Qhelphtm
%'RT speed error discussion
4icrocontroller uses 2$46; cloc* because
the USB sampling But using this cloc* "alue has
disad"antage that baudrate speed generating
contains small error for the standard baudrates
But high "alue of cloc* minimi;es this error
4aximum error that can be accepted in baudrate
generation is cca 7R( because maximum error is
half bit duration (83) and the maximum pac*et
time is 2$bits : 2start bit C -data bits C 2parity
bit C $stop bits Then the error is( 8352$S288R :
72R
!unction in B11 automatically chec*s this
error and set baudrate to microcontroller only if
the error is bellow 7R (and returns error in case
of unsupported baudrate)
&n the next table is summari;ed the error of
standard baudrates in case of use 2$46; cloc*
Standard
&audrates
Baudrate in
AVR
7rror CDE
<88 <8$ C8%%
2$88 2$87 C8%%
$788 $78- C8%%
7-88 7-8- C82H
9<88 9<2< C82H
29$88 29$%8 C82<
$--88 $--7< C82<
%-788 %-7<$ C82<
3H<88 3H<9$ C82<
223$88 223%-7 C82<
Table 4: AVR UART baudrate errors (12MHz
clock)
Function prototype in "AVR309.dll" library:
Delphi:
25&4$
AVR309DLL? FAVR30!C099FG
//return values from AVR309DLL functions:
NO!RROR ? 0G
D!V"C!NO#$R!%!N# ? 1G
NODA#AAVA"LA&L! ? 2G
"NVAL"D&A'DRA#! ? 3G
OV!RR'N!RROR ? 4G
"NVAL"DDA#A&"#% ? 5G
"NVAL"D$AR"#( ? 6G
"NVAL"D%#O$&"#% ? 7G
7u&2$%5& DoGetInfraCode8:/3 TimeCodeDiagramEarray of byteG :/3 DiagramLengtEinteer;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$I&73/C50-FG
7u&2$%5& DoSetData!ortDire"tion8Direction!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$D/$/P53$D%3-2$%5&FG
7u&2$%5& DoGetData!ortDire"tion8:/3 DataDirection!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$D/$/P53$D%3-2$%5&FG
7u&2$%5& DoSet#$tData!ort8Data"ut!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$"u$D/$/P53$FG
7u&2$%5& DoGet#$tData!ort8:/3 Data"ut!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$"u$D/$/P53$FG
7u&2$%5& DoGetInData!ort8:/3 Data#n!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$I&D/$/P53$FG
7u&2$%5& DoSetData!ortDire"tion%8Direction!yte!= Direction!yteC= Direction!yteD= $%ed&ort%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,-
FD5S-$D/$/P53$D%3-2$%5&4FG
7u&2$%5& DoGetData!ortDire"tio n%8:/3 DataDirection!yte!= Direction!yteC= Direction!yteD= $%ed&ort%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,-
FD5G-$D/$/P53$D%3-2$%5&4FG
7u&2$%5& DoSet#$tData!ort%8Data"ut!yte!= Data"ut!yteC= Data"ut!yteD= $%ed&ort%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$"u$D/$/P53$4FG
7u&2$%5& DoGet#$tData!ort%8:/3 Data"ut!yte!= Data"ut!yteC= Data"ut!yteD= $%ed&ort%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,-
FD5G-$"u$D/$/P53$4FG
7u&2$%5& DoGetInData!ort%8:/3 Data#n!yte!= Data#n!yteC= Data#n!yteD= $%ed&ort%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$I&D/$/P53$4FG
7u&2$%5& Do&&!R#'Read8Addre%%E(ordG :/3 Data#n!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5**PR"MR-/0FG
7u&2$%5& Do&&!R#')rite8Addre%%E(ordG Data"ut!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5**PR"M63%$-FG
7u&2$%5& DoRS232Send8Data"ut!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5RS232S-&0FG
7u&2$%5& DoRS232Read8:/3 Data#n!yteEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5RS232R-/0FG
7u&2$%5& DoSetRS232*a$d8!audRateEinteer;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$RS232B/u0FG
7u&2$%5& DoGetRS232*a$d8:/3 !audRateEinteer;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$RS232B/u0FG
7u&2$%5& DoGetRS232*$ffer8:/3 R'(3(!u))erEarray of byteG :/3 R'(3(!u))erLengtEinteer;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$RS232Bu77-3FG
7u&2$%5& DoRS232*$fferSend8:/3 R'(3(!u))erEarray of byteG :/3 R'(3(!u))erLengtEinteer;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5RS232Bu77-3S-&0FG
7u&2$%5& DoSetRS232Data*it%8Data!it%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$RS232D/$/B%$4FG
7u&2$%5& DoGetRS232Data*it%8:/3 Data!it%Ebyte;E%&$-.-3G 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$RS232D/$/B%$4FG
7u&2$%5& DoSetRS232!arity8&arityEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$RS232P/3%$'FG
7u&2$%5& DoGetRS232!arity8:/3 &arityEbyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$RS232P/3%$'FG
7u&2$%5& DoSetRS232Stop*it%8'top!it%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5S-$RS232S$5<B%$4FG
7u&2$%5& DoGetRS232Stop*it%8:/3 'top!it%Ebyte;EinteerG 4$02/99 -($-3&/9 AVR309DLL &/,- FD5G-$RS232S$5<B%$4FG
C++ *$ilder + 'i"ro%oft Vi%$al C++:
H%70-7 II2<9u4<9u4
-($-3& JCJ K
H-&0%7
H0-7%&- AVR309DLL JAVR30!C099JG
//return values from AVR309DLL functions:
H0-7%&- NO!RROR 0G
H0-7%&- D!V"C!NO#$R!%!N# 1G
H0-7%&- NODA#AAVA"LA&L! 2G
H0-7%&- "NVAL"D&A'DRA#! 3G
H0-7%&- OV!RR'N!RROR 4G
H0-7%&- "NVAL"DDA#A&"#% 5G
H0-7%&- "NVAL"D$AR"#( 6G
H0-7%&- "NVAL"D%#O$&"#% 7G
int II4$02/99 DoGetInfraCode8$"har L TimeCodeDiagram= int Dummy#nt= int , DiagramLengt;G
int II4$02/99 DoSetData!ortDire"tion8$"har Direction!yte;G
int II4$02/99 DoGetData!ortDire"tion8$"har , DataDirection!yte;G
int II4$02/99 DoSet#$tData!ort8$"har Data"ut!yte;G
int II4$02/99 DoGet#$tData!ort8$"har , Data"ut!yte;G
int II4$02/99 DoGetInData!ort8$"har , Data#n!yte;G
int II4$02/99 DoSetData!ortDire"tion%8$"har Direction!yte!= $"har Direction!yte= $"har Direction!yte= $"har $%ed&ort%;G
int II4$02/99 DoGetData!ortDire"tion%8$"har , DataDirection!yte!= $"har , DataDirection!yteC= $"har , DataDirection!yteD= $"har , $%ed&ort%;G
int II4$02/99 DoSet#$tData!ort%8$"har Data"ut!yte!= $"har Data"ut!yteC= $"har Data"ut!yteD= $"har $%ed&ort%;G
int II4$02/99 DoGet#$tData!ort%8$"har , Data"ut!yte!= $"har , Data"ut!yteC= $"har , Data"ut!yteD= $"har , $%ed&ort%;G
int II4$02/99 DoGetInData!ort%8$"har , Data#n!yte!= $"har , Data#n!yteC= $"har , Data#n!yteD= $"har , $%ed&ort%;G
int II4$02/99 Do&&!R#'Read8$%hort Addre%%= $"har , Data#n!yte;G
int II4$02/99 Do&&!R#')rite8$%hort Addre%%= $"har Data"ut!yte;G
int II4$02/99 DoRS232Send8$"har Data"ut!yte;G
int II4$02/99 DoRS232Read8$"har , Data#n!yte;G
int II4$02/99 DoSetRS232*a$d8int !audRate;G
int II4$02/99 DoGetRS232*a$d8int , !audRate;G
int II4$02/99 DoGetRS232*$ffer8$"har L R'(3(!u))er= int Dummy#nt= int , R'(3(!u))erLengt;G
int II4$02/99 DoRS232*$fferSend8$"har L R'(3(!u))er= int Dummy#nt= int , R'(3(!u))erLengt;G
int II4$02/99 DoSetRS232Data*it%8$"har Data!it%;G
int II4$02/99 DoGetRS232Data*it%8$"har L Data!it%;G
int II4$02/99 DoSetRS232!arity8$"har &arity;G
int II4$02/99 DoGetRS232!arity8$"har L &arity;G
int II4$02/99 DoSetRS232Stop*it%8$"har 'top!it%;G
int II4$02/99 DoGetRS232Stop*it%8$"har L 'top!it%;G
H%70-7 II2<9u4<9u4
M
H-&0%7
Vi%$al *a%i":
Pu19%2 C5&4$ AVR309DLL?JAVR30!C099JG
)return values from AVR309DLL functions:
Pu19%2 C5&4$ NO!RROR ? 0G
Pu19%2 C5&4$ D!V"C!NO#$R!%!N# ? 1G
Pu19%2 C5&4$ NODA#AAVA"LA&L! ? 2G
Pu19%2 C5&4$ "NVAL"D&A'DRA#! ? 3G
Pu19%2 C5&4$ OV!RR'N!RROR ? 4G
Pu19%2 C5&4$ "NVAL"DDA#A&"#% ? 5G
Pu19%2 C5&4$ "NVAL"D$AR"#( ? 6G
Pu19%2 C5&4$ "NVAL"D%#O$&"#% ? 7G
Pu19%2 D-29/3- +u&2$%5& DoGetInfraCode L%1 JAVR30!C099J 8B'R-7 TimeCodeDiagram A% Any= B'V/9 Dummy#nt A% Lon= B'R-7 DiagramLengt A% Lon; A%
Lon
Pu19%2 D-29/3- +u&2$%5& DoSetData!ortDire"tion L%1 JAVR30!C099J 8B'V/9 Direction!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetData!ortDire"tion L%1 JAVR30!C099J 8B'R-7 DataDirection!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSet#$tData!ort L%1 JAVR30!C099J 8B'V/9 Data"ut!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGet#$tData!ort L%1 JAVR30!C099J 8B'R-7 Data"ut!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetInData!ort L%1 JAVR30!C099J 8B'R-7 Data#n!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSetData!ortDire"tion% L%1 JAVR30!C099J 8B'V/9 Direction!yte! A% *yte= B'V/9 Direction!yteC A% *yte= B'V/9 Direction!yteD A%
*yte= B'V/9 $%ed&ort% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetData!ortDire"tion% L%1 JAVR30!C099J 8B'R-7 DataDirection!yte! A% *yte= B'R-7 DataDirection!yteC A% *yte= B'R-7
DataDirection!yteD A% *yte= B'R-7 $%ed&ort% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSet#$tData!ort% L%1 JAVR30!C099J 8B'V/9 Data"ut!yte! A% *yte= B'V/9 Data"ut!yteC A% *yte= B'V/9 Data"ut!yteD A% *yte=
B'V/9 $%ed&ort% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGet#$tData!ort% L%1 JAVR30!C099J 8B'R-7 Data"ut!yte! A% *yte= B'R-7 Data"ut!yteC A% *yte= B'R-7 Data"ut!yteD A% *yte=
B'R-7 $%ed&ort% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetInData!ort% L%1 JAVR30!C099J 8B'R-7 Data#n!yte! A% *yte= B'R-7 Data#n!yteC A% *yte= B'R-7 Data#n!yteD A% *yte= B'R-7
$%ed&ort% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& Do&&!R#'Read L%1 JAVR30!C099J 8B'V/9 Addre%% A% )ord= B'R-7 Data#n!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& Do&&!R#')rite L%1 JAVR30!C099J 8B'V/9 Addre%% A% )ord= B'V/9 Data"ut!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoRS232Send L%1 JAVR30!C099J 8B'V/9 Data"ut!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoRS232Read L%1 JAVR30!C099J 8B'R-7 Data#n!yte A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSetRS232*a$d L%1 JAVR30!C099J 8B'V/9 !audRate A% Lon; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetRS232*a$d L%1 JAVR30!C099J 8B'R-7 !audRate A% Lon; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetRS232*$ffer L%1 JAVR30!C099J 8B'R-7 R'(3(!u))er A% Any= B'V/9 Dummy#nt A% Lon= B'R-7 R'(3(!u))erLengt A% Lon; A%
Lon
Pu19%2 D-29/3- +u&2$%5& DoRS232*$fferSend L%1 JAVR30!C099J 8B'R-7 R'(3(!u))er A% Any= B'V/9 Dummy#nt A% Lon= B'R-7 R'(3(!u))erLengt A% Lon;
A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSetRS232Data*it% L%1 JAVR30!C099J 8Data!it% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetRS232Data*it% L%1 JAVR30!C099J 8B'R-7 Data!it% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSetRS232!arity L%1 JAVR30!C099J 8&arity A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetRS232!arity L%1 JAVR30!C099J 8B'R-7 &arity A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoSetRS232Stop*it% L%1 JAVR30!C099J 8'top!it% A% *yte; A% Lon
Pu19%2 D-29/3- +u&2$%5& DoGetRS232Stop*it% L%1 JAVR30!C099J 8B'R-7 'top!it% A% *yte; A% Lon
End user application
The end)user application will only use
functions from the B11 library to communicate
with the de"ice &ts main purpose is to ma*e a
user)friendly AU& (graphical user interface)
+pplication programmers use the B11 library
to write their own applications +n example can
be found in the published proTect where all the
source code is a"ailable 4any applications can
be written using this example as starting point,
and in se"eral programming languages (Belphi,
'CC, @isual Basic)
There is included an example of an end user
application called N+@#%89demoexeO This
software is only meant as an example on how to
use the functions from the B11 library The
source code can be used as a template for other
applications
Appendi1 A: Source code of firmware for ATme3a5 AVR
Source code of firmware for +Tmega- +@# microcontroller was written in +@# Studio 7 Source code is in text file
USBto#S$%$asm or in syntax highlighted form file USBto#S$%$asmpdf
Appendi1 B: '8R70:;dll interface
1ibrary +R3./-d!! was written in Belphi% therefore its source code is based on 'b0ect Pasca! language But in the next
is described interface also for other programming languages( 1e!p%i, C2C33 and isua! Basic
&nterface to B11 library (exported functions) N+@#%89dllO are described in file +@#%89QB11Qhelphtm
Appendi1 <: 6 li&rar, '8R70:;dll source code
.hole source code of +@#%89dll library written in Belphi% is in file +@#%89dpr (Belphi% proTect)
Appendi1 6: 7nd user application e1ample 4 '8R70:%S&demo;e<e !wit) source
code(
=xample of using B11 library from end user application is software +@#%89USBdemoexe .hole source codes as
Belphi% proTect of this example application( +@#%89USBdemodpr
Used documentation and resources
>$$<E//BBBC2-4)5C>54$C4) - /u$>534 B-1 </.-4 /&0 :/3%5u4 <35N-2$4
%S& related resources"
I8J http(55wwwusborg ) USB specification and another USB related resources
I8J us&4in4a4nuts)ell#pdf from http(55wwwbeyondlogicorg5usbnutshell5usb)in)a)nutshellpdf ) "ery
good and simple document how USB wor*s
I8J http(55wwwbeyondlogicorg ) USB related resources
I8J enumeration#pdf ) exact pictures how USB enumeration wor*s
I8J http(55mesloyolaedu5faculty5phs5usb2html
I8J http(55wwwmcuc; ) USB section (in ';ech5Slo"a* language)
I8J crcdes#pdf E implementation '#' in USB
I8J USBspec"4"#pdf E USB 22 specification
I8J us&F*0#pdf E USB $8 specification
'8R related resources"
I8J http(55wwwatmelcom ) +@# -)bit microcontrollers family
I8J doc0539#pdf E +T98S$%2% datasheet (U#1 http(55wwwatmelcom5atmel5acrobat5doc8-%9pdf )
I8J doc*G5H#pdf E +Tmega- datasheet
I8J avr9"0#pdf E +@# &SP programming
I8J http(55wwwa"rfrea*scom ) a lot of +@# resources and information
I8J AVR Studio G E debugging tool for the +@# family (from http(55wwwatmelcom)
I8J Simple 8T +S8 pro3rammer (http(55wwwhwc;5products5lptQispQprog5indexhtml)
*river related resources"
I8J http(55wwwbeyondlogicorg ) USB related resources about USB dri"ers
I8J http(55wwwcypresscom ) fully documented USB dri"er (for USB thermometer)
I8J http(55wwwTungocom ) 9in6river and @ernet6river E easy to use USB dri"ers
I8J http(55microsoftcom 4icrosoft .indows BBL E Bri"er Be"elopment Lit E tools for dri"ers writing
+uthor(
In- Ior Ce%.o
Slo/a.ia
(((-"e%.o-ho%t-%.
"e%.o0internet-%.