OK. But what do you actually mean by "horse power". Sure more code space will be used by further parsing and error checking code which may exceed one COGs worth of assembler, here LMM would help. Sure more time would be taken as well, and LMM would also help.
Is it really so that the Prop, in one COG with LMM, would still not have the speed to do it?
I thought in USB everything was controlled by the host. The devices never speak unless they are spoken to. In that way can't the host be a little more leisurely? Or is there some timing in the USB spec. that would be missed?
Are devices, as exist in the wild, actually so fussy about this timing ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
In that way can't the host be a little more leisurely? Or is there some timing in the USB spec. that would be missed?
Are devices, as exist in the wild, actually so fussy about this timing ?
No, Yes, Yes.
There are specific timing requirements placed on the host pertaining to turnaround times. Devices are _required_ to treat anything outside these tolerances as an error. If you are late reading a response, or late getting a query out to a device, the device will flag that delay as an error. It's how quite a bit of the protocol is implemented. If the host receives a valid packet from the device it _must_ get a reply out in a defined period of time.
As Ale pointed out, the AVR implementation has all its packets pre-generated in ROM, it simply clocks out pre-coded arrays of bits. This is ok if you only ever want your host to talk to one particular tested variety of device and ignore any errors that may crop up, but if you want a reasonable approximation of a functioning stack then you need to be a little more clever.
It's a bit like the AVR-device stacks out there. None of them do any error checking on the incoming data, so CRC errors are silently ignored. The propeller device stack checks for all documented errors (bitstuff/overrun/16bitCRC/5bitCRC), but is still slow enough that if you were to chain 3 hubs together it would exceed the absolute maximum timing limits in the protocol. As it is if you plug it into a single hub or directly into the root hub, it will meet the absolute worst case limit requirements, but it's nowhere fast enough to meet the certification timings.
We can of course turn off CRC checking to make it much, much closer to complying timings, but then we are no better than the AVR stacks. (I have an option to turn off inbound CRC checking in the HID bootloader - for space rather than speed though).
One particular difficulty with USB is that not only does it have tight timing constraints on the low-level bit-banging but it also has timing constraints at higher levels of the protocol. Even with control over one side of the protocol ( allowing laxness there in error checking and the like ) it is still necessary to comply with the spec because that is what the other device requires. One may get lucky with particular product but cannot rely on any USB device working outside of spec.
The approach to bit-banging USB seems to be; look at what is necessary for complete compliance to the spec, realise it's too much for bit-banging or a non-dedicated controller and strip away parts until it can work, accepting loss of functionality and/or reliability along the way.
Nothing wrong with that per se but as BradC points out that does leave rather limited capabilities for what is supported, while it may work with one device it will not with another.
It's then a question of what's required, what's acceptable and what people's expectations are. I think we all know or can foresee the frustrations of, "Sure the Propeller can have a USB keyboard connected providing it's made by XYZZY Inc and manufactured between July and September 2006".
I personally think it would be acceptable to have a Propeller solution at that level, at least as proof of concept and delivering a starting point to build upon. It's real usefulness would however be in being able to reasonably easily reconfigure for other USB devices. That might be easier said than done.
My opinion is that something would be better than nothing even if a flawed design and not as robust or as flexible as it could be. Others perhaps disagree.
As the stack can (barely) handle one hub, it might be barely possible to support three USB devices at once - a mouse, a keyboard, and a serial port (two serial would be better yes I'm greedy) with one cog (+LMM) - which would be a huge win, and effectively win back two cogs for a lot of apps.
Best Regards,
Bill
BradC said...
heater said...
In that way can't the host be a little more leisurely? Or is there some timing in the USB spec. that would be missed?
Are devices, as exist in the wild, actually so fussy about this timing ?
No, Yes, Yes.
There are specific timing requirements placed on the host pertaining to turnaround times. Devices are _required_ to treat anything outside these tolerances as an error. If you are late reading a response, or late getting a query out to a device, the device will flag that delay as an error. It's how quite a bit of the protocol is implemented. If the host receives a valid packet from the device it _must_ get a reply out in a defined period of time.
As Ale pointed out, the AVR implementation has all its packets pre-generated in ROM, it simply clocks out pre-coded arrays of bits. This is ok if you only ever want your host to talk to one particular tested variety of device and ignore any errors that may crop up, but if you want a reasonable approximation of a functioning stack then you need to be a little more clever.
It's a bit like the AVR-device stacks out there. None of them do any error checking on the incoming data, so CRC errors are silently ignored. The propeller device stack checks for all documented errors (bitstuff/overrun/16bitCRC/5bitCRC), but is still slow enough that if you were to chain 3 hubs together it would exceed the absolute maximum timing limits in the protocol. As it is if you plug it into a single hub or directly into the root hub, it will meet the absolute worst case limit requirements, but it's nowhere fast enough to meet the certification timings.
We can of course turn off CRC checking to make it much, much closer to complying timings, but then we are no better than the AVR stacks. (I have an option to turn off inbound CRC checking in the HID bootloader - for space rather than speed though).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
As the stack can (barely) handle one hub, it might be barely possible to support three USB devices at once - a mouse, a keyboard, and a serial port (two serial would be better yes I'm greedy) with one cog (+LMM) - which would be a huge win, and effectively win back two cogs for a lot of apps.
No, I'm afraid you have the wrong end of the stick on that one. The device stack can cope with the delays involved in passing through a hub. It can't enumerate one.
I'd venture to suggest a host stack capable of enumerating a hub would consume a large proportion of the current propeller. Hub enumeration is a resource intensive business, and certainly incredibly timing critical. Not to mention that the spec mandates all hubs use at a minimum a "full speed" uplink. So we are really SOL as far as that goes.
Well, it was a nice thought while it lasted - however I suspect the PropII will be more than up to it.
Best Regards,
Bill
BradC said...
Bill Henning said...
Hi Brad,
As the stack can (barely) handle one hub, it might be barely possible to support three USB devices at once - a mouse, a keyboard, and a serial port (two serial would be better yes I'm greedy) with one cog (+LMM) - which would be a huge win, and effectively win back two cogs for a lot of apps.
No, I'm afraid you have the wrong end of the stick on that one. The device stack can cope with the delays involved in passing through a hub. It can't enumerate one.
I'd venture to suggest a host stack capable of enumerating a hub would consume a large proportion of the current propeller. Hub enumeration is a resource intensive business, and certainly incredibly timing critical. Not to mention that the spec mandates all hubs use at a minimum a "full speed" uplink. So we are really SOL as far as that goes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Lets assume we are not talking about an all singing all dancing, any kind of device host implementation. Rather just a keyboard handler, say, or just mice.
Seems the CRC is a big stumbling block here so what about....
I get the impression for a give actual physical keyboard, say, there must be a limited number of packets types going up and down and many of them will always have the same content. For example for a given actual keyboard its device descriptor packet will always be the same, as will say it's configuration descriptor. Similarly for packets going out from the host.
So why not have the host do the CRC and other checks on these packets just ONCE. This may well cause a time out and an error in the device. But so what ? Reset the device and from then on forget the CRC checking just match the incoming bytes with a stored copy of the good packet that was checked. Or use a simple checksum against the checksum of the original good packet. Bingo no time wasted on CRC. Similarly for outward bound packets.
That is, the host learns what packets may come, and short circuits the checks thereafter.
That only leaves the CRC checking of actual data packets when a key is pressed, but these are surely very short and quick. Or just skip the CRC as mentioned.
I have to study USB some more......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ale said...
Why is CRC a problem ? I mean, you calculate it taking the values from a table... 1 xor, 1 rdbyte/word/long one add... or am I missing something ?
\
Speed is the problem. Even using a 16 bit table like I do in the current stack, you chew up nearly 66% of your response time just verifying the CRC. There really is very little time to do the legwork before you need to get a response packet out, and I'm a stickler for error checking.
So did anyone considered implementing a "function" driver (as opposed to the host, using the usb lingo) on the prop? Let's say to just shoot bulk data back and forth or even isochronous streams.
I am currently trying to tackle USB examples for stm32 and got their "virtual com" demo to work with linux ACM driver just fine. Kernel automatically creates ttyACM0 device as i plug in (updated ubuntu 8.04 here).
The usblib for stm32 is not exactly simple (and you guys are right that understanding how usb works is a bear), but i think most of that complexity comes from the lib's flexibility. One can probably come up with a hardcoded virtual-com prop driver that would have the two IO endpoints and a way for other cogs to read and write into their buffers.
With the speed and CRC, it would be a good alternative to a simple and slow uart for communication to the host PC
Hello all.· I'm new to the forum and new to the Propeller chip.· This post title caught my eye because I'm currently in the preliminary stages of a design which would need USB, among other things.· Specifically, I want to build a device with ALL of the following: USB, ethernet, wireless, LCD,·mouse, keyboard, VGA, video, audio out, and·audio in.· The propeller demo board already has the ability to do the last 6 items, but not the 1st 4.· One of Propeller's main competitors in the 100 ish MIPS range is the PIC32 from Microchip.· Depending on the model of chip purchased, it already has USB on the chip, both host, device, and on the go which can be either.· The chip has a large parallel port, which can drive an LCD.· Ethernet and wireless can be added with add on cards.· They provide prebuilt stacks for USB, TCP/IP, two different kinds of wireless, and LCD displays up to 320 x 240 with full bitmapping.· They also provide application notes and case studies and, in some cases, reference designs.··The PIC32 is available with 84 I/O pins.· Propeller, on the other hand, does the 6 items mentioned perhaps better out of the box than the PIC32.· The propeller is also very appealing from the point of view of the parallel architecture.· I understand that the items mentioned are complex and resource intensive, but to compete in the arena with more demanding industrial and consumer applications, I believe Parallax has to support these communications technologies.· It's great to be able to use software designed by the user community.· However, if these tasks are too complicated or time consuming, I think the company should build them and provide them like Microchip has.· I'm actually considering marrying these two devices together in one box to get the capabilitites I want.· The idea of learning two high level languages, two assembly languages, and two programming environments is very intimidating, so I'd prefer to do this some other way.· It would be great if I could do it all with one or more propeller chips.· It would also be very helpful if I could do 1024 x 768 x 256 color full bitmap VGA at least, and it would be great if I could gang the chips together to get more available I/O pins.· Any advice you can give me would be greatly appreciated.
PS: How does the microphone input work?· Is there an A/D converter built into the chip?· Thanks in advance.
A low speed device with a 1.5 mhz instruction clock is around 13 propeller instructions per cycle. As Brad has pointed out that takes some gymnastics to get done, let alone full speed. For it to be a robust system it about requires a hardware level interface. USB complete says it takes around 2500 gates to get this done. I doubt it will happen but it would be slick to slip in one of these somewhere on the prop on one cog or something.
Comments
Is it really so that the Prop, in one COG with LMM, would still not have the speed to do it?
I thought in USB everything was controlled by the host. The devices never speak unless they are spoken to. In that way can't the host be a little more leisurely? Or is there some timing in the USB spec. that would be missed?
Are devices, as exist in the wild, actually so fussy about this timing ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No, Yes, Yes.
There are specific timing requirements placed on the host pertaining to turnaround times. Devices are _required_ to treat anything outside these tolerances as an error. If you are late reading a response, or late getting a query out to a device, the device will flag that delay as an error. It's how quite a bit of the protocol is implemented. If the host receives a valid packet from the device it _must_ get a reply out in a defined period of time.
As Ale pointed out, the AVR implementation has all its packets pre-generated in ROM, it simply clocks out pre-coded arrays of bits. This is ok if you only ever want your host to talk to one particular tested variety of device and ignore any errors that may crop up, but if you want a reasonable approximation of a functioning stack then you need to be a little more clever.
It's a bit like the AVR-device stacks out there. None of them do any error checking on the incoming data, so CRC errors are silently ignored. The propeller device stack checks for all documented errors (bitstuff/overrun/16bitCRC/5bitCRC), but is still slow enough that if you were to chain 3 hubs together it would exceed the absolute maximum timing limits in the protocol. As it is if you plug it into a single hub or directly into the root hub, it will meet the absolute worst case limit requirements, but it's nowhere fast enough to meet the certification timings.
We can of course turn off CRC checking to make it much, much closer to complying timings, but then we are no better than the AVR stacks. (I have an option to turn off inbound CRC checking in the HID bootloader - for space rather than speed though).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
The approach to bit-banging USB seems to be; look at what is necessary for complete compliance to the spec, realise it's too much for bit-banging or a non-dedicated controller and strip away parts until it can work, accepting loss of functionality and/or reliability along the way.
Nothing wrong with that per se but as BradC points out that does leave rather limited capabilities for what is supported, while it may work with one device it will not with another.
It's then a question of what's required, what's acceptable and what people's expectations are. I think we all know or can foresee the frustrations of, "Sure the Propeller can have a USB keyboard connected providing it's made by XYZZY Inc and manufactured between July and September 2006".
I personally think it would be acceptable to have a Propeller solution at that level, at least as proof of concept and delivering a starting point to build upon. It's real usefulness would however be in being able to reasonably easily reconfigure for other USB devices. That might be easier said than done.
My opinion is that something would be better than nothing even if a flawed design and not as robust or as flexible as it could be. Others perhaps disagree.
As the stack can (barely) handle one hub, it might be barely possible to support three USB devices at once - a mouse, a keyboard, and a serial port (two serial would be better
Best Regards,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
No, I'm afraid you have the wrong end of the stick on that one. The device stack can cope with the delays involved in passing through a hub. It can't enumerate one.
I'd venture to suggest a host stack capable of enumerating a hub would consume a large proportion of the current propeller. Hub enumeration is a resource intensive business, and certainly incredibly timing critical. Not to mention that the spec mandates all hubs use at a minimum a "full speed" uplink. So we are really SOL as far as that goes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Well, it was a nice thought while it lasted - however I suspect the PropII will be more than up to it.
Best Regards,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Seems the CRC is a big stumbling block here so what about....
I get the impression for a give actual physical keyboard, say, there must be a limited number of packets types going up and down and many of them will always have the same content. For example for a given actual keyboard its device descriptor packet will always be the same, as will say it's configuration descriptor. Similarly for packets going out from the host.
So why not have the host do the CRC and other checks on these packets just ONCE. This may well cause a time out and an error in the device. But so what ? Reset the device and from then on forget the CRC checking just match the incoming bytes with a stored copy of the good packet that was checked. Or use a simple checksum against the checksum of the original good packet. Bingo no time wasted on CRC. Similarly for outward bound packets.
That is, the host learns what packets may come, and short circuits the checks thereafter.
That only leaves the CRC checking of actual data packets when a key is pressed, but these are surely very short and quick. Or just skip the CRC as mentioned.
I have to study USB some more......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Speed is the problem. Even using a 16 bit table like I do in the current stack, you chew up nearly 66% of your response time just verifying the CRC. There really is very little time to do the legwork before you need to get a response packet out, and I'm a stickler for error checking.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I am currently trying to tackle USB examples for stm32 and got their "virtual com" demo to work with linux ACM driver just fine. Kernel automatically creates ttyACM0 device as i plug in (updated ubuntu 8.04 here).
The usblib for stm32 is not exactly simple (and you guys are right that understanding how usb works is a bear), but i think most of that complexity comes from the lib's flexibility. One can probably come up with a hardcoded virtual-com prop driver that would have the two IO endpoints and a way for other cogs to read and write into their buffers.
With the speed and CRC, it would be a good alternative to a simple and slow uart for communication to the host PC
PS: How does the microphone input work?· Is there an A/D converter built into the chip?· Thanks in advance.
Sincerely,
Ron
·