Request for a feedback

Discussions and support about ChibiOS/EX, the External Peripherals Abstraction Layer.
Posts: 12
Joined: Fri Jul 22, 2016 5:23 am
Been thanked: 3 times

Re: Request for a feedback

Postby webbbn » Fri Jul 22, 2016 8:22 pm

awygle wrote:I'm very interested in what you come up with here. I've been writing EX drivers for a couple of RF transceiver chips lately and those things have a *ton* of configuration parameters. Currently I'm exposing more-or-less all of them in the Config struct and making sure to put together a sensible default_config to act as a starting point. When those are a little further along I'll post the code and you can see what too much configuration looks like :D

This is not directly related to this topic, but I have quite a bit of experience in RF modules (at least the HopeRF modules), and while you may want to tweak some parameters, generally most of the parameters are highly dependent on other parameters. Most of the parameters can be set in a lookup table based on RF datarate. In fact, for the RFM22B there's a spreadsheet where you put in the datarate (and maybe another parameter or two) and it spits out most of the register settings.

As for MEMS sensors, you probably want to control most of the parameters, but I wouldn't put any biases or scales. They are required, but they're not something that you can default in a standard configuration, and they're easy enough to apply externally.

Another couple of complications is that some sensor allow you to chain sensors onto them. This is common to add e.g. an external magnetometer or pressure sensor. Some even support full attitude solutions in addition to the raw sensor values.

Posts: 118
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 12 times
Been thanked: 21 times

Re: Request for a feedback

Postby Thargon » Tue Jul 26, 2016 4:13 pm

Hi RoccoMarco,

I was just planing to introduce some abstraction layer for periphery hardware in my project as well, when I noticed this new subproject of ChibiOS :). I have not tried your solution yet, but after a brief look at the code I found some things missing, which I thought to be very important for my own implementation. So here are my points:
  • "EXternal peripherals" as you call this subproject should include everything you can attach to an MCU using any communication interface. So far I am missing things like motors or LEDs (or are LEDs handled as displays?). So when evolving the project, actuators should also be considered.
  • Since the defined _base_sensor_methods (hal_sensors.h) will probably be used very often, they should offer more flexibility. The current definition of read_raw() for example, will cause issues if the sensor returns 32 bit unsigned integer values, and there will be overhead in case the sensor returns just a lot of 8 bit values (many 'small' channels).
  • In addition to the previous point, I find it quite important that you can select which channels to read from a sensor. Some sensors might not support this, so there should be a way to detect that (e.g. some hasFeature() method), but for instance if I have many peripherals all connected via a single I2C bus, I may want to minimize bandwidth requirements and hence read only specific channels.
    I noticed that such selective reading is implemented in some drivers (e.g. lis302dl), but using a configuration is quite cumbersome imo and you still need to allocate the full memory (e.g. int[3] even if you want to read only a single channel) and can not detect which channels have been read afterwards.
    Example: Let A and B be two threads and S a sensor driver with multiple channels. A configures S to read all channels. Later, B reconfigures S to read only one channel. A can not detect that the configuration was altered without explicitly looking into the current configuration.
  • The BaseSensor (hal_sensors.h) defines the methods read_raw() and read_cooked(). Actually I do not understand the intention of the latter (maybe a more informative documentation would help ;) ). As I read it, 'cooked' means preprocessed sensor data and this preprocessing was done by the sensor itself. That again sounds to me more like an additional channel or a completely new virtual sensor.
    Example: Let an accelerometer return its raw data as int32 with some scaling applied, depending on its configuration. The sensor can either return the raw data, normalized as float or normalized as int16 with a defined range. I might be wrong, but as I see it, the BaseSensor interface can not be applied here. You could, however, implement the driver for this accelerometer as three distinct virtual BaseSensors: One reading the int32 data, one reading the floats and another reading the int16 values.
I hope there are not too many points only because I did not look very deeply into the code. :oops:
Anyway, you asked for feedback :P

Best regards,

Return to “ChibiOS/EX”

Who is online

Users browsing this forum: No registered users and 3 guests