Err how sure are you these don't also fall back and work in LS ?
The Cypress part I looked at, mentioned only FS USB.
Once they can do FS USB, LS USB is more testing, and more cost to a MCU vendor.
Hosts I think do need to be Speed-aware, but devices can run at whatever is cheapest and easiest of LS/FS.
Even though Mice and keyboards do not need above 1.5MBd the nature of creeping featurism will see 12M become standard in MCUs
Once a single device is sorted out, is support for device on a connected USB hub a matter of enumerating devices and talking across the same pins or does it become an absolute timing issue with the amount of data a P2 can exchange across a USB connection?
Supporting USB kbd and mouse on a single USB connection would be sweet.
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...
Yeah, that's the part that's been sticky for me, too. Now that I can get repeatable successful transactions, I'm going to have to scrutinize the code mess I've got now to see if I can make sense of it...
Maybe I'm wrong, but I don't see why one cog couldn't host 16 or more HID devices. The data rate is very low...
Yes, maybe, but I was not going to suggest going there in one step..
You could phase the 1ms frames, which means the SW adds a Pin-Index scheme, and does them on a rotation basis - a NAK could get tricky, as is it ok to push that to the next 1ms ?
Comes down to Code Size ?
Supporting USB kbd and mouse on a single USB connection would be sweet.
USB is not designed to be multi-drop. To fan-out you need a HUB.
However, P2 has a shipload of Smart Pin Cells!
So the better question is can one COG manage a USB keyboard and USB mouse (and why not add USB touch Screen here too ) ?
Time-wise, it is likely to be easy to interleave low rate traffic, Data needed is small, which leaves Code-Size ?
3 USB hosts from one COG would certainly be nifty
That's why my first paragraph talked about a device connected to a hub, so you would have the fan out of a hub for multiple devices through one port on the P2.
That's why my first paragraph talked about a device connected to a hub, so you would have the fan out of a hub for multiple devices through one port on the P2.
oops, I missed the hub word..:)
I'm rusty on this, but I think hubs need more of a dance, and they collect downstream info
- but good question, Host-via-hub may be something users choose, even if multiple USB are available on P2. Both choices should be available, but adding HUB tolerance will likely expand the code.
There have been a few cases go past, where something worked on a HUB, but failed direct connect.
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...
We can easily add a do-nothing-for-n-bit-periods command that gets buffered just like a byte does.
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...
We can easily add a do-nothing-for-n-bit-periods command that gets buffered just like a byte does.
Chip, could you provide the internal state sequence for the USB transmitter, much like you did for the asynchronous serial transmitter in your doc? I'm assuming that the "buffer empty" flag gets raised when the output byte gets moved to the shifter? And is it the same when a line state change command is issued?
The inter-packet delays are measured in bit times at the end of the EOP->IDLE transition. Since EOP is output for us by the smart pins I've been basing my IP delay on sniffing for the EOP and it seems to be working pretty well. But a little more detail about when it all happens would be a real help.
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...
We can easily add a do-nothing-for-n-bit-periods command that gets buffered just like a byte does.
I probably just haven't figured out the right way to do it...
Here's the issue... I wanted a certain interpacket delay (something like 6us).
With simple code, it's simple, you just do waitx ##650 after sending the last byte and you have it.
But, was looking for a more elegant way when there is more code in between packets... So, what I did was wait for EOP to come in. If I send a new byte then, it would come before that 6us target. So, I send an IDLE and then the byte, but that winds up a little after the target.
How many cycles does it do IDLE when you tell it to?
I should say I didn't spend a whole lot of time playing with this because it just worked anyway even though the delay wasn't exactly what I wanted...
Here's the issue... I wanted a certain interpacket delay (something like 6us).
With simple code, it's simple, you just do waitx ##650 after sending the last byte and you have it.
But, was looking for a more elegant way when there is more code in between packets...
If the code has a known Cycles/word (I think P2 is fairly predictable there ?) you can use the address offset with a multipler to reduce the SysClk counts, and then use a SysCLK:USBCLK ratio to scale this from one declaration point ?
(I'm guessing no complex branches in this short code piece?)
Even a (new) Delay opcode is going to need some code-counting, as it will only stretch up to a point, and will have a pre-fire delay.
Now that I've had some time to think on it, maybe just having a simple counter register for elapsed bit periods at the transceiver's set baud rate would do it? The USB inter-packet and turn-around times are all specified in terms of transceiver bit periods, so having something similar to the prop's getct, but for bit periods, takes sysclk out of the equation entirely.
Now that I think about it, it would be nice if there was an easier way to get the right interpacket delay. Feels a bit cludgy now. But, maybe I'm not doing it right...
We can easily add a do-nothing-for-n-bit-periods command that gets buffered just like a byte does.
I probably just haven't figured out the right way to do it...
Here's the issue... I wanted a certain interpacket delay (something like 6us).
With simple code, it's simple, you just do waitx ##650 after sending the last byte and you have it.
But, was looking for a more elegant way when there is more code in between packets... So, what I did was wait for EOP to come in. If I send a new byte then, it would come before that 6us target. So, I send an IDLE and then the byte, but that winds up a little after the target.
How many cycles does it do IDLE when you tell it to?
I should say I didn't spend a whole lot of time playing with this because it just worked anyway even though the delay wasn't exactly what I wanted...
When you tell it to go IDLE, or do anything, it always waits for the next bit clock before doing it. The bit clock sets the time base for all output changes.
If you wait for EOP and then start responding with a new packet, immediately, you will be within the USB spec at 80MHz. I need to add some time-spacing option to all output commands to make sure that timing can be consistent at all SysClk frequencies, so nobody is leaning in things like WAITX to get their timing straight.
Now that I think about it, I could have just read the cnt after last byte and the later on waited for that cnt+650... That's not much different than waiting for EOP, but gets whatever timing I want.
Ok, that was my problem... In my last attempt, I was waiting for idle...
Before that I waited for EOP and then idle. I didn't realize was waiting for 7+ bit clocks of idle...
What I maybe should have done is wait for EOP and then send out several IDLES to get the spacing I want.
I've found it better to just wait for EOP, immediately add a delay of ~5 bit times, and call it good. Remember, when the smart pins output EOP, it's as [SE0, SE0, J, then IDLE]), so IMO there's no reason to wait for idle.
Now that I've had some time to think on it, maybe just having a simple counter register for elapsed bit periods at the transceiver's set baud rate would do it? The USB inter-packet and turn-around times are all specified in terms of transceiver bit periods, so having something similar to the prop's getct, but for bit periods, takes sysclk out of the equation entirely.
You still need SysCLK to set the USB-Baud-Divider, so you cannot remove it entirely.
A N-USB-bits command does sound useful, provided it is flexible.
The thing to avoid is locking too much into silicon, and finding later something important needs a timing tweak....
Here's what I'm thinking about for USB host test board...
Has two connectors, one for keyboard, one for mouse.
It's all through hole or easy SMT. So, if I give these away, you can solder your own stuff on easily.
The 5V is from MAX756 chip that I used a long time ago. Gives 200 mA, which should be fine.
Put some servo headers on, maybe that's enough juice with a big capacitor.
Has spot for SQI flash and uSD connector.
Connector in middle is for a camera module (sold by techtoys.com.hk)
I have some working SSD1921 code for that so maybe can adapt to P2 and get 640x480 color video or 2MPixel photo.
Now, I have to think about what pins to use... If there are only 16 smart pins, might be low on full pins...
Comments
Err how sure are you these don't also fall back and work in LS ?
There are good and bad distractions. Surely this would be a good one ?
The Cypress part I looked at, mentioned only FS USB.
Once they can do FS USB, LS USB is more testing, and more cost to a MCU vendor.
Hosts I think do need to be Speed-aware, but devices can run at whatever is cheapest and easiest of LS/FS.
Even though Mice and keyboards do not need above 1.5MBd the nature of creeping featurism will see 12M become standard in MCUs
Supporting USB kbd and mouse on a single USB connection would be sweet.
USB is not designed to be multi-drop. To fan-out you need a HUB.
However, P2 has a shipload of Smart Pin Cells!
So the better question is can one COG manage a USB keyboard and USB mouse (and why not add USB touch Screen here too ) ?
Time-wise, it is likely to be easy to interleave low rate traffic, Data needed is small, which leaves Code-Size ?
3 USB hosts from one COG would certainly be nifty
Yes, maybe, but I was not going to suggest going there in one step..
You could phase the 1ms frames, which means the SW adds a Pin-Index scheme, and does them on a rotation basis - a NAK could get tricky, as is it ok to push that to the next 1ms ?
Comes down to Code Size ?
Did you do that on your unit with NAKs ?
( I thought USB may have some rules around the retry too )
That's why my first paragraph talked about a device connected to a hub, so you would have the fan out of a hub for multiple devices through one port on the P2.
I'm rusty on this, but I think hubs need more of a dance, and they collect downstream info
- but good question, Host-via-hub may be something users choose, even if multiple USB are available on P2. Both choices should be available, but adding HUB tolerance will likely expand the code.
There have been a few cases go past, where something worked on a HUB, but failed direct connect.
We can easily add a do-nothing-for-n-bit-periods command that gets buffered just like a byte does.
The inter-packet delays are measured in bit times at the end of the EOP->IDLE transition. Since EOP is output for us by the smart pins I've been basing my IP delay on sniffing for the EOP and it seems to be working pretty well. But a little more detail about when it all happens would be a real help.
Thanks!
I probably just haven't figured out the right way to do it...
Here's the issue... I wanted a certain interpacket delay (something like 6us).
With simple code, it's simple, you just do waitx ##650 after sending the last byte and you have it.
But, was looking for a more elegant way when there is more code in between packets... So, what I did was wait for EOP to come in. If I send a new byte then, it would come before that 6us target. So, I send an IDLE and then the byte, but that winds up a little after the target.
How many cycles does it do IDLE when you tell it to?
I should say I didn't spend a whole lot of time playing with this because it just worked anyway even though the delay wasn't exactly what I wanted...
(I'm guessing no complex branches in this short code piece?)
Even a (new) Delay opcode is going to need some code-counting, as it will only stretch up to a point, and will have a pre-fire delay.
When you tell it to go IDLE, or do anything, it always waits for the next bit clock before doing it. The bit clock sets the time base for all output changes.
If you wait for EOP and then start responding with a new packet, immediately, you will be within the USB spec at 80MHz. I need to add some time-spacing option to all output commands to make sure that timing can be consistent at all SysClk frequencies, so nobody is leaning in things like WAITX to get their timing straight.
It's the IDLE sensor that indicates when you've had 7+ bit clocks of IDLE state.
Before that I waited for EOP and then idle. I didn't realize was waiting for 7+ bit clocks of idle...
What I maybe should have done is wait for EOP and then send out several IDLES to get the spacing I want.
A N-USB-bits command does sound useful, provided it is flexible.
The thing to avoid is locking too much into silicon, and finding later something important needs a timing tweak....
Has two connectors, one for keyboard, one for mouse.
It's all through hole or easy SMT. So, if I give these away, you can solder your own stuff on easily.
The 5V is from MAX756 chip that I used a long time ago. Gives 200 mA, which should be fine.
Put some servo headers on, maybe that's enough juice with a big capacitor.
Has spot for SQI flash and uSD connector.
Connector in middle is for a camera module (sold by techtoys.com.hk)
I have some working SSD1921 code for that so maybe can adapt to P2 and get 640x480 color video or 2MPixel photo.
Now, I have to think about what pins to use... If there are only 16 smart pins, might be low on full pins...
https://learn.adafruit.com/minty-boost
Maybe have a header and jumper option for external 5v?