USB Testing

1246720

Comments

  • :) Don't get distracted from testing P2!
    It looks like most wireless devices are now FS USB, so bit-bang LS Host would have limited scope.

    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 ?
  • jmgjmg Posts: 13,561
    edited 2016-05-17 - 00:18:45
    Tubular wrote: »
    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

    Tubular wrote: »
    There are good and bad distractions. Surely this would be a good one ?
    :) Sure, once P2 testing is all done...

  • 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.
    MOV OUTA, PEACE <div>Rick </div><div>"I've stopped using programming languages with Garbage Collection, they keep deleting my source code!!"</div>
  • Rayman wrote: »
    Took me a long time too...

    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...
    garryj
  • jmgjmg Posts: 13,561
    mindrobots wrote: »
    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 :)
  • 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...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,561
    Rayman wrote: »
    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 ?


  • for the real data, NAK just means there's nothing new to report...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,561
    Rayman wrote: »
    for the real data, NAK just means there's nothing new to report...
    So it is ok to bump the next try, to the next USB frame ?
    Did you do that on your unit with NAKs ?

    ( I thought USB may have some rules around the retry too )

  • mindrobotsmindrobots Posts: 6,506
    edited 2016-05-17 - 01:50:47
    jmg wrote: »
    mindrobots wrote: »
    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. :)

    MOV OUTA, PEACE <div>Rick </div><div>"I've stopped using programming languages with Garbage Collection, they keep deleting my source code!!"</div>
  • jmgjmg Posts: 13,561
    mindrobots wrote: »
    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.

  • Rayman wrote: »
    Took me a long time too...

    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.
  • cgracey wrote: »
    Rayman wrote: »
    Took me a long time too...

    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.

    Thanks!
    garryj
  • And yes, I think a wait-for-n-bit periods command would be sweet!
    garryj
  • RaymanRayman Posts: 9,480
    edited 2016-05-17 - 10:34:38
    cgracey wrote: »
    Rayman wrote: »
    Took me a long time too...

    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...

    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,561
    Rayman wrote: »
    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.

  • Maybe when told to output idle, it puts out 8 bits worth of idle?
    Prop Info and Apps: http://www.rayslogic.com/
  • garryjgarryj Posts: 265
    edited 2016-05-17 - 14:12:20
    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.
    garryj
  • Rayman wrote: »
    cgracey wrote: »
    Rayman wrote: »
    Took me a long time too...

    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.
  • Ok, I had the sense that the IDLE did more that one bit clock, but maybe I'm wrong.
    Prop Info and Apps: http://www.rayslogic.com/
  • 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.
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Ok, I had the sense that the IDLE did more that one bit clock, but maybe I'm wrong.

    It's the IDLE sensor that indicates when you've had 7+ bit clocks of IDLE state.
  • RaymanRayman Posts: 9,480
    edited 2016-05-17 - 19:11:23
    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.
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    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.
    garryj
  • Here's the wait EOP sub I'm using:
    ' Wait for tx buffer empty followed by EOP
    wait_eop
    		testb	ina, #DP		wc
    	if_nc	jmp	#wait_eop			' Wait tx buffer empty
    		pinack	#DM				' Want to sniff receiver for EOP
    .eop
    		testb	ina, #DM		wc
    	if_nc	jmp	#.eop
    		pingetz	urx, #DM
    		testb	urx, #RXERRB		wc
    	if_c	jmp	#sab
    		pinack	#DM
    		testb	urx, #EOPB		wc
    	if_nc	jmp	#.eop
    		testb	status, #LOW_SPEEDB	wc
    	if_c	waitx	##IP_WAIT_LOW			' Inter-packet delay is in speed bit times
    	if_nc	waitx	##IP_WAIT_FULL
    		ret
    
    garryj
  • jmgjmg Posts: 13,561
    garryj wrote: »
    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....



  • RaymanRayman Posts: 9,480
    edited 2016-05-20 - 20:01:11
    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...

    350 x 481 - 16K
    Prop Info and Apps: http://www.rayslogic.com/
  • Looks good. I think its worth trying a HyperRam on there bottom left too. I went with P0-11, so it'd be bottom left corner
  • If you wanted 500mA you could use the mintyboost circuit from adafruit
    https://learn.adafruit.com/minty-boost
  • I like it too -- count me in!

    Maybe have a header and jumper option for external 5v?
    garryj
Sign In or Register to comment.