Skip to content
This repository has been archived by the owner on Jun 14, 2020. It is now read-only.

Suggested enhancements to the replacement header files #2

Closed
roybaer opened this issue Apr 1, 2020 · 3 comments
Closed

Suggested enhancements to the replacement header files #2

roybaer opened this issue Apr 1, 2020 · 3 comments

Comments

@roybaer
Copy link

roybaer commented Apr 1, 2020

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:

/** @brief struct for access to Window Watchdog registers (_WWDG) */
typedef struct {

  /** @brief WWDG Control register (_WWDG_CR) */
  struct {
    _BITS   T       : 7;    ///< 7-bit WWDG counter
    _BITS   WDGA    : 1;    ///< WWDG activation (n/a if WWDG enabled by option byte)
  } CR;


  /** @brief WWDR Window register (_WWDG_WR) */
  struct {
    _BITS   W       : 7;    ///< 7-bit window value
    _BITS           : 1;    //   Reserved
  } WR;

} _WWDG_t;

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:

/** @brief struct for access to Window Watchdog registers (_WWDG) */
typedef struct {

  /** @brief WWDG Control register (_WWDG_CR) */
  union {
    struct {
      _BITS   T       : 7;    ///< 7-bit WWDG counter
      _BITS   WDGA    : 1;    ///< WWDG activation (n/a if WWDG enabled by option byte)
    };
    uint8_t bits;
  } CR;


  /** @brief WWDR Window register (_WWDG_WR) */
  union {
    struct {
      _BITS   W       : 7;    ///< 7-bit window value
      _BITS           : 1;    //   Reserved
    };
    uint8_t bits;
  } WR;

} _WWDG_t;

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:

#define _UART1_BRR1 _SFR(uint8_t, UART1_AddressBase+0x02)

with something like this:

#define _UART_BRR1(_base) _SFR(uint8_t, _addr(_base)+0x02)

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:

// compile time
_UART_BRR1(_UART1) = foo;
// run time
_UART_BRR1(uart_from_variable) = foo;

It would also reduce code duplication within the header file itself.

What do you think?

@gicking
Copy link
Contributor

gicking commented Apr 8, 2020

hi roybaer,

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...

See you,
Georg

@gicking
Copy link
Contributor

gicking commented Apr 19, 2020

hi again,

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!

Georg

@gicking
Copy link
Contributor

gicking commented Jun 14, 2020

see #1

@gicking gicking closed this as completed Jun 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants