USART in SPI mode for reading 128 bit stream at 25,000 bps

Go To Last Post
46 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will be trying to capture a stream of 128 bits at aprox 40uS intervals. I know I can do this easily with counter/timer interrupts, although the interrupt latency could introduce some jitter, but I'm thinking of using the USART in SPI mode. The application has to do some time-consuming pattern comparisons, and I rather like the idea of no variable latency and having the hardware do the de-serialization.

I don't know if anyone's done this before, I guess I'll have to waste a GPIO or two on clock and TX, but it's a Mega2560, and I have oodles of GPIO...

 

Four legs good, two legs bad, three legs stable.

Last Edited: Thu. May 14, 2020 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Was there a question in there John, otherwise sounds like a good plan.

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
stream of 128 bits at aprox 40uS intervals
Is the single bit time 40uS or is it 128 bits every 40us? If you can
John_A_Brown wrote:
do this easily with counter/timer interrupts
I am assuming you mean the bit time is 40uS, but just to be sure...

 

Edit: Silly me, I guess I didn't read the topic heading!blush

David

Last Edited: Wed. May 13, 2020 - 02:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. Bit time is 40uS.
I guess the question is, has amyone done this, and are there any gotchas.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
and are there any gotchas.

I guess that depends on what you will do with the data, not much room to store it.....

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Main question is :

What else do you need to do at the same time ? 

 

using the SPI in USART mode

Does your data stream have the needed start and stop bit's ?

 

Else you need to use SPI mode, where you start sending when the line change first time. (I guess after half a bit time some thinking of SPI  mode needed). Then read the incoming data and make sure you keep the transmission going without holes.  

 

 

Last Edited: Wed. May 13, 2020 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

John_A_Brown wrote:
and are there any gotchas.

I guess that depends on what you will do with the data, not much room to store it.....

 

Jim

 

Only 16 bytes...

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Does your data stream have the needed start and stop bit's ? "

No.

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Only 16 bytes...

Duh....   I must have been thinking bytes, or k-bytes or something.....  

Oh well, good luck with the project.

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

capture a stream of 128 bits at aprox 40uS intervals

ok, you previously said each bit is a 40us interval.  By stream do you mean a non stop onslaught of bits, where you compare 128 against some pattern?  Or is this: send 128 bits wait a second & sending another 128 bits? 

 

 time-consuming pattern comparisons,

such as?  how much time? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. May 13, 2020 - 07:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's 128 bits every 10mS or so. I can do.it anyway, I just wondered if anyone had any insight into using the SPI hardware. What else does the app have do? It has to find the best mstch from 40 or so saved bit patterns, by exclusive ORing and counting the zeros
.

Four legs good, two legs bad, three legs stable.

Last Edited: Wed. May 13, 2020 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need a way to quickly count the zeros, here is a way:

  clr   totzer
  sbrs  mybyte, 0
  inc   totzer
  sbrs  mybyte, 1
  inc   totzer
  sbrs  mybyte, 2
  inc   totzer
  sbrs  mybyte, 3
  inc   totzer
  sbrs  mybyte, 4
  inc   totzer
  sbrs  mybyte, 5
  inc   totzer
  sbrs  mybyte, 6
  inc   totzer
  sbrs  mybyte, 7
  inc   totzer
  ret

there are some others here

https://www.avrfreaks.net/forum/counting-1-bits-byte#comment-2916391

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Split delete post posts to here https://www.avrfreaks.net/forum/...

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I found that thread a couple of days ago. It has some neat tricks, but I might just go for a 256 byte lookup table from the outset. Right now I have no idea about timing. I used yo write a lot more in assembler, and have a good feel for cycle counts, but after more working with ARMs and suchlike I'm out of practice.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right now I have no idea about timing

Well, if another blast of 128 bits is coming every 10ms (200000 single cycle at 20 MHz), you might first want to know if there will be time to do all of this slow checking & whatever else you're doing.  It's probably doable, but that will put a load on the AVR.

 

If speed was problematic, some programmable logic would be a good candidate. 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:

I guess the question is, has amyone [sic] done this, and are there any gotchas.

I've done this in reverse - to generate an arbitrary bit-stream of 840 bits with invariant timing. This used one of the SPI modules on PIC24 where I had the luxury of a small hardware FIFO to avoid gaps in the bit-stream.

 

Even though you only have 128 bits you may need to oversample somewhat. I think you'll find things easier if you also use a hardware FIFO. Is your UART also a USART (has synchronous).

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

John_A_Brown wrote:

I guess the question is, has amyone [sic] done this, and are there any gotchas.

I've done this in reverse - to generate an arbitrary bit-stream of 840 bits with invariant timing. This used one of the SPI modules on PIC24 where I had the luxury of a small hardware FIFO to avoid gaps in the bit-stream.

 

Even though you only have 128 bits you may need to oversample somewhat. I think you'll find things easier if you also use a hardware FIFO. Is your UART also a USART (has synchronous).

 

Apologies for the typo.

Why do you think I might need oversampling?

I think if the whole thing is interrupt driven, I should be OK with the double buffering that's part of the USART. It's not that fast - 320uS for a byte. Mega2560 running at 16MHz.

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now we are back to my questions in #6

 

What else do you need to do while this happen?

 

If you use a UART you will need some start and stop bit you don't have 

 

(Or am I missing something).

 

About oversampling : Is the signal 100% clean ? ,a normal UART has a median filter, you will need oversampling to make something like that.

 

If you don't sync somewhere the receiver (and transmitter) has to run very precise!

Perhaps use edge interrups and see how many bits since last change. That will keep you in sync. 

 

Add:

I assume that you don't have a clk. in the data stream.

 

Last Edited: Thu. May 14, 2020 - 01:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
What else do you need to do while this happen?

Like I said, find the best match from 40 or so stored 128 bit patterns.

No start and stop bits, I believe they're not used when the USART is in SPIM mode.

 

I apologise for the misleading thread title, should have been "USART in SPI mode". I'll change it...

 

With the best will in the world, I don't really need advice on how to do any of this, apart from asking if there are any things to look out for when using USART in SPI mode to sample what is, effectively, a series of highs and lows. Using an edge interrupt would be unhelpful, as there can be the occasional glitch or three.

I don't need bit sync, as it's simply a pattern best-match exercise. The friend I'm helping out with this has done all the analysis of the principles in a spreadsheet(including glitch simulation), it just remains to write the code to do it in real time.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recommended oversampling because if you were unlucky enough to be sampling exactly at the bit transitions; any jitter or even noise could result in bit errors.

 

If you do like a real UART and oversample at x16 you'll generate huge amounts of data, but it'll be fairy clean and perhaps easier to analyse. I suppose its a trade-off.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are no bits, as such. Once again, I fear I have used confusing terms. I'm only interested in the general shape of the input. It's a rectangular waveform, high if the original analogue signal is rising, low for falling(status quo for flat). Depending on the amount of hysteresis, and preceding LPF, it can be a bit glitchy in places. But as I said, the principle has been tested in a spreadsheet, with added "random" errors. I used the word bitstream inadvisably. Maybe I should have said rectangular waveform.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

high if the original analogue signal is rising, low for falling(status quo for flat).

One bit that has 3 levels ?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

high if the original analogue signal is rising, low for falling(status quo for flat).

One bit that has 3 levels ?

 

 

No.

Two levels.

Status quo was supposed to indicate that the rectangular wave would maintain the previous level in the presence of a "flat" original analogue input.

So that's high for rising, low for falling, no-change for flat.

Sometimes I forget that Latin is not everyone's mater lingua.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 high if the original analogue signal is rising, low for falling(status quo for flat). Depending on the amount of hysteresis, and preceding LPF, it can be a bit glitchy in place

bit stream?  Uart?   Takes 20 post to now say there are no bits????  now analog waveform & filter?  Your problem statement seems to be all over the place??   

Maybe time to start over to say what you are doing.  If it is analog, did you ever describe the waveform--is there any clocking involved?  Or is this some signal going hi/low on a comparator?  What is considered a bit? Is it really that tough to describe?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. May 14, 2020 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

 high if the original analogue signal is rising, low for falling(status quo for flat). Depending on the amount of hysteresis, and preceding LPF, it can be a bit glitchy in place

bit stream?  Uart?   Takes 20 post to now say there are no bits????  now analog waveform & filter?  Your problem statement seems to be all over the place??   

Maybe time to start over to say what you are doing.  If it is analog, did you ever describe the waveform--is there any clocking involved?  Or is this some signal going hi/low on a comparator?  What is considered a bit? Is it really that tough to describe?

It's not a problem statement.

 

I don't have a problem. You may have a problem understanding what I'm going to do, and that may be my fault, in which case I'm sorry.

 

As I've already said, I'm not asking how to do this. I know how to do it.

 

I just enquired as to whether anyone else had used the USART in SPI mode in a similar fashion, and if so, was there anything I should look out for.

 

But to answer your questions, there is an analogue signal, which is precision rectified, low pass filtered, and then fed to a comparator circuit that determines if the signal is rising or falling, and the comparator outputs a high or a low accordingly. I am interested in sampling this digital signal every 40uS for a total of 128 samples. Then I will compare these 128 samples with a selection of stored patterns to determine the best match. This process will repeat every 10mS. I have written some test code, and I can do the best-match function in about 2.8mS without resorting to assembler.

 

I'm only stating this because I'm nice, and it seems like you want to know. I am not asking for advice on how to do it.

 

And yes, I know that I could scrap pretty much all of the analogue circuitry and do the whole thing with a bit of DSP, but I'm helping a friend with his project, so it's not my decision. I can only advise and offer support.

 

 

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The biggest problem MAY be how to maintain timing across byte boundaries. Normally, I would suggest a gap a byte boundaries to allow for processing time in the receiver. But, from your description of the process, that may not be possible in this project.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

The biggest problem MAY be how to maintain timing across byte boundaries. Normally, I would suggest a gap a byte boundaries to allow for processing time in the receiver. But, from your description of the process, that may not be possible in this project.

 

Jim

I believe that if I use the USART in SPI mode that I will benefit from the double buffering that exists in the USART hardware. But to be honest, now I know I can do the pattern (best)matching in under 3mS, if I have to stick to timer interrupts and sampling the input in code, it'll still be fine, as long as a few cycles of jitter owing to the interrupt latency don't have a noticeable effect.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Then I will compare these 128 samples with a selection of stored patterns to determine the best match.

Alexis order more TP,  order confirmed! devil

 

I love shouting that when I enter my sister-in-laws house!

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the details.. .it make a lot more sense now...this first sentence sent things way off:

 

I will be trying to capture a stream of 128 bits at aprox 40uS intervals.

 

No device is spitting out bits at the avr...this is just building a sampler, somewhat like this:    I will be sampling a comparator output every 40uS in blocks of 128 samples, every 10ms.

So  you can provide the desired blocks of clocking to take the samples. Unless you have other alternative, this should be effective.  

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

John_A_Brown wrote:
Then I will compare these 128 samples with a selection of stored patterns to determine the best match.

Alexis order more TP,  order confirmed! devil

 

I love shouting that when I enter my sister-in-laws house!


No. It's not speech recognition. I'm not quite stupid enough to think such a system would have any chance of working.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
I guess the question is, has amyone done this, and are there any gotchas.

 

Full disclosure, I have never done this. If you keep the UDR fed so that the transmit shift register doesn't run dry until the last byte I can't see why this won't do exactly what you want.

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
But to answer your questions, there is an analogue signal, which is precision rectified, low pass filtered, and then fed to a comparator circuit that determines if the signal is rising or falling, and the comparator outputs a high or a low accordingly

Things are much clearer now - this a bit like a sigma-delta modulator where you decimate the stream of 1s & 0s, do some digital trickery; and get a nice number at the end.

 

I'd say "go for it" you should have a prototype knocked up fairly soon. Of course to test it you'll have to generate a known stream of 1s & 0s like I described in #16.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

John_A_Brown wrote:

But to answer your questions, there is an analogue signal, which is precision rectified, low pass filtered, and then fed to a comparator circuit that determines if the signal is rising or falling, and the comparator outputs a high or a low accordingly

 

Things are much clearer now - this a bit like a sigma-delta modulator where you decimate the stream of 1s & 0s, do some digital trickery; and get a nice number at the end.

 

I'd say "go for it" you should have a prototype knocked up fairly soon. Of course to test it you'll have to generate a known stream of 1s & 0s like I described in #16.

 

That's exactly what I am planning as the next move.

Thanks.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On a project I used a 433MHz remote control, (from cheap AC relay switches), and the data pin of the receiver to a AVR input.

Because it come relative fast, and the micro has to a lot of other things at the time, I had to sample to a buffer, one byte at the time. (sample speed 64KHz). And then decode later

 

For what you now tell I would do about the same, just sample the PORT 128 times with a timer ISR, (perhaps and the other 7 bits away so the sample would be zero or none zero).

The AVR is not that fast a bit compares.

But it depends of what kind of patterns you are looking for. 

 

I have also made SW decoder for AIS (9600 baud), and there a simple auto correlation was good (and fast), to find start and get a good phase lock.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

On a project I used a 433MHz remote control, (from cheap AC relay switches), and the data pin of the receiver to a AVR input.

Because it come relative fast, and the micro has to a lot of other things at the time, I had to sample to a buffer, one byte at the time. (sample speed 64KHz). And then decode later

 

For what you now tell I would do about the same, just sample the PORT 128 times with a timer ISR, (perhaps and the other 7 bits away so the sample would be zero or none zero).

The AVR is not that fast a bit compares.

But it depends of what kind of patterns you are looking for. 

 

I have also made SW decoder for AIS (9600 baud), and there a simple auto correlation was good (and fast), to find start and get a good phase lock.  

 

Thanks. But I repeat once more, I'm not looking for advice on how to do this, unless you have personal experience of using the USART in SPI mode for a similar purpose.

 

As for the AVR not being that fast at bit compares, you may have missed that I wrote that code to check timings, and I can find the best match out of 40 stored patterns in under 3mS. So fast enough.

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And that I have , and I gave the answer in #6, (when you did't tell us what it was what you wanted).

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems to work well. I tested it on an Arduino Mega2560 PCB. The clocking pin for USART1 in SPI mode isn't connected on the PCB, apparently, so only wasting one pin(TX1).

Apart from not having to worry about variable latency, as would be the case if I was using a timer interrupt and reading the input, it does all the deserialisation as well. All in all it's pretty neat.

 

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so only wasting one pin(TX1)

If you don't enable the TX then nothing would come out on the pin. (same as for the XCK)

 

(Enable pin's and the USART are independent, it will run without any IO's enabled, if you just want it for timing, shifting etc.) 

 

Add:

Same as interrupt, you can just enable the (in this case TX interrupt), when you have received a byte, and pool it (you have to clear the bit your self).

Last Edited: Mon. May 18, 2020 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"If you don't enable the TX then nothing would come out on the pin. (same as for the XCK) "

 

Is that true?

My understanding was that I have to keep the TX fed with bytes, as that what drive the SPI engine. Therefore I assumed I had to have TX enabled.

I will test it...............

 

Interesting. If I don't enable TX, then I still get RX done interrupts(although I haven't checked at what frequency), but all the data samples on the RX pin are zero, regardless of what the physical RX pin is doing.

That's not any use to me, but it's not what I expected. I could do more tests to find out what's happening, but it's not important to me.

 

 

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That sounds a bit odd

 

In USART mode you will get a TX done interrupt when you have written to UDR, (And also a RX it seems, but that make scene since you also receive a byte).

But disable the TX pin should not change anything, are you sure that you don't disable RX as well? (the enable bits is in the same byte)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the datasheet...

 

"Using the USART in MSPI mode requires the Transmitter to be enabled, that is, the TXENn bit in the UCSRnB reg-ister is set to one. When the Transmitter is enabled, the normal port operation of the TxDn pin is overridden and given the function as the Transmitter's serial output. Enabling the receiver is optional and is done by setting the RXENn bit in the UCSRnB register to one. When the receiver is enabled, the normal pin operation of the RxDn pin is overridden and given the function as the Receiver's serial input. The XCKn will in both cases be used as the transfer clock"

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


ok I stay corrected, it just brake the normal rules.

 

Add:

And I just looked at the diagram of the usart :

 

And from that there is no reason that TX need to be enabled.

But later they also write:

So they really have to point out that what you try to do don't make sense ;)    

(But it's is because it differ from the diagram)   

Last Edited: Mon. May 18, 2020 - 01:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

So they really have to point out that what you try to do don't make sense ;)    

It makes every sense - I use a simple sigma-delta ADC that is SPI read-only so when the DATA_RDY line goes low you just clock the thing and readout 4-bytes of data. The ADC has the equivalent of MISO only, it has CLK of course.

 

Now you could make an argument for the CLK being essential in Master Mode but in my #16 example I didn't even need that. If I were writing John_A_Brown's example on PIC24, I could get around this by not allocating any physical pins to the unwanted functions.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a surfeit of I/O pins. I can live without the TX1 pin.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When the Transmitter is enabled, the normal port operation of the TxDn pin is overridden and given the function as the Transmitter's serial output. 

Typically, to actually see an output the DDR bit must be set to get an output at the pin itself.  Other wise, it  remains internal. Maybe that varies among the devices.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For anyone who reads this thread with an eye to doing something similar, one thing to remember is that if you re-write the baud rate divider register, it resets the divider. This is relevant if you are trying to sync the sampling to some other trigger, which I am doing with this project.

 

Four legs good, two legs bad, three legs stable.