Configuration for diff board but same code in Propeller Tool

MacTuxLin

Hi All,

May I know if there is a better and/or smarter way (I'm pretty sure there are, just that I need some wise advice) to keep different settings for different boards but in the same code? Example like project setting or preference setting. What I'm currently doing is:

CON

  'Board Rev 1.1
    'Snd Setting
    _Left_Snd = 20
    _Right_Snd = 21
    _Snd_SD = 22

{
  'Board Rev 1.2
    'Snd Setting
    _Left_Snd = 11
    _Right_Snd = 12
    _Snd_SD = 13
}

{
  other board rev ...
}

I'm getting to work on more than a hand full of different board configuration but still the same code so I'm worried I'll get out of hand one day

Thanks.

MagIO2

Most boards have 64kB of EEPROM. If that's true for your boards, why don't you write all those settings to the upper part of EEPROM and let your code read it from there? The code then is identical on all boards.

This way you only need to run a short setup-program once the board is build which writes the setup to the upper EEPROM. For each board revision with different settings you have one setup-program.

MagIO2

Another way is to put all those constants into it's own SPIN-file. In your main-program you'd then simply create an object of the SPIN file for the current revision. You can then access the constants of the object using the #.

For example:
REV_1_2.SPIN:

CON
_Left_Snd = 11

PUB dummy

Main.SPIN:

OBJ
C: "REV_1_2"

PUB
setup_serial( C#_Left_Snd )

You only need the dummy function in the revision-spin-files, but that won't eat up a lot of RAM when it's empty.

But it's only advantage is that you don't have constants for 10 revisions/boards in the constant section where most are commented out. I'd prefere the previous solution using EEPROMs, as this is simply fire and forget. Whenever you update the code you don't have to care about the setup (uncommenting the right section / using the right SPIN-file)

To be honest I have an even more complex approach in use. Most of these constants are for starting drivers, for example to tell the SD driver which pins to use. I put the whole driver compiled for a board into upper EEPROM. During startup I read the driver into a buffer and launch the driver. The advantage here is that the driver does not need memory in the main application, which gives the main application more memory.

MacTuxLin

Thank you very much MagIO2! A Merry Christmas to you.

Yes, using the upper EEPROM for board-specific config makes a lot of sense! Hmm, now, I'll need to see how I could rearrange the setup as I'm using boot loader occupying the lower EEPROM with the main app in upper. I've already planned to design in a 2nd EEPROM so that could be the best option.

Thanks again!

MagIO2

Why? Does your bootloader eat up all 32kB of lower memory of your EEPROM? You can simply use the memory addresses from 0 to boodloader-size for your bootloader and memory from 32k-1 to 32k-1-number of settings for your setup. The setup procedure would be:

1. Compile the bootloader and write to EEPROM
2. Compile and run from RAM the setup for the current revision, which writes the setup to upper part of the first 32k
3. Put your application to upper EEPROM as you do it usually

As long as the bootloader (and the setup of course) stays the same there is no need to rerun the setup.

Very likely your main application has less than 32k as well. So, if your bootloader only loads the portion thats occupied by the application there is no need to load the setup, as it's already there when the bootloader is booted. You can access the setup by direct addresses then, for example:

PUB main
  setup_serial( long[ $fffb ] )

if _Left_Snd has been put to memory location $fffb in the EEPROM.

This way you don't need an additional EEPROM.

Merry Xmas


PS:
To make the code more readable you can define constants for the addresses of the single setup parameters:
_LEFT_SND = $fffb
_RIGHT_SND = $fff8
...
And now my second tip is usefull, as you can put the address constants into it's own SPIN-file and use them in all setup-files and the main application.

MacTuxLin

You're a genius! OK, the additional EEPROM was initially planned to hold emergency data which are critical to the users in the event the uSD is not accessible. I think I had a misconception about writing to EEPROM from Propeller Tool so need your advice there:

1. I thought that Prop Tool will write the compiled code + 00 all the way to 32k-1? If the size of bootloader is smaller (you're right, it is very small) than 32k, is it that Prop Tool will not touch the Free area but will 00 the Variable area, is this correct?

2. For writing to upper EEPROM, I basically save the app code to .eeprom which is already 32k in size. Do you mean I should save it is binary instead?

Thank you very much for your advices.

MagIO2

It's right that the propeller tool will write a full 32k image to EEPROM, where all not needed memory is set to 0. But nobody hinders you on using all the empty memory locations afterwards!
Read the rephrased advice again:
1. Use "Load to EEPROM" for the bootloader. This will overwrite the whole 32k (lower part of a 64k EEPROM).
2. Use "Load to RAM" for your setup programs. For each revision you have you need one such program. This program simply writes the setup to whatever memory locations you decided to use. Suggestion is to start with address 32k-1 downward. You can find drivers that are able to write to EEPROM in Object Exchange. Again ... this program itself writes the setup to the upper part of lower 32k of your EEPROM, leaving the bootloader untouched. Don't load this program to EEPROM!

I don't know your bootloader, but you should makr sure that it only loads the main-program without filler-zeros. (So to say the binary version of a program and not the EEPROM version). As long as the main program is smaller than 32k-"size of setup", your main program will find the setup directly in RAM, as the full 32k bootloader-image -now including the setup-data- is loaded during boot of the propeller.

As long as there is no change in the bootloader there is no need to repeat step 1.
If there is a change in the bootloader you'd repeat step 1 and 2.
As long as there is no change in the setup there is no need to repeat step 2.
If there is a change in the setup you'd repeat step 2 - no need to repeat step 1.

3. However you put the main-program to upper 32k-(64k-1) part of the EEPROM at the moment simply stays the same.

So for question 2.: Yes. And make sure the code that copies the image to upper EEPROM can handle smaller binary files.

Take care of the size. When the binary file + size of setup is bigger than 32k you have a problem. Then you'd need some code in the main program to read the setup-data when needed.
If your bootloader is fairly small you can also put the emergency-data into the unused area.

You're welcome!

MacTuxLin

Thank you very much MagIO2!!! (~slapping my head~, that's right, make use of the empty area after write), I'm very clear now & will implement this when I'm back office.

Thank you again.