Setup driver settings from EEPROM information

[Ilya Gavrilov]

Definition of Done

• code for mentioned task is complete. examples & documentations are complete.

• build chains are tested

• corresponding branch is closed

• merging is done

[Ilya Gavrilov]

EEPROM has vendor string, we can map each vendor string to settings set:

"TimeSwipe NORM" => Mode 0; Offsets 0,0,0,0; Gains 0,0,0,0; Transmissions 1,1,1,1
"TimeSwipe IEPE" => Mode 1; Offsets 0,0,0,0; Gains 0,0,0,0; Transmissions 1,1,1,1
"TimeSwipe DMS" => Mode 2; Offsets 0,0,0,0; Gains 0,0,0,0; Transmissions 1,1,1,1
and so on

• This map should be hardcoded in the app
• Once applications starts it reads EEPROM (as already implemented)
• on TimeSwipe object creation SetMode SetOffsets SetGains SetTransmissions method are calling with mapped settings from EEPROM
• user can get settings using new methods GetMode GetOffsets GetGains GetTransmissions
• user can override any settings with corresponding setters
• if map entry doesn't exist user have to call all setters before Start

@IngoKaiser is that expected design?

[Ingo Kaiser]

Hey @iluxa

Quite good, but adoption is needed:
I hope I can make it clear: we have two different boards. Both have a basic (primary) measurement principle (DMS or IEPE). Both can also process Normsignals (second principle) and we are introducing a third principle to be able to read digital inputs.

In Vendor Information we find Product id- this tells if board is DMS (0) or IEPE (1)

Mode is more like which principle on board should be used, just as primary (DMS or IEPE according to product id), secondary (NORM) or third (DIGITAL) - so user needs to choose.

According to that we have some settings available on board.

For IEPE Board we just toggle Mode (principle) in Firmware.

For DMS principle on DMS Board we can do some more settings (bridge voltage, hardware zero balancing)

At the moment the three software settings we have are:

Set Offset: this is just Software Offset to shift level - e.g. for zero adjustments - like on a kitchen scale

Set Gain - this will be available in a calibration atom in eeprom soon. At the moment we are setting this manually. This is a board specific property - specific for each channel.

Set Transmission - this is a value we need to set manually since it’s a sensor specific property - user can add this to get right measuring unit. If default (1) is set, he only gets result in Volts.

So Mode(0) is DMS or IEPE - according to product Id.

Mode(1) is NORM

and Mode(2) is DIGITAL

From choosing a Mode and sending the mode on spi we don’t set other settings. It’s just for to firmware to toggle principle on board.

[Ilya Gavrilov]

@begodev Is there issue created for product id(for DMS and IEPE) in vendor information and calibration atom in EEPROM?
There should be Mode access point implemented too.

[begodev]

• This map should be hardcoded in the app

Why it has to be hardcoded? Why just don't read the corresponding ATOM from the EEPROM?

[begodev]

At the moment "SetGain" and "SetTransmission" act as divisors. Is it correct?

[begodev]

Is there issue created for product id(for DMS and IEPE) in vendor information and calibration atom in EEPROM?
There should be Mode access point implemented too.

No. Should I creaate it?

[Ilya Gavrilov]

At the moment "SetGain" and "SetTransmission" act as divisors. Is it correct?

yes.

No. Should I creaate it?

We can use share this issue, I can work in related issue#22

[Ingo Kaiser]

At the moment "SetGain" and "SetTransmission" act as divisors. Is it correct?

Yes - what’s the point? 😉

[begodev]

Just a bit confusing for me: I imagine gain and transmission as factors (multipliers)

[begodev]

We can use share this issue, I can work in related issue#22

ok

[Ingo Kaiser]

@iluxa are gain and transmission implemented as multipliers?

[Ilya Gavrilov]

yes, and converted to one multiplier

[Phil Malessa]

@IngoKaiser I think this can be closed as well, because only one Board is active currently.