I am looking into the possibility of writing a bootloader for an ATTiny that also serves as sort of base library to allow function changes to be loaded without changing the base code.
What I want to know is, can I put a function into the bootloader and call it from my main loop?
An example might be something like upload a monitor for inputs and the bootloader can be called to "update" code from another source (maybe an external EEPROM or SDCARD). Or custom loader that loads code or data from another application (connection to a PC or Bluetooth device).
I was reading up on bootloaders and there was a great tutorial about how it works on the ATMegas and from what I understand the bootloader code it loaded in "high" memory and application code is loaded in "low" memory. But I am not clear if that happens on a ATTiny. I am certain from what I read that the ATMega bootloader can be protected but there is not (again I am not certain) a mechanism that allows that on an ATTiny.
I looked at the Micronucleous Bootloader for the ATTiny. It looks like it has been used for the Digispark board and some others. I like the idea of having a project that can be updated via USB. I would like to use that but only load a portion.
So I wonder if it is possible.
If anyone could explain or point me in the direction, I greatly appreciate it.
dmilton2004:
What I want to know is, can I put a function into the bootloader and call it from my main loop?
its called a bios (basic in/out system). popular on high end computers like pc but not so much mcu. definitely possible and was a revolutionary step for me. specially for tiny series where space is a premium. it not only made possible same functionality in ~1/10 the space but made programming a lot easier.
the key was to implement a jump table (actually set of calls in fixed location) for things like serial i/o, flash read/write, sd card access, button debounce, adc, number conversion (puthex, putdec), lcd, etc. it proved so useful on the tiny that i extended it to mega series where similar benefits accrue. i dont find the actual serial upload ability of bootloaders that useful but this is definitely worthwhile.
easy to integrate into bootloaders like the compact opti. it really didnt end up taking any more space because most of the code was already there and just needed conversion into subroutines. somebody on this forum did something similar with flash write code so flash can be programmed from sketches. i did this a long time before and carried it a lot further.
I would like to put library or common routines into the boot loader so only the application can be updated without having to recompile the library every time. Perhaps via another mechanism other than the IDE. Maybe through another app or even via WiFi or Bluetooth.
Does anyone know of a place to start? Is it possible to program bootloader code within the Arduino IDE? Now I do understand that using the C compiler may not be the smallest and more efficient way to program this type of code, but I am looking to experiment a little before diving deep! LOL I am thinking that I may need the ATMEL development environment to do this.
More info would help me greatly! Also I am searching for the basics, but what I am finding is alternatives to the bootloader on the Arduino, or versions designed for the ATTiny with a USB interface. Which I may look into for something else, but I would like understand the bootloader process and the basics of a jump table and how to access it from the main application.
dmilton2004:
Is it possible to program bootloader code within the Arduino IDE?
ide has option "tools/burn_bootloader". however for tiny its used to set fuses but rarely for bootloader in small chips. its possible to create bootloaders as small as 64 bytes but arduino people and c programmers dont know how to do this. only asm afaik. i got down to 32 bytes for t13 but not standard protocol.
dmilton2004:
I would like understand the bootloader process and the basics of a jump table and how to access it from the main application.
heres an example of an actual jmp table from one of my boot/monitor files:
this is a pretty basic one. some others are far more sophisticated. of course you have to write the routines to jump to. generally to fit into the regular boot area asm is best. it can be done with c but not as efficient and considerably more difficult.
if you go that route i suggest looking up the flash write from application thread i mentioned. iirc full source was included. i tried it and it worked fine but didnt fit my needs so didnt save a link. maybe somebody else recalls.
john1993:
i suggest looking up the flash write from application thread i mentioned. iirc full source was included. i tried it and it worked fine but didnt fit my needs so didnt save a link. maybe somebody else recalls.
yes. thanks, thats the one. majek did an incredible job there.
speaking of bios i got my hands on an arduino101. since there was virtually no software available for the x86 i decided to put together a bios myself to run a basic pc os or stand alone com files.
ooops... no so fast. seems this is effectively a harvard architecture with NO ABILITY TO RUN FROM RAM! no program loading and no self modifying code. wtf.
why does arduino company keep banging its head against the wall with these intel losers? you might think they would smarten up after more than a few previous total flops.
seems this is effectively a harvard architecture with NO ABILITY TO RUN FROM RAM!
What leads you to that conclusion? (I can't even find a datasheet for the Curie module!)
The Arduino programming of the 101 is for the ARC core only, anyway...
exactly the reason for having to develop your own x86. anyway quark d1000 user guide section 5.1:
The Program Memory can only be read. Any attempt to write to this address range will
result in a machine check exception.
and 5.4:
Data memory can be accessed only via operand fetch or debug controller. Any attempt
to fetch instructions from this address range will result on a machine check exception.
reminds me of the pi fake claims of open design. even if it was really open so complicated not even close to manageable by the average experimenter.
huh. Section 4.8 in my Quark D1000 datasheet, but you're right:
SRAM
The MCU has 8 kB of zero latency, zero wait state SRAM. This memory is accessible only from the 32-bit data bus. It occupies the address range 0x6000 0000 to 0x7FFF FFFF and is aliased throughout. Instructions cannot be fetched from SRAM. Attempting to do so generates a bus error, which causes a machine check exception.
Interesting. Unclear whether that also applies to the Quark SE used on the Curie (which, after all, has 80k of SRAM rather than 8k, so it's a significantly different beast.)
