I am working to bring up a board with a variety of components, LORA, UWB, IMU etc.. so I am writing drivers and would like to follow the existing structure for doing so.
I understand the architecture, I'd say most of my components will be complex drivers making use of existing peripheral drivers and then some abstraction for them as they may be replaced.
I am trying to relate the architectural figures to the files themselves: Complex Drivers, Device Drivers, Low Level Drivers
Looking at the directories I see:
os/ex/ -- has some devices from particular vendors
/hal/lib/peripherals -- some common devices, I'm thinking this is the top abstraction layer?
/various/devices_lib -- appears to be low level interface to specific device models?
I could just put all my own work in a folder of it's on but the would just make for spaghetti in linking.
Any advice would be appreciated as the hierarchy isn't really self evident to me in the folder structure.
Alex
Advice on filesystem organisation
Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Advice on filesystem organisation
Hi,
Mostly correct:
os/ex/ are implementations of abstract interfaces defined in os/hal/lib/peripherals, Complex Drivers meant to address board-level devices.
os/various/devices_lib is a leftover, replaced by ex, it will be removed soon.
About drivers:
Normal Drivers: HAL drivers meant to interact with application on the high side and HW on the low side. The API is standard.
Platform Drivers: Generic drivers for platform-specific functionalities and use the HAL "style" but the API is custom.
Complex Drivers: Anything that sits only on HAL and OSAL without touching RTOS and/or HW is classified as complex driver.
Abstract Interfaces: C++/like interfaces, just written in C.
High level subsystems like graphic libraries, communication stacks or file systems can be classified as Complex Drivers.
Giovanni
Mostly correct:
os/ex/ are implementations of abstract interfaces defined in os/hal/lib/peripherals, Complex Drivers meant to address board-level devices.
os/various/devices_lib is a leftover, replaced by ex, it will be removed soon.
About drivers:
Normal Drivers: HAL drivers meant to interact with application on the high side and HW on the low side. The API is standard.
Platform Drivers: Generic drivers for platform-specific functionalities and use the HAL "style" but the API is custom.
Complex Drivers: Anything that sits only on HAL and OSAL without touching RTOS and/or HW is classified as complex driver.
Abstract Interfaces: C++/like interfaces, just written in C.
High level subsystems like graphic libraries, communication stacks or file systems can be classified as Complex Drivers.
Giovanni
Re: Advice on filesystem organisation
Ok so let's see if I understand this using the Invensense mpu-9250 IMU as an example.
I would put the low level driver devices specifics files in ex/Invensense/mpu9250.h ... mpu9250.h ... mpu9250.mk
This is an I2C devices so it is a complex driver interfacing to hal/src/hal_12c.c
In hal/lib/sensor/ I would make a hal_imu.h and I can use hal_sensors.h as a template to work from.
If I also had a mpu-9150 i would do the same for this similar device. I include my choice of device to use in my project makefile and don't have to touch the hal_imu assuming they support all the same features.
Is this your intended structure?
I would put the low level driver devices specifics files in ex/Invensense/mpu9250.h ... mpu9250.h ... mpu9250.mk
This is an I2C devices so it is a complex driver interfacing to hal/src/hal_12c.c
In hal/lib/sensor/ I would make a hal_imu.h and I can use hal_sensors.h as a template to work from.
If I also had a mpu-9150 i would do the same for this similar device. I include my choice of device to use in my project makefile and don't have to touch the hal_imu assuming they support all the same features.
Is this your intended structure?
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Advice on filesystem organisation
Hi,
Correct except that ha_sensors.h is a base interface not a template, you need to extend that interface like other sensors do, see the accelerometer for example.
Giovanni
Correct except that ha_sensors.h is a base interface not a template, you need to extend that interface like other sensors do, see the accelerometer for example.
Giovanni
Re: Advice on filesystem organisation
Great! thank you very much.
I'm still very "hello world" at this point and I'm trying to get LED, USB, IMU up running first with HAL then RTOS.
I will be moving to some more complex devices such as LORA and UWB at some point, but perhaps i'll wait until then before getting into an appropriate classification of peripheral type.
It looks to me as though a new folder may be in order for RF type devices.
Alex
I'm still very "hello world" at this point and I'm trying to get LED, USB, IMU up running first with HAL then RTOS.
I will be moving to some more complex devices such as LORA and UWB at some point, but perhaps i'll wait until then before getting into an appropriate classification of peripheral type.
It looks to me as though a new folder may be in order for RF type devices.
Alex
Who is online
Users browsing this forum: Bing [Bot] and 18 guests