Very rookie question about UART: DMA vs interrupt

[uliano]

For STM32 debugging, the SWV ITM console is also fast; you can set a clock speed in the MHz range. You need STLINK V3.

I just don't find it reliable.

there's also SEGGER RTT but I would prefer something less of a lock-in

[Siwastaja]

I try to follow:

you are copying relevant info to ram, in binary format (efficient) each ISR() call, and in the superloop you (slowly) dump it but only when your ram buffer is full.

by doing so (having a blocking dump) you may (and probably will) clog your superloop to the point that you probably have moved all the rest of the code to ISRs.

My projects tend to have, especially on ARM Cortex (because it has such good and simple to use interrupt priority system, including software interrupts allowing continuing a high-priority task as low-priority task), either completely empty "superloop", or superloop which does totally non-timing critical things, such as blocking networking code or UART debug printing.

Yeah, rest of the code in ISRs. That works very well. It is like event-driven programming. (Really the main difference to using threaded RTOS is, with simple interrupts, tasks are always triggered so that function execution starts at the beginning, while RTOS threads can have longer functions that wait for other signals and continue execution. In bare-metal (no OS) project, you only have ONE thread capable of that behavior (what you call superloop). Sometimes I take advantage of that; sometimes not.) Interrupt-driven bare metal works very well in projects where you don't have dependencies on poorly designed, blocking libraries.

Besides, blocking UART print has completely predictable timing.

why you wait for buffer full before start dumping? to simplify (and fasten) things without the circular hassle?

That was just a made-up example which I wrote in 3 minutes in the reply window, to communicate the idea with code instead of wall of text. Obviously you choose what you exactly want to do. For periodic interrupts (like control loops), checking for "trace full" condition is good because it happens quickly anyway, and if you have too much data, just ignore the rest.

also i miss completely the role of trigger_condition :-(

I mean something like a pushbutton "start recording", or maybe trigger it when motor turns on, some voltage level is exceeded, or maybe even leave that code in production and trigger on an error condition. What I show is, after all, pretty equivalent to what storage oscillosscopes do, but with insight into internal state variables if you so wish.


The only other (possibly even better performance) option really is hardware trace monitor system (like Segger RTT and friends). The massive advantage of your own code instrumentation is, it works in production, over the air, whatever. You don't need to plug in a debugger and hope to catch the event on the lab table!

And performance gain between printf() and binary data collection is probably nearly two orders of magnitude, and same can be said about RAM usage. You get much longer trace in the same amount of RAM when you don't need to store repeated text labels, separators, or inefficient decimal numbers.

[uliano]

In bare-metal (no OS) project, you only have ONE thread capable of that behavior (what you call superloop). Sometimes I take advantage of that; sometimes not.) Interrupt-driven bare metal works very well in projects where you don't have dependencies on poorly designed, blocking libraries.

I used to keep an event (one or few bytes each) queue loaded in ISRs and processed in superloop, but then AVR interrupts were much simpler.

I should spend time (lots of it) reading manuals and re-thinking about all that stuff.

[Siwastaja]

Note that not everybody agrees with me. But I have worked that way for some 6-7 years now and have zero regrets. I think it boils down to this difference: instead of setting a "process data" flag in a fast peripheral ISR, trigger a software interrupt (NVIC->STIR = MADEUP_IRQ_NUMBER, anything that does not clash with peripheral IRQ numbers you want to use) and do the processing there. The rest is the same: instead of processing the data in superloop, you are processing it in an ISR. Both will be interrupted by further high-priority interrupts. Then you set the interrupt priorities to control what pre-empts what.

Periodic housekeeping tasks can be done in a timer interrupt, which can be of fairly low priority.

[AVI-crak]

I should spend time (lots of it) reading manuals and re-thinking about all that stuff.

For real-time tasks, for sharing with an external hardware solution that has its own quartz, for controlling motors or other inert loads - printf () cannot be used !!! This was one of the reasons printo() existed - a very quick answer.

In fact, you have completely different problems that have not yet manifested themselves.
1) You need a galvanically isolated channel. All designs with power supply from the network - require galvanic isolation. Concurrently - this data channel can later be used as a manager.
The simplest and most lame option is to use an ESP8266 or something similar.
The solution is a little more complicated - to use a galvanic isolator. This option will evenly add headaches on the hot and cold side, but is guaranteed to save you money.
2) You need to review all the lines of printing in the context of the relevance of the moment of application. It makes no sense to accumulate tedious reports, you do not have accounting there. Even if at some point the current exceeded the allowable limit - there is no point in sending 100500 messages about this, just make a decision on the spot. For example, by changing one or more control signals - so that the current becomes less. And then you can send a message.

[Siwastaja]

Even if at some point the current exceeded the allowable limit - there is no point in sending 100500 messages about this, just make a decision on the spot. For example, by changing one or more control signals - so that the current becomes less.

Here, you are just saying "don't make any bugs" in a convoluted way. Of course exceeding current is dealt with by changing the state to something that will lower the current.

But visibility into the system is needed because we make false assumptions and human errors, and introduce bugs. Having logged internal state around the happening, you improve your chances of finding and fixing the bug.

Besides, there are cases when the system is kinda working, but not optimally. For example, a control loop might cause the current to go out-of-bounds, and a pulse-by-pulse safety comparator triggers on every cycle, which might manifest itself as suboptimal performance of motor. You need visibility into the control loop calculations to understand what is happening and how to make it better.

[Siwastaja]

Here is an example plot of a csv coming from a short trace of a motor controller ISR which worked the way shown above. Way more information than a few debug prints.

[NorthGuy]

My idea, as inexperienced hobbyist, is to use a ring buffer and drop (to /dev/null) incoming text when it is full. This because I think that on most (at least those who controls mosfets, motors, devices, ...) MCU firmwares stopping isn't an option, and a log with "holes" in it is still providing me information (even where the hole starts!).

Collecting status information on your FETs and motors is a task which is completely different than providing printf() facility to your program - neraly nothing in common.

Imagine you have a hammer. It can be used to drive nails, but some may also be used to pull nails. You can collect extensive information on how to drive nails with the hammer, but all this information will be completely useless if what you want to do is pulling nails. Same with UART. This is a tool, just like a hammer. Any design starts from the task, not from the tools. Imagine what an architect would achieve if he started a design for a house from writing instructions to the carpenter on how to swing his hammer.

If you want to collect data, first start by calculating bandwidth. Say, you have a 30 kHz control loop interrupt where you need to adjust PWM for your motor. Say, you want to collect two bytes of information each interrupt. This is 60 kBytes/sec. Clearly, if you run UART at less than 600 kBaud you will have losses. But if your baud rate is above 600 k then you can transmit all your data. So, running UART at 1MBuad would work fine, assuming there's enough bandwidth on all the path from your MCU to the PC to transport at this rate.

Then you analyze how the data originate. For example, if you want to transmit from your 30 kHz control loop then your data originate at regular intervals - 2 bytes every 33 us. Your task it to pass the data to UART. Obviously, by the time you need to transmit, the data you passed to the UART from the previous interrupt is already gone and UART hardware is empty. Thus, there's no need to verify anything - simply push your data.

Then you think how to pass the data to the UART. Here you consult your datasheet to figure out if it is possible to pass two bytes one immediately after the other. Most UART modules can do this because they have built-in FIFOs or shadow registers. Assume yours can do this. Then you just write your 2 bytes to the UART module register from your ISR and nothing else needs to be done - only two lines of code.

Then you think what you do on PC. PC has lots of resources and naturally this is the place where you want to do most of the processing. You need to establish the data position in the stream of bytes (because there may be a shift by one byte), then you can do whatever you want - log it, plot it, or whatever it is you're passing data for. If you cannot program on PC, use the same C which you use on your MCU - works just as well, even better.

The above is not an instruction on what you must do. I actually don't know your task, so I cannot know how to solve it. Rather, this is meant as a demonstration of how, by thinking logically, you can simplify your work and create a simple and reliable solution. If you start thinking about the real task you need to perform, you will find a good solution. But you will never find a generic solution which works for all possible situations.

[AVI-crak]

Here, you are just saying "don't make any bugs" in a convoluted way.

There will always be mistakes. If there is a possibility of an error, then it must first be corrected, and only then reported about it.
A quick response is much more important than a message to the user. Actuality!!!

[Siwastaja]

Here, you are just saying "don't make any bugs" in a convoluted way.

There will always be mistakes. If there is a possibility of an error, then it must first be corrected, and only then reported about it.
A quick response is much more important than a message to the user. Actuality!!!

You misunderstood. Nothing of this had anything to do with user interfaces. The idea is to collect data during development, and even in production, for the developers, to enable bughunting.

[AVI-crak]

Maybe you are right.
Printing messages and collecting logs are different processes. We need to decide on a direction.

[peter-h]

It would be interesting to see some code which simply extends the UART TX and RX FIFOs, using DMA and RAM, with functions like ipqcount, opqspace, readbuf, writebuf. That's basically what is needed.

[dietert1]

Remember using STM32Cube and HAL library with DMA for UART. DMA would receive into a circular buffer. After some hours i learned how to extract chunks of incoming data from that buffer. The application main loop was polling the DMA request state and then parsing available data without terminating the original DMA request. There was only one DMA request at boot time and it would continue forever, unless some error happened like buffer overrun. That software could run for days streaming in megabytes of data. I wouldn't want to implement all that from scratch.

Regards, Dieter

[AVI-crak]

I wouldn't want to implement all that from scratch.

There are literally 20 lines of code - the kind that do useful work. You just need to peel off the husk, and it will become beautiful and compact.