Hi Eric,
having thought this over, I see pros and cons for both options.
Therefore I have just started a discussion under
https://github.com/gicking/stm8-bootloader-erase-write/discussions to
collect arguments.
Georg
Am 08.12.20 um 08:58 schrieb Eric Rullens:
Hi Georg,
Yes, that is exactly what I mean: load your own loader code in RAM and from
there you are free to do as you please. For example use a more efficient
protocol, and/or change to (higher) baudrates that are not supported by the
built-in bootloader.
I do this for NXP LPC and STM32 controllers and it works very well (adding
STM8 is on the wish list, but not with high priority at the moment). I would
not bother trying to write a "one size fits all" bootloader, just make
specialized ones for UART, SPI, CAN as required. Even 1 kB of RAM should be
plenty this way.
Aside from internal flash I also added loaders that can program external
EEPROM or serial flash. This is quite convenient to have.
In my case all the loaders have an option to reset the chip and restart the
built-in bootloader, so the whole process can be repeated (e.g. to first
program an external EEPROM and then the internal flash).
Eric
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
