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.

▲ aDyslecticCrow 5 days ago | parent | next [-]

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 5 days ago | parent [-]

Not necessarily a waste in all languages. A c++ `std::vector<bool>` efficiently packs bits for example, although it does have its own 'issues'.

	▲	verall 4 days ago \| parent \| next [-]
		Yes, this is interestingly considered one of the worst design decisions in C++ history. It's not /the/ worst but it's up there.
	▲	aDyslecticCrow 5 days ago \| parent \| prev [-]
		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.

▲ jilles 5 days ago | parent | prev | next [-]

* 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).

	▲	pessimizer 5 days ago \| parent \| next [-]
		`enum Bool { True, False, FileNotFound };` https://thedailywtf.com/articles/What_Is_Truth_0x3f_ edit: The 24th of October will be the 20th anniversary of that post.
	▲	nh23423fefe 5 days ago \| parent \| prev [-]
		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

▲ devnullbrain 5 days ago | parent | prev | next [-]

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 5 days ago | parent | prev | next [-]

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.

▲ leni536 5 days ago | parent | prev | next [-]

> 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.

▲ padjo 5 days ago | parent | prev | next [-]

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 5 days ago | parent | prev [-]

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 5 days ago | parent | next [-]

This is semantic pedantry. The association true/1/high and false/0/low is well-known and understood.

	▲	kps 5 days ago \| parent [-]
		Plenty of signals are asserted (true) by being brought low, or have 1=low (e.g. CAN).

▲

marcellus23 5 days ago | parent | prev [-]

huh? The LED isn't true or false, but whether the LED is on is true or false.

	▲	simondw 5 days ago \| parent [-]
		And whether the LED is off is false or true.