Add HAL folder for common boards #366

New Issue

muellerr · 2021-02-01T11:54:57+01:00

muellerr commented

2021-02-01 11:54:57 +01:00

Space hardware is usually expensive. A Raspberry Pi (Linux) or a STM32H743ZI-Nucleo (FreeRTOS & RTEMS) is not. I think it would be nice if sw developers who, for example, want to test their device handler for a sensor could just grab one of those cheap boards, plug the sensor in and test whether their device handler works. This would also allow SW development before the target hardware is acquired. Raspberry Pi and STM32 already provide hardware abstraction layers. The Raspberry Pi does so in form of Linux drivers(ioctl) and STM32 with their HAL. The only thing required in addition is a thin abstraction layer in form of DeviceCommunicationIF objects for all important peripheral protocols and a corresponding CookieIF cookie implementation.

The following interfaces would be very useful:

Raspberry Pi (or any other embedded linux system):

GPIO abstraction layer, maybe also possible generic, contains internal map which maps gpio ID to BCM pin.
SPI abstraction layer, which uses the GPIO abstraction layer for slave selection and otherwise uses the Linux SPI device drivers. GPIO ID (or pin?) stored in Cookie.
I2C abstraction layer, using the Linux I2C device drivers

STM32H743ZI-Nucleo (FreeRTOS and propably also RTEMS):

GPIO abstraction layer. Here, we don't have the convenience of BCM pins, so maybe the map is a little bit more complex
SPI abstraction layer, which uses the GPIO abstractio layer and uses the STM32 HAL library. I don't know whether RTEMS provides SPI drivers
I2C abstraction layer, using the STM32 HAL. I don't know whether RTEMS provides I2C drivers

Host:

USB/Serial port abstraction layer. For some reason, C++ does not have a portable serial port abstraction layer like the one Python provides with PySerial. The best option probably is boost::asio. This would be interesting to send commands to an Arduino or any other device connected directly via USB, maybe with a USB-RS232 connector in between.
TCP/IP abstraction layer. There is already a TMTC bridge which uses TCP/IP. But maybe a ComIF would not be bad either. One could send a command to a Raspberry Pi in the same network which relays the command to a connected sensor. Again, no portable solution provided by standard C++ library yet, but boost::asio provides one.

Possible folder structure:

-> fsfw
--> ...
--> hal
---> stm32
---> rpi

And conditional compilation via CMake options like FSFW_ADD_RASPBERRYPI_HAL, FSFW_ADD_STM32_HAL, FSFW_USE_BOOST_LIB etc. which are set by upper CMakeLists.txt file.

Space hardware is usually expensive. A Raspberry Pi (Linux) or a STM32H743ZI-Nucleo (FreeRTOS & RTEMS) is not. I think it would be nice if sw developers who, for example, want to test their device handler for a sensor could just grab one of those cheap boards, plug the sensor in and test whether their device handler works. This would also allow SW development before the target hardware is acquired. Raspberry Pi and STM32 already provide hardware abstraction layers. The Raspberry Pi does so in form of Linux drivers(`ioctl`) and STM32 with their HAL. The only thing required in addition is a thin abstraction layer in form of `DeviceCommunicationIF` objects for all important peripheral protocols and a corresponding `CookieIF` cookie implementation. The following interfaces would be very useful: Raspberry Pi (or any other embedded linux system): - GPIO abstraction layer, maybe also possible generic, contains internal map which maps gpio ID to BCM pin. - SPI abstraction layer, which uses the GPIO abstraction layer for slave selection and otherwise uses the Linux SPI device drivers. GPIO ID (or pin?) stored in Cookie. - I2C abstraction layer, using the Linux I2C device drivers STM32H743ZI-Nucleo (FreeRTOS and propably also RTEMS): - GPIO abstraction layer. Here, we don't have the convenience of BCM pins, so maybe the map is a little bit more complex - SPI abstraction layer, which uses the GPIO abstractio layer and uses the STM32 HAL library. I don't know whether RTEMS provides SPI drivers - I2C abstraction layer, using the STM32 HAL. I don't know whether RTEMS provides I2C drivers Host: - USB/Serial port abstraction layer. For some reason, C++ does not have a portable serial port abstraction layer like the one Python provides with `PySerial`. The best option probably is `boost::asio`. This would be interesting to send commands to an Arduino or any other device connected directly via USB, maybe with a USB-RS232 connector in between. - TCP/IP abstraction layer. There is already a TMTC bridge which uses TCP/IP. But maybe a ComIF would not be bad either. One could send a command to a Raspberry Pi in the same network which relays the command to a connected sensor. Again, no portable solution provided by standard C++ library yet, but `boost::asio` provides one. Possible folder structure: -> fsfw --> ... --> hal ---> stm32 ---> rpi And conditional compilation via CMake options like `FSFW_ADD_RASPBERRYPI_HAL`, `FSFW_ADD_STM32_HAL`, `FSFW_USE_BOOST_LIB` etc. which are set by upper `CMakeLists.txt` file.

muellerr added the

feature

label 2021-02-01 11:54:57 +01:00

gaisser commented

2021-04-20 18:29:44 +02:00

Part of https://egit.irs.uni-stuttgart.de/fsfw/fsfw_hal

gaisser closed this issue

2021-04-20 18:29:44 +02:00

Sign in to join this conversation.