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
hi Eric,
the STM8 ROM bootloader does all the protocol handling and device
specific tests. Only the actual write and erase is executed from RAM.
The routines for this have to be uploaded to RAM first. This is
described in the STM8 bootloader manual (UM0560). The repective hexfiles
for
Am 07.12.20 um 19:45 schrieb Basil Hussain:
>
> Any particular reason why callee-saves has not been implemented for STM8?
I wasn't considered an important feature for stm8 so far. stm8 is the
second-youngest port family in SDCC (only pdk is newer, and there were
some additions in the z80
Just a question on this topic: why use the STM8 built-in bootloader routines
at all (other than for bootstrapping your own bootloader code)?
The flash/EEPROM controller is documented in the reference manual(s) and it
is very easy to code the few instructions that are required for erase/write
On 07/12/2020 17:23, Philipp Klaus Krause wrote:
That leaves some ports without either:
stm8, pic16, pdk13, pdk14, pdk15.
Hmm, that's unfortunate. :(
This is in relation to the efforts of myself and Georg on substitute
open-source STM8 bootloader erase/write routines.
You see, for these
Am 07.12.20 um 17:58 schrieb Basil Hussain:
> This wouldn't happen to be one of those SDCC features that is
> 8051-specific, but not documented as such?
I only had a quick look at the code, but it looks like it is not
8051-specific:
I think it would work for:
mcs51, ds390, hc08, s08 and pic14.
Hi all,
I have been trying to use the callee-saves option to specify that an
external function (that's not part of my code) should be called without
saving registers (because it would be optimal to do so - the func is
just a few MOVs of immediate values to peripheral registers and then a
