(Incidentally, this would be a nice mode for making a logic analyzer! Assuming the above estimates are somewhat accurate, you could do a 16-pin logic analyzer with 4 cogs processing 4 pins each at an effective sample rate of about 10Msps. Or 8 cogs processing 2 pins apiece for about 20Msps. In fact, you could allow the user to trade off between pin count and effective sample rate, which is a feature I don't think I've seen before.)
wouldn't you just wait for the trigger pattern und use the streamer to capture the data as fast as possible?
just my naive thinking ;-)
Sure, there are two basic approaches
a) Trigger and then run like heck (aka the streamer as sampler)
This usually needs some manual clock scaling, and buffer trade offs.
b) capture the edge-set and timestamp, which has implicit compression
Approach b) has much wider dynamic range and needs far less memory than a), but it does have a lower peak rate.
If b) can use the streamer, the compression capture limit is only half the streamer limit. (but edge resolution is still sysCLK)
The important bit, is it IS possible, being rare does not help the user.
Also users may not think they have fast edge events at all - they may miss double pulses on their external comparators, for example.
What does it matter? At that point, you've missed edge events no matter how they appear to the user. Just like the original version of mode %10001, if you miss an event, all bets are off!
Let's estimate 30-40 clock cycles for minimal processing (including the PINGETZ).
On the final chip, you are realistically limited to edge events <40MHz (assuming 160MHz sysclk). If you are handling multiple pin events on the same cog, this will be even lower.
Did you mean 4MHz from that 30-40 clock cycles ?
Oops! Yes, 4MHz. Still not bad, but a bit less impressive for things like logic analyzers. However, I suppose you could switch between this mode and the streamer mode (for higher sample rates), where the obvious trade-off would be sample length.
Sorry I'm slow to respond to the mode %10001 idea. I read it a few times, but it never sunk in until I reread it very slowly just now. That's a neat idea. It gets things down to an absolute time. That could be done, and I agree that some timescale is necessary. The only problem I see with that is the need to run the whole 32-bit counter to every smart pin. That may be no big deal, but it almost doubles the number of hub/cog signals going into the smart pin. After I get this communication sped up, we'll look more into this.
Maybe you could add a local counter to every pin, since I assume that the sysclk signal already runs to each of the pins. Or maybe only 16 counters, where each is assigned to a cog and four pins. Or whatever strikes the best balance. Not as energy efficient, of course, but it would hopefully ease the signal routing concern.
The important bit, is it IS possible, being rare does not help the user.
Also users may not think they have fast edge events at all - they may miss double pulses on their external comparators, for example.
What does it matter? At that point, you've missed edge events no matter how they appear to the user. Just like the original version of mode %10001, if you miss an event, all bets are off!
That depends on how it is missed, and this is why I like your suggestion of absolute time capture, not capture-reset.
With capture-reset, a missed edge also loses time, with absolute time (no reset), a missed (or extra) edge does not lose correct time.
Oops! Yes, 4MHz. Still not bad, but a bit less impressive for things like logic analyzers. However, I suppose you could switch between this mode and the streamer mode (for higher sample rates), where the obvious trade-off would be sample length.
I know the streamer can capture pins, I'm less clear on what else can feed it ?
A mode where the streamer was Clock enabled by events, and captures the Pins, and then Time, in 2 captures, would give a much higher than 4MHz peak rate, and would be automatic elastic in nature.
I (and maybe Ken too) was hoping we'd stop thinking about adding new features after (or maybe before) USB was done...
Was just and Disney World and saw a Disney quote on a wall. Looked it up and here's the full quote:
“Everyone needs deadlines. Even the beavers. They loaf around all summer, but when they are faced with the winter deadline, they work like fury. If we didn’t have deadlines, we’d stagnate.”
I seem to recall Beau mentioning the need for deadlines before.
Anyway, do we have a deadline for P2 FPGA checkout completion?
Sidenote: I think we (or me at least) could use about 2 months to check new things out...
Sorry I'm slow to respond to the mode %10001 idea. I read it a few times, but it never sunk in until I reread it very slowly just now. That's a neat idea. It gets things down to an absolute time. That could be done, and I agree that some timescale is necessary. The only problem I see with that is the need to run the whole 32-bit counter to every smart pin. That may be no big deal, but it almost doubles the number of hub/cog signals going into the smart pin. After I get this communication sped up, we'll look more into this.
There are already counters in the pins - enough to do capture ? - so rather than add a lot more signals, why not look at the simpler detail of getting those counters in sync ?
If they can all start on the same SysCLK, you have the same nett result ?
Likewise, Capture should also be many-pin same SysCLK arm-able.
I think you've mentioned a reset release mechanism that is many-pin same SysCLK in nature, sounds nearly there ?
The limit of this, is I think 32 pins is the most that can be done in one opcode ?
Where someone did want more than 32, I think the fixed offsets of doing 32+32 would be manageable in most cases ?
I finally got the faster variable-size (byte/word/long) links working between the smart pins and the cogs. The word size is data-dependent in each direction.
It used to take 10 clocks to send data to a smart pin. Longs still take 10, but words now take 6 and bytes now take 4. The cog appropriately sizes the message, based on where the leading zeros begin.
It used to take 9-16 clocks to receive data from a smart pin. Longs now take 10-18 clocks, words take 6-10 clocks, and bytes take 4-6 clocks. The smart pin message size is mode-determined. For example, USB returns words, while serial returns bytes/words/longs, based on the selected word size.
The USB is now able to respond to an EOP with an SOP in 3-4 bit periods, whereas before it was around 6-7, which was at the USB spec limit.
Finally had some time to try out USB sniffer circuit.
But, I'm not having any luck...
My wireless mouse is actually running at full speed, 12 MHz, instead of expected low speed.
I changed chip's code just a bit to keep the transmitter in the idle state.
Also, moved usb to pins 30 and 31 to match that code.
The receiver is not working this way. It shows a new byte (via toggle on P7) only every ~130 milliseconds, which is strangely repeatable but very wrong.
I guess with that original test code, the transmitter and receiver signals are all inside the FPGA and so connections to the physical I/O pins don't change the shape of the signal...
SHR D,#8 WC ‘get byte into D, get toggle bit into C
CMPX flag,#1 WZ ‘compare toggle bit to flag, new byte if Z
IF_Z XOR flag,#1 ‘if new byte, toggle flag
IF_Z <use byte> ‘if new byte, do something with it
SHR D,#8 WC ‘get byte into D, get toggle bit into C
CMPX flag,#1 WZ ‘compare toggle bit to flag, new byte if Z
IF_Z XOR flag,#1 ‘if new byte, toggle flag
IF_Z <use byte> ‘if new byte, do something with it
It doesn't seem to be working for me...
I will be out in the shop tonight and I will look into this.
I think I need to see of ozpropdev's logic analyzer can help me out...
The USB keyboard is easier to look at because there is no activity after key pressing stops..
There is a flurry of signals when a key is pressed and then it stops.
After a brief pause, the very last thing is an "IN" command from host and then a "NAK" from keyboard.
Those two things are very close together in time with maybe 6 clocks of space between them.
What the Prop gives me at that same time is a single $C6 byte. This is very repeatable.
Don't know how $C6 jives with the NAK... The NAK is $01 for start of packet and then $5A for NAK nibble and it's reverse...
Doesn't seem to match with the IN command either. Still deciphering that, but looks like $01 for start of packet and then $96991 but still trying to see how many bits are there.
Is it assumed that the new prop will allow it to be host or HID device? Will a board require an external USB interface for initial programming? I would assume that the USB is not usable until there is software loaded onto it already?
Is it assumed that the new prop will allow it to be host or HID device? Will a board require an external USB interface for initial programming? I would assume that the USB is not usable until there is software loaded onto it already?
I think yes to all the above, however the ROM is quite late defined ( & 16k Bytes?) , and if you look at the reference examples I gave for Silabs boot of sub 512 bytes for each of Serial, i2c and sub 1,5k for USB, it is possible that USB could fit into the ROM.
Once code is running, and proven, then such 'boot laundry list' decisions could be made.
SHR D,#8 WC ‘get byte into D, get toggle bit into C
CMPX flag,#1 WZ ‘compare toggle bit to flag, new byte if Z
IF_Z XOR flag,#1 ‘if new byte, toggle flag
IF_Z <use byte> ‘if new byte, do something with it
It doesn't seem to be working for me...
I will be out in the shop tonight and I will look into this.
This whole day got spent doing family things, but I'll be on this, first thing, on Monday. I want to get the next full release out soon. I think that the "flow" of the USB mode needs some work.
This USB keyboard with Win10 computer does something interesting during inactivity...
Normally, I think the host polls the devices continuously and the device only responds to requests from the host.
But, there is not activity at all when keys aren't being pressed. It appears that the keyboard does a USB reset by pulling both data lines down (SE0) when a key is pressed again and then there's a flurry of data transmission.
After a short pause with nothing, there's a final IN and NAK response before bus goes silent.
USB keyboard
But, there is not activity at all when keys aren't being pressed. It appears that the keyboard does a USB reset by pulling both data lines down (SE0) when a key is pressed again and then there's a flurry of data transmission.
After a short pause with nothing, there's a final IN and NAK response before bus goes silent.
Interesting, so it relies on a wakeup time, and does not have the 1ms polling.
I thought that 1ms poll had to always be there on a connected USB device.
A keyboard is probably the most-latency tolerant device, more so than a mouse or joystick.
Sounds like a great mode-pathway check for P2 as a host.
I'm interested in testing a 10 point touch screen's USB protocol (acer T232H monitor). I've worked with serial (rs232) touch screen readers previously so know roughly what to expect in terms of the touch co-ordinate byte protocol, but not so much about the usb and timing
Do you mind sharing what pins you're using to hook up your USB devices? That way any code we post back and forth will just run. I have plenty of smorgasboards to grab that board from too...
Think I just calculated low speed USB period at 53 clocks. Should be plenty of time to capture raw data to hub and then transmit sniffed packet over serial later
Ok thanks Rayman, will hook it up that way. I was thinking it could also be fairly easy just to cut usb extender cable in half and terminate to DIL pins, but lets start with the smorgasboard approach
Comments
Sure, there are two basic approaches
a) Trigger and then run like heck (aka the streamer as sampler)
This usually needs some manual clock scaling, and buffer trade offs.
b) capture the edge-set and timestamp, which has implicit compression
Approach b) has much wider dynamic range and needs far less memory than a), but it does have a lower peak rate.
If b) can use the streamer, the compression capture limit is only half the streamer limit. (but edge resolution is still sysCLK)
What does it matter? At that point, you've missed edge events no matter how they appear to the user. Just like the original version of mode %10001, if you miss an event, all bets are off!
Oops! Yes, 4MHz. Still not bad, but a bit less impressive for things like logic analyzers. However, I suppose you could switch between this mode and the streamer mode (for higher sample rates), where the obvious trade-off would be sample length.
Maybe you could add a local counter to every pin, since I assume that the sysclk signal already runs to each of the pins. Or maybe only 16 counters, where each is assigned to a cog and four pins. Or whatever strikes the best balance. Not as energy efficient, of course, but it would hopefully ease the signal routing concern.
That depends on how it is missed, and this is why I like your suggestion of absolute time capture, not capture-reset.
With capture-reset, a missed edge also loses time, with absolute time (no reset), a missed (or extra) edge does not lose correct time.
I know the streamer can capture pins, I'm less clear on what else can feed it ?
A mode where the streamer was Clock enabled by events, and captures the Pins, and then Time, in 2 captures, would give a much higher than 4MHz peak rate, and would be automatic elastic in nature.
I (and maybe Ken too) was hoping we'd stop thinking about adding new features after (or maybe before) USB was done...
Was just and Disney World and saw a Disney quote on a wall. Looked it up and here's the full quote:
“Everyone needs deadlines. Even the beavers. They loaf around all summer, but when they are faced with the winter deadline, they work like fury. If we didn’t have deadlines, we’d stagnate.”
I seem to recall Beau mentioning the need for deadlines before.
Anyway, do we have a deadline for P2 FPGA checkout completion?
Sidenote: I think we (or me at least) could use about 2 months to check new things out...
If they can all start on the same SysCLK, you have the same nett result ?
Likewise, Capture should also be many-pin same SysCLK arm-able.
I think you've mentioned a reset release mechanism that is many-pin same SysCLK in nature, sounds nearly there ?
The limit of this, is I think 32 pins is the most that can be done in one opcode ?
Where someone did want more than 32, I think the fixed offsets of doing 32+32 would be manageable in most cases ?
It used to take 10 clocks to send data to a smart pin. Longs still take 10, but words now take 6 and bytes now take 4. The cog appropriately sizes the message, based on where the leading zeros begin.
It used to take 9-16 clocks to receive data from a smart pin. Longs now take 10-18 clocks, words take 6-10 clocks, and bytes take 4-6 clocks. The smart pin message size is mode-determined. For example, USB returns words, while serial returns bytes/words/longs, based on the selected word size.
The USB is now able to respond to an EOP with an SOP in 3-4 bit periods, whereas before it was around 6-7, which was at the USB spec limit.
I need to test these new links thoroughly now.
But, I'm not having any luck...
My wireless mouse is actually running at full speed, 12 MHz, instead of expected low speed.
I changed chip's code just a bit to keep the transmitter in the idle state.
Also, moved usb to pins 30 and 31 to match that code.
The receiver is not working this way. It shows a new byte (via toggle on P7) only every ~130 milliseconds, which is strangely repeatable but very wrong.
Could be my wires are too long for 12 MHz...
The signals I'm seeing with the scope are very analog looking with a shape a lot like the Wikipedia page: https://en.wikipedia.org/wiki/File:USB_signal_example.svg
SHR D,#8 WC ‘get byte into D, get toggle bit into C CMPX flag,#1 WZ ‘compare toggle bit to flag, new byte if Z IF_Z XOR flag,#1 ‘if new byte, toggle flag IF_Z <use byte> ‘if new byte, do something with itIt doesn't seem to be working for me...
I will be out in the shop tonight and I will look into this.
The USB keyboard is easier to look at because there is no activity after key pressing stops..
There is a flurry of signals when a key is pressed and then it stops.
After a brief pause, the very last thing is an "IN" command from host and then a "NAK" from keyboard.
Those two things are very close together in time with maybe 6 clocks of space between them.
What the Prop gives me at that same time is a single $C6 byte. This is very repeatable.
Don't know how $C6 jives with the NAK... The NAK is $01 for start of packet and then $5A for NAK nibble and it's reverse...
Doesn't seem to match with the IN command either. Still deciphering that, but looks like $01 for start of packet and then $96991 but still trying to see how many bits are there.
Once code is running, and proven, then such 'boot laundry list' decisions could be made.
This whole day got spent doing family things, but I'll be on this, first thing, on Monday. I want to get the next full release out soon. I think that the "flow" of the USB mode needs some work.
Normally, I think the host polls the devices continuously and the device only responds to requests from the host.
But, there is not activity at all when keys aren't being pressed. It appears that the keyboard does a USB reset by pulling both data lines down (SE0) when a key is pressed again and then there's a flurry of data transmission.
After a short pause with nothing, there's a final IN and NAK response before bus goes silent.
It behaves more like what I'd expect...
There is a ~100 microsecond burst of data about every 8 milliseconds.
Does this have the 1ms USB presence scan too ?
Interesting, so it relies on a wakeup time, and does not have the 1ms polling.
I thought that 1ms poll had to always be there on a connected USB device.
A keyboard is probably the most-latency tolerant device, more so than a mouse or joystick.
Sounds like a great mode-pathway check for P2 as a host.
I'm interested in testing a 10 point touch screen's USB protocol (acer T232H monitor). I've worked with serial (rs232) touch screen readers previously so know roughly what to expect in terms of the touch co-ordinate byte protocol, but not so much about the usb and timing
Do you mind sharing what pins you're using to hook up your USB devices? That way any code we post back and forth will just run. I have plenty of smorgasboards to grab that board from too...
regards
Lachlan
But, my wires are short so using P32 and p33. Minus on 32 and plus on 33.
Actually I just did some solder jumpers so also have same USB on p34 and p35
This lets me capture actual pins states at same time as USB smart pin output
You know, I'm kind of looking forward to having a lot of USB things attached. Can never have too many usb ports