baud rate autodetection on AVR 8-bit?

On Monday, December 17, 2012 7:32:24 AM UTC-8, Mel Wilson wrote:
> 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.
> 

There are Atmel and LUFA USB stacks for AVR and Microchip stacks for PICs.  You don't have to write them, just use them.

On Mon, 17 Dec 2012 13:27:53 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> 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.
>
>> 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.

Thanks, Simon. I agree with you about posting on here about
this subject when the time comes. I will air my ignorance and
take all the abuse, if any, with good nature. My interest is
to learn.

Yes, I'd like to actually do all of the detailed work
involved of writing everything. I'm not interested in just
using someone's library, except perhaps as another technical
reference "book" I can study along with the spec. There is
nothing quite as good at teaching all of the details. Once I
know them, I can then __intelligently__ make decisions about
what some minimal implementation can be for some application.
There are times when I may not be able to afford a "library"
and need to know if I can do with less. Just using a library
will never enable that kind of knowledge.

And thanks for the above writing, as well. That will give me
a leg up, as well.

Jon

On Mon, 17 Dec 2012 12:03:22 -0800, I wrote:

>Thanks, Simon. I agree with you about posting on here about
>this subject when the time comes. I will air my ignorance and
>take all the abuse, if any, with good nature. My interest is
>to learn.
>
>Yes, I'd like to actually do all of the detailed work
>involved of writing everything. I'm not interested in just
>using someone's library, except perhaps as another technical
>reference "book" I can study along with the spec. There is
>nothing quite as good at teaching all of the details. Once I
>know them, I can then __intelligently__ make decisions about
>what some minimal implementation can be for some application.
>There are times when I may not be able to afford a "library"
>and need to know if I can do with less. Just using a library
>will never enable that kind of knowledge.
>
>And thanks for the above writing, as well. That will give me
>a leg up, as well.

Oh, and although I know that some of this can be done using
HID drivers written already for linux or Microsoft's O/S, I
am also interested in the work involved on the host side. But
I'll start on the slave side. It is just that I may want to
write a host side implementation for embedded use, too. There
are those occasional times when that would be a "nice to
have" for hobby work so that I could attach keyboards, for
example.

Jon

On Mon, 17 Dec 2012 12:17:55 -0800
Jon Kirwan <jonk@infinitefactors.org> wrote:

> Oh, and although I know that some of this can be done using
> HID drivers written already for linux or Microsoft's O/S, I
> am also interested in the work involved on the host side. But
> I'll start on the slave side. It is just that I may want to
> write a host side implementation for embedded use, too. There
> are those occasional times when that would be a "nice to
> have" for hobby work so that I could attach keyboards, for
> example.

I definitely recommend NOT trying to solve both halves of the problem
(device side and host side) at the same time! Start out building a
device. Get it to enumerate and show up in lsusb (or the equivalent for
a different OS). Then start talking to it with user-space host-side
software via libusb. Then decide whether you want to move to
implementing a standard device class if it makes sense for your device,
write a kernel-mode OS driver, or just stick with libusb.

Chris

On Mon, 17 Dec 2012 23:36:48 -0800, Christopher Head
<chead@is.invalid> wrote:

>On Mon, 17 Dec 2012 12:17:55 -0800
>Jon Kirwan <jonk@infinitefactors.org> wrote:
>
>> Oh, and although I know that some of this can be done using
>> HID drivers written already for linux or Microsoft's O/S, I
>> am also interested in the work involved on the host side. But
>> I'll start on the slave side. It is just that I may want to
>> write a host side implementation for embedded use, too. There
>> are those occasional times when that would be a "nice to
>> have" for hobby work so that I could attach keyboards, for
>> example.
>
>I definitely recommend NOT trying to solve both halves of the problem
>(device side and host side) at the same time! Start out building a
>device. Get it to enumerate and show up in lsusb (or the equivalent for
>a different OS).

Yeah, I think I know that much, ignorant as I am otherwise
about USB.  ;)

>Then start talking to it with user-space host-side
>software via libusb.

Hmm.

>Then decide whether you want to move to
>implementing a standard device class if it makes sense for your device,
>write a kernel-mode OS driver, or just stick with libusb.
>
>Chris

Doesn't sound like where I'd like to be. I am thinking, say,
about hooking up a standard, cheap, PC keyboard to a ...
well, let's say an MSP430 with ... let's give it 16k flash
and 512 bytes sram total. Hmm. There are six different ones
with that spec. Three at $1 and three at $2.

Any chance? It is just a keyboard, after all.

Jon

On 2012-12-18, Jon Kirwan <jonk@infinitefactors.org> wrote:
>
> Doesn't sound like where I'd like to be. I am thinking, say,
> about hooking up a standard, cheap, PC keyboard to a ...
> well, let's say an MSP430 with ... let's give it 16k flash
> and 512 bytes sram total. Hmm. There are six different ones
> with that spec. Three at $1 and three at $2.
>
> Any chance? It is just a keyboard, after all.
>

I have not done anything with the HID layer yet so I don't have a
feeling for what is involved there. However, Microchip have fitted
both a CDC layer and a HID layer (to control GPIO lines, not a
keyboard) into it's MCP2200 device. The MCP2200 is widely reported
to just be a PIC18F14K50 with custom Microchip firmware.

I don't know how the code density of the PIC18 compares with the MSP430
but that should give you a feeling for what is possible on the PIC18.

Note that this does not take into account the additional code needed to
poll the keyboard and also note the PIC18F14K50, when you add in the 256
bytes of USB RAM in bank 2, has 768 bytes of SRAM in total compared to
the 512 bytes you mention above for your MSP430 device.

Here is Microchip's PIC18F14K50 page so you can compare it to your
MSP430 device:

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en533924

I am not familiar with the MSP430 range. Is the USB device controller
in the MSP430 you are looking at a high speed, full speed or a low
speed controller ?

I see TI have a PDF writeup about creating a USB keyboard using a full
speed MSP430 device connected to a keyboard:

http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=slaa514&fileType=pdf

Simon.

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

On Tuesday, December 18, 2012 8:54:00 PM UTC+13, Jon Kirwan wrote:
> 
> Doesn't sound like where I'd like to be. I am thinking, say,
> about hooking up a standard, cheap, PC keyboard to a ...
> well, let's say an MSP430 with ... let's give it 16k flash
> and 512 bytes sram total. Hmm. There are six different ones
> with that spec. Three at $1 and three at $2.
> 
> Any chance? It is just a keyboard, after all.

Hi Jon, 

Sure, just wiggle the lines for PS/2 mode, which you can hope is still there somewhere in the corner of the silicon ;)

Otherwise, you need a USB HOST capable uC, and they are still not 'bottom end' parts.

Cheapest mini host is OTG, and Digikey says PIC32 is lowest cost stocked version.
See also 
http://ww1.microchip.com/downloads/en/DeviceDoc/USB_OTG_ver_1.0.pdf

-jg

On Tue, 18 Dec 2012 14:04:30 -0800 (PST),
j.m.granville@gmail.com wrote:

>On Tuesday, December 18, 2012 8:54:00 PM UTC+13, Jon Kirwan wrote:
>> 
>> Doesn't sound like where I'd like to be. I am thinking, say,
>> about hooking up a standard, cheap, PC keyboard to a ...
>> well, let's say an MSP430 with ... let's give it 16k flash
>> and 512 bytes sram total. Hmm. There are six different ones
>> with that spec. Three at $1 and three at $2.
>> 
>> Any chance? It is just a keyboard, after all.
>
>Hi Jon, 
>
> Sure, just wiggle the lines for PS/2 mode, which you can
> hope is still there somewhere in the corner of the silicon
> ;)

Presume it is a new keyboard that doesn't support PS/2 mode.

>Otherwise, you need a USB HOST capable uC, and they are still not 'bottom end' parts.

But I think, if all I need is a stripped down host support
for a keyboard then perhaps I can fit it. The question is
about knowledge to know for sure.

>Cheapest mini host is OTG, and Digikey says PIC32 is lowest cost stocked version.
>See also 
>http://ww1.microchip.com/downloads/en/DeviceDoc/USB_OTG_ver_1.0.pdf

Nah. Not going there for just adding a keyboard. I'd find
another way for some of the cheap stuff I'm thinking about.

I'm interested in seeing if I can get to the point where I
can code up a keyboard-minimal version of USB hosting on a
small proc. May be impossible. But by the time I can say,
from personal knowledge, that it is impossible I will know a
lot more about USB. ;)

Jon

On Tue, 18 Dec 2012 14:13:46 -0800
Jon Kirwan <jonk@infinitefactors.org> wrote:

> But I think, if all I need is a stripped down host support
> for a keyboard then perhaps I can fit it. The question is
> about knowledge to know for sure.

Code-wise, supporting just keyboards is certainly easier than supporting
a wider variety of devices, and if you use BOOTP, even easier than
supporting a full variety of *input* devices. BOOTP is a simplified
form of HID protocol intended for use by things like embedded systems
and BIOS configuration menus; keyboards (and I think mice) support it.
However, you will still need "full" host support at the hardware level.
This is a property of USB: the hardware for a host is somewhat
different to (and bigger than) the hardware for a device. It&rsquo;s not
physically possible to take a chip that does device mode only and hack
around it to do any kind of host mode. I&rsquo;m afraid I&rsquo;m not familiar with
the MSP430 series, but I do know that the STM32F4 series does host
mode, as do some of the higher-end PICs (which jg mentioned). You sound
like you&rsquo;re looking for something pretty low-end, though, and I agree
with jg, you&rsquo;re unlikely to find such a chip.

You are right that my advice earlier about using libusb sounded
completely wrong. I thought you were trying to build a USB device, not
a USB host. They&rsquo;re very different problems, so ignore my earlier
message!

Chris

On 2012-12-19, Christopher Head <chead@is.invalid> wrote:
>
> You are right that my advice earlier about using libusb sounded
> completely wrong. I thought you were trying to build a USB device, not
> a USB host. They?re very different problems, so ignore my earlier
> message!
>

That's exactly what I thought as well and it's what my responses have
been assuming. When Jon then talked about adding a keyboard, I thought
he was planning to learn about USB by combining a PS/2 (or similar)
keyboard with a USB device capable MCU to create a USB based keyboard.
Now I don't know. :-)

Jon, are you planning to connect a PS/2 type keyboard to a MSP430 and
then create a USB keyboard for use with a host PC or are you wanting to
take a USB keyboard and connect it to a MSP430 with the final destination
target for the keystrokes been a program running on the MSP430 itself ?

If it's the former, you only need a MCU with USB device support and there
are plenty of those. If it's the latter, then as already mentioned you
are going to need to a MCU with USB host capability and the most hobbyist
or student friendly of those (if they are building their own circuits)
is probably the PIC32MX.

I do know there's a AVR based software-only USB stack but it is USB device
only and only supports low speed connectiosn to a host PC; it does not
have any host support.

Simon.

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