Streaming data via smartpins
__red__
Posts: 470
in Propeller 2
I've seen mention of streaming data from the smartpins into hub memory for things like ADC sampling... is there an analog (gett'it :cool: ) for streaming data to or from serial in?
All the examples I've seen for sync/async modes for smartpins appear to be for 1 word at a time which means I still need to dedicate a cog to this communication.
Ideally, a buffer of > 1 word would be glorious.
All the examples I've seen for sync/async modes for smartpins appear to be for 1 word at a time which means I still need to dedicate a cog to this communication.
Ideally, a buffer of > 1 word would be glorious.
Comments
I am not going to do the ADC modes for the streamer. We can't easily get good quality readings that way.
It would be really neat to have the smart pins be able to stream to memory, but the streamer would have to take care of the job. That would preclude use of WxPIN from cog software, because timing of the streamer would not be known.
You can use interrupts to feed the smart pins for background comms, freeing the cog for other stuff.
I'm afraid that I may miss data on the line and lose sync.
It's not like the smartpin receiver has any way to block incoming traffic right? so to be sure I probably need to dedicate another gpio to some form of flow control.
The smartpins are doing the hard work, so all your interrupt routine has to do is store the bytes in a buffer and update FIFO pointers for whatever is consuming the data.
The cog that does that will have some overhead but should still be mostly available for other uses.
Perhaps another silly question - does this mean that I have to be sending and receiving in multiples of 4 bytes?... Not a problem I guess since I can always put a 4-byte post-amble on the end of my communication mechanism after the OET signature.
If you download Chip's FPGA files there is source code for a simple demo of the serial mode in there.
My first serial data "target" is to build something that can send telemetry from an internal debugger.
The hardware version will be run by a P1.
The emulator version will work over the network.
I think that specific example you mention is the one I should be trying to target - then the opcodes that @ozpropdev uses in his debugger shim.
(I just made the assumption that he's using serial-out smartpins - that may be erroneous)
That's currently the easiest/fastest way to move data.
The link is actually the bottleneck, the mainstream UARTS top out at 3~4MBd one way for FS-USB, and 12MBd for HS-USB UARTS.
That 12Mbd ceiling is somewhat annoying, as the HS-USB can go well above that. EXAR have USB-UART that nudges to 15Mbd.
Appealing is the speed of the FT4222, QSPI/i2c device, which claims "Up to 53.8Mbps data transfer rate in SPI master with quad mode transfer", but that's not so easy to connect.
It also does have a better price than FT232H, also strange, as you would expect HS-USB to serial to have similar platform costs.
FT232H/FT2232H does have a Fast Serial Data mode, but that needs more pins for CLK and FSCTS, looks to be good for 50MHz CLKs (100MHz+ P2)
Mike
That could actually get quite high.
( Currently, P2 cannot output a SysCLK with the data, to clock things directly at SysCLK speeds, but there are some workarounds for P2 to P2 ..)
There are already tested streams of 250MHz outgoing, to connect to HDMI, and that uses a 25MHz sync CLK/frame.
With 2 P2's running from the same master Oscillator, it depends how closely the PLLs can lock, but you might expect << 1 period.
The slave P2 could WAIT on the master CLKframe-edge (1 sysclk granular), then launch streamer RX - some small pipeline delay would exist, but if Launch TX is the same delay as Launch RX, they shopuld start in phase.
Perhaps some known header could confirm exact edge-lock, but from there, SysCLK or ~250MHz data rates, of any binary width, should be possible.
If you are more remote, and cannot use same master oscillator, then a more Async speed would be needed, there around /4,/6,/8 are upper limits, for maybe 40 MBaud Async speeds.
or, with a good TCXO moderate bursts of quasi sync could work ?
Here one P2 waits on CLKframe edge, which resolves to 1/SysCLK in time, if the data is sent at SysCLK/2 or SysCLK/3, it takes 500k clks for 1ppm error to 'walk' half a bit.
That could send 80~120Mbaud, in blocks of up to 100k CLKs ?
Of course a VCTCXO + P2.DAC could allow one P2 to sample the CLKframe, and self-adjust the oscillator to better than 1ppm, for longer block tolerance.
P2 should be able to manage the FT232H/FT2232H Fast Serial Data mode, to the spec'd 50MHz
I am not really able to understand exactly what you stated, (English is my -hmm- third language) but as far as I could follow P2 to P2 can exceed usual baud rates on FTDI USB adapters. That was, was I was asking for, so good to know.
Some years ago @"Beau Schwabe" made a demo of High speed serial transfer on the P1 for the use of transferring some block of HUB ram between multiple P1 chips. I loved that idea because of it's simplicity. I do not want to offend him in any way, but this was so STUPID simple that it took me 2 weeks to finally understand it.
His demo just send a b lock of HUB ram around X number of P1 chips. One cog for transmit, one cog for receive and around it goes, from P1 to P1 to P1 to... you get it.
The interesting thing is that most P1 cog to cog communication runs thru mailboxes in HUB ram and if those HUB ram addresses get shared thru that ring buffer one can easy(?) use cogs on other processors by accessing the 'shared' HUB address transferred around in that serial transmission.
This, of course, just makes sense if the ring-buffer-transmission is fast, else it will add to much delay.
@"Beau Schwabe"'s code reached something like 12 mbit on the P1 and I had a lot of fun using it for multi-p1 experiments.
worked like a charm.
Like other people here I would like to build some replacement for the ever and ever changing Desktop computer. Something that can last without updates for years not weeks. Or, some Work-Bench System like @potatohead described.
And a single P2 will not do it. But a couple of them might have a lot of resources to be combined, I am dreaming about this for years now.
~100mbaud is fast.
Chipmas is coming,
Mike
Does anyone happen to know the (failure?) behavior in the following cases?
Async serial rx:
1. A full word is received but not read. Another word comes in. Does that read return the first word (second word ignored) out the second word returned (first word overwritten).
2. A full word is received, a race condition where the user reads the register while the pin is receiving the next word (say on a byte boundary).
Do we get the first word, and it not futz with reception of the next word? Do we get a mix of both? (Fifo'esque?)
3. I'm pretty sure I asked this before, but do I have to read in words? If I wanted to read in single characters (say a client) can I do reading on a single char?
An associated question of 1. is does the user have any way to know they have RX overrun ?
For 2. the expected operation would be for Shift->Holding transfer to delay as needed, which can be right up to the shift-in of the first data bit moment, in a well designed system.
If the Holding was still not read, by that instant, the overrun flag (assuming that exists) would be set.
You need to poll the smart pin so you don't miss and characters.
There are multiple ways to do this efficiently.
A word can be any size you want 1-32 bits (usually 8 bits),so single characters are no problem.
A event is triggered on the rise of the smart pin (data ready) signal.
The character is read and stored in a buffer.
Apologies if someone has already told you, but you certainly can use smartpins without going through interrupts. Testing of pending events is done with WAITs or POLLs. They check the same event mechanism that powers interrupts.
Or, in the case of a smartpin, you can test the IN state of its pin#. When a smartpin is enabled, it takes over the wiggling of IN and indicates job done in some fashion or other. Just like it intercepts DIR as well - used as a smartpin reset control.