[bluGill]

Globals are common and even right in this application. However they didn't take proper care in other ways (i'm not clear what I've just been in embedded long enough to know globals are often required despite how hard they are to get right)

[UltraSane]

tons of global variables on code that has lots of people working on it seems almost as hard as trying to write lock-free data structures.

[bsder]

Global variables (nee static) are fairly normal in embedded. You want to preallocate all your memory since you generally don't have a heap.

Mostly you have specific inputs from some other tasks and your outputs are consumed by different tasks. So, even though the variables are "global" they generally only have one writer with multiple readers in properly done embedded programming.

What Toyota did was not even in the same universe as "properly done embedded".

[UltraSane]

"specific inputs from some other tasks and your outputs are consumed by different tasks" sounds a lot like how PLCs work. Just running an infinite loop scanning inputs and triggering outputs in response to the state of the inputs.

[bluGill]

In general embedded controllers like this don't have a lot of people working on them. They also have rules (enforced by review which isn't great) about when they can be accessed. In an embedded context you are not allowed to allocate memory (except at startup), so a lot of these globals are just arrays/buffers only used by one function or pseudo class (a class by intent but not actually a class by the language if the language even has a concept of class)

[heavyset_go]

IIRC, their code was evaluated against MISRA-C and was found to have tons of blatant and preventable violations of its principles.