At this moment, it appears to me to be correct. But, I've had things backwards a lot lately...
Sounds good.
If you have LS ticking over on USB content, you could connect RX to sniff on a connected device FS USB (eg the connected FT231X) and look for this 1ms tick ?
"The Start of Frame packet is sent every 1 ms on full speed links.
The frame is used as a time frame in which to schedule the data transfers which are required."
SOF(3:0) 0101b (send LSB first) PID0.PID1.PID2.PID3.\PID0.\PID1.\PID2.\PID3
expect to see scope of 1010_0101
Sync , PID[8b] Frame No.[11b] CRC5[5b] EOP
I think that Frame No ticks over ?
Could be a 'small steps' check of NCO FS ? (and also confirms CRC, if that FrameNo cycles )
I decided that the CRCs are sent MSB first after doing a lot of binary long division and reading on the web. I'm pretty sure they did this just to make it harder to understand....
Chalk another one up to LE confusions I guess. I can see writing the bits one way and the bytes the other will trip people up too.
Yes, but once the Verilog is right, the bits become invisible, and users only need think about bytes.
It is getting to that stage, that becomes a little convoluted...
If you are calculating the CRC, don't forget to xor the CRC after you calculate it!
The code I posted analyses the bitstream correctly including the CRC. I have a later version that does it all in pasm but won't be able to post until I arrive in the uk and settle down. Just waiting for the flight now
But, I did notice that the received byte flag gets toggled by the $80 sync byte a the start of a packet. It toggles the byte flag but doesn't put $80 as the received byte. Received byte just stays what it was before.
If I'm seeing that right, it might be better if that $80 is put as received byte?
But, I did notice that the received byte flag gets toggled by the $80 sync byte a the start of a packet. It toggles the byte flag but doesn't put $80 as the received byte. Received byte just stays what it was before.
If I'm seeing that right, it might be better if that $80 is put as received byte?
Upon receiving an SOP ($80), the byte flag gets cleared to 0. You are seeing it go to 0, but it's giving the impression that it's toggling from 1 to 0.
What I see is the status byte go from $A0 to $10 when it gets start of packet.
Then, it goes from $10 to $90 when the next byte comes in.
So, the SOP flag is staying on for a while
For the immediately following packet, It goes $A4 for SE0 state
then it goes$A0 for while start of packet coming in
Then, toggles between $10 and $90 for the rest of the packet.
I guess this can work, just want to make sure this the expected behavior...
What I see is the status byte go from $A0 to $10 when it gets start of packet.
Then, it goes from $10 to $90 when the next byte comes in.
So, the SOP flag is staying on for a while
For the immediately following packet, It goes $A4 for SE0 state
then it goes$A0 for while start of packet coming in
Then, toggles between $10 and $90 for the rest of the packet.
I guess this can work, just want to make sure this the expected behavior...
SE0 marks the end of packet. So, what you are seeing is correct. There are two different packets coming in.
Ok, that's fine. For a minimalist sniffer, maybe it'd be easier if byte toggle bit only toggled for real bytes, but this can work. Just want to make sure what I'm seeing is right...
When we get a new image, and time, I will have a look at the smart pins and confirm that it gives what I have snooped. I have a de0-nano and bemicro cv-a9 in the uk with me.
Ok, that's fine. For a minimalist sniffer, maybe it'd be easier if byte toggle bit only toggled for real bytes, but this can work. Just want to make sure what I'm seeing is right...
Don't think of it as toggling, or not. Think of it as resetting on every SOP and toggling thereafter on each byte.
I hope this document: Parallax Propeller 2 Assembly Instruction Set
Gets updated one day. It seems like many of the new instructions have "?" on their explanation.
Or, the explanation isn't enough for me to figure out how to use them...
I'd like to use some of the new instructions, but I don't really know how some of the work...
I'm sure there is explanation buried somewhere in this forum, but looking for that and figuring out which version of P2 it's for is tedious...
Made a hair more progress with USB sniffer... Now using only Smartpin to capture USB instead of bit banging and comparing to smartpin.
I think I see now that the joystick is polled with IN at regular intervals and responds with alternating DATA0 then DATA1 responses. I can see the data in the packets changing with joystick movement and button pushes.
But, I think joystick is much lower interest than keyboard and mouse. So, I'm going to switch to that now. Just got some cheap ones off Amazon and hope they work in low speed mode...
Looking at data from USB mouse now. This is a AmazonBasics mouse, one of the cheapest they had. Fortunately, it is still low speed.
The data is almost exactly as described by: http://www.usbmadesimple.co.uk/ums_5.htm
Think it should be fairly straightforward to host this directly with Prop...
Been driving me crazy. Everything's looked right, but was getting no response from USB mouse or joystick.
Captured data from sniffing when connected to PC shows that first thing is a setup command:
2D 00 10
followed by data0:
C3 80 06 00 01 00 00 40 00 DD 94
The mouse responded with D2 when connected to PC but no response with Prop.
Finally figured out that the space between the 2D setup and C3 data0 packets are important.
It was about 7 us initially.
Used scope to compare traces directly and noticed the PC one had a 4 us spacing.
Changed that and finally got the D2 response from mouse!
Finally got a response from a USB device!
...
Changed that and finally got the D2 response from mouse!
Woohoo! - A milestone that deserves its own thread ?
You are saying you now have a P2 hosting a mouse, with value extract ?
Any numbers ? -
What size is the code ?
How long from mouse-insert, to first co-ord output ?
What SysCLK clock speed could this work down to ? (given it looks to have a min-time aspect)
Does the Mouse accept any config data, or is it a simple response-only model.
Now you have LS working, does the same code work on a FS Mouse ?
Finally figured out that the space between the 2D setup and C3 data0 packets are important.
It was about 7 us initially.
Used scope to compare traces directly and noticed the PC one had a 4 us spacing.
hmm, strange 3us matters, maybe there are other details lurking in real USB systems....?
BTW I am surprised it worked at all with even a 4us delay. USB response times are extremely tight to be in spec.
I believe this is a Low Speed test, and my reading was that 4us~7us was not a response-time, so much as a gap between two Host (P2) packets ?
The PC gives the 'gold standard', as that works.
I guess there will be other 'implied timings' where simple slaves have been tested on a PC Host(s), and once it works, they ship.
ie any Finer timing tolerance spreads are simply not tested.
>Ok, I double checked and that definitely was the problem.
Didn't see the spacing requirement mentioned anywhere I was looking for reference...
It may not be 'a spec', but an artifact of the simplest design (which could even be USB-in-SW) ?
Maybe they run a simple monostable for their packet resync, or maybe they drift too much in a longer time ?
Hmm... Makes me wonder if sequential packets are expected to be on the same clock...
Maybe that's the real problem... That could be what I did my matching PC output without realizing it.
Do you mean on the same 1.5MHz edge-slots.
I would think that was important, but I expected P2 to manage that automatically, when you choose a NCO Clock 1.5MHz ?
Can the timing move away from 1.5MHz edge-slots ?
Comments
Sounds good.
If you have LS ticking over on USB content, you could connect RX to sniff on a connected device FS USB (eg the connected FT231X) and look for this 1ms tick ?
"The Start of Frame packet is sent every 1 ms on full speed links.
The frame is used as a time frame in which to schedule the data transfers which are required."
SOF(3:0) 0101b (send LSB first) PID0.PID1.PID2.PID3.\PID0.\PID1.\PID2.\PID3
expect to see scope of 1010_0101
Sync , PID[8b] Frame No.[11b] CRC5[5b] EOP
I think that Frame No ticks over ?
Could be a 'small steps' check of NCO FS ? (and also confirms CRC, if that FrameNo cycles )
It is getting to that stage, that becomes a little convoluted...
The code I posted analyses the bitstream correctly including the CRC. I have a later version that does it all in pasm but won't be able to post until I arrive in the uk and settle down. Just waiting for the flight now
I made the change to allow sensing of individual EOP's, as occur in low-speed mode. It will be in the next release.
But, I did notice that the received byte flag gets toggled by the $80 sync byte a the start of a packet. It toggles the byte flag but doesn't put $80 as the received byte. Received byte just stays what it was before.
If I'm seeing that right, it might be better if that $80 is put as received byte?
Upon receiving an SOP ($80), the byte flag gets cleared to 0. You are seeing it go to 0, but it's giving the impression that it's toggling from 1 to 0.
Then, it goes from $10 to $90 when the next byte comes in.
So, the SOP flag is staying on for a while
For the immediately following packet, It goes $A4 for SE0 state
then it goes$A0 for while start of packet coming in
Then, toggles between $10 and $90 for the rest of the packet.
I guess this can work, just want to make sure this the expected behavior...
SE0 marks the end of packet. So, what you are seeing is correct. There are two different packets coming in.
Don't think of it as toggling, or not. Think of it as resetting on every SOP and toggling thereafter on each byte.
Gets updated one day. It seems like many of the new instructions have "?" on their explanation.
Or, the explanation isn't enough for me to figure out how to use them...
I'd like to use some of the new instructions, but I don't really know how some of the work...
I'm sure there is explanation buried somewhere in this forum, but looking for that and figuring out which version of P2 it's for is tedious...
I think I see now that the joystick is polled with IN at regular intervals and responds with alternating DATA0 then DATA1 responses. I can see the data in the packets changing with joystick movement and button pushes.
But, I think joystick is much lower interest than keyboard and mouse. So, I'm going to switch to that now. Just got some cheap ones off Amazon and hope they work in low speed mode...
The data is almost exactly as described by: http://www.usbmadesimple.co.uk/ums_5.htm
Think it should be fairly straightforward to host this directly with Prop...
Don't see that anywhere on P123 board, not any of the headers anyway...
Guess I'll use second USB jack on my test setup with data lines disconnected to supply power from PC.
I'm sorry we didn't think to put a 5V supply on the Prop123 board. The highest you have available there is only 3.3V.
Just don't warm the leds up too much as they're quite temperature sensitive
Been driving me crazy. Everything's looked right, but was getting no response from USB mouse or joystick.
Captured data from sniffing when connected to PC shows that first thing is a setup command:
2D 00 10
followed by data0:
C3 80 06 00 01 00 00 40 00 DD 94
The mouse responded with D2 when connected to PC but no response with Prop.
Finally figured out that the space between the 2D setup and C3 data0 packets are important.
It was about 7 us initially.
Used scope to compare traces directly and noticed the PC one had a 4 us spacing.
Changed that and finally got the D2 response from mouse!
Woohoo! - A milestone that deserves its own thread ?
You are saying you now have a P2 hosting a mouse, with value extract ?
Any numbers ? -
What size is the code ?
How long from mouse-insert, to first co-ord output ?
What SysCLK clock speed could this work down to ? (given it looks to have a min-time aspect)
Does the Mouse accept any config data, or is it a simple response-only model.
Now you have LS working, does the same code work on a FS Mouse ?
hmm, strange 3us matters, maybe there are other details lurking in real USB systems....?
BTW I am surprised it worked at all with even a 4us delay. USB response times are extremely tight to be in spec.
I should double check that the spacing was the actual issue... I was changing a million things trying to make it work...
>Ok, I double checked and that definitely was the problem.
Didn't see the spacing requirement mentioned anywhere I was looking for reference...
I think I just got there today.
I believe this is a Low Speed test, and my reading was that 4us~7us was not a response-time, so much as a gap between two Host (P2) packets ?
The PC gives the 'gold standard', as that works.
I guess there will be other 'implied timings' where simple slaves have been tested on a PC Host(s), and once it works, they ship.
ie any Finer timing tolerance spreads are simply not tested.
It may not be 'a spec', but an artifact of the simplest design (which could even be USB-in-SW) ?
Maybe they run a simple monostable for their packet resync, or maybe they drift too much in a longer time ?
Maybe that's the real problem... That could be what I did my matching PC output without realizing it.
Do you mean on the same 1.5MHz edge-slots.
I would think that was important, but I expected P2 to manage that automatically, when you choose a NCO Clock 1.5MHz ?
Can the timing move away from 1.5MHz edge-slots ?