2

Currently I am sending the UART the strings I want to log and reading it on the host with any terminal.

In order to reduce the logging time and hopefully the image size as well (my flash is tiny), I figured out that the strings are unused in the embedded system, so why storing them on the flash?

I want to implement a server, whom I can send a hashed-key of any string (for example - it's ROM address) and the string will be output to file or screen.

My questions are:

  1. How to create the key2string converter out of the image file (the OS is CMX, but can be answered generally)
  2. Is there a recomended way to generate image, that will know the strings addresses but will exclude them from ROM?
  3. Is there a known generic (open-source or other) that implemented a similar logger?

Thanks

lkanab
  • 924
  • 1
  • 7
  • 20
  • 1
    You may want to also see this question: http://stackoverflow.com/questions/6912406/printf-debugging-library-using-string-table-decoder-ring – Ross Jul 25 '13 at 17:03
  • thanks. http://stackoverflow.com/a/17907744/724291 – lkanab Jul 28 '13 at 11:32
  • 1
    It's ok to post an answer to your own question here (and to mark it as the accepted answer.) That way future readers know how the problem was solved. – Ross Jul 29 '13 at 13:11

2 Answers2

2

Rather than holding hard-coded strings, then trying to hash the answers and sent it via a UART, then somehow remove the strings from the resulting image, I suggest the following.

Just send an index for an error code. The PC side can look up that index and determine what the string is for that condition. If you want the device code to be more clear, the index can be an enumeration.

For example:

enum errorStrings
{
   ES_valueOutOfLimits = 1,
   ES_wowItsGettingWarm = 2,
   ES_randomError = 3,
   ES_passwordFailure = 4
};

So, if you were sending data to the UART via printf, you could do the following:

printf("%d\n",(int)ES_wowItsGettingWarm);

Then your PC software just needs to decode the "2" that comes across the UART back into a useful string of "Wow it's getting warm."

This keeps the firmware small, but you need to manually keep the file containing the enum and the file with the strings in sync.

Ross
  • 1,313
  • 4
  • 16
  • 24
  • Generally it's a good idea. The only drawback is the maintenance effort. I think I have an idea, though. Hoping to update soon enough. – lkanab Jul 24 '13 at 13:40
1

My solution is sending file name and line (which should be 14-20 Byte) and having a source parser on the server side, which will generate map of the actual texts. This way the actual code will contain no "format" strings, but single "filename" string for each file. Furthermore, file names can be easily replaced with enum (unlike replacing every string in the code) to reduce the COMM throughput.

I hope the sample psaudo-code will help clarifying the idea:

/* target code */
#define PRINT(format,...) send(__FILE__,__LINE__,__VA_ARGS__)
...

/* host code (c++) */
void PrintComm(istream& in)
{
    string fileName;
    int    line,nParams;
    int*   params;
    in>>fileName>>line>>nParams;
    if (nParams>0)
    {
        params = new int[nParams];
        for (int i=0; i<nParams; ++i)
            in>>params[i];
    }
    const char* format = FindFormat(fileName,line);
    ...
    delete[] params;
}
lkanab
  • 924
  • 1
  • 7
  • 20