Continuous Data Read Limit
gis667en11
Posts: 73
So I've been doing quite a bit of research into pushing a large amount of data continuously into the propeller. Hub access happens every 16 clock cycles, which means that a continuous write of longs to the hub from a single cog running at 80MHz happens at an average rate of 32 bits per 200 nanoseconds. This would mean that, if I wanted to read serial data and send it every 32 bits, because you might as well use WRLONG if all hub access ops take the same amount of time, you'd have to be able to get back before the next bit to catch it. So, hardware dictates that the absolute maximum possible baud rate for a single cog to pass serial data to hub is 5MHz / Mbaud. Correct? Of course with software limiting this potential significantly, I just want to make sure I'm getting the hang of the way the prop is put together.
Comments
but I think hub instructions take 8 cycles. a jump takes 4. which means you don't even have enough time to increment the HUB address and change the value between writes if you want 160 Mbps. You can only do one or the other. Let alone do something vaguely useful like read from an 8-bit parallel port four times and combine the values. I suppose it is enough time to read for a 32-bit port and write to the same hub address constantly.
start: mov value, INA wrlong hubAddress, value jmp #startFor 3Mbaud clocked serial coming in, you've got 333 nanoseconds between clocks. Would be enough time to shift the bit in, increment the hub address, and every 32 bits write the long to hub?
top waitpeq clockmask, clockmask 'wait for clock high tst ina, datamask wz 'test for data bit (need lots of hold time) if_nz or accum, #1 'insert the bit shl accum, #1 'shift it djnz count32, #top 'accumulate one full long mov cogbuffer, accum 'save it add #$-1, nextdest 'modify previous instruction mov count32, #32 'next long jmp #toplooks like nine instructions for every 32nd bit. Need to find a little external buffer somehow.If speed matters, rather than fighting serial, just use a FT240x, which has a code loop very similar to the one above.
ie You Wait for RXF low, then RD low, get Byte, Rd Hi, and would unroll the 4 byte read/shifts - this has handshake inherent, and if you can read > 2M, that's ~16Mbd, so the USB is the limit, not the Prop.
FT240 specs 8M Baud equiv.
Should be easy enough to test ?
If you buffer enough into memory, they can alternate ?
Now there are a couple of tricks to this. If you perform the block copy in reverse, ie decrement rather than increment, you can catch every hub cycle. See my overlay loader in obex.
Next, you can use 2 cogs to read the input, and flip between cogs while you do blocks. I use 4 cogs interleaved to read the input pins on every clock (12.5ns) on my data logger software.
So once you get proficient with the prop, there are a lot of tricks we can use to really soup up the prop.
And lastly you can overclock. I have been using 6.5MHz for years, but this requires special layout an decoupling!