This extension is deprecated

[rtek1000]

Install VS-Code

Ubuntu and Mint linux

$ wget https://go.microsoft.com/fwlink/?LinkID=760868 -O vscode.deb
$ sudo dpkg -i vscode.deb

$sudo apt-get install code

Add extention

press ( Ctrl + Shift + X ) then search and install the folowing extention:

C/C++ for Visual Studio Code
C++ Intellisense
hexdump for VSCode
vscode-devdocs

C++ Intellisense
This extension is deprecated. Use the C/C++ extension instead.

hexdump for VSCode
This extension is deprecated. Use the Hex Editor extension instead.

[MrPivato]

Hi, just out of curiosity, have you been able to get debugging to work?

[rtek1000]

Hi, just out of curiosity, have you been able to get debugging to work?

I can't get it going right now, I tried it once but I'm more used to Eclipse so maybe I'll try to get it working later.

Search for Platformio and Vscode. It already has support for SDCC and Stm8 as well. I just don't know about debugging.

Just a tip, the code generated using libraries can be more than 8x bigger than manipulating registers directly. Small devices cannot afford to lose memory.

Ref.: platformio/platform-ststm8#60

[MrPivato]

I kinda got it to work, but only for one file using the stm8-gdb, like, it would debug the main.c, but for the other files it would complain "No source file named xxxx.c", both on VSCode and Eclipse, no matter what directories or paths I tried to add in the configuration. Was wondering if anyone got the same problem, but no luck so far.

Did you get multiple file debug to work in Eclipse?

Search for Platformio and Vscode. It already has support for SDCC and Stm8 as well. I just don't know about debugging.

I got it to compile, but no luck also in debug, at least with the Platformio Unified Debbuger.

Just a tip, the code generated using libraries can be more than 8x bigger than manipulating registers directly. Small devices cannot afford to lose memory.

Yeah haha, I had this problem very early on, I just had some Timers and GPIO set up, and it ballooned to 16kb.

[rtek1000]

I don't understand much about debug yet. I've been making microcontroller programs since 2006, but I test on boards. I heard that ST has good degug features, but I didn't have time to try it out.

But as far as I know. it's the *.ELF files that are debugged, so it must be after linking that you can debug. The SDCC waits for the main.c file if I'm not mistaken, I believe that the other files must be included in the main.c file.

STM32CubeIDE Advanced Debug Features: Part 1

[rtek1000]

I don't understand much about debug yet. I've been making microcontroller programs since 2006, but I test on boards. I heard that ST has good degug features, but I didn't have time to try it out.

But as far as I know. it's the *.ELF files that are debugged, so it must be after linking that you can debug. The SDCC waits for the main.c file if I'm not mistaken, I believe that the other files must be included in the main.c file.

STM32CubeIDE Advanced Debug Features: Part 1

Note: main routine, not main.c file

[rtek1000]

I found some tutorials on using the STM8, after seeing these materials, the person must certainly fully understand this microcontroller, if you want to see it, it's at this link:

https://github.com/rtek1000/STM8S-examples/

[MrPivato]

But as far as I know. it's the *.ELF files that are debugged, so it must be after linking that you can debug. The SDCC waits for the main.c file if I'm not mistaken, I believe that the other files must be included in the main.c file.

Compiling, assembling, linking etc. seem to be working fine, I think it's something to do with the communication between OpenOCD and the Stlink

STM32CubeIDE Advanced Debug Features: Part 1

Thanks, I'll watch it, maybe I find something I was missing out, even if it is for the STM32 most things may apply.

I found some tutorials on using the STM8, after seeing these materials, the person must certainly fully understand this microcontroller, if you want to see it, it's at this link:

https://github.com/rtek1000/STM8S-examples/

Thanks for compiling them in one place, but it seems that the examples are using the Cosmic compiler, are the diferences only "surface level"? Because I've been porting some firmware things from IAR, and it was quite the work.

[rtek1000]

it seems that the examples are using the Cosmic compiler, are the diferences only "surface level"?.

All the libraries I've found so far are adaptations of the library provided by ST:

https://www.st.com/en/embedded-software/stsw-stm8069.html

Some adaptations were made to include SDCC support for example.

The latest version is V2.3.1 / 26-April-2018 (Unzipped folder name: STM8S_StdPeriph_Lib)

In any case, only by programming in assembler will it be possible to obtain maximum performance.

In the repository STM8S-examples, there are no tutorials just about the Cosmic compiler. It also has about assembler and register handling.

• lujji: Mixing C and assembly on STM8
• lujji: Bare metal programming: STM8

But the examples for Cosmic are adaptable for SDCC because they use the same base library, only some registers may have been renamed, or split, or reassembled, to facilitate some application.

[MrPivato]

Thanks for the recommendations.
If I find anything interesting I'll let you know.