Modifying boot loader

I'm making a custom designed board with a few added switching/multiplexer chips for serial and whatnot.

On power up I want a specific I/O pin to be set to high/low (dependent on final design), I'll have a push button on a interrupt pin that when pressed will invert the pin output.

This is a hardware configuration, I don't want to have to include it in every single program I write on setup.

How does one go about doing this?
Do I need a program to decode the hexfile?

Google is overwhelmed with burning boot loaders pages, I can't find anything helpful.

harddrive123:
On power up I want a specific I/O pin to be set to high/low (dependent on final design), I'll have a push button on a interrupt pin that when pressed will invert the pin output.

So a human will have to press / not press a pushbutton at the exact moment the bootloader runs. What if a human is not there? Will the hardware not be correctly configured?

Your right, aside from making sure that I/O pin is low on start up I can't really use the boot loader.

From what I can tell all the pins start LOW on boot, so I probably don't need to even modify the boot loader.
But assuming I do add that into the descriptors.c and the .h file for my board, what do you use to compile the .hex file.

Secondary question:

The goal is that when I press a button connected to a interrupt pin, it toggles the output on a different pin. But this is a background subroutine, not part of the sketch.

I need to figure out how to write my interrupt subroutine code to a memory slot ex. 0x002A that won't be overwritten by new sketches or conflicts with the bootloader.

If you use interrupts you do this all the time at the end of your main loop, I'm just trying to figure out how to have it stored outside the sketch memory.

Any ideas?

Your right, aside from making sure that I/O pin is low on start up I can't really use the boot loader.

Upon power-up or reset all I/O pins default to input pins, so neither LOW nor HIGH, just input pins with floating inputs unless wired to something.

..... :~

So anyone know how to do a specific memory location write as a starting point?

Perhaps if you would again try and explain what you are trying to accomplish rather then how you think it should be accomplished, we might better understand and give better suggestions.

harddrive123:
Any ideas?

Yes. Don't do it. It's a bad idea.

Two alternatives...
• Modify / clone the core so the code is always included
• Package the code in a library such that you only need to include the library / header file

If you've ever used machine code you'd know what I'm talking about.
The memory addresses are automatic or predetermined by the compiler/ boot loader.

Ex. The boot loader is from 0x0000 to whatever 2-4k in hex I'll use a easy number like 0x00AA. The sketch would likely start at 0x00AB , main loop at 0x00BB, subroutines 0x00CC all these numbers random and some would change based on length of code used.

Concept is to reserve part of the memory for a my code. If I determine that I only need 1k of memory, I'd like to shift the sketch memory down 1k. This in turn would reduce my available sketch size by 1K.

Exactly the same concept as when people don't use a boot loader, with 4K boot loader you have28K for sketch. Without you could use 32K for sketch. What I want to do is 4k boot loader 1K ISR, 27K sketch space.

If you don't know what I'm talking about then you don't know much about programming. I'm no expert but I know the basics.

that said I do realize the easiest methods is probably in using a library and will do that as starting point.

In the common AVRs chips used in arduino boards like the Uno, all programs (sketches) are loaded starting at flash address 0. If the fuse bytes are burned to enable a protected bootloader to reside in protected high flash memory then the AVR will start execution from whatever booloader flash size has been enabled. If you have no bootloader installed but do have bootloader protection enabled via fuse bytes the execution will start at the bootloader starting address but the resulting NOPs (0xFF) will just wrap around and start execution of code starting at zero. All this is explained in the ATMEL datasheet for the specific chip in question.