BUG: HSE_Value should be HSE_VALUE in stm8s.h

[pacman]

This bug is several years old and should really be fixed.

In stm8s.h, the following line ...

#if !defined HSE_Value

... should (obviously!) be ...

#if !defined HSE_VALUE

... in order to allow HSE_VALUE to be defined on the command-line.

I just found out that this bug is several years old and has not yet been fixed.

See this link:

https://community.st.com/s/question/0D50X00009XkZibSAF/stm8l15x-peripheral-library-minor-bug-report

(Which interestingly also makes it possible to define the LSE_VALUE on the command-line).

[Willunen]

Agreed. Unfortunately it seems like ST has stopped working on anything for the STM8 line. The Standard Peripheral Library I recently downloaded was last updated in april 2018. STM8CubeMX doesn't do any code generation and mistakes in configuration (e.g. TIM4 in STM8S103 is missing) are not fixed. We are on our own.

Wilko

[pacman]

Fortunately, this is not a big problem for me.

I can of course change my library and put it on a private git-server, but it would have been nice if the change didn't have to be made if I download the libraries again.

OT: Also, I'm normally a STM32-guy, I only bought a STM8-board to see if I could do anything with it. At the moment, it seems that stm8flash hangs (in USBLIB), so I've put the tests on a shelf; my STM32 stuff is more important.

I do like that the peripherals in STM8 are similar to those in STM32 (or should I put it the other way round?) - so that one can dive straight in without learning how to do things from scratch; that's indeed a great way to do things (though I'd like 32-bit GPIO-ports instead of 16-bit, so one can change 32 pins in one clock cycle and not having to mess with latches and also 32-bit registers on the timers - I know it would break compatibility, but it would step up the STM32 line a lot for me).

[Willunen]

Same for me. But I do not use git, i have downloaded the SPL once and made a template of some files and instructions to get started. (And I use Tortoise SVN)

[pacman]

Actually, I think it would be a great thing if for products that are not 'fully active' anymore, one of the engineers at ST would - once a month - check the bug-reports and apply all the 'easy fixes' (such as typo-corrections, and obvious things like the above mentioned issue).

By 'easy fixes', I mean things that do not require following complex code or investigating things in deep levels.

-Then once every third month, some of the complicated stuff could be taken.

The 'once-a-month' is not meant just for one particular product, it's more like "what could be done quickly today?".

I know that most of the engineers are working on the leading-edge stuff and their thoughts are occupied with these new products, which is why I'd only ask for a 'once-a-month' event (eg. right before starting "new tasks").

OT: ... Personally, using some kind of version control is a good habit in my opinion. I picked git over SVN, because I have worked with (the obviously flawed) CVS for several years. When I decided to move to something different and tried checking out a SVN project, the filenames were messed up (truncated and casing problems), so I decided to try git and have grown quite fond of it. It does take some getting used to in the beginning, but after a while, it's just another habit. ;)