AVR Freaks

Only 16 bytes...

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
.

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.

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.

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.

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.

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.

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.

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

Thanks.

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.

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.

"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.

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"