C doesn't really guard anything. It does keep you from having to roll your own multiword arithmetics or integer division algorithms, and from dealing with architecture-related things that are mind-boggling for a human, but just another set of rules to a compilers (pipelines, delayed instructions, etc.), and takes over things like optimizing register usage.

On a computer, all the guides come at the cost of performance. Sure, you can make a programming langugage where buffer overflows are alway caught, but that language will spend a lot of CPU cycles on checks.

And there's also plenty of ARM chips that don't run Linux (because they can't due to lack of a MMU), e.g. Cortex-M0...M4-based parts.

That's one of the nice things about small target embedded work. It covers everything from 8-bit to 32-bit, from simple (no hardware multiplier, no division in hardware) to loaded (hardware floating point support, MAC units, HW dividers), from slow (temperature logging) to fast (control loop running at 30 kHz requiring 3us latency).

Well, not really. There are some architectures that were basically designed to be used with C (68k, ARM), but there are others (8051) where a C compiler need to jump through some major hoops.

And the C compiler still shields the programmers from things like stack frames or worrying about CPU register allocation.

To clarify: "Small target" means memory (RAM/Flash) is measured in kB, sometimes even in bytes.

You still have Python-capable processors for embedded systems if you can't afford to learn C.

As far as target size goes, that thing does not qualify as "small target".

FWIW, I've been struggling with LPC4300 series processors.

Those chips look like they're on the large end of "small target". Cortex-M4s are already pretty beefy CPUs.

The open source toolchain is just so bad that your CPU hard faults on first attempted function call (most likely due to incorrect memory maps).

You can usually get pretty detailed reasons for a hard fault if you dig into the appropriate CPU registers (HFSR, etc).

I'd check the linker command file. Setting up a basic memory map isn't that hard - it's the not-so-basic stuff where things get interesting (copying functions to RAM for execution, etc).

Not getting the TSA/DHS/ZXY treatment at the airport is worth a few hours of driving.

He was working for an oil company. Burning more gas means more profit for oil companies.

It's actually very simple. The brain is soft. The skull is hard. When the two collide due to the head experiencing too much acceleration, it's easy to guess which of the two will be damaged more.

The are dozens of types of sport that don't involve the participants head and neck experiencing large forces as a normal part of the game.

Then don't play football.

Avoidable brain damage is stupid. Avoidable mechanical brain damage twice so.

The author of the article mentioned using a simple login/password, but rejected the idea because it was too much hassle - not because someone else could use the login/password combination. This means that the employees can be trusted not misuse their credentials.

History disagrees with you.

http://en.wikipedia.org/wiki/B...