Better BSP

Embedded systems don't have to suck

RANT: Why Don't You Use Vendor-Provided Tools and Examples?

I’ve had an aversion to vendor tools for a long time. I’m going to pick on Freescale here, but that’s just because I’m currently waiting for their sample code to finish downloading. All 660MB of sample code and… other stuff? My previous post was pointed squarely at ST. I love the hardware these companies put out, I just can’t handle their software or the code that they write. I’ll take emacs over Eclipse any day of the week, and most vendors these days just rebrand Eclipse. Good for lots of people, just not good for me.

Anyway, on to an example. Here’s some Freescale example code for the FRDM-KL25Z. It says this should be the content of your main() function. I’ve fixed the formatting for them a little bit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
volatile int delay;

// Configure board specific pin muxing
hardware_init();

// Initialize the UART terminal
dbg_uart_init();

PRINTF("\r\nRunning the myProject project.\n");

// Enable GPIO port for LED1
LED1_EN;

for (;;)
{
  LED1_ON;

  delay = 5000000;
  while(delay--);

  LED1_OFF;

  delay = 5000000;
  while(delay--);
}

Ok, so this starts out well. They have init functions for the board and the debug UART. Nitpick: you can use vowels, debug is just find, you don’t need to shorten that to dbg.

Next, we see PRINTF. The fact that the function name is in all caps suggests to me that it’s some weird version of printf, perhaps implemented as some kind of macro so that it outputs on the debug UART. Either way, it’s a bit scary. Also, they can’t seem to decide on whether to use Windows- or Unix-style newlines; the first one is Windows-style, the second is Unix-style.

The next line is where I start getting grumpier. LED1_EN; is not a function call. It looks to me like a side-effect free statement. (just like x; is valid, but pointless C code). But, judging by the name, this affects a GPIO register!

The body of the for-loop continues on the same way. The LED1_ON and LED1_OFF macros are gross, and the delay loops are pretty ridiculous.

I’ve ranted before about this, and I’ll do it again here: Sample code is documentation, and possibly the only documentation your users are ever going to read. By giving this as the very first example of what the code can look like, you’re teaching new developers to write garbage.

And that’s why I set up real toolchains that just use standard C libraries and some very light (and idiomatic!) macros to do embedded development.

Comments