scpi-parser
scpi-parser copied to clipboard
j123b567
How low (in memory capacity) can we go?
My company is planning on working with TMS320F2838x MCUs from Texas Instruments.
It's Connectivity Manager (CM) has 96KB of RAM. I want to know has anyone here has gotten the parser to work in a real application with even lower memory constraints?
There are even possibilities to run this on 8-bit AVR. Primary purpose of this library are small microcontrollers.
This library has these memory requirements
- store command template table - on sane architectures this can be completely in flash without problems so it does not consume RAM. On old 8-bit architectures, this needs patching the library (AVR, '51, PIC16), but it is not your case with ARM Cortex M4.
- store full incomming command - this is limitation for situations, where you need to pass large data into the device (like signal generator). This preallocated buffer needs to be as big as the largest expected command with data. This is not a big limitation for all other purposes. There is no limitation on the size of outgoing message.
- last big memory block is error queue - this is the maximum number of errors the device can memorize.
There are no dynamic memory allocations. There are no extensive stack usages but I don't know exact numbers.
Without any command and a buffer of only 10, I increase the .text of only 11632 bytes and .data of 368 on an stm32l496 (cortex m4) So it's really small !
That will fit. I use the library with the TI Hercules family. The drivers of TMS320 are somewhat similiar to the Hercules ones - I'm using the UART one for SCPI exchange. Ping if you need an example.
@jancumps Are any of those Hercules MCUs the ones that only have 32 KB RAM?
https://www.ti.com/microcontrollers/hercules-safety-mcus/products.html#p1219=32
I'm unable to get below roughly 90K binary size, even using -Os. I'm targeting a system with 32K of ram, and slow flash. I configured the library for SYSTEM_BARE_METAL. Do you have any suggestions?
And that's just the library. All command patterns and their callbacks consume more flash. This library is written in such a way that it should follow the standards as much as possible. You can sacrifice this functionality by removing some commands.
Writing a simple command handler from scratch is also possible if you don't need these command patterns and these standard SCPI commands. It's just a tradeoff between completeness and size. Then you can say that you support the SCPI-Like interface. The more you remove from the standard functionality, the more your users will get angry. But unfortunately this is common practice for all companies, including those you wouldn't expect (including some industry-leading companies in test and measurement).
...users may express their gratefulness via disappointment through anger :)
It should be possible to get well below 90KB. We have a binary for a AVR8 (32K flash 2.5K ram) which is 20KB, and that includes dozens of quite long commands. The binary also includes a decent amount of application specific code, a USB library, and a DFU bootloader - I'd be surprised if the SCPI parser component is more than 12KB. Unless I'm missing something?
Thanks @j123b567 for the great library! Good to have some perspective on what is achievable from the comments in this thread. I was able to decrease my code size by using the --gc-sections option in my LD flags to garbage collect unreferenced sections, and -ffunction-sections -fdata-sections in my CC flags. It seems like this is the norm in embedded applications.
I will put together a build with all of my commands and callbacks to see what code size I can achieve. Worst case I can live with the performance hit of linking libscpi exclusively in flash (8x higher read latency in my case).