AVR Freaks

Fear not ... be aware.

Testing shows the presence, not the absence of bugs. - Edsger W. Dijkstra

from http://www.ganssle.com/tem/tem360.html#quotesandthoughts

Formal methods can prove the absence of defects though that's a somewhat daunting computer science course (easier now than 25y ago)

Static analysis can cover cases that won't be covered by testing.

In-lieu of the above, do what a cPLD and FPGA designer knows (Boolean algebra, combinatorial digital logic) though the solution space can be large (though usually sparse)

PSP - Personal Software Process

Discipline for Software Engineering: The Complete PSP Book

The Software Process Dashboard | The Software Process Dashboard Initiative

... until I the application I implemented mis-operated the RTOS (deadlock, process/task/thread starvation)

An event framework is an alternative to a RTOS; analogous to the event system in XMEGA and unified memory AVR.

untruth as written by one who has a Ph.D (you)

It's not age, it's health.

Our brains are made of cholesterol and fueled by glucose (fats that are a match to your body, complex sugars with fiber [fruits and vegetables])

There's nutritional therapy for brain function.

Welcome ... we who can't place our finger on it.

 

---

E.W.Dijkstra Archive: Home page

New Book About SPARK 2014 - The AdaCore Blog

learn.adacore.com - Intro to SPARK

Modern Embedded Programming: Beyond the RTOS « State Space

 

edit: strikethru

edit2: PSP has an additional book as of '05; Introduction to PSP ('96) is also in Spanish.

✎ Books by Watts S. Humphrey

 

TDD - Test-Driven Development

MDD - Model-Driven Development

Sometimes the system engineer drops a whopper onto the software developers, "This is what I want ... implement it."

A principle is a design must be executable.

One literally "walks" a design.

Likewise with specifications.

My method is different. I do not rush into actual work. When I get an idea I start at once building it up in my imagination. I change the construction, make improvements, and operate the device entirely in my mind. - Nikola Tesla

https://www.goodreads.com/work/quotes/4756-my-inventions-the-autobiography-of-nikola-tesla

 

---

Trends in Embedded Software Design « Barr Code

...

 

Trend 2: Complexity Forces Programmers Beyond C

(next to last paragraph)

Thus I predict that tools that are able to reliably generate those millions of lines of C code automatically for us, based on system specifications, will ultimately take over. 

...

MPLAB® Device Blocks for Simulink® - Developer Help

 

edit: Simulink

 

OK so here's a worked example:

 

https://www.avrfreaks.net/forum/...

 

I simply pick this thread because it happened to turn up this morning. This is not having a go at OP in that thread - just using it as a timely example. It's simple, perhaps too simple to represent a real product but the design techniques could still apply.

 

You can tell early on (from the obvious copy/paste error) that this stuff is just being "made up" in the C editor and already it has led to problems.

 

Take that sequence for reading a button that has been copy/pasted. The very fact that a significant block of code has just been duplicated should ring the alarm bells already. Programs that have sections of almost identical code repeated many times already say "no pre-implementation thought went into this". If someone had sat back and thought about this first they might have spotted the fact "I need a routine to read buttons", "I will use it for one button to increment a counter", "I will use it to read another button to decrement a counter".

 

But let's wind back. How should this have been implemented?

 

1) Specification. The customer (which might also be the implementor) needs to be pretty clear about what the "device" is actually going to do. For the purposes of illustration let's assume OP's current implementation IS the final goal so the spec is something like:

 

"A device to display a counter on three 7-seg digits with two buttons to adjust the counter up or down"

 

2) Requirements. OK so what do we actually require to implement that? Now there would be a whole section here about the requirements of the hardware but let's take that as read - we have an AVR, we have three 7-seg on a port, There are "common" to select each digit in turn, There are two buttons wired to PINB.0 and PINB.1. The software requirements would be something like:

 

2.1) require PORTB to be set as input to read the buttons

2.1.1) require PB0 to be interpreted as "count up" button

2.1.2) require PB1 to be interpreted as "count down" button

2.2) require PORTD to have 3 (active low) output to act as display commons

2.3) require PORTA to have 8 segment outputs (a..g and dp)

2.4) require button signals to be debounced for N ms (to be determined by experiment)

2.5) require decimal digits to 7 segment translation.

2.5.1) Segs a..g map to A0 .. A6

2.6) require 0 to 999 counter to be maintained

2.7) at 999 do not allow further increment of counter

2.8) at 0 do not allow further decrement of counter

2.9) require to split three digit counter into separate 100, 10 and unit digits for display

2.10) require single digit display to enable common and output one digit

2.11) require to multiplex digits so each is rewritten regularly to give the effect of all on at once

2.12) require to be able to increment/decrement counter at least 10 times per second

2.13) main loop to invoke one time initialisation then loop reading buttons and adjusting counter - also driving display

 

3) Design (numbers here relate to same section in (2)). Sketch out more detail of how each requirement may be realised

 

3.1) Only PB0/PB1 used and input so either accept power on default for DDRB or deliberately set bits 1,0 low
 Examine button logic/schematic - are pull up/down provided or should PORTB be written to enable

3.1.1) and 3.1.2) consider specific way to isolate bit 0 and bit 1 inputs

3.2) Set bits 4,5 and 6 of DDRD as output for common drive

3.3) Set whole of PORTA as output to drive segments

3.4) may need early prototyping experiments to determine best solution - just use delays in main loop or use timer interrupt polling (possibly better)

3.5) 7 segment display to use following digit shapes:
 

Assume segments are:

 

(picture shamelessly stolen from the internet! )

 

Provide a look up function to take 0..9 (range checked) and return bit pattern to select these digits on PORTA

 

3.5.1) Lookup data will be for bits in PORTA:

  pgfedcba
0b00111111 - 0
0b00000110 - 1
0b01011011 - 2
0b01001111 - 3
0b01100110 - 4
0b01101101 - 5
0b01111101 - 6
0b00000111 - 7
0b01111111 - 8
0b01100111 - 9

0b01111001 - F

Return 0..9 pattern or 'F' if invalid input passed.

3.6) As counter is 0..999 most appropriate type is uint16_t. However as lower bound is 0 int16_t better still as easy test for <0 to check lower bound. Probably global or consider passing by reference

3.7) logic such as:

counter++;
counter = (counter > 999) ? 999 : counter; // is max(999, counter)

3.8) logic such as:

counter--;
counter = (counter < 0) ? 0 : counter; // ie min(0, counter)

3.9) consider function with three member struct return to give split to individual decimal digits

3.10) function(?) to be passed new value and common drive pin to display digit

3.11) display each in turn with small following delay - should delay be part of 3.10 ?

3.12) should button reading/counter adjustment be done via ISR to guarantee temporal requirement?

 

4) Implementation.It is common to give each requirement a unique ID number then to show which parts of the code implement that requirement. Let's call them SWR_N.M to match the 2.M numbers in section 2:

// two possible approaches - either start at high level and inmplement top level
// logic then "fill in the blanks" or, per requirements, develop the support
// routines first (and test each in turn) then implement top level to pull
// together. There are arguments for both approaches but maybe start with
// top level logic:

int main(void) {
    uint8_t confidence_but0 = 0;
    uint8_t confidence_but1 = 0;

    init();

    while(1) {
        if (button_pressed(&PINB, 0, &confidence_but0)) {
            increment_counter();
        }
        if (button_pressed(&PINB, 1, &confidence_but1)) {
            decrement_counter();
        }
        split_digits = split(counter);
        display_digit(HUNDREDS, split_digits.hundreds);
        display_digit(TENS, split_digits.tens);
        display_digit(UNITS, split_digits.units);
    }
}

Peer review (or in this case me just changing my mind!) possibly suggests bad idea to use global counter - so pass by ref to inc/dec functions:

int main(void) {
    uint8_t confidence_but0 = 0;
    uint8_t confidence_but1 = 0;
    static int16_t counter = 0 // SWR_2.6

    init();
    while(1) {
        if (button_pressed(&PINB, 0, &confidence_but0)) {
            increment(&counter);
        }
        if (button_pressed(&PINB, 1, &confidence_but1)) {
            decrement(&counter);
        }
        etc.

Functions / types to implement then:

typedef enum {
    HUNDREDS = 4, // these are actual pin numbers in PORTD for each 7-seg
    TENS = 5,
    UNITS = 6
} digit_e;

// satisfies SW_2.1, SWR_2.2, SW_2.3
void init(void) {
    DDRB &= ~((1 << 1) | (1 << 0)); // two button inputs
    PORTB = ((1 << 1) | (1 << 0)); // also pull-up (this line optional - according to h/w design)
    DDRD = (1 << 6) | (1 << 5) | (1 << 4); // three common drive lines
    PORTD = (1 << 6) | (1 << 5) | (1 << 4); // display drive default high (inactive)
    DDRA = 0xFF; // outputs a..g and d.p from bit 0 upwards
}

// satisifies SWR_2.4
uint8_t button_pressed(volatile uint8_t * port, uint8_t bit, uint8_t * confidence) {
    uint8_t retval = 0;

    if (!(*port & (1 << bit))) //active low buttons
    {
        *confidence = *confidence + 1;
        if(*confidence > 80)
        {
            retval = 1;
            *confidencce = 0;
        }
    }
    return retval;
}

// satisfies SWR_2.1.1, SWR_2.7
void increment(int16_t * count) {
    *count = *count + 1;
    *count = (*count > 999) ? 999 : *count; // is max(999, count)
}

// satisfies SWR_2.1.2, SWR_2.8
void decrement(int16 * count) {
    *count = *count - 1;
    *count = (*count < 0) ? 0 : *count; // ie min(0, count)
}

typedef struct {
    int8_t hundreds;
    int8_t tens;
    int8_t units;
} split_t;

// satisfies SWR_2.9
split_t split(int16_t count) {
    static split_t retval;
    int8_t temp;

    retval.hundreds = count / 100;
    temp = count % 100;
    retval.tens = temp / 10;
    retval.units = temp % 10;
    return retval;
}

// satisfies SWR_2.10
void display_digit(digit_e dig, int8_t val) {
    PORTD &= ~(1 << dig);
    PORTA = convert_7seg(val);
    _delay_ms(1);
    PORTD |= (1 << dig);
}

// satisfies SWR_2.5
uint8_t convert_7seg(int8_t val) {
    uint8_t segs[] = {
        0b00111111, // - 0
        0b00000110, // - 1
        0b01011011, // - 2
        0b01001111, // - 3
        0b01100110, // - 4
        0b01101101, // - 5
        0b01111101, // - 6
        0b00000111, // - 7
        0b01111111, // - 8
        0b01100111, // - 9

        0b01111001  // - F
    };
    if ((val < 0) || (val > 9) {
        val = 10; // will display 'F'
    }
    return segs[val];
}

And I think that about does it. It effectively implements the same thing as the OP did in that other thread but (a) it is modular, (b) as such each sub-function could be written in any order, by different people and tested in isloation and possibly most importantly if (2) and (3) are written down somewhere there is a complete record of the requirements and design to aid the maintainer in 3 years when he comes back to this to apply a feature or bug fix.

 

The above is simple and is not rigorous. For a real project (2) and (3) are held in an immense database - many people use "IBM Rational DOORS" or similar for the upfront architecture, requirements and design.

 

One further benefit of this is that you can share (2) and possibly (3) with the customer who ordered this design.  In (2) they might not like my design for a 7-seg '6' in (2.5)/(3.5) so they could feed back there ideas into the requirements/design the this could trigger an auto request for a reimplementation of the consequences of (2.5) and so on.

 

I like to believe my design of this code is "better" than OPs original attempt because (2) and (3) made me sit down and contemplate exactly what I needed to achieve and how.

 

Of course this doesn't just "fall out". You might find that (2) and (3) actually take 6 months to a year on something really complex. Even here I probably spent an hour on the two just to illustrate this point.

 

My final implementation looks something like:

typedef enum {
    HUNDREDS = 4, // these are actual pin numbers in PORTD for each 7-seg
    TENS = 5,
    UNITS = 6
} digit_e;

typedef struct {
    int8_t hundreds;
    int8_t tens;
    int8_t units;
} split_t;

// satisfies SW_2.1, SWR_2.2, SW_2.3
void init(void) {
    DDRB &= ~((1 << 1) | (1 << 0)); // two button inputs
    PORTB = ((1 << 1) | (1 << 0)); // also pull-up (this line optional - according to h/w design)
    DDRD = (1 << 6) | (1 << 5) | (1 << 4); // three common drive lines
    PORTD = (1 << 6) | (1 << 5) | (1 << 4); // display drive default high (inactive)
    DDRA = 0xFF; // outputs a..g and d.p from bit 0 upwards
}
// satisifies SWR_2.4
uint8_t button_pressed(volatile uint8_t * port, uint8_t bit, uint8_t * confidence) {
    uint8_t retval = 0;

    if (!(*port & (1 << bit))) //active low buttons
    {
        *confidence = *confidence + 1;
        if(*confidence > 80)
        {
            retval = 1;
            *confidencce = 0;
        }
    }
    return retval;
}

// satisfies SWR_2.1.1, SWR_2.7
void increment(int16_t * count) {
    *count = *count + 1;
    *count = (*count > 999) ? 999 : *count; // is max(999, count)
}

// satisfies SWR_2.1.2, SWR_2.8
void decrement(int16 * count) {
    *count = *count - 1;
    *count = (*count < 0) ? 0 : *count; // ie min(0, count)
}

// satisfies SWR_2.9
split_t split(int16_t count) {
    static split_t retval;
    int8_t temp;

    retval.hundreds = count / 100;
    temp = count % 100;
    retval.tens = temp / 10;
    retval.units = temp % 10;
    return retval;
}

// satisfies SWR_2.5
uint8_t convert_7seg(int8_t val) {
    uint8_t segs[] = {
        0b00111111, // - 0
        0b00000110, // - 1
        0b01011011, // - 2
        0b01001111, // - 3
        0b01100110, // - 4
        0b01101101, // - 5
        0b01111101, // - 6
        0b00000111, // - 7
        0b01111111, // - 8
        0b01100111, // - 9

        0b01111001  // - F
    };
    if ((val < 0) || (val > 9) {
        val = 10; // will display 'F'
    }
    return segs[val];
}

// satisfies SWR_2.10
void display_digit(digit_e dig, int8_t val) {
    PORTD &= ~(1 << dig);
    PORTA = convert_7seg(val);
    _delay_ms(1);
    PORTD |= (1 << dig);
}

int main(void) {
    uint8_t confidence_but0 = 0;
    uint8_t confidence_but1 = 0;
    int16_t counter = 0 // SWR_2.6

    init();
    while(1) {
        if (button_pressed(&PINB, 0, &confidence_but0)) {
            increment(&counter);
        }
        if (button_pressed(&PINB, 1, &confidence_but1)) {
            decrement(&counter);
        }
        split_digits = split(counter);
        display_digit(HUNDREDS, split_digits.hundreds);
        display_digit(TENS, split_digits.tens);
        display_digit(UNITS, split_digits.units);
    }
}

Compare this to #1 in the other thread. Which would you prefer to be maintaining ?

 

I've never talked to a duck, but I have often found the solution while trying to explain the problem to somebody else. Sometimes, I'm composing a question here, and don't post it because I saw the bone-headed mistake.

Sometimes I think that Monsanto and Other Companies are putting Roundup / GMO's and other crap in our food to make us dumb enough to not be able to organize or revolt but still smart enough to keep making money they can steal.

 

On the other hand.

It seems that you have a pretty complex application and have done a mayor rewrite / refactoring without much testing in between.

Something like that is bound to fail.

No normal human being can oversee the concequences of all the details in such a big project.

 

There are a lot of methods that are supposed to help with writing better software, but they al require frequent and early testing of small parts.

In your first post you write: 

But in #9 you write about a whole lot of undocumented and untested behaviour.

I'ts very difficult to rewrite an existing (badly written?) application into something "good".

And without more discipline and thought poured into it than in the first itereation, chances are it is not going to be much better.

How many man-hours did you put in the previous version?

If I had a nickel for every time that's happened, I'd be posting this under the shade of a palm tree, while sipping on a margarita.

I was watching re-runs of old episodes of House the other day. Anyone who watches this know that he has a team of fellow doctors he usually bounces ideas off but in this episode he was stuck on a plane over the Arctic so he just picked three fellow passengers at random and had the usual "exchange of ideas" with them which naturally triggered the solution anyway! 

House.

So realistic.

We can't rule out Lupus!

 

It was thoroughly entertaining though.

wrt '(3)' :

Jack Ganssle's blog: Software Process Improvement for Firmware

January 21, 2019

[immediately before mid-page]

Fraction of budget spent on architecture

 

But that's the reason there's a feedback loop on the V model. This image from Wikipedia:

 

 

The browny/gold arrow for "verification and validation" shows the feedback. When the tests show that the implementation does not meet the requirements you re-spin that part of the design.

 

A more detailed view of the same:

 

 

In fact if you do an image search for "V model" you will see a LOT of similar diagrams!

 

etc etc.

Well everything in the system is modular (another precept of "Agile") so you already work on isolated, small packages anyway. And, yes, different modules may have different designers/design teams.

 

If you were working alone then the same would apply. You design small parts completely in isolation as long as they then deliver the interfaces needed in the top level design. You could envisage a UART module or an ADC module or similar and the 5..10 exposed functions they might provide to support the rest of the system.

I'm guessing you simply can't teach old dogs new tricks 

 

 

A very rough rule is 10K SLOC for each one.

... divide (abstract) ... communicating sequential processes (CSP) (multi-process or multi-task)

best effort, iterative incremental, one does what one can do

 

---

Communicating Sequential Processes (CSP), by C. A. R. Hoare (PDF Version)

Jack Ganssle's blog: Software Process Improvement for Firmware

[two paragraphs on 'requirements']

 

edit : one is an individual

 

Learned a lesson that the pressure relief valve oscillates therefore the pressure oscillates therefore the pressure limit is very briefly though acceptably exceeded; the software defect was to limit on peak instead of mean pressure, that led to a pressure fault, and that led to a failure of an inadvertent shutdown (my knowledge of hydraulics is from Physics 101 instead of Mechanical Engineering 401)