Software » Campo

Alarms/Alerts¶

Devices should indicate issues; e.g.:

• Battery low
• I2C problems
• Buffer overflow

Object structutre¶

Size	Decription	Examples
2	Object/Subsystem	I2C, VBat,
1	Unit	hz, Float, Time, Date, Percent, promilPwm, centiCelsius, canId, room, Multipacket-String
1	Issue	Whats wrong, Undervolts, Communication error
4	Value	32Bit data of kind 'unit'

Size	Decription	Examples
2	Event/Alert	buffer overflow, want sleep, overtemperature, Undervolts, Communication error + categorie
1	Unit	hz, Float, Time, Date, Percent, promilPwm, centiCelsius, canId, room, Multipacket-String
1	type
4	Value	32Bit data of kind 'unit'

Room is a bit specifik to the timeout-shutdown-thing. subindex
Setting ambient light has the same issue.

Categorie:
USB, UART, System

Type:
Critical, Warning, Info, Event

Events:
Simple integer code which can be send via logging * Buffer overflow * I2C issue

Events vs. Alerts¶

Events can be integrated into logging. They can be used anywhere in the code like ISRs. An Event has no output value. Events just happen. They do not "disapear" or have an state.
The overhead should be acceptable. The code still compiles if events are disabled.

bWarningE( EV_BUFFER_OVERFLOW | EV_UART, LDS("Buffer overflow: %d", "BOF:", cnt);

Alarms are send explicitly as system errors in the main event loop. An Alarm has an concrete value and it has an state like "apeared" or "disapeared".
The overhead is a little big higher than events. It uses an additional function code in Tdt.

sendAlarm( Tdt::EAlarm::OverTemperature, Tdt::EAlarmState::appear,
                 Tdt::EUnit::centiCelsius, Tdt::SValue { ._int=temperature } );
sendAlarm( Tdt::EAlarm::UnderVoltage, Tdt::EAlarmState::appear,
                 Tdt::EUnit::milliVolt, Tdt::SValue { ._int=voltage } );
sendAlarm( Tdt::EAlarm::UnderVoltage, Tdt::EAlarmState::disappear,
                 Tdt::EUnit::none, Tdt::SValue {  } );

Events and alarms are implemented independantly. They can be used mutual.