Best way to choose which program to load into AVR?

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Guys,

I have an application board that uses an M128. I would like to use the same board and the same M128 to load three different programs (not at the same time of course) into (board hardware stays the same for three different programs). What is the best way to do this without using the ISP or removing the M128 and reprogramming it with a different program?

Is there any way I can have an external switch (something like a DIP switch) which I can use to select either of the three programs and load it in the AVR?

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could, if you like (and if each program is small enough), have all 3 programs loaded and the DIP switch setting simply tells the m128 which program its going to run. This way you program once only.

Steve.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If interrupts are used, the said DIP switch should be tested in each ISR as well.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Steve and MBedder.

@Steve,
So how can I do it? Should I load three different hex files into my AVR? Any pointers/links would be very useful. I have never done this before. Appreciate your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would suggest you write one program to do three things. Makes life much easier when it comes to supporting it. The dipswitch can be used to select what actual function is performed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
If interrupts are used, the said DIP switch should be tested in each ISR as well.
In my opinion, the thing to testing should be a global variable which initialized from said DIP switch when program just started.
This method guarantees that selector can't be changed while the program runs and parts of main program and all ISRs will be coherent.
Some procedure can be added for periodically testing that DIP switch state and restarting the program when the state is changed.

wbr, ReAl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

npat_avr wrote:
Should I load three different hex files into my AVR?
No, independent hexes can't be combined into on program.
You should write program in next manner:

uint8_t selector;

int main() {
    initialize_selector_from_DIP_switch();
    switch(selector) {
    case 0:
        do_program_0();
        break;
    case 1:
        do_program_1();
        break;
    default:
        do_program_2();
        break;
    }
}

static inline prog0_tim0_ovf_isr()
{
    // ...
}

static inline prog1_tim0_ovf_isr()
{
    // ...
}

static inline prog2_tim0_ovf_isr()
{
    // ...
}

ISR(TIMER0_OVF_vect)
{
    switch(selector) {
    case 0: prog0_tim0_ovf_isr(); break;
    case 1: prog1_tim0_ovf_isr(); break;
    default: prog2_tim0_ovf_isr(); break;
    }
}

and so on.

wbr, ReAl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed. I ReAlAlly should have mentioned that :D

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

npat_avr,

The idea of writing one program that does 3 different things is not illegal. You know that manufacturers sometimes use this method? There is a program inside the uC that does 2 different things. The first is the production auto testing procedure and the second is the original application program.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

@Steve,
So how can I do it? Should I load three different hex files into my AVR? Any pointers/links would be very useful. I have never done this before. Appreciate your help.

Like others I don't understand why you don't put the function off all three programs into one and at power on it reads DIP then executes the appropriate section. However an off the wall idea because the 128K has so much memory (assuming each separate program isn't THAT big) would be to use a bootloader and then divide the remaining 124K into 4 pieces. At 0x7C00 you put prog1, at 0xF800 you put prog2 and at 0x17400 you put prog3. The BOOTRST fuse is set and at power on the code enters the bootloader, reads the DIP then SPM programs 0x7C00 bytes from one of those 3 addresses to 0x0000 and then finally does a JMP 0.

In this way each program can be built completely separately with its own vector table, preamble and so on then a hex editing tool is just used to rebase the image to the relevant base address.

The downside here is the 10,000 write cycle limit on SPM'ing the flash - obviously the code doesn't reprogram if the DIP switch selects the same as already copied at the last boot - it just enters it. Either each app has a unique ID that can be checked or maybe you just store 1/2/3 in an EEPROM location?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A question from the sideline
Why not use function pointers (set at boot/reset) for ISR functions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
A question from the sideline
Why not use function pointers (set at boot/reset) for ISR functions.
I prefer to avoid any non-inline function calls in ISR because of ISR must save all caller-saved registers in this case.
Great solution is
https://www.avrfreaks.net/index.p...
but it is compiler-dependent.

wbr, ReAl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your feedback, guys.
@ReAlAl:
Why would I need a timer? Can I not use the pin level change interrupts for this purpose?
Shouldn't there be a while(1) loop after the switch initialize function?

@icarus1
Thanks for the info. I did not know that. Can you give me some examples of real life products/designs that do that for my own personal edification?

@Kartman and Cliff,
I think the idea of putting all three programs into one program is probably the best to use in my case. It looks a lot simpler than Cliff's idea but I agree that Cliff's idea is also attractive. I will implement the AIO program idea first.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its common practice to have diagnostic code and the application code as one. The diagnostic code usually only gets activated when the board is being tested.

having all the apps in one means that support of the product will be much easier. When a board is supplied to the customer and you have three choices of code, odds on the wrong one will be sent. Result - unhappy customer. Having all in one avoids this issue. If there is a common defect in the code, you only need to maintain the one. I learnt this the hard way. For a given product, always seek to add features rather than have another piece of code. And have version control.