baud rate autodetection on AVR 8-bit?

In article <kafp1t$79j$1@dont-email.me>, 
clubley@remove_me.eisner.decus.org-Earth.UFP says...
> 
> On 2012-12-14, Ivan Shmakov <oneingray@gmail.com> wrote:
> >>>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
> >
> > [...]
> >
> > > And frankly the use of RS-232/async ports should not be a first
> > > choice these days.
> >
> > 	Given the intended application, I tend to agree -- the use of
> > 	USB would probably simplify the things there a lot.
> >
> > 	Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
> > 	perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem
> > 	to fit well, for its CDC-ACM capability is necessarily a hack.)
> > 	The best I've found so far are some STM32's for under $4.  I'd
> > 	like to see if there could be anything else at half that price.
> >
> 
> I am assuming you want USB device only. If you want USB host as well,
> try looking at the PIC32MX range to see if it's something that would
> match your requirements.
> 
> Your previous postings imply that you are doing hobbyist type work and
> you don't say what packaging you need the device in so as much as it
> pains me :-), I am going to point you to the PIC18F range if you want
> it in PDIP.
> 
> Start by looking at the PIC18F14K50. It's quite a limited device so
> you may need to look at the other options in the PIC18F range to see
> which of them also support USB device.
> 
> > 	(Though USB identifiers may become an issue.  They provide one
> > 	allowing for relatively unrestricted use with V-USB, but I don't
> > 	know what's the current practice for the MCU's with hardware USB
> > 	ports.)
> >
> 
> Since I only use them for my own projects, I just make them up. Since
> no one else uses my embedded code, I also don't know what the current
> practice is short of having to pay for formally assigned identifiers.
> 
> In the past I have heard of some manufacturers allowing you to use
> identifiers within a subset of the range assigned to the manufacturer,
> but I don't know what the current policy is.

I think FTDI still does that for their interface chips.  I once used
IDs from a subset that they assigned to me.   Now, I just use their
default IDs.  That gets a standard USB serial driver loaded under
Windows and they have a config bit that will cause their direct
driver to be loaded so that you can use their API for direct
comms with their chips.   Things got more complex under Win7x64
when it started requiring signed drivers.  Just changing IDs in
the configuration text files caused the driver to be rejected as 
unsigned.

I've used the FT245RL  FIFO-to-USB chip in a number of designs.
If you have about 12 free bits---ideally with 8 of them in
a single port---you can add USB without having to worry about
any of the USB details.  With an MSP430 at 8MHZ and a pretty
simple Windows host program I can transfer data at about
200KBytes/second.


If you need higher speed transfers, you can move up to the
UM-232H.   With that module connected to an STM32F2XX with a
hardware SDIO port, I can upload data from the SD card
at 4-6MB/second.

Mark Borgerson

>>>>> Paul  <paul@pcserviceselectronics.co.uk> writes:
>>>>> In article <86vcc4o5gb.fsf@gray.siamics.net>, oneingray@gmail.com says...
>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

[...]

 >>> Your previous postings imply that you are doing hobbyist type work
 >>> and you don't say what packaging you need the device in so as much
 >>> as it pains me :-), I am going to point you to the PIC18F range if
 >>> you want it in PDIP.

 >> My guess is that anything with 0.8 mm or larger spacing will be just
 >> fine.  0.5 mm pitch feels a bit too fine to tackle for an amateur,
 >> but I'm yet to try it myself.

 > Try getting a Schmart Board then to mount it very easily.

 > Look here http://www.schmartboard.com/

	Indeed, I've ordered some LQFP 48 to DIP break-out boards from
	http://dipmicro.com/ (I guess I'd need to wait for quite some
	time for delivery, since they're on the other side of the Earth,
	literally), not to mention that I have a couple of home-made SO
	prototyping boards, each with a TQFP 32 landing space (the
	design that could certainly be improved.)

	Yet, as I've said before, my intent is to eventually publish my
	designs for the others to use (and improve), and I'm still in
	doubt that mounting a 0.5 mm pitch IC would be an easy thing for
	a J. Random Amateur.

	But well, perhaps I'm wrong on that.

-- 
FSF associate member #7257

>>>>> Jon Kirwan <jonk@infinitefactors.org> writes:
>>>>> On Fri, 14 Dec 2012 09:18:00 -0800, Rob Gaddi wrote:
>>>>> On Fri, 14 Dec 2012 23:21:11 +0700 Ivan Shmakov wrote:

[...]

 >>> Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
 >>> perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem to
 >>> fit well, for its CDC-ACM capability is necessarily a hack.)  The
 >>> best I've found so far are some STM32's for under $4.  I'd like to
 >>> see if there could be anything else at half that price.

 >> Half that price is easy, buy them at kilounit quantities.  Digikey's
 >> got the LPC1342, 250p at $2.57, and 1000p at $1.95.  If you need
 >> fewer pieces than that, then at the end of the day you're just not
 >> talking about much money as compared to the other engineering costs.

 > To Rob: The title of the thread includes the word "amateur," so
 > probably not kilounit qty.  More likely, it's more about posting up a
 > web page on some completed project or another.

	The point is that if I'd be able to get in touch with the fellow
	amateurs in my vicinity, then we'd probably "waste" a few dozens
	of chips together, in relatively short time.  1000 PCS of any
	given IC would most probably be beyond our demands.

 > To OP: For a cheap hobbyist one-off with USB connection I'll probably
 > just grab an MSP430 LaunchPad off the shelf if the application idea
 > fits.  It's already got connectors for a daughterboard, the cpu is
 > socketed, comes with two cpus,

	Somehow, I was unable to find out what exactly comes with this
	board?  But given the price, it indeed looks like a nice thing
	to have.

 > a 32kHz xtal, two different colored LEDs, two different pushbuttons,
 > a USB cable, and uses RS232 between the target and the host via USB.

	Does that mean CDC ACM?  Or that the board includes an USB to
	Serial (UART) converter (which is TUSB3410, I guess)?

 > It is $4.30, good tools are available, and most anyone can easily get
 > one.

	... But what surprises me is that while one can get this one for
	under $5, the TUSB3410 chip alone costs over $6.

 > You still write simple rs232 drivers that way, as well.

-- 
FSF associate member #7257

On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov
<oneingray@gmail.com> wrote:

>>>>>> Jon Kirwan <jonk@infinitefactors.org> writes:
>>>>>> On Fri, 14 Dec 2012 09:18:00 -0800, Rob Gaddi wrote:
>>>>>> On Fri, 14 Dec 2012 23:21:11 +0700 Ivan Shmakov wrote:
>
>[...]
>
> >>> Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
> >>> perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem to
> >>> fit well, for its CDC-ACM capability is necessarily a hack.)  The
> >>> best I've found so far are some STM32's for under $4.  I'd like to
> >>> see if there could be anything else at half that price.
>
> >> Half that price is easy, buy them at kilounit quantities.  Digikey's
> >> got the LPC1342, 250p at $2.57, and 1000p at $1.95.  If you need
> >> fewer pieces than that, then at the end of the day you're just not
> >> talking about much money as compared to the other engineering costs.
>
> > To Rob: The title of the thread includes the word "amateur," so
> > probably not kilounit qty.  More likely, it's more about posting up a
> > web page on some completed project or another.
>
>	The point is that if I'd be able to get in touch with the fellow
>	amateurs in my vicinity, then we'd probably "waste" a few dozens
>	of chips together, in relatively short time.  1000 PCS of any
>	given IC would most probably be beyond our demands.

yeah, that's about where my mind was at after reading what
you were saying. Rob is a sharp person, but I didn't think
Rob had noticed your context -- or, if he had, had discounted
it for other reasons when he wrote, "If you need fewer
pieces than that, then at the end of the day you're just not
talking about much money as compared to the other engineering
costs." It's spoken from a professional perspective, but one
that has long since fogotten their roots and/or hobbyist
perspectives.

> > To OP: For a cheap hobbyist one-off with USB connection I'll probably
> > just grab an MSP430 LaunchPad off the shelf if the application idea
> > fits.  It's already got connectors for a daughterboard, the cpu is
> > socketed, comes with two cpus,
>
>	Somehow, I was unable to find out what exactly comes with this
>	board?  But given the price, it indeed looks like a nice thing
>	to have.

You get:
&bull;    Nice box
&bull;    Paperwork
&bull;    &frac12; m USB cable
&bull;    Microcrystal MS3V-T1R tuning fork 32.768kHz crystal
&bull;    MSP430G2231 cpu, DIP
&bull;    MSP430G2211 cpu, DIP
&bull;    LaunchPad board, which includes a USB to host section
and a developer section with socket for cpu, two pushbuttons
for user use (as well as reset), two leds, one green, one
red, jumpers for enabling and disabling features, a special
interface for using the board to program target boards as
well (6-pin EZ430 connector), a power connector for your use
to run the board, and of course a USB connector
&bull;    four headers for daughter card extensions, 2 male-female
and 2 male-male

You can look for the documents, SLAU318 and the "Student
guide and Lab manual" for the LaunchPad (I don't know the
number for that one.)

There are two pins (dedicated if you want, or reusable for
any reason you want by pulling two jumpers) used for RxD and
TxD that talk with the USB section of the board. That section
then communicates with the host by setting up a HID virtual
COM port, automatically. Any serial port software can talk
with it.

> > a 32kHz xtal, two different colored LEDs, two different pushbuttons,
> > a USB cable, and uses RS232 between the target and the host via USB.
>
>	Does that mean CDC ACM?  Or that the board includes an USB to
>	Serial (UART) converter (which is TUSB3410, I guess)?

Not sure what CDC ACM means. I'm sorry. But yes, I think it
uses the TUSB3410 chip plus another dedicated MSP430 as well
to run it and communicate with your target processor.

> > It is $4.30, good tools are available, and most anyone can easily get
> > one.
>
>	... But what surprises me is that while one can get this one for
>	under $5, the TUSB3410 chip alone costs over $6.

Yeah. I know. And you can get completed AD9850 boards from
ebay for way less than you can buy an AD9850 chip, too.
Regardless, that's one reason this board is such a steal of a
deal. I've used it as the base of several successful projects
-- the first of which was snap onto a parallel-port printer
output of a device and to convert the output into a text file
on the PC, via the USB interface. Used both cpus for that
one, one to handle the parallel port interface comms and the
other to handle the rs-232 section, and using a versatile
protocol in between the two for synchronization and
buffering.

Jon

> > You still write simple rs232 drivers that way, as well.

On 2012-12-14, Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
> > The AT90USB162-16AU comes in a TQFP 0.8mm pitch package according to
> > Atmel's summary PDF; the Farnell UK price seems reasonable at qty 10,
>
> 	As it seems, ATmega8U2/TQFP is available at the same price.  Any
> 	specific reason to prefer one over the other?
>

Sorry, but I have no experience with the USB capable AVRs. I only know
about them because I have seen them mentioned while working with other
AVRs.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov
><oneingray@gmail.com> wrote:
>>
>>	Does that mean CDC ACM?  Or that the board includes an USB to
>>	Serial (UART) converter (which is TUSB3410, I guess)?
>
> Not sure what CDC ACM means. I'm sorry. But yes, I think it
> uses the TUSB3410 chip plus another dedicated MSP430 as well
> to run it and communicate with your target processor.
>

CDC ACM is the standards based way to implement a serial port over USB.

Many vendors (ie: FTDI and Prolific [PL-2303]) implement serial ports
over USB by using their own protocols which (a) require you to install a
driver on the host PC and (b) for which the specifications are not freely
available unless you sign a NDA.

However, the USB specifications include the Communications Device Class
(CDC) which has implemented within it the Abstract Control Model (ACM)
and which can be used to implement a serial port. It's main limitation
(for me) is that there's no way to signal CTS changes from the device
attached to the USB serial port back to the host PC.

The way Microchip (for example) appear to handle the problem in their
MCP2200 USB serial port is to implement the RTS/CTS handling on the
MCP2200 itself instead of passing the CTS signal back to the host PC.
They appear to have a out-of-band mechanism by which a host PC
configuration utility can turn on and off RTS/CTS flow control handling
on the MCP2200.

I also have implemented a CDC ACM driver within my own USB device stack
and when I add RTS/CTS flow control to it, I also plan to handle the
flow control on the USB device itself, so in practice, I don't see this
as been a major issue for at least some usage patterns.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Mon, 17 Dec 2012 00:53:21 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>> On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov
>><oneingray@gmail.com> wrote:
>>>
>>>	Does that mean CDC ACM?  Or that the board includes an USB to
>>>	Serial (UART) converter (which is TUSB3410, I guess)?
>>
>> Not sure what CDC ACM means. I'm sorry. But yes, I think it
>> uses the TUSB3410 chip plus another dedicated MSP430 as well
>> to run it and communicate with your target processor.
>>
>
>CDC ACM is the standards based way to implement a serial port over USB.
>
>Many vendors (ie: FTDI and Prolific [PL-2303]) implement serial ports
>over USB by using their own protocols which (a) require you to install a
>driver on the host PC and (b) for which the specifications are not freely
>available unless you sign a NDA.
>
>However, the USB specifications include the Communications Device Class
>(CDC) which has implemented within it the Abstract Control Model (ACM)
>and which can be used to implement a serial port. It's main limitation
>(for me) is that there's no way to signal CTS changes from the device
>attached to the USB serial port back to the host PC.
>
>The way Microchip (for example) appear to handle the problem in their
>MCP2200 USB serial port is to implement the RTS/CTS handling on the
>MCP2200 itself instead of passing the CTS signal back to the host PC.
>They appear to have a out-of-band mechanism by which a host PC
>configuration utility can turn on and off RTS/CTS flow control handling
>on the MCP2200.
>
>I also have implemented a CDC ACM driver within my own USB device stack
>and when I add RTS/CTS flow control to it, I also plan to handle the
>flow control on the USB device itself, so in practice, I don't see this
>as been a major issue for at least some usage patterns.

I think I may like to discuss this subject at more length,
sometime soon. I'm actually interested in the details (data
structures that must be used, what they are filled with, the
order of communications, etc.)

I'm currently fairly ignorant, excect from glancing through
the 1000 page USB 2.0 spec -- which to my reading does not do
any tutorials on the actual data structures that a slave
device must use, nor much detail on the Windows drivers (or
Linux, freeBSD, etc) side. I know there is code out there to
read, but I'd like to get an overview of subsets, one at a
time, to consider and then master before moving on. Mostly,
it seems an all-or-nothing approach in the USB 2.0 manual --
which makes taking the time quite daunting to start out. And
I consider Jan Axelrod's book almost useless, as well.

If you would consider the idea, perhaps in a few month's time
I may want to contact you. I'd be pretty dumb, to start,
except that I have 35 years embedded programming practice --
so this would mostly be about me reading and testing and then
asking questions when I get stuck on something. (Which, at
first, I expect to be often.  sadly.)

Or perhaps there is a great forum for someone focused on
mastering various details but starting out largely ignorant
of the terms and the domain space?

Jon

On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>
> I think I may like to discuss this subject at more length,
> sometime soon. I'm actually interested in the details (data
> structures that must be used, what they are filled with, the
> order of communications, etc.)
>

Assuming I have the time available when you want to discuss this,
I don't have a problem with this. However, I think the discussion
should be in comp.arch.embedded because it could benefit others
as well. Another advantage would be that any opinions or comments
I have would also be reviewable by others here.

> I'm currently fairly ignorant, excect from glancing through
> the 1000 page USB 2.0 spec -- which to my reading does not do
> any tutorials on the actual data structures that a slave
> device must use, nor much detail on the Windows drivers (or
> Linux, freeBSD, etc) side. I know there is code out there to
> read, but I'd like to get an overview of subsets, one at a
> time, to consider and then master before moving on. Mostly,
> it seems an all-or-nothing approach in the USB 2.0 manual --
> which makes taking the time quite daunting to start out. And
> I consider Jan Axelrod's book almost useless, as well.
>

Don't focus on the size of the USB 2.0 spec; you only have to read
a few chapters of it in order to implement a USB device stack as
the spec covers physical specifications as well as hub/host requirements.
You don't need to read much of that in order to implement a device only
stack.

I found I spent the vast majority of my time in Chapters 8 and 9 along
with some dipping into Chapter 5. However, I already knew much of what
is in Chapter 5 when I started, so you may spend more time there than
I did.

I also very strongly recommend you start out with a full speed device
instead of a high speed one. This means you can ignore the high speed
specific parts of the protocol until later.

Your jumping on point for following the USB protocol at data structure
level is the SETUP packet which your device will receive from the host
as part of any operation on the control endpoint (endpoint 0). This is
in table 9.2 of section 9.3. Look at this table while reading 8.5.3
(Control Transfers) which shows how this packet fits into the scheme of
things.

Higher level protocols (such as the CDC layer) have their own data
structures and are documented in their own specifications.

When you plug your USB device into the host, the USB device controller
will be reset. When you have enabled endpoint 0 and have come out of
reset, the next thing which will happen is that you will receive a
SETUP packet from the host on endpoint 0.

Your control endpoint logic is geared around interpreting these requests
and responding to them as required. One of these requests will be for the
device descriptor which, along with the configuration/interface/endpoint
descriptors, describes your device's capabilities.

I recommend you start out by making the device descriptor a vendor specific
descriptor (table 9.8, bDeviceClass = 0xff) so that the host does not
recognise it. In this way you don't have to worry about higher level
protocols throwing requests at your device stack (at least on Linux,
I don't know about Windows), but you will still go through the process
of been asked for your descriptors, been assigned a address by the host
and been told which configuration to use.

This will allow you to start out by developing and testing the lower
levels of the USB stack without having to worry about the higher level
function layers just yet.

Be warned however, that if you want to write a USB device stack, there will
be a lot of work involved in understanding the details. Given the multiple
layers to the protocol as well as it's scope, this cannot be avoided.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley wrote:

> On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>
>> I think I may like to discuss this subject at more length,
>> sometime soon. I'm actually interested in the details (data
>> structures that must be used, what they are filled with, the
>> order of communications, etc.)
>>
> 
> Assuming I have the time available when you want to discuss this,
> I don't have a problem with this. However, I think the discussion
> should be in comp.arch.embedded because it could benefit others
> as well. Another advantage would be that any opinions or comments
> I have would also be reviewable by others here.

[ ... ]
Thanks for these tips.  I know USB is not hard because the guy working next 
to me did it, based on the implementation for PIC32.  Because he did it, I 
didn't have to.  Now on another project I have to.

	Mel.

On Sunday, December 16, 2012 4:29:21 PM UTC-8, Simon Clubley wrote:
> On 2012-12-14, Ivan Shmakov <oneingray@gmail.com> wrote:
> 
> >>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> 
> >
> 
> > > The AT90USB162-16AU comes in a TQFP 0.8mm pitch package according to
> 
> > > Atmel's summary PDF; the Farnell UK price seems reasonable at qty 10,
> 
> >
> 
> > 	As it seems, ATmega8U2/TQFP is available at the same price.  Any
> 
> > 	specific reason to prefer one over the other?
> 

Yes, i prefer to buy the newer Atmega8U2, but still have to use the old At90usb162 stocks.  Unless the older chips are much cheaper.