baud rate autodetection on AVR 8-bit?

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

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

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

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

Hmm.

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

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:

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:

Simon.

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

-jg

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

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.

version.

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

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?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?m afraid I?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?re looking for something pretty low-end, though, and I agree with jg, you?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?re very different problems, so ignore my earlier message!

Chris

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.

FTDI also do a host device - AFAIK with own processor etc - "VINCULUM" was what it used to be called.

I know that the hardware is different. That's not the issue for me. What's important is the software behind it and how complex it must be. There already are several project web sites I've visited which implement USB, monitoring the Sync Pattern in software and doing the NRZI encoding in software using standard I/O pins coupled to the required hardware for attaching to USB host ports. No hardware support is used if I understand what I've read (I may not have.)

I do NOT know if similar things can be done for a host-side implementation to support ONLY a USB-only keyboard, or not. I mean a keyboard that does NOT support PS/2 mode. (I have complete docs on doing that.) Not all keyboards support a connection via either USB or PS/2.

I already know how to talk with PS/2 (I have the original docs from IBM still and have used that information before -- did you know that the BIOS supports downloading code via the keyboard interface?)

I'm curious about the idea of supporting USB-only keyboards with processors which do not have any USB peripheral support at all. It's likely that it isn't worth the trouble in a real product, but I'm curious partly because some of the products I've worked on before succeeded because they did things with better margins, less power, and smaller size than the competition using processors that were less obvious choices.

Jon

See my response to Christopher.

No.

Yes.

I love the PIC32 processor family and am already ramping up skills there. But it is overkill for some other applications and would drive up cost, size, and power consumption to the point of killing the idea.

Yes, and there is one for a PIC16:

It's been mentioned here before. But both the AVR and PIC projects merely point in a direction. I'm curious about the more difficult question.

Jon

I mean... "No peripheral hardware support within the cpu ..."

Jon

I guess you might be able to do something like the V-USB project (the software-only device-side USB stack for AVR). Maybe you would want a bit faster CPU (just because the host-side stuff is probably a bit more complex?though it does have the advantage that a host doesn?t need to always watch the wires for traffic the way a device does), and it would not be USB compliant (because a compliant USB host must support at least low speed *and* full speed, while a device only needs to support one or the other, and you would probably only implement low speed), but in the limited case of plugging in USB keyboards, it might work. At least, you could probably get it to work with *most* keyboards.

Chris

Thanks, Chris. That doesn't say I can't do it, or that I necessarily can. But maybe. At least the door remains open, so far.

I appreciate your thoughts very much, Jon

I guess you are going to be reading the full USB spec after all. :-)

I am not familiar with the physical signalling level as you don't need that knowledge to write a USB device or host stack which uses a hardware USB controller so I will comment on some other issues.

First, are the USB keyboards you can buy today still low-speed devices or are they now full speed only devices ?

Given what I currently know, I think you can justify exploring further the idea of a software only low speed USB host, but I don't see how you can implement a full speed host in software on the types of MCUs you are talking about without some hardware support.

I've also been thinking about what steps are _required_ from the device enumeration sequence after it's attached to a host. I think it may be possible to drop the reading of the descriptors; there's certainly nothing in my device stack which _requires_ the descriptors to be read before the next stage can complete.

The values in the descriptors (for example, the configuration index) are required in later steps of the sequence, but if your host stack already has prior knowledge of the values, I don't see why it would need to read them from the keyboard's descriptors.

However, the other steps are all required. For example, during reset I configure endpoint 0, setting the address is required before you can set a configuration and the set configuration stage (at least in my stack) is where you run down the endpoint descriptors and configure the application level (ie: HID in your case) endpoints as required.

Simon.

With the currently-shipping v1.5 LaunchPad boards you get:

MSP430G2553: 16Kb FLASH, 512b RAM, UART/SPI/I2C, 8ch/10bit ADC, comparator, touch-sense enabled I/Os. MSP430G2452: 8Kb FLASH, 256b RAM, UART/SPI/I2C, 8ch/10bit ADC, comparator, touch-sense enabled I/Os.

Plus two compiler/IDE suites plus the MSP430 port of gcc.

As for USB, I'm aware of one effort in this direction:

USB v1.1 support on the MSP430 Launchpad

Hope this helps...

Frank McKenney

Thanks for the correction. I do remember, now that you bring it up, that the CPUs had changed. I just don't have any to remind me about it. Thanks!

Yes. I've been having almost nothing but trouble with IAR's on my "clean" install of Win7 Ultimate 64-bit, though. I don't know what the problem is, but I've tried it with many different LaunchPads and different USB connectors (the motherboard has a LOT of them) and I also tried doing it with the XP 32-bit VM from Microsoft running underneath without any better success (I didn't expect that to work, anyway.) On the same system, CCS does just fine. Odd thing there, _if_ both are using the same DLL (which maybe they are not.)

On a Thinkpad laptop running Win7 Professional, though, IAR works great. And on all my other machines, just fine. But they aren't 64-bit installs.

Oh, yes. Added to my USB favorites folder. I'll look it over. Thanks.

Jon

I believe they are low speed, HID. I agree completely that a full speed host would be ... difficult. ;)

Understood. Point taken.

I'll need to understand more of the spec and think a bit to see what can be done here, I suspect. But I'm keeping all this for later and, as with Chris, I very much appreciate these comments. They will most certainly help focus my attention better.

Thanks, Jon