This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Abstraction layer for multiple vendors

Hi,

We are thinking about starting to developing "middleware" firmware. It would not be very complex code, but it would need access to an SPI and UART peripheral. Ethernet and USB could however be very useful in the future.

The source code would ideally be compatible with Cortex-M micro-controllers from a large variety of vendors. As a minimum we would like to support a few parts from ST, NXP and Cypress (PSoC).

Obviously we would like to develop as few code as possible to abstract the difference hardware. Apart from the work involved, we have little experience in embedded software development.

CMSIS-Driver seems a very good solution, except that we are unsure whether this is still very active. For instance, the last change to the pack for all STM32F0 controllers is from two years ago. There is also no support for PSoC micro-controllers.

We are curious how other people tackle this problem, do you have any advice, facts or opinions? A few questions that pop in mind:

- Can we expect support for PSoC to be added in due course?

- Can we expect better support for LPC5500 in the future? Currently it's mostly restricted to SPI, UART and I2C.

- What is the code stability/quality of the drivers in practice?

- Are there alternatives? We found libopencm3, does anyone have experience with that library?

- Is it reasonable to expect cross-platform USB support, or should we expect that the only way to get this working is with the libraries provided by the manufacturer?

Many thanks in advance. Apologies if this is not the correct forum to post this question.

Best regards,

pietro

Parents
  • From what I see are HAL not widely used as they often lack this or that feature one needs. On the other hand, a HAL with support for every feature of a peripheral is overloaded and not used due to its code size.
    But if you plan something like this, don't try to support everything from the beginning. Advance slowly and make sure your HAL is bug-free (I know, no software is bug-free). But also provide a number of tests for the HAL.

    Nothing is worse then using a HAL/drivers for a new SoC and the first thing is starting to debug it.

    Just my 2cents.

    PS: Don't rely on a certain RTOS. ;-)

Reply
  • From what I see are HAL not widely used as they often lack this or that feature one needs. On the other hand, a HAL with support for every feature of a peripheral is overloaded and not used due to its code size.
    But if you plan something like this, don't try to support everything from the beginning. Advance slowly and make sure your HAL is bug-free (I know, no software is bug-free). But also provide a number of tests for the HAL.

    Nothing is worse then using a HAL/drivers for a new SoC and the first thing is starting to debug it.

    Just my 2cents.

    PS: Don't rely on a certain RTOS. ;-)

Children