> Am 19.02.2018 um 10:50 schrieb Maarten Brock:
> >
> > Do I understand correctly that your STM8 has code memory
> above 0x?
> > So the problem is that SDCC only generates 16 bit jump/call
> > instructions and thus cannot reach 0x1 and above, but
> it can 'overflow' into that area.
>
.@spth.de]
> Verzonden: vrijdag 6 april 2018 14:24
> Aan: sdcc-user@lists.sourceforge.net
> Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in
> asxxx x?
>
>
> Am 06.04.2018 um 14:12 schrieb Eric Rullens:
> > Dear Philipp,
> >
> >
Dear Philipp,
Apologies for bumping into this conversation (and thank you very much for
all the work!), but I think the assembler does what it should do.
Please consider the following:
116 ; Assembler test (r10380): loading
0xhhmmll (high, mid, low) bytes into
> -Oorspronkelijk bericht-
> Van: Philipp Klaus Krause [mailto:p...@spth.de]
> Verzonden: zondag 25 maart 2018 20:06
> Aan: sdcc-user@lists.sourceforge.net
> Onderwerp: Re: [Sdcc-user] STM8 >32kB code fails...?
>
> Work on the feature request
>
, but it works for this little test. Do you think it
can also work with the code generator?
Eric
> -Oorspronkelijk bericht-
> Van: Eric Rullens
> Verzonden: dinsdag 27 maart 2018 09:31
> Aan: 'sdcc-user@lists.sourceforge.net'
> Onderwerp: Re: [Sdcc-user] STM8 &
elijk bericht-
> Van: Eric Rullens
> Verzonden: donderdag 29 maart 2018 16:27
> Aan: 'sdcc-user@lists.sourceforge.net'
> Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in
> asxxx x?
>
>
> Dear Philipp and Maarten,
>
> I was just checking and got th
Dear Philipp and Maarten,
I was just checking and got this far: the assembler contains a special case
for mcs51 (I think ds390 is essentially the same thing). After making a
simple general change in the assembler, the rel files look ok, but the rst
file still is broken. So there probably is a
been reported before for MCS51 as well:
https://sourceforge.net/p/sdcc/mailman/message/35171634/
But for the example above I don't see the issue for MCS51.
Any thoughts?
Eric Rullens
-Original Message-
From: Philipp Klaus Krause [mailto:p...@spth.de]
Sent: zondag 11 februari 2018
Just a wild guess after browsing the manual: the UART pins can be selected
via S1_S[1:0] in P_SW1, and this setting does not seem to have a default?
Eric
> -Original Message-
> From: Philipp Klaus Krause [mailto:p...@spth.de]
> Sent: zondag 7 juni 2020 16:01
> To: Sdcc-User
> Subject:
Klaus Krause:
> > Am 07.06.20 um 21:41 schrieb Eric Rullens:
> >> Just a wild guess after browsing the manual: the UART pins can be
> >> selected via S1_S[1:0] in P_SW1, and this setting does not
> seem to have a default?
> >>
> >> Eric
&g
The manual shows several samples for doing this. The main trick seems to be
to enable access to the "special special" function registers in XRAM space.
"The following special function registers are expanded SFR and logical
address is located in the XDATA area. Before accessing, the P_SW2 (BAH)
Hi Basil,
Maybe it is not that simple. The STM8 has a prefetch buffer (for flash
access) and also sports pipelined execution. Under certain conditions the
pipeline is flushed and the CPU may be stalled. Then execution time is not
simply the sum of the (nominal) number cycles to execute an
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
nal EEPROM and then the internal flash).
Eric
-Oorspronkelijk bericht-
Van: Georg Icking-Konert [mailto:ge...@cream-tea.de]
Verzonden: dinsdag 8 december 2020 07:41
Aan: Eric Rullens; 'sdcc-user@lists.sourceforge.net'; Hynek Sladký
CC: Basil Hussain
Onderwerp: Re: [Sdcc-user] RAM program
hi Eric,
th
14 matches
Mail list logo
