0

I am fairly new to embedded systems, though not to programming.

We manage large lists of different data structures in our application, that we fill with data parsed from incoming arrays of characters. For debugging, looking the watch for each structure doesn't seem very practical and I've thought of building functionality to print data contained in the structures to a file, so I can easily compare expected vs. results. Is this something you would do in an embedded system? What other options do I have?

To avoid increasing codesize including this only for the debug version. The system is stm32F2xx and the IDE keil uVision.

Thanks!!

Paul
  • 3
  • 5
  • 2
    "Embedded" covers a multitude of sins and to be honest I'm not clear on why you're asking us for permission. In general you ought to go ahead and use any debugging tool you find useful but what adverse effects do you expect from this one? For the record I, for one, have found this sort of technique useful in the embedded world. – doynax Mar 05 '15 at 17:20
  • I guess I could be doing something like said [here](http://stackoverflow.com/questions/13027018/debugging-embedded-system-with-eclipse-how-to-print-to-a-logging-file) or [here](http://stackoverflow.com/questions/3224583/output-debug-via-printf-on-a-cortex-m3-cpu-stalls-at-bkpt-instruction-confusi?rq=1) – Paul Mar 05 '15 at 17:21
  • @doynax My question was exactly that: "what are the adverse effects I may expect" if there's any. I think you have answered by stating you do use this technique. Thanks. – Paul Mar 05 '15 at 17:24
  • 2
    Do you actually have a filesystem on the target? If you do an space to spare then fine; otherwise it would make more sense to send that out of a debug UART or USB interface (optionally, or on explicit request) and if desired direct that to a file on the development system. – Chris Stratton Mar 05 '15 at 17:24

3 Answers3

1

It is often simpler to develop, debug and unit test purely data processing code on a PC in a test framework before integrating it with your embedded application; leaving you only with the task of debugging I/O drivers, scheduling and real-time processing on the target.

Helpfully the STM32 data type sizes and endianness are the same as those of a 32 bit x86 compiler, so there are generally no issues with data processing code portability. You might however be cautious of floating point data where results on the ARM compiler's software floating point may not be exactly identical to the x86 hardware floating point.

Certainly if you are intending to compare actual results with expected results that does rather suggest a unit testing framework. You also benefit from far greater data throughput so you can perform a great deal more testing that you might on the target. You may then only need to do minimal testing on the target in order to verify that the results are comparable to the unit test behaviour. 32 bit

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thanks Clifford. This would have been the first thing I'd do. However, in this project this approach would involve striping the fw of the code related to the STM32 (includes, flash_write calls and so on), and that'd take a long time! – Paul Mar 06 '15 at 12:31
  • You need not strip such calls, simply implement test stubs for them. Flash read/write calls for example could simply stubbed with implementations that use the file system to store the data. This is easiest of course if you have a clean distinction between device and application layer, so that there are fewer high-level functions to stub, which is good practice in any case. If your application level code is littered with very low level STM32 standard peripheral library or ARM CMSIS calls for example then you will have a harder time, and fixing that will pay dividends in any case. – Clifford Mar 06 '15 at 12:51
  • It is littered with very low level code I'm afraid... It is a code we have inherited and one of the tasks of the project is to make that distinction between layers. It will happen later on though. – Paul Mar 09 '15 at 15:57
1

I seldom use the toolchain's debugger for my embedded work, except when I'm facing a very difficult problem or bringing up a board. Rather, I usually do "printf debugging" to one of the device's serial ports, and view the output in a serial terminal program (e.g. putty) on the host PC.

This allows me to compile with optimizations and strip the resulting binaries of nonessential information and still monitor my program's execution and memory. I have a few utility functions in my arsenal to make this kind of debugging productive and I wrap the tracing/debugging code #ifdef TRACE or the like to ensure such code doesn't end up in my release builds.

I don't know about others who work in this field, but this works well for me, and I honestly don't know of a better way.

Verax
  • 2,409
  • 5
  • 27
  • 42
0

If you can JTAG into the device, then usually your can fprintf into your project directory in the host through JTAG/IDE chain.

If you can transport the parsed structures back in the same way you transport the strings in, then you can consider processing them in the host environment.

Luckily our device and host both runs Linux and uses GCC, and things like integer size, floating point format, alignment requirement, endianness are all the same on the device or the host, we had little difficulty working with raw byte stream of structs.

If this is the case for you, you can do the same.

Further, you can use mex functions to convert C struct to MATLAB struct and process it in MATLAB.

user3528438
  • 2,737
  • 2
  • 23
  • 42