How to deal with AT messages in correct way on STM32 MCU

Linas L · ‎2020-03-29

Hello. I was searching for information but I was unable to find clear answer. What is correct way to handle AT messages from gsm/bluetooth/gps modules ?

I am making one product that will use at least two uart interfaces (SARA-R12) and NINA-W151 modules for communication.

My understanding is that i need to use DMA so i don't get overrun, but how to deal with messages ? Track DMA transfer count,? search for messages and advance pointer after message is read ?

For ping pong AT commands reset DMA after each message ? I just want to understand how it is done by smart people, since it looks to me i have to Brut-force this problem.

Second question how much is how much flash do i need to have for complex application ? ( all i need is to do same CANBus work, send GPS coordinates to server and deal with Bluetooth emulating ELM327 module)

Planning to use STM32L552VET6, but is it big enough. I don't have feel how much code is translate to flash size

Does 512KB is a lot for this application, or i should go for 2M version of MCU ?

KnarfB · ‎2020-03-29

Here are my 5 ct: Dealing with AT commands and responses is alot about parsing and obeying timeouts and not so much about data throughput. Therefore, I would not start with DMA but with a char by char interrupt. The interrupt handler will accumulate chars in a line buffer and forward that to a higher level interpreter at the end of each line.

Once I have also used a different approach using a circular DMA for reception but not using DMA complete handlers. Instead the DMA counter is polled regularily in the main loop and the incoming chars are accumulated as above.

Haven't used the SARA-R12 but: will you use its USB interface for main data comm?

berendi · ‎2020-03-29

Fully agreeing with @KnarfB.

STM32L552VET6 can run on 110 MHz. What is your UART speed, 115200 Hz? The UART needs 10 bits to transmit a byte, so we are talking about receiving 11520 characters / second. In other words, there are almost 10000 clock cycles to process each incoming character. 100 to 200 cycles should be enough for arranging incoming data into line-oriented buffers, and notify the main loop when a packet is ready. Just be careful with the communication between the interrupt handlers ant the main task, keep in mind that interrupts can happen any time.

I would be very surprised if the code to handle all that would take more than 32k.