Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
is it possible to add a small example project? i want to try this in combination with a stm8 discovery board
I have the board, too. The problem is that there is currently no way how to burn the firmware into STM8. Some piece of programmer HW is needed. I was thinking about PIC18F2455 but I am not sure if its speed is sufficient to use it for SWIM communication…
It is just a thought, why not using the ST visual programmer (STVP) for programming the stm8 discovery board? The sad part is that in this case you're only covering windows users.
Another option is to load using the uart in a bootloader setup, the preparing of the controller needs to be done with the traditional discovery tools as presented
i like the idea of your project, cause there are not so many 'low priced' compilers available compared to other controllers. I guess it will never be so popular like the arduino movement. but if i can help to give it a little boost, i'm prepared to assist. (btw i made a small shield in case you're interested - the current connections are imho a bit weird)
Yes, you already answered. My main motivation was to have consistent development environment for ST7/STM8 on Linux. Bootloader is interesting idea. Honestly I forgot this possibility. Is there any ready-to-use solution for Linux users?
I would like to finish ucsim to have something to test SDCC with. If you want, you can try to compile ucsim and start to test with ASM code created in STVD. glob.cc is still not finished and so is the actual simulation engine, anyway…
I have downloaded recent MinGW executables of SDCCSTM8 (2.9.4 from 13 I 2013).
I have successfully built a simple application for STM8. I must say not without problems:
Sample STM8 application.
SDCC for STM8 compiler.
volatile int my_var =9; // .data section
my_var++; //load, increment, store
}while(1); //never return from main()
First compiled it: "sdcc -mstm8 -debug -out-fmt-elf -S main.c" -> "main.asm". I wanted symbolic information in it.
Here first problem: reset vector lacks ".dw 0x8200" (already reported here ).
Then assembled: "asstm8 -plosgffwzcy main.asm" to get "main.rel" (object file) also with symbolic information.
finally linked: "aslink -mu -b _CODE=0x8080 -b _DATA=0x0000 -i main.ihx main" to get "main.i86"
Here I could not force aslink to produce *.hex or *.ihx file. The ones *.i86 I got contain some RAM data that I must manually remove or it later upsets STVD and STVP. Minor problem.
Now, I can debug that hex in STVD, but:
The code provided is not linked with any initialization routines so neither .data nor .bss has proper values for now.
I have generated asm and rel files with debugging information. Unfortunately I have no idea how to generate *.elf with that.
STVD from STM comes with GNU GDB (called gdb7.exe) but unfortunately it is an older version without MI interface(no CDT with Eclipse) so the only way to debug is to send text commands to it (like "stepi", "info regsters " etc). The gdb7 can seamlessly communicate with STM8x-DISCOVERY ST-link dongles seamlessly.
The problem is that STVD cannot (obviously) find symbolic information which dooms C source level debugging.
(Mind STVD has bug: without symbolic information, shortcut keys (like "Alt+F11") do not work and stepping must be made via a menu.)
My aim was to get symbolic *.elf information out of the whole process so that I could use it with gdb7 with source debugging.
Any thoughts about that?
STM8 port is incomplete and it will stay incomplete. This project contains more or less complete support for ST7. And I have no plans to improve STM8 port. Please have a look at SDCC. There are activities to make STM8 port. In SVN there is STM8 branch. I had not time to do anything there during last 2 months. Maybe somebody else started.
Sorry for that,