printf for embedded

eTPU_C | | | | | |

There's only so much debugging information an LED or LCD display can report. What's worse, embedding debugging code in the executable can provoke misuse, while stripping it out can cause heisenbugs.

Your C compiler can help manage debugging information for you in a way that doesn't interfere with your product. Here's how:

Code Development Systems offer a __BCdirect() function for emitting code or other reports to the .COD file. These reports are linked to code generation: the records store the current program counter, a record type, and the specified information.

Toolchain programs that consume the .COD file to load the executable and source level debugging information can also load these records. Depending on the environment, the records can include directives to cause printf-style output to a console.

Here's an example of a printf that works with a downstream simulator:

#define printf(s, ...)      __BCdirect(b, ((ps printf s, __VA_ARGS__)))
#define fprintf(f, s, ...)  __BCdirect(b, (log f,(printf s, __VA_ARGS__)))


void main(void)
{
  for(unsigned char i = 0; i < 5; i++)
     {
        fprintf(testlog.log,"i is : %d", i);
        NOP();
      }
  printf("%s", "got here");
  NOP();
}

The embedded printf statements in source code create no generated code only information in the .COD that can be used by supporting emulator and simultors. The result is the code that is shipped is the code that is tested with no need to recompile before release.