I am sure that this utility must exist, hey, there may even be a ProcessorExpert bean for it - but I don't know what it would be called or what to look under.
Having a bit of trouble getting results with ADC on HCS08 - not sure what is going on, so what I would like to be able to do is to send the value of a variable off over the UART at various steps in the code (or when I change certain inputs.)
What I want is something small and efficient that can take an int, and convert the value to an ASCII (human-readable) representation, which I can send out over the UART and view through the Linux screen utility.
I could have a stab at writing something myself, but I am sure that it would be anything but efficient, and probably not appropriate for a light-weight embedded system (I come from a high-level language background [Perl].)
Is there a tool for this ready to use and, if not, what exactly would a utility like this be called?
Solved! Go to Solution.
That utility is called 'Utility' :-)
There are are many ways to do this in C (or C++). Things like itoa() or sprintf(). But they are all not very suited for embedded system programming, mainly because of the usual code bloat, but even worse with the danger of buffer overflow. That's why a lot of programmers use their own smaller and more efficient routines. For myself I have put them into a Processor Expert component, available here: Utility
It comes with many string manipulation routines (converting a value to a string or back, formatting a value (e.g. prefixing it with a fill character) and many more. They are all implemented in a way to avoid buffer overflows, so you have to pass the size of the buffer to the routines.
Example for what you want to do:
uin8_t buf[32];
uint32_t adcVal;
UTIL1_strcpy(buf, sizeof(buf), "Val: ");
UTIL1_strcatNum32u(buf, sizeof(buf), adcVal);
UTIL1_strcat(buf, sizeof(buf), "\r\n");
UART_Print(buf);
Hope this helps,
Erich
That utility is called 'Utility' :-)
There are are many ways to do this in C (or C++). Things like itoa() or sprintf(). But they are all not very suited for embedded system programming, mainly because of the usual code bloat, but even worse with the danger of buffer overflow. That's why a lot of programmers use their own smaller and more efficient routines. For myself I have put them into a Processor Expert component, available here: Utility
It comes with many string manipulation routines (converting a value to a string or back, formatting a value (e.g. prefixing it with a fill character) and many more. They are all implemented in a way to avoid buffer overflows, so you have to pass the size of the buffer to the routines.
Example for what you want to do:
uin8_t buf[32];
uint32_t adcVal;
UTIL1_strcpy(buf, sizeof(buf), "Val: ");
UTIL1_strcatNum32u(buf, sizeof(buf), adcVal);
UTIL1_strcat(buf, sizeof(buf), "\r\n");
UART_Print(buf);
Hope this helps,
Erich
By the way, where are you getting your UART_Print() from? I can only see AsynchroSerial in the standard components library, and can't see any UART stuff on your extensions page. Whilst it's no big deal to iterate through a buffer array, sending each byte in turn, a shrink-wrapped tool is obviously preferable as, once again, I'd probably manage to do the most inefficient implementation possible!
UART_Print() was just a simple placeholder. Yes, for S08 there is AsynchroSerial which does the same kind of thing.
Maybe have a look at the FSShell component and examples. It provides a console/command interface using a serial (or USB) connection.
Hope this helps,
Erich
Thanks, Erich - that's EXACTLY what I wanted. I think the term I was looking for was "strcat."
Now I can put together a light-weight framework whereby I can, by sending appropriate characters to the MCU via the UART, get machine state back. A bit like a simple, poor-man's serial debugger :smileyhappy:
This also prepares the way for when I hook up an HCS08 to an Xbee ZigBee module - I'll be sending all the data in "plain text" rather than binary, as I've decided that all parts of my system (embedded only one part of it) will be sending data in JSON format. That binary to hexadecimal conversion (strcatNumXXHex()) will be indispensable there.
Found the problem with my ADC in the meantime. Whilst PEx refers to channel 1 in the properties of Component Inspector, the GetValue16() call is using a regular zero-starting index. Which is confusing. In my mind, a channel should have the same identifier in all views, ie: starting with zero.