Fast Simple Serial TX works, RX not so much...

Oldbitcollector (Jeff)

I'm attempting to use Fast Simple Serial (attached) in my project to save a cog.

I'm running it at 38400. The TX seems to be working perfect, but I can't get reliable data (or any data) from the RX.

Does anyone have any experience with this code?

Thanks
Jeff

Peter Jakacki

Oldbitcollector (Jeff) wrote: »

I'm attempting to use Fast Simple Serial (attached) in my project to save a cog.

I'm running it at 38400. The TX seems to be working perfect, but I can't get reliable data (or any data) from the RX.

Does anyone have any experience with this code?

Thanks
Jeff

It is fairly easy to get precise timing on transmit as the cog is controlling the timing via WAITCNT so as long as the loop is shorter than WAITCNT then it will work perfectly and precisely. However RX is asynchronous and as soon as an edge is detected there are imprecisions involved in overheads to WAITCNT half a bit time to sample and verify the start bit after which bit timing is used for WAITCNT to sample the remainder of the data. However if the start bit gets sampled late and there are other timing errors then this sampling may start to occur towards the edges rather than the middle of the data bits. The other problem is once it has received a character than it may not be fast enough to pass it along and be ready for the next. Either pace each character by using 2 stop bits from the PC etc or introduce a character delay. Obviously the only good reliable way to receive asynch data at higher speeds is to dedicate a cog for it.

Paul

I used FSS to decode a modbus stream last year because it has parity (8-E-1)
I had to modify line 88 to the following:

' rxStopBitTime := (bitTime + bitTime * parity) - 381   ' adjusts stop bit length for extra parity bit and waitcnt overhead
  rxStopBitTime := (bitTime * parity) - 381   ' adjusts stop bit length for extra parity bit and waitcnt overhead

I don't remember exactly why though. The two "bitTimes" does look weird.

Paul
/edit: I was running 19200 if it matters.

ksltd

Jeff,

Pretty funny that someone would call 38400 fast, huh?

You don't say enough about your application to know what's going on. To have a prayer of having 38400 work, you have to be running at 80Mhz. In fact, that library will fail horribly if you're not.

Then, it will only work if you call Rx before any characters are in flight - there's no way it can be used if your program isn't always sitting in Rx before data arrives. It's suitable for parsing keyboard input in response to prompts, but it's not suitable for much else. And even with keyboard input, if the user responds before the program has finished generating the prompt, the keystroke will be lost.

For it to work reliably, you'd need to dedicate a core to it and add some buffering, at which point you'd be much better off using another of the Objects that are designed to be run that way and include buffering.

lonesock

Try this version? 38_400 is right on the edge...reading multiple characters and storing them somewhere will probably trip you up, but you can do a simple echo test.

Jonathan

Oldbitcollector (Jeff)

Thanks Jonathan, I'll give it a shot

Peter Jakacki

Bear in mind that there is less than 26us if the stop bit is sampled, maybe more if your object ignores it, but Spin is very slow and you are very unlikely to be ready for the next character unless it's in a tight loop but getting out of that loop involves time consuming code too.

Just an observation but many times too much focus is given to a particular area rather than looking at the way everything works together, and this is a fault both of an OP's constrained question and the failure of the responders in not taking a wider perspective and perceiving the real problem. If now you had said this is what the other cogs are doing then it is quite possible that they could be freed up easily so that you could have a cog dedicated to serial and then other less timing critical matters could even be handled in Spin.