CODEWITHSUNDEEP
cembeddedtdd
breaker
breaker

Reputation: 21

TDD for Embedded C : How to Design Tests for LED Driver?

I m newbie to TDD and following "Test Driven Development for Embedded C edition 3".

Find a very interesting question brought by the author. It's under Getting Started->Testing Your Way to Done->Put the knowledge to Work, P103:

  1. Our hardware engineer informed us she could save $0.12/board if the LEDs used inverted logic. Modify the LedDriver and its tests to use inverted logic. How could our tests or design be improved so that most of the tests don’t care about inverted logic?
  2. Our company just completed the version of the board with inverted LED logic. We find out that some of the previous version are still in the field. How should the LedDriver and its tests be modified to support both versions of the hardware? Conditional compilation is not part of a correct answer. We want one binary.
  3. The production board’s silkscreen is wrong! LED 1 is labeled 16, Led 2 is 15, and so on. How do you modify the tests and code to work with the real hardware?

Is there any best practice I can follow to modify production code or test script in these cases?

B.R.

Upvotes: 1

Views: 359

Answers (1)

Lundin
Lundin

Reputation: 213950

Generally, this sounds like a task for the programmer, not the tester.

If you write to a port with active high logic, then you'd use PORT |= MASK;, otherwise PORT &= ~MASK;. The main problem here is that we need different operators depending on polarity, so the naive solution would be:

if(active_high)
  PORT |= MASK;
else
  PORT &= ~MASK;

This produces overhead code though. The best solution is if we can generate MASK at compile time and always have the code do PORT = MASK; without destroying any other non-related port pins. Which in turn means that this needed to be considered as early on as during hardware pin routing!

Assuming the PORT = MASK; solution is possible, then you might do something like:

#define LED2 (1u << 2)  // active high
#define LED1 (0u << 1)  // active low
#define LED0 (1u << 0)  // active high

#define MASK (LED0 | LED1 | LED2)

Or if you will: #define POLARITY 1... #define LED2 (POLARITY << 2) ...

That being said, one of the most important skills in engineering is critical critical thinking/scepticism and thinking outside the box.

So if the hardware engineer says that they can save $0.12/board and your company makes millions of boards, give a thumb's up. If you sell hundred or so per year, and the fix will take you several days of work, then maybe tell them to get lost, because the programmer's salary for fixing it will cost many times more than any money "saved" during the lifetime of this product.

Similarly, "conditional compilation is not part of a correct answer. We want one binary" is a pre-mature requirement. If you screw up the silk screen on a prototype board, the best solution is to deliver one binary for that screwed-up board, until the point where you roll out the next PCB version and then you permanently change the firmware at that point in time. These things should generally be handled by version control, not by conditional compilation. Make a separate branch for the screwed up board, problem solved.

If that isn't possible, well... when designing the board, it is also possible to do tricks like sacrificing 4 GPIO pins, set them as inputs and tie each to Vdd or GND in order to form a binary number. The MCU can read the pins to tell the hardware version of the board and there's room for 16 revisions. Then you can have one binary that supports every single version.

Always question the requirements!

Upvotes: 0

Related Questions