Is there a way to see a char[] on one line in live variables

[GeneM]

I’m working my way through the VisualGDB and STM UART driver examples hoping to get to a interrupt driven, DMA driver that can transfer an unknown number of bytes using idle line detection (https://stm32f4-discovery.net/2017/07/stm32-tutorial-efficiently-receive-uart-data-using-dma/).  Right now, I’m just working on an interrupt driver as a first step.  Every time bytes show up in the interrupt driver, I add them to the char messageBytes[] array.  When a LF shows up indicating the end of a message, I’ll pass the array to the appropriate function.  For now, I’d just like to visualize the array as it gets built up by the driver.  The Live Variables window is very helpful but it shows each character on a separate line which is kind of awkward for a 50-ish byte array.

Is there a way to display a byte or character array as a string or at least all on one line in the Live Variables window?  Or is there a better way?

And a very basic question: is there a string variable type that can be used in STM32 C++ embedded programs?

And a wishful thinking question: There are a lot of libraries floating around for ingesting and parsing NMEA messages from GPS receivers.  Is there a library like that that would work in VisualGDB for STM32 apps?

Thanks

[support]

Hi,

Please try enabling the live mode in the Memory window (lightning icon). This will allow viewing the contents of the buffer as it is being filled. We are also experimenting with an alternative mechanism for fetching live variable information directly from the ELF file, so we might be able to support additional variable types in the future, although it’s hard to give any estimates now.

Regarding C++, you can try using the regular STL, however it would have a considerable runtime overhead.

NMEA message handling unfortunately looks too specific for VisualGDB to handle it directly. Please feel free to ask on StackOverflow and/or STM32 forums; perhaps someone else have developed a similar application and can share some suggestions.

[GeneM]

Live mode in the memory window worked really well and I’m assuming with much less overhead than adding printf statements.  One more newbie question if you don’t mind.  Are there any low overhead functions to do things like strchr, strncmp, strtok, etc?

[GeneM]

I think I found the magic Google search secret.  If I preface my search with GCC, I can find stuff that actually works in VisualGDB.  I found string.h and that seems to have most of the functionality I’m looking for.  Thanks again.

[support]

Indeed, VisualGDB normally uses the GCC compiler (that is itself one of the most popular compilers in the embedded space), so all the solutions that work with GCC would also work with VisualGDB.

Also a heads up that our support covers VisualGDB-specific issues (e.g. help finding features like Live Memory or fixing bugs in VisualGDB itself), however we are generally not able to provide help with the external components (e.g. the GCC compiler, vendor-specific SDKs, connectivity/power issues, external libraries, etc.), as those components are outside of our control. We do offer paid consulting services for everything that isn’t covered, however in order to make sure we can allocate resources to develop our products and fix issues that are within our control, we have to be fairly strict about what we can address via our regular product support.

[GeneM]

I understand about what you can and can’t do on this forum, no worries.  Once I get a little farther along, I’ll definitely be looking for a consultant to move us up the learn curve effectively.  Do you have something that describes your consulting services and expertise?

[support]

Our consulting focuses on issues that are too specific to be supported directly by the off-the-shelf products. E.g. porting specific libraries to new platforms, porting projects between compilers or SDKs, creating tools for automatically importing large multi-project solutions in a custom format, creating BSPs and detailed setup tutorials for niche devices that are not sufficiently popular to be supported directly, etc. We also do paid screen sharing sessions helping our users troubleshoot weird problems in their codebase that would otherwise take too long to narrow down. Feel free to reach out to our sales if you need an estimate for a specific issue.

[Author]

Posts