2019-10-08 07:53 AM
I'm using ST Visual develop and Cosmic to program a STM8S003K3 and I'm thought it would be nice to use the STM8 Standard Library (downloaded from ST.COM).
Within a very short time I got errors telling me that I tried to put more code in the MCU than possible (8K). I hadn't even finished the initialization of all the peripherals I intend to use.
So I took a look at the compiler settings and changed the optimizations from None to Minimize Code Size.
That did help.
For a few minutes.
A look at the map file shows this: (not the entire file)
--------
Segments
--------
start 00008080 end 00008103 length 131 segment .const
start 00008106 end 00009bab length 6821 segment .text
start 00004000 end 00004000 length 0 segment .eeprom
start 00000000 end 00000000 length 0 segment .bsct
start 00000000 end 0000000a length 10 segment .ubsct
start 0000000a end 0000000a length 0 segment .bit
start 0000000a end 0000000a length 0 segment .share
start 00000100 end 00000100 length 0 segment .data
start 00000100 end 00000100 length 0 segment .bss
start 00000000 end 00000584 length 1412 segment .info.
start 00008000 end 00008080 length 128 segment .const
start 00008103 end 00008106 length 3 segment .init
-------
Modules
-------
C:\Program Files (x86)\COSMIC\FSE_Compilers\CXSTM8\Lib\crtsi0.sm8:
start 00008106 end 00008156 length 80 section .text
start 00000100 end 00000100 length 0 section .bss
start 00000000 end 00000000 length 0 section .ubsct
start 00000000 end 00000034 length 52 section .info.
Release\main.o:
start 00008156 end 000081da length 132 section .text
start 00000034 end 000000c0 length 140 section .info.
Release\stm8s_it.o:
start 000081da end 000081ef length 21 section .text
start 000000c0 end 00000150 length 144 section .info.
Release\stm8s_clk.o:
start 000081ef end 000087a3 length 1460 section .text
start 00000150 end 000001e1 length 145 section .info.
start 00008080 end 000080b3 length 51 section .const
Release\stm8s_gpio.o:
start 000087a3 end 000088a1 length 254 section .text
start 000001e1 end 00000273 length 146 section .info.
start 000080b3 end 000080db length 40 section .const
Release\stm8s_tim1.o:
start 000088a1 end 00009a60 length 4543 section .text
start 00000273 end 00000305 length 146 section .info.
start 000080db end 00008103 length 40 section .const
The timer1 initialization takes 4k ?
This is worth 4k ?
static void TIM1_Config(void)
{
TIM1_DeInit();
TIM1_TimeBaseInit(15999, TIM1_COUNTERMODE_UP, 999, 0);
TIM1_ITConfig(TIM1_IT_UPDATE, ENABLE);
TIM1_ARRPreloadConfig(ENABLE);
TIM1_Cmd(ENABLE);
}
Do I have to go back to "bare-metal" register setting?
Now I'm only just starting with STM8, so it is more than likely that I'm doing something very wrong, am I?
Wilko
Solved! Go to Solution.
2019-10-30 07:31 AM
Works like a charm! All repositories pulled and rebuilt.
-No problem with the libraries; I'll likely be building my own anyway, since I have them stored in a different location. ;)
I now also use your configure_stm8 in sdcc-gas (I didn't notice it earlier); this makes my build-script use all your provided scripts and thus it's now quite short. =)
BTW: chmod +x configure_stm8
I wonder if the "--function-sections" and "--data-sections" could be named "-ffunction-sections" and "-fdata-sections" like gcc, so that it would be easier to have common Makefiles / migrate Makefiles ?
(if the -f is already taken, I accept).
Another thing I was thinking about, was to make symlinks in the binaries-folder like ...
stm8-cc -> sdcc
stm8-c++ --> /usr/bin/false
( cd $bin; ln -s sdcc cc; ln -s $(which false) c++ )
... that would make switching compilers very consistent with the gcc-toolchains.
I definitely think both sdcc-gas and stm8-binutils-gdb are valuable.
This was just what sdcc needed in my opinion. :)
2019-10-30 08:37 AM
"-ffunction-sections" and "-fdata-sections" were my intention originally, but SDCC only parses command line arguments starting with two dashes. That could be modified too, but I did not want to spend time on minor features and focused on getting dead code elimination as well as other important features implemented instead. Similarly, "configure_stm8" was just a quick hack that got uploaded to the repository somehow :)
Anyway, if you own a GitHub account, feel free to contribute to both repositories. Since I have already implemented what I needed, it's now up to the SDCC development team to merge these changes so everyone can benefit.
Thanks a lot for your help!
2019-10-30 09:18 AM
Well, I have a Github account, but I need a new OpenID before I can access it.
This OpenID thing has been on my todo-list for a while, but unfortunately there are more pressing matters (actually lots of those).
My hints were small compared to the work you've done. I very much appreciate your modifications and especially that you've made them publicly accessible. :)
You've moved the STM8 up a lot on my priority list; if I worked at ST, I'd send you one of the best evaluation boards or a bunch of MCUs.
-Note: I just saw that someone made a (low speed) USB driver for the STM8.
2019-11-04 12:50 AM
Hi Xavi92,
I tried your toolchain yesterday and I was able to successfully build it. The stm8-dce-example gave the expected results.
However, when I tried to compile my own application, I encoutered the following error:
-:0: error 33: Attempt to assign value to a constant variable (=)
This SDCC bug seems have been solved eleven years ago in SDCC 2.8.1 #5154 by applying patch #1957148.
I wonder why it still exists in your modified version.
Did you start your work on a recent version of SDCC?
If not, do you think it's possible to apply your modification on the latest mainline SDCC version?
Thanks an regards
2019-11-04 04:35 AM
@cs, the fork was checked out from SDCC's SVN repository at revision 11345, which dates from 2019-08-22. That is newer than the latest release, 3.9.0, that was released on 2019-04-15. See https://sourceforge.net/p/sdcc/code/11345/tree/ for further reference. From my own experience, I have compiled a 30+ file project successfully, although I did find an issue:
So please check if there are any "const"-qualified variables that might be unconsciously modified.
2019-11-05 12:21 AM
@Xavi92: you're right, SDCC has some trouble with inlined functions with const arguments. I remove the useless const qualifier and the "error 33" disappeared. I will continue the application build process and I'll let you know the outcome.
2019-11-06 09:13 AM
My aplication building work is complete. I flashed the code generated by SDCC on a real hardware. It seems to be working well.
Nice work, Xavi92!
To reach the same level than STVP+Cosmic toolchain, I need to find how to integrate your toolchain in an IDE and achieve source level debugging. @Xavi92: could you advise me on this subject?
2019-11-07 04:13 AM
Ake explains how to run stm8-gdb from Eclipse on the stm8-binutils-gdb website: https://stm8-binutils-gdb.sourceforge.io/
I have not tried it myself since I am used to GDB TUI instead, but I might give it a try too.
OTOH, I fixed some issues affecting sdcc-gas that were reported by Philipp. Among them, the "--gas" switch was changed to "--asm=gas". So please update your local copy of sdcc-gas when possible.
2019-11-08 09:42 AM
Hi Xavi92.
I'll take a look on your debugging options.
For now, I've updated my copy of sdcc-gas with your last version 3.9.3 and encountered a new unexpected error. In my code:
memcpy(cmd, "XXXX", 4);
generates an error: undefined reference to '___str_0'
I found a workaround:
{
const char[] s="XXXX";
memcpy(cmd, s, 4);
}
does not generate the above error.
I didn't encouter this behaviour with the previous version.
2019-11-10 11:18 AM
Hi @cs ,
You are right: that bug has appeared after fixing the following regression issue: https://github.com/XaviDCR92/sdcc-gas/issues/4 . I have pushed a new commit that fixes both issues.