Dear all,
I am thinking about an improvement of MEMS related EX drivers. While I have clear ideas on certain points I have a lot of doubts on others. The question is what features user should be able to configure? As example L3GD20 has 5 CR plus other register for FIFO and IRQ: the capability of configure all of them would require a very long Configuration. I would like to understand what kind of settings are mandatory, what kind of settings could be considered advanced (so something to be optionally enabled) and what kind of settings could be ignored.
My idea is
MANDATORY
full scale, odr, bandwidth, blockdatupdate
ADVANCED
lowpower, filteringstuffs, irqstuffs, endianness
IGNORABLE
axeanbling, fifo, all other not mentioned
Please share your opinion.
Ciao,
RM
Request for a feedback
- RoccoMarco
- Posts: 655
- Joined: Wed Apr 24, 2013 4:11 pm
- Location: Munich (Germany)
- Has thanked: 83 times
- Been thanked: 67 times
- Contact:
Re: Request for a feedback
My experience with MEMS is quite limited, but by looking at the L3GD20, if I were planning to use it I would probably start with the FIFO in Stream mode and setting up the appropriate interrupts to page data out at various levels. I'm also not sure when I'd ever use block data update, to be honest. The other things that you have seem to be approximately in the order of priority that I'd put them in.
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
As an aside, I was very surprised to see a high pass filter setting - I would have expected a low-pass filter, which I guess does exist but is very poorly documented. Is that to remove a DC offset in the MEMS gyro or something? Seems like you'd miss all your steady-state rotation...
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
As an aside, I was very surprised to see a high pass filter setting - I would have expected a low-pass filter, which I guess does exist but is very poorly documented. Is that to remove a DC offset in the MEMS gyro or something? Seems like you'd miss all your steady-state rotation...
- RoccoMarco
- Posts: 655
- Joined: Wed Apr 24, 2013 4:11 pm
- Location: Munich (Germany)
- Has thanked: 83 times
- Been thanked: 67 times
- Contact:
Re: Request for a feedback
LP filter is not suitable since except gyroscope, every MEMS has a DC component. Gravity vector for accelerometer, EM Earth field for compass, temperature for thermometer and so on. Bias usually is removed through a compensation procedure which depends on MEMS kind.
Thanks for you feedback.
Thanks for you feedback.
- Korken
- Posts: 270
- Joined: Wed Apr 02, 2014 4:09 pm
- Location: Luleå, Sweden
- Has thanked: 5 times
- Been thanked: 6 times
- Contact:
Re: Request for a feedback
Hi RM! I will give some input
One thing, MEMS sensor have a lot of settings so I would not obsess if it takes a day to set it up correctly.
Everything still needs to be set, either by the user or by the writer of the driver (and abstracting it for the user).
MANDATORY
* full scale
With this I assume you mean setting the scaling factor, this is indeed a must - especially for online calibration.
* odr
Also a must.
* bandwidth
This goes together with "filteringstuffs", as the sensor internally applies a lowpass filter (sometimes analog and sometimes digital).
But it needs to be set in any case. Usually to "no filtering" and let the MCU do the filtering, but depends on application.
* blockdatupdate
This name makes little sense to convey the function (even though the datasheets use it), maybe look into giving it a name that reflects the function better?
Something along the lines of allowing data overwrite in the registers?
Not sure though, the hardcore MEMS guy would like this name, not sure about beginners and how much abstraction we should have.
ADVANCED
* lowpower
This fits as advanced.
* filteringstuffs
This goes hand-in-hand with bandwidth, but is this is only for MCU-based filtering, then it fits well here.
* irqstuffs
This fits as advanced.
* endianness
It's certainly good to have, but does anything except MSP use big-endian today?
MISSING (in my opinion )
* bias settings should be mandatory with fullscale.
All these systems work on the sensitivity*raw value + bias, so maybe have them as a bundled package at all time?
* For ADVANCED, an interface to update the sensitivity and bias based on incoming data for sample to sample temperature compensation.
This could also be left to the user to implement.
I think you are referring to high-pass filtering.
Low-pass allows bias (the low frequency) to be kept but attenuates higher frequencies and adds phase shift as a bi-product.
One thing, MEMS sensor have a lot of settings so I would not obsess if it takes a day to set it up correctly.
Everything still needs to be set, either by the user or by the writer of the driver (and abstracting it for the user).
MANDATORY
* full scale
With this I assume you mean setting the scaling factor, this is indeed a must - especially for online calibration.
* odr
Also a must.
* bandwidth
This goes together with "filteringstuffs", as the sensor internally applies a lowpass filter (sometimes analog and sometimes digital).
But it needs to be set in any case. Usually to "no filtering" and let the MCU do the filtering, but depends on application.
* blockdatupdate
This name makes little sense to convey the function (even though the datasheets use it), maybe look into giving it a name that reflects the function better?
Something along the lines of allowing data overwrite in the registers?
Not sure though, the hardcore MEMS guy would like this name, not sure about beginners and how much abstraction we should have.
ADVANCED
* lowpower
This fits as advanced.
* filteringstuffs
This goes hand-in-hand with bandwidth, but is this is only for MCU-based filtering, then it fits well here.
* irqstuffs
This fits as advanced.
* endianness
It's certainly good to have, but does anything except MSP use big-endian today?
MISSING (in my opinion )
* bias settings should be mandatory with fullscale.
All these systems work on the sensitivity*raw value + bias, so maybe have them as a bundled package at all time?
* For ADVANCED, an interface to update the sensitivity and bias based on incoming data for sample to sample temperature compensation.
This could also be left to the user to implement.
RoccoMarco wrote:LP filter is not suitable since except gyroscope, every MEMS has a DC component. Gravity vector for accelerometer, EM Earth field for compass, temperature for thermometer and so on. Bias usually is removed through a compensation procedure which depends on MEMS kind.
I think you are referring to high-pass filtering.
Low-pass allows bias (the low frequency) to be kept but attenuates higher frequencies and adds phase shift as a bi-product.
- RoccoMarco
- Posts: 655
- Joined: Wed Apr 24, 2013 4:11 pm
- Location: Munich (Germany)
- Has thanked: 83 times
- Been thanked: 67 times
- Contact:
Re: Request for a feedback
Hey korken,
you mean there should be an initial bias/sensitività field in memsConfig?
About LP I have messed up. Ignore my previous shitty answer.
you mean there should be an initial bias/sensitività field in memsConfig?
About LP I have messed up. Ignore my previous shitty answer.
- Korken
- Posts: 270
- Joined: Wed Apr 02, 2014 4:09 pm
- Location: Luleå, Sweden
- Has thanked: 5 times
- Been thanked: 6 times
- Contact:
Re: Request for a feedback
>> you mean there should be an initial bias/sensitività field in memsConfig?
Indeed, I have yet to find a sensor where this is not used.
The ones I have changed this for include: acc, gyro, mag, baro and mems microphone.
Indeed, I have yet to find a sensor where this is not used.
The ones I have changed this for include: acc, gyro, mag, baro and mems microphone.
- RoccoMarco
- Posts: 655
- Joined: Wed Apr 24, 2013 4:11 pm
- Location: Munich (Germany)
- Has thanked: 83 times
- Been thanked: 67 times
- Contact:
Re: Request for a feedback
I am working on L3GD20 trying to make driver more elegant.
Current configuration structure is
I would like to add advanced things related to IRQ but this is is a PITA because IRQ cfg has a lot of switches and values in a lot of different registers.
I don't know how it should be done. An idea could be this.
Suggestions?
Current configuration structure is
Code: Select all
/**
* @brief L3GD20 configuration structure.
*/
typedef struct {
#if L3GD20_USE_SPI || defined(__DOXYGEN__)
/**
* @brief SPI driver associated to this L3GD20.
*/
SPIDriver *spip;
/**
* @brief SPI configuration associated to this L3GD20.
*/
const SPIConfig *spicfg;
#endif /* L3GD20_USE_SPI */
#if L3GD20_USE_I2C || defined(__DOXYGEN__)
/**
* @brief I2C driver associated to this L3GD20.
*/
I2CDriver *i2cp;
/**
* @brief I2C configuration associated to this L3GD20.
*/
const I2CConfig *i2ccfg;
#endif /* L3GD20_USE_I2C */
/**
* @brief L3GD20 initial sensitivity.
* @details If set to @p NULL default typical value is used.
*/
float sensitivity[L3GD20_NUMBER_OF_AXES];
/**
* @brief L3GD20 initial bias.
* @details If set to @p NULL zero value is used.
*/
float bias[L3GD20_NUMBER_OF_AXES];
/**
* @brief L3GD20 full scale value.
*/
l3gd20_fs_t fullscale;
/**
* @brief L3GD20 output data rate selection.
*/
l3gd20_odr_t outputdatarate;
#if L3GD20_USE_ADVANCED || defined(__DOXYGEN__)
/**
* @brief L3GD20 block data update.
*/
l3gd20_bdu_t blockdataupdate;
/**
* @brief L3GD20 endianness.
*/
l3gd20_end_t endianness;
/**
* @brief L3GD20 HP filter mode.
*/
l3gd20_hpm_t hpmode;
/**
* @brief L3GD20 HP configuration.
*/
l3gd20_hpcf_t hpconfiguration;
#endif
} L3GD20Config;
I would like to add advanced things related to IRQ but this is is a PITA because IRQ cfg has a lot of switches and values in a lot of different registers.
I don't know how it should be done. An idea could be this.
Code: Select all
/**
* @brief L3GD20 configuration structure.
*/
typedef struct {
#if L3GD20_USE_SPI || defined(__DOXYGEN__)
/**
* @brief SPI driver associated to this L3GD20.
*/
SPIDriver *spip;
/**
* @brief SPI configuration associated to this L3GD20.
*/
const SPIConfig *spicfg;
#endif /* L3GD20_USE_SPI */
#if L3GD20_USE_I2C || defined(__DOXYGEN__)
/**
* @brief I2C driver associated to this L3GD20.
*/
I2CDriver *i2cp;
/**
* @brief I2C configuration associated to this L3GD20.
*/
const I2CConfig *i2ccfg;
#endif /* L3GD20_USE_I2C */
/**
* @brief L3GD20 initial sensitivity.
* @details If set to @p NULL default typical value is used.
*/
float sensitivity[L3GD20_NUMBER_OF_AXES];
/**
* @brief L3GD20 initial bias.
* @details If set to @p NULL zero value is used.
*/
float bias[L3GD20_NUMBER_OF_AXES];
#if L3GD20_USE_ADVANCED || defined(__DOXYGEN__)
/**
* @brief L3GD20_CTRL_REG1 value.
*/
uint8_t cr1;
/**
* @brief L3GD20_CTRL_REG2 value.
*/
uint8_t cr2;
/**
* @brief L3GD20_CTRL_REG3 value.
*/
uint8_t cr3;
/**
* @brief L3GD20_CTRL_REG4 value.
*/
uint8_t cr4;
/**
* @brief L3GD20_CTRL_REG5 value.
*/
uint8_t cr5;
/**
* @brief L3GD20_REFERENCE value.
*/
uint8_t reference;
/**
* @brief L3GD20_FIFO_CTRL_REG value.
*/
uint8_t fifocr;
/**
* @brief L3GD20_FIFO_SRC_REG value.
*/
uint8_t srccr;
/**
* @brief L3GD20_INT1_CFG value.
*/
uint8_t int1cfg;
/**
* @brief L3GD20_INT1_SRC value.
*/
uint8_t int1src;
/**
* @brief L3GD20 X-axis threshold value.
*/
uint16_t xthreshold;
/**
* @brief L3GD20 Y-axis threshold value.
*/
uint16_t ythreshold;
/**
* @brief L3GD20 Z-axis threshold value.
*/
uint16_t zthreshold;
/**
* @brief L3GD20_INT1_DURATION value.
*/
uint8_t int1duration;
#else
/**
* @brief L3GD20 full scale value.
*/
l3gd20_fs_t fullscale;
/**
* @brief L3GD20 output data rate selection.
*/
l3gd20_odr_t outputdatarate;
#endif
} L3GD20Config;
Suggestions?
- Giovanni
- Site Admin
- Posts: 14461
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Request for a feedback
Configuration structures are usually constant, are all those parameters meant to be modifiable or constant?
Giovanni
Giovanni
- RoccoMarco
- Posts: 655
- Joined: Wed Apr 24, 2013 4:11 pm
- Location: Munich (Germany)
- Has thanked: 83 times
- Been thanked: 67 times
- Contact:
Re: Request for a feedback
All of them are constant,
These value are just the initial value of register or driver fields. If some of them requires edits after the start there would be specific APIs like any other driver.
RM
These value are just the initial value of register or driver fields. If some of them requires edits after the start there would be specific APIs like any other driver.
RM
Who is online
Users browsing this forum: No registered users and 0 guests