You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 14, 2020. It is now read-only.
It's been a while, but I've only just taken a closer look at your proposed replacement headers and noticed a few things that could perhaps be improved.
Let's look at struct types like this, for instance:
Would it be possible (and sufficiently portable) to turn the structs CR and WR into anonymous structs wrapped in unions that make the value accessible as byte, as well?
Provided that this approach yields efficient code for bytewise access, you could do away with a lot of the preprocessor macros for bytewise access.
If the approach outlined above is not sufficiently portable or efficient, one would have to keep the macros, but I see some room for practicality-related improvements there, as well.
The macros for the various UART SFRs could for example be remodeled in such a way that they take the base address as parameter, i.e. replacing this line:
yes, it's been a while... Actually my effort in the past months has shifted towards other projects and I currently don't maintaining this idea anymore. Sorry! There are several reasons why my focus has shifted from SDCC and STM8, namely:
seems like there won't be C++ / LLVM support in the foreseeable future. And I have really come to like C++...
the different STM8 families differ too much for manual creation/maintenance of header files. I tried to automate that but so far I couldn't get it to work reliably
the demand for STM8 OS headers seemingly doesn't exist. Actually yours is the first feedback since >1 year
other, personal reasons
Actually I do like your above proposals and would like to implement them. Well, maybe (much) later. Until then...
thanks to lockdown I had another go on this during the past days. To handle the high number of required header files for the STM8 variants (above issue #2), I now created a XML database for almost each STM8 variant. From that it should be rather straightforward to automatically generate headers - and implement later improvements without a lot of manual work :-) The next step is to write that program to create headers from XML.
Are you interested in those XMLs? Would it make sense to upload them to the Github repo? For your feedback thanks a lot in advance!
It's been a while, but I've only just taken a closer look at your proposed replacement headers and noticed a few things that could perhaps be improved.
Let's look at struct types like this, for instance:
Would it be possible (and sufficiently portable) to turn the structs CR and WR into anonymous structs wrapped in unions that make the value accessible as byte, as well?
Roughly like this:
Provided that this approach yields efficient code for bytewise access, you could do away with a lot of the preprocessor macros for bytewise access.
If the approach outlined above is not sufficiently portable or efficient, one would have to keep the macros, but I see some room for practicality-related improvements there, as well.
The macros for the various UART SFRs could for example be remodeled in such a way that they take the base address as parameter, i.e. replacing this line:
with something like this:
This would greatly simplify generic code that lets you choose the UART at compile time or even at run time and would let you write code like this:
It would also reduce code duplication within the header file itself.
What do you think?
The text was updated successfully, but these errors were encountered: