[Sdcc-user] renamed "STM8_serial_flasher" to "stm8gal"

[Georg Icking-Konert <georg@cr...>]

hello all,

following a proposal by Philipp Krause (see 
https://github.com/gicking/STM8_serial_flasher/issues/10) I renamed my 
STM8 programming tool from "STM8_serial_flasher" to "stm8gal". It is now 
available from https://github.com/gicking/stm8gal. Sorry for any 
inconvenience this might cause!

Regards,
Georg Icking-Konert

[Sdcc-user] Fwd: patches for STM8 Standard Peripheral Libraries

[Georg Icking-Konert <georg@cr...>]

hello all,

today I uploaded SDCC patches for all available STM8 Standard Peripheral Libraries from the ST homepage (STM8S/A, STM8L10x, STM8L15x-16x-05x-AL31-L and STM8TL5x) to Github under https://github.com/gicking/STM8-SPL_SDCC_patch

Instructions on obtaining the SPL software and the patch process are also given there. Main issue is the lack of testing and a lack of running code from RAM (still don't know how to do this). Please let me know if you experience any issues.

Regards,
Georg Icking-Konert

Re: [Sdcc-user] Silicon Labs EFM8 Headers/Keil C51 Compatibility

[R0b0t1 <r030t1@gm...>]

On Sun, Aug 27, 2017 at 12:16 AM, R0b0t1 <r030t1@...> wrote:
> Hello,
>
> I apologize if this is too product-specific for this list. I've a
> development board from Silicon Labs and have just demoed the product
> with the manufacturer's software. However, my real intent was to use
> SDCC and OpenOCD to program the board. To this end I would like some
> recommendations on compiling software for the EFM8 line.
>
> I seem to have found the headers in
> "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\8051\v4.0.7\Device\EFM8SB2"
> and "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\8051\v4.0.7\Device\shared\si8051Base".
> I expect to be able to copy these into a project directory, add them
> to the include path, and invoke sdcc. Should I expect source
> compatibility with Keil C51?
>
> Having done this with STM32 parts, I found there were third party
> libraries for those parts. Is this the same with Silicon Labs parts? I
> do not expect this to be the case, but I think I should ask.
>
> As for OpenOCD - I expect to be able to use the integrated Segger
> J-Link and for that to automatically select C2 by default (or for
> OpenOCD to do it, I am still a bit confused on that part). If not I
> feel I can follow up on this myself, but any hints are appreciated.
>
>
> I feel this are generally basic questions but I *didn't* ask some
> basic questions the last time I did this general process and ended up
> wasting a bunch of time.
>
> Thanks in advance,
>      R0b0t1

Seems like I will be having the most issue setting up OpenOCD, as I
expected. I might follow up here once I find an appropriate
configuration. Sorry for the post to the list but I was pretty
confused for an hour or two. Cheers!

[Sdcc-user] Silicon Labs EFM8 Headers/Keil C51 Compatibility

[R0b0t1 <r030t1@gm...>]

Hello,

I apologize if this is too product-specific for this list. I've a
development board from Silicon Labs and have just demoed the product
with the manufacturer's software. However, my real intent was to use
SDCC and OpenOCD to program the board. To this end I would like some
recommendations on compiling software for the EFM8 line.

I seem to have found the headers in
"C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\8051\v4.0.7\Device\EFM8SB2"
and "C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\8051\v4.0.7\Device\shared\si8051Base".
I expect to be able to copy these into a project directory, add them
to the include path, and invoke sdcc. Should I expect source
compatibility with Keil C51?

Having done this with STM32 parts, I found there were third party
libraries for those parts. Is this the same with Silicon Labs parts? I
do not expect this to be the case, but I think I should ask.

As for OpenOCD - I expect to be able to use the integrated Segger
J-Link and for that to automatically select C2 by default (or for
OpenOCD to do it, I am still a bit confused on that part). If not I
feel I can follow up on this myself, but any hints are appreciated.


I feel this are generally basic questions but I *didn't* ask some
basic questions the last time I did this general process and ended up
wasting a bunch of time.

Thanks in advance,
     R0b0t1

Re: [Sdcc-user] SiLabs EFM8 Support

[R0b0t1 <r030t1@gm...>]

On Fri, Aug 18, 2017 at 12:35 PM, Maarten Brock
<sourceforge.brock@...> wrote:
>> On Fri, Aug 18, 2017 at 10:39 AM, R0b0t1 <r030t1@...> wrote:
>>> What is the status of EFM8 support? They are an 8051 based
>>> microcontroller, so I expect code generation to be a nonissue. What
>>> difficulties might I experience porting the manufacturer's device
>>> headers?
>>>
>>
>> Sorry list, I checked some older posts and people are using the older
>> Silicon Labs parts without much issue. I guess I have no reason to
>> expect problems.
>>
>>> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is
>>> inconclusive, or I don't understand it.
>>>
>>> I would also like to indirectly reply to
>>> https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the
>>> integrated Segger J-Link on the EFM8 starter kits. Eventually, the
>>> Black Magic Probe firmware may support EFM8 targets. Currently it only
>>> supports EFM32 ARM devices.
>>>
>>> Thanks in advance,
>>>      Rob0t
>
>
> The biggest problem usually is the watchdog that is enabled by default.
> With sdcc you can disable it in sdcc_startup as described in the manual.
>

Thanks for the heads up. I invariably seem to spend a day or two
troubleshooting an issue like this. Sadly my Mouser order was help
back to do an export controlled part, can't wait to try these parts
out. They're nice and cheap.



On Fri, Aug 18, 2017 at 2:03 PM, Philipp Klaus Krause <pkk@...> wrote:
> Am 18.08.2017 um 17:39 schrieb R0b0t1:
>> What is the status of EFM8 support? They are an 8051 based
>> microcontroller, so I expect code generation to be a nonissue. What
>> difficulties might I experience porting the manufacturer's device
>> headers?
>>
>> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is
>> inconclusive, or I don't understand it.
>
> I've added a clarifying sentence at the top of that page.
>

Thank you for the clarification. I understand what the page originally
said now, but that might be because of your update. Cheers!

R0b0t1.

Re: [Sdcc-user] SiLabs EFM8 Support

[Philipp Klaus Krause <pkk@sp...>]

Am 18.08.2017 um 17:39 schrieb R0b0t1:
> What is the status of EFM8 support? They are an 8051 based
> microcontroller, so I expect code generation to be a nonissue. What
> difficulties might I experience porting the manufacturer's device
> headers?
> 
> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is
> inconclusive, or I don't understand it.

I've added a clarifying sentence at the top of that page.

Philipp

Re: [Sdcc-user] SiLabs EFM8 Support

[Maarten Brock <sourceforge.brock@ds...>]

> On Fri, Aug 18, 2017 at 10:39 AM, R0b0t1 <r030t1@...> wrote:
>> What is the status of EFM8 support? They are an 8051 based
>> microcontroller, so I expect code generation to be a nonissue. What
>> difficulties might I experience porting the manufacturer's device
>> headers?
>>
>
> Sorry list, I checked some older posts and people are using the older
> Silicon Labs parts without much issue. I guess I have no reason to
> expect problems.
>
>> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is
>> inconclusive, or I don't understand it.
>>
>> I would also like to indirectly reply to
>> https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the
>> integrated Segger J-Link on the EFM8 starter kits. Eventually, the
>> Black Magic Probe firmware may support EFM8 targets. Currently it only
>> supports EFM32 ARM devices.
>>
>> Thanks in advance,
>>      R0bot


The biggest problem usually is the watchdog that is enabled by default.
With sdcc you can disable it in sdcc_startup as described in the manual.

Maarten

Re: [Sdcc-user] How to place some data at a specific location amidst some code?

[Maarten Brock <sourceforge.brock@ds...>]

Hello Philipp,


> I haven't been using the keyword __at much.
> But now I have a case where I want code to be placed in the 0x0000 to
0x9fff range.
>
> However, at the specific location 0x1ff0 I want 16 specific header
bytes. The linker should just put the code around the header (which
might require leaving a few bytes unused), but it doesn't work for me so
far.
>
> I tried
>
> const struct header __at(0x1ff0) header = ...;
>
> but the linker creates an overlap: The header gets put into the
> binary at the correct location with the correct data. But that
> means the data ends up in the middle of a function.
>
> Philipp
>

I'm afraid the Z80 backend is still broken in this area. Look at the
generated .area line and check for the property CON. If there is none make
the backend generate it.

Maarten

Re: [Sdcc-user] SiLabs EFM8 Support

[R0b0t1 <r030t1@gm...>]

On Fri, Aug 18, 2017 at 10:39 AM, R0b0t1 <r030t1@...> wrote:
> What is the status of EFM8 support? They are an 8051 based
> microcontroller, so I expect code generation to be a nonissue. What
> difficulties might I experience porting the manufacturer's device
> headers?
>

Sorry list, I checked some older posts and people are using the older
Silicon Labs parts without much issue. I guess I have no reason to
expect problems.

> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is
> inconclusive, or I don't understand it.
>
> I would also like to indirectly reply to
> https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the
> integrated Segger J-Link on the EFM8 starter kits. Eventually, the
> Black Magic Probe firmware may support EFM8 targets. Currently it only
> supports EFM32 ARM devices.
>
> Thanks in advance,
>      R0b0t1

[Sdcc-user] SiLabs EFM8 Support

[R0b0t1 <r030t1@gm...>]

What is the status of EFM8 support? They are an 8051 based
microcontroller, so I expect code generation to be a nonissue. What
difficulties might I experience porting the manufacturer's device
headers?

http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is
inconclusive, or I don't understand it.

I would also like to indirectly reply to
https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the
integrated Segger J-Link on the EFM8 starter kits. Eventually, the
Black Magic Probe firmware may support EFM8 targets. Currently it only
supports EFM32 ARM devices.

Thanks in advance,
     R0b0t1

Re: [Sdcc-user] PIC14 and printf/puts

[Philipp Klaus Krause <pkk@sp...>]

Am 15.08.2017 um 23:58 schrieb Erlo Haugen:
> On 2017-08-15 23:22, Philipp Klaus Krause wrote:
>> Am 14.08.2017 um 23:47 schrieb Erlo Haugen:
>>> What library must I link to in order to access printf or puts?
>>>
>>> Command:
>>>
>>> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
>>> --use-non-free   dreje.c
>>> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr".
>>> error: Missing definition for symbol "_puts", required by "dreje.o".
>>>
>>> br
>>> Erlo
>>
>> Do other std library functions work for you? From a quick look at
>> sdcc/device/lib/pic1?, it seems that the pic14 doesn't really have a
>> library (expect for support functions and floating-point math functions)
>> and the pic16 has its own library, separate from what all the non-pic
>> backends use.
>>
>> Philipp
>>
> 
> Actually, I am not using other library functions as far as I know.
> 
> Erlo

Well, the pic backends are still considered "work in progress". And that
is even more true fro pic14 than for pic16.

I suggest you try just taking puts() from sdcc/device/lib/puts.c and see
if it works for you for pic14.

Philipp

Re: [Sdcc-user] PIC14 and printf/puts

[Erlo Haugen <erlo.haugen@gm...>]

On 2017-08-15 23:22, Philipp Klaus Krause wrote:
> Am 14.08.2017 um 23:47 schrieb Erlo Haugen:
>> What library must I link to in order to access printf or puts?
>>
>> Command:
>>
>> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
>> --use-non-free   dreje.c
>> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr".
>> error: Missing definition for symbol "_puts", required by "dreje.o".
>>
>> br
>> Erlo
> 
> Do other std library functions work for you? From a quick look at
> sdcc/device/lib/pic1?, it seems that the pic14 doesn't really have a
> library (expect for support functions and floating-point math functions)
> and the pic16 has its own library, separate from what all the non-pic
> backends use.
> 
> Philipp
> 

Actually, I am not using other library functions as far as I know.

Erlo

Re: [Sdcc-user] PIC14 and printf/puts

[Erlo Haugen <erlo.haugen@gm...>]

On 2017-08-15 23:12, Philipp Klaus Krause wrote:
> Am 14.08.2017 um 23:47 schrieb Erlo Haugen:
>> What library must I link to in order to access printf or puts?
>>
>> Command:
>>
>> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
>> --use-non-free   dreje.c
>> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr".
>> error: Missing definition for symbol "_puts", required by "dreje.o".
>>
>> br
>> Erlo
> 
> Which version of SDCC?
> 
> Philipp
> 
> 

3.6.0 #9615

Erlo

Re: [Sdcc-user] PIC14 and printf/puts

[Philipp Klaus Krause <pkk@sp...>]

Am 14.08.2017 um 23:47 schrieb Erlo Haugen:
> What library must I link to in order to access printf or puts?
> 
> Command:
> 
> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
> --use-non-free   dreje.c
> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr".
> error: Missing definition for symbol "_puts", required by "dreje.o".
> 
> br
> Erlo

Do other std library functions work for you? From a quick look at
sdcc/device/lib/pic1?, it seems that the pic14 doesn't really have a
library (expect for support functions and floating-point math functions)
and the pic16 has its own library, separate from what all the non-pic
backends use.

Philipp

Re: [Sdcc-user] PIC14 and printf/puts

[Philipp Klaus Krause <pkk@sp...>]

Am 14.08.2017 um 23:47 schrieb Erlo Haugen:
> What library must I link to in order to access printf or puts?
> 
> Command:
> 
> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
> --use-non-free   dreje.c
> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr".
> error: Missing definition for symbol "_puts", required by "dreje.o".
> 
> br
> Erlo

Which version of SDCC?

Philipp

Re: [Sdcc-user] PIC14 and printf/puts

[Philipp Klaus Krause <pkk@sp...>]

Am 15.08.2017 um 22:41 schrieb Gál Zsolt:
> Did you find this?
> 
> http://sdcc.sourceforge.net/wiki/index.php/List_of_the_SDCC_library
> 

That page seems very much out of date.

Philipp

Re: [Sdcc-user] PIC14 and printf/puts

[Gál Zsolt <tralitoverin@fr...>]

Did you find this?

http://sdcc.sourceforge.net/wiki/index.php/List_of_the_SDCC_library


2017-08-14 23:47 GMT+02:00 Erlo Haugen <erlo.haugen@...>:

> What library must I link to in order to access printf or puts?
>
> Command:
>
> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
> --use-non-free   dreje.c
> message: Using default linker script "/usr/share/gputils/lkr/
> 16f690_g.lkr".
> error: Missing definition for symbol "_puts", required by "dreje.o".
>
> br
> Erlo
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>



-- 
~~~~~~~~~~~~~~~~

[Sdcc-user] How to place some data at a specific location amidst some code?

[Philipp Klaus Krause <pkk@sp...>]

I haven't been using the keyword __at much.
But now I have a case where I want code to be placed in the 0x0000 to
0x9fff range.

However, at the specific location 0x1ff0 I want 16 specific header
bytes. The linker should just put the code around the header (which
might require leaving a few bytes unused), but it doesn't work for me so
far.

I tried

const struct header __at(0x1ff0) header = ...;

but the linker creates an overlap: The header gets put into the binary
at the correct location with the correct data. But that means the data
ends up in the middle of a function.

Philipp

[Sdcc-user] PIC14 and printf/puts

[Erlo Haugen <erlo.haugen@gm...>]

What library must I link to in order to access printf or puts?

Command:

erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690
--use-non-free   dreje.c
message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr".
error: Missing definition for symbol "_puts", required by "dreje.o".

br
Erlo

[Sdcc-user] Fatal Compiler Error, PIC14

[Erlo Haugen <erlo.haugen@gm...>]

I opened a ticket (2636) regarding a fatal compiler error when compiling
for 16f690.
Do I need to supply more information?

BR
Erlo

Re: [Sdcc-user] Access to local variables from inline assembly (PIC14)

[Erlo Haugen <erlo.haugen@gm...>]

On 2017-08-07 18:20, Augusto Fraga Giachero wrote:
> PIC microcontrollers (PIC12/PIC14/PIC16) doesn't have a general purpose
> stack (it has a hardware stack used only to sub-routines and interrupts
> return). I don't known how the sdcc implements local variables for these
> targets (may be a software stack or fixed allocation).
> 
> Augusto

The compiler allocates memory from the general purpose registers, as far
as I can see. But the names may change if another variable is defined or
the order of definition is changed.

> 
> On 08/06/2017 07:12 PM, Maarten Brock wrote:
>>> Access to global variable is no problem, just use _varname, but how can
>>> I access local variables? Is there no other way than using the
>>> compiler-generated names (which may change if the code is changed)?
>>>
>>> BR
>>> Erlo
>> This highly depends on the target and compiler options. Local
>> variables on
>> stack don't even have a name in assembler.
>>
>> Hav you considered using static variables?
>>
>> Maarten

Not static, but a global variable. The issue with both approaches is the
variable can not be overlayed/reused in another function and memory is
sparse in the small PICs.

Erlo

Re: [Sdcc-user] Access to local variables from inline assembly (PIC14)

[Augusto Fraga Giachero <augustofg96@gm...>]

PIC microcontrollers (PIC12/PIC14/PIC16) doesn't have a general purpose 
stack (it has a hardware stack used only to sub-routines and interrupts 
return). I don't known how the sdcc implements local variables for these 
targets (may be a software stack or fixed allocation).

Augusto

On 08/06/2017 07:12 PM, Maarten Brock wrote:
>> Access to global variable is no problem, just use _varname, but how can
>> I access local variables? Is there no other way than using the
>> compiler-generated names (which may change if the code is changed)?
>>
>> BR
>> Erlo
> This highly depends on the target and compiler options. Local variables on
> stack don't even have a name in assembler.
>
> Hav you considered using static variables?
>
> Maarten
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] Access to local variables from inline assembly (PIC14)

[Maarten Brock <sourceforge.brock@ds...>]

> Access to global variable is no problem, just use _varname, but how can
> I access local variables? Is there no other way than using the
> compiler-generated names (which may change if the code is changed)?
>
> BR
> Erlo

This highly depends on the target and compiler options. Local variables on
stack don't even have a name in assembler.

Hav you considered using static variables?

Maarten

Re: [Sdcc-user] Access to local variables from inline assembly (PIC14)

[Gál Zsolt <tralitoverin@fr...>]

Hello,

I think that is the only way using global variables if you want to use
inline assembly.

Better solution is writing time critical function in assembly and compile
source codes into object files and linking them.

There is some help in the sdcc manual how is it working and how can you
give parameters to assembly functions.

Regards,

  Zsolt

2017-08-06 22:20 GMT+02:00 Erlo Haugen <erlo.haugen@...>:

> Access to global variable is no problem, just use _varname, but how can
> I access local variables? Is there no other way than using the
> compiler-generated names (which may change if the code is changed)?
>
> BR
> Erlo
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>



-- 
~~~~~~~~~~~~~~~~
http://galzsolt.zzl.org

[Sdcc-user] Access to local variables from inline assembly (PIC14)

[Erlo Haugen <erlo.haugen@gm...>]

Access to global variable is no problem, just use _varname, but how can
I access local variables? Is there no other way than using the
compiler-generated names (which may change if the code is changed)?

BR
Erlo