I am thinking about getting a Maple for black box recording to an SD card. I am looking at it because it has a lot of memory and head room as the serial data that I need, I have to first request and then wait to receive at horrible baud rates - 976 and 7812. Will the Maple be able to handle these?
Thanks,
Frank
Think about Software Serial.
Just using a pin.
And a Hardware Timer controlling the baud rate.
No, you are using really horrible Baud rates...:
976 BAUD
7812 BAUD
Sounds like Frequencies to receive some RTTY on a demodulated SSB receiver.
Since the Baud rates are very low:
Definitely, the Maple will handle those.
Its for an old Motorola ECU and those are the baud rates it uses. It is rather dumb.
The protocal is rather simple.
"You send code 0x12 at 976 baud until the ECU replies with 0x12. You then switch to 7812 baud and send 0x12 to confirm hi-speed logging, ECU replies with 0x12 if confirmed. You then send single byte memory addresses to retrieve data; ECU replies with data at the location sent."
My goal is to make a black box recorder for particular parameters instead of using a laptop. Coupled with a selector knob and SD card, I could have several different profiles of which they each log a different combination of parameters.
I have done several microcontroller projects, but I make bad assumptions. My concern is that I am going to waste a lot of clock cycles waiting to receive data. Is there some kind of hardware buffer I could use? My ultimate goal is to combine with this a display with some smoothing algorithms.
Thanks,
Frank
Nonblocking SoftSerial is throughoutly without problem on the Maple / Maple IDE:
You only have to use one or two of the four built-in hardware timers.
The timer is connected to an interrupt routine, which you do use for sending the bytes in the desired baud rate.
The baud rate could be configured up to 36.000.000 ;-)
here is an example for a SoftSerial.send(), with a non-blocking output ring buffer:
The same way, you could connect an interrupt to some receive pin to start your data receiving timer to generate the baud rate and fill your recieve buffer - independantly from the main.loop.
But: you could use also one of the 3 USART's. Ask them in the loop, if they've got a char for you, if so, store it in your buffer (fastest with DMA.)
At both baud rates, you will have definitely very, very many Processor cycles to do other stuff - as long as you arn't waiting with Delay() or While(!Serial1.Available()) do wait...
As the "baud" rate divisor that gets programmed into the usarts is computed on the fly and not pulled from a look up table, you are not locked in to standard "baud" rates. You ought to be able to do Serial.begin(976); and/or Serial.begin(7812); and use the standard serial functions and it should have a good chance of working fine.
becker
Member
Further, the underlying hardware uses a "fractional baud rate generator". This increases the transmit accuracy over a simple integer division of the high speed clock by having a correction fraction.
Not that it should matter for an async serial link, which resynchronizes with each start bit.
gbulmer
Moderator
fkatzenb - I agree with tdc218 and becker, just use one of the USARTs.
Get yourself a copy of RM0008 from ST.com to see how very flexible the USARTs are.
At such a slow data rate (less than one character/millisecond), it isn't likely the extra complexity of using DMA will save much work. Further the protocol you describe appears to be only a few bytes at a time in either direction before it needs processor involvement. So you might burn more cycles setting up the DMA for a short (e.g. 2 or 3 byte) transfer, as just dealing with the USART directly.
Using an interrupt service routine to allow the program to do other work might be worth investigating if other processing is asynchronous and can't be done using DMA or interrupts.
You must log in to post.
