Adding lines to a hex file?

Other Hardware 3rd Party Boards
1

All the reading I've done doesn't say I can't put bytes in un-written-to AVR flash by adding lines to the hex file.

I have a function that uses a data table and arrays that can get big enough to be a PITA using PROGMEM lines in source. When the number of words in a table can top 1K, it's time to simplify.

There is no problem with adding lines to write bytes to most any page is there?

With a bootloader that allows writing to flash in runtime, perhaps it will be easier if I define my own data spaces rather than having Arduino IDE do it?

It would also let a general purpose sketch run different data sets added to the hex file post-compile.

2

That double negative first sentence is a doozy. Sure, you can add lines to a hex file. Every time you recompile.

Seriously, why would you want to make the process harder than just compiling and downloading? Are you forgetting that any program download will erase the table? Put the table in its own file and fugetaboutit.

3

There are two common ways to handle large tables from some sort of binary file:

Both are better than trying to edit the .hex file, and are about equivalent in "complexity impact" to the build process. Even (1) works with surprisingly large files. I about had a fit when I discovered someone at work was using the utility that had been designed for microcode to convert an entire linux .iso file!

4

I'm not trying to put code in the flash. This is for tabled data and the lines would be added to the sketch hex file after compile.

Although what's a couple thousand PROGMEM lens between coders anyway?

5

WattsThat:
That double negative first sentence is a doozy.

Especially since the negatives do not negate each other, having different subjects, are not a double-negative.

Sure, you can add lines to a hex file. Every time you recompile.

Seriously, why would you want to make the process harder than just compiling and downloading? Are you forgetting that any program download will erase the table? Put the table in its own file and fugetaboutit.

Seriously, I have reasons that you don't address there at all. Like gee, I'd be putting the hex lines for the table into the sketch hex file so I don't think that the download will do anything but put the table at the addresses in the lines.

I could generate source to PROGMEM data where the compiler will put it or I could generate hex file lines. Last time I made source, for even a demo it made a lot.

I'm not exactly new to programming. What I'm doing may use 1000's of keys even on an Uno. I'd rather not put it in source just to get it to flash.

But Wait! There's More! With the Mighty MCU bootloader, having my data in the right places means that I can leave room to add during runtime that the compiler might not leave.

6

I can read hex in formats, I look at the ino hex and the hex for ino and bootloader hex I see no problem with inserting lines addressing flash between what looks much like the sketch and boot area hex lines.

It's my guess that the addresses should progress upwards.

That last line is EOF record, rectype 01, always at the end. :00000001FF

Is writing flash 0xFF the same as leaving it erased? If the hex is bootloaded, will that ensure that the flash is erased or does bootloading now erase the whole flash at start? It didn't used to, only erased where it was writing but page or byte I'm not so sure, that was 2015.

7

Is writing flash 0xFF the same as leaving it erased?

Yes. Well, except I'm not sure that avrdude will "write" full pages of 0xFF - it used to "optimize" the upload by assuming that a chip erase has been done, and therefore "all" memory was already 0xFF.

If the hex is bootloaded, will that ensure that the flash is erased or does bootloading now erase the whole flash at start?

No, the bootloaders (at least, the AVR bootloaders) only erases the pages that are actually written.
(But it should do that for each file uploaded, so theoretically you can upload your sketch and then upload the data table area separately.)