4 ms·

This is such a weird advice and it seems to come from a particular experience of software development. How about using Booleans for binary things? Is the LED o

by bsoles 1y ago

This is such a weird advice and it seems to come from a particular experience of software development. How about using Booleans for binary things? Is the LED on or off, is the button pressed or not, is the microcontroller pin low or high? Using Enums, etc. to represent those values in the embedded world would be a monumental waste of memory, where a single bit would normally suffice.

leni536 1y ago
> Using Enums, etc. to represent those values in the embedded world would be a monumental waste of memory, where a single bit would normally suffice. In C++ you can use enums in bit-fields, not sure what the case is in C.
jilles 1y ago
* led status: on, off, non-responsive * button status: idle, pressing, pressed I'm with you by the way, but you can often think of a way to use enums instead (not saying you should).
- nh23423fefe 1y ago
  well yes. every boolean is iso to 2, and every 2 can be embedded in 3. and every N can be embedded in N+1
- pessimizer 1y ago
  enum Bool { True, False, FileNotFound }; https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_ edit: The 24th of October will be the 20th anniversary of that post.
padjo 1y ago
I think it’s implicitly in the context of datastore design. In that context it feels like decent advice that would prevent a lot of mess.
kps 1y ago
They're boolean (single bit of information) but not boolean (single bit interpreted as meaning true or false). The LED isn't true or false, the microcontroller pin isn't true or false.
- bsoles 1y ago
  This is semantic pedantry. The association true/1/high and false/0/low is well-known and understood.
  - kps 1y ago
    Plenty of signals are asserted (true) by being brought low, or have 1=low (e.g. CAN).
- marcellus23 1y ago
  huh? The LED isn't true or false, but whether the LED is on is true or false.
  - simondw 1y ago
    And whether the LED is off is false or true.
aDyslecticCrow 1y ago
The boolean type is the massive whaste, not the enum. A boolean in c is just a full int. So definitely not a whaste to use an enum which is also an int. And usually you use operations to isolate the bit from a status byte or word, which is how it's also stored and accessed in registers anyway. So its still no boolean type despite expressing boolean things. Enums also help keep the state machine clear. {Init, on, off, error} capture a larger part of the program behavior in a clear format than 2-3 binary flags, despite describing the same function. Every new boolean flag is a two state composite state machine hiding edgecases.
- glxxyz 1y ago
  Not necessarily a waste in all languages. A c++ `std::vector<bool>` efficiently packs bits for example, although it does have its own 'issues'.
  - aDyslecticCrow 1y ago
    I kinda hate that. It gives the vector very special behaviour for one type in particular, going against the intuition behind how both boolean and vector works everywhere else in the language. Id prefer if they just added std::bitvector.
  - verall 1y ago
    Yes, this is interestingly considered one of the worst design decisions in C++ history. It's not /the/ worst but it's up there.
devnullbrain 1y ago
Having spent time in the embedded mines, I think the onus is on embedded to vocally differentiate itself from normal software development, not for it to be assumed that general software advice applies to embedded. If embedded projects start using C standards from the past quarter century, they can join in on type discourse.
bigger_cheese 1y ago
I work at an industrial plant we use boolean datatypes for stateful things like this. For example is Conveyor belt running (1) or stopped (0). Sure we could store the data by logging the start timestamp and a stop timestamp but our data is stored on a time series basis (i.e. in a Timeseries DB, the timestamp is already the primary key for each record) When you are viewing the trend (such a on control room screen) you get a nice square-wave type effect you can easily see when the state changes. This also makes things like total run time easy to compute, just sum the flag value over 1 second increments to get number of seconds in a shift the conveyor was running for. Sure in my example you could just store something like motor current in Amps (and we do) and use this to infer the conveyor state but hopefully I've illustrated why a on/off flag is cleaner.

by bsoles 1y ago

leni536 1y ago

> Using Enums, etc. to represent those values in the embedded world would be a monumental waste of memory, where a single bit would normally suffice. In C++ you can use enums in bit-fields, not sure what the case is in C.

jilles 1y ago

* led status: on, off, non-responsive * button status: idle, pressing, pressed I'm with you by the way, but you can often think of a way to use enums instead (not saying you should).

nh23423fefe 1y ago
well yes. every boolean is iso to 2, and every 2 can be embedded in 3. and every N can be embedded in N+1
pessimizer 1y ago
enum Bool { True, False, FileNotFound }; https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_ edit: The 24th of October will be the 20th anniversary of that post.

padjo 1y ago

I think it’s implicitly in the context of datastore design. In that context it feels like decent advice that would prevent a lot of mess.

kps 1y ago

They're boolean (single bit of information) but not boolean (single bit interpreted as meaning true or false). The LED isn't true or false, the microcontroller pin isn't true or false.

bsoles 1y ago
This is semantic pedantry. The association true/1/high and false/0/low is well-known and understood.
- kps 1y ago
  Plenty of signals are asserted (true) by being brought low, or have 1=low (e.g. CAN).
marcellus23 1y ago
huh? The LED isn't true or false, but whether the LED is on is true or false.
- simondw 1y ago
  And whether the LED is off is false or true.

aDyslecticCrow 1y ago

The boolean type is the massive whaste, not the enum. A boolean in c is just a full int. So definitely not a whaste to use an enum which is also an int. And usually you use operations to isolate the bit from a status byte or word, which is how it's also stored and accessed in registers anyway. So its still no boolean type despite expressing boolean things. Enums also help keep the state machine clear. {Init, on, off, error} capture a larger part of the program behavior in a clear format than 2-3 binary flags, despite describing the same function. Every new boolean flag is a two state composite state machine hiding edgecases.

glxxyz 1y ago
Not necessarily a waste in all languages. A c++ `std::vector<bool>` efficiently packs bits for example, although it does have its own 'issues'.
- aDyslecticCrow 1y ago
  I kinda hate that. It gives the vector very special behaviour for one type in particular, going against the intuition behind how both boolean and vector works everywhere else in the language. Id prefer if they just added std::bitvector.
- verall 1y ago
  Yes, this is interestingly considered one of the worst design decisions in C++ history. It's not /the/ worst but it's up there.

devnullbrain 1y ago

Having spent time in the embedded mines, I think the onus is on embedded to vocally differentiate itself from normal software development, not for it to be assumed that general software advice applies to embedded. If embedded projects start using C standards from the past quarter century, they can join in on type discourse.

bigger_cheese 1y ago

I work at an industrial plant we use boolean datatypes for stateful things like this. For example is Conveyor belt running (1) or stopped (0). Sure we could store the data by logging the start timestamp and a stop timestamp but our data is stored on a time series basis (i.e. in a Timeseries DB, the timestamp is already the primary key for each record) When you are viewing the trend (such a on control room screen) you get a nice square-wave type effect you can easily see when the state changes. This also makes things like total run time easy to compute, just sum the flag value over 1 second increments to get number of seconds in a shift the conveyor was running for. Sure in my example you could just store something like motor current in Amps (and we do) and use this to infer the conveyor state but hopefully I've illustrated why a on/off flag is cleaner.