C vs C++ in Embedded Systems?

This reminded me of someone I worked with once. He was tasked to reverse engineer a piece of kit that had an 8 bit embedded processor in it, and the source code was lost.

However, rather than use a disassembler, he was content to hand disassemble the program. We didn't have the tools, and it seems that no effort was made in getting any. I did talk about tools to him but he wasn't particularly interested. Our manager didn't really know anything about embedded development so he didn't intervene.

After about three months, it was obvious that the task was going nowhere so our manager put an end to the task.

I remember loads of paper covering his desk (and lots of bits of rubber!). To his credit though, he did use a pencil for his hand disassembly and not a pen.

;-)

Regards,

Paul.

Reply to
Paul Taylor
Loading thread data ...

I might agree if the saturation value is INF (which is often supported with FP arithmetic). Then, further calculation will yield *obviously* wrong results and you also don't need to hand-propagate errors.

Ok so far...

Nope. Unless you're going to discard the results (which would defeat the pupose of the calculation), someone or something actively has to decide that the results are wrong and take action on that fact. This decision is either made in program code or by a human reading some kind of output. There definitely will be a check *somewhere*, otherwise the calculation is useless.

IME, this is typically not possible. An application using a library often employs its own layers to simplify library usage. Errors reported from the library almost always need to be propagated through these layers so that they can be dealt with...

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
 Click to see the full signature
Reply to
Andreas Huber

do

generator,

taste,

OO techniquies will improve 8 bit controllers when they are designed to use them So far NO 8 bitters think about OO but consider.

class PERIPHERAL { public: PERIPHERAL(BYTE config); ~PERIPHERAL(void); void enable_interrupt(void) { mode |= 0x02; } void disable_interrupt(void) { mode |= 0x02; } void start(void) { mode |= 0x01; } void stop(void) { mode &= ~0x01; } bool ready(void) { return ((status & 0x04) !=

0)} private: BYTE config; BYTE mode, BYTE status; }

class TIMER : public PERIPHERAL { public: TIMER(void); BYTE counter; BYTE reload_high BYTE reload_low; }

class SPI : public PERIPHERAL { public: SPI(void); BYTE data; }

By using the inheritance mechanism for the definition of the peripherals the code size for an 8 bit controller will be reduced. The code to enable interrupt for the SPI will be the same as the code for enabling interrupt for the timer. They can thus share the same configuration routine.

If you have 4 UARTs in the device, and the interrupt for a certain UART automatically maps in the UART register to a static location, you will save a LOT of code space.-

OO is the way to go for lower cost, (Embedded) C++ is the only alternative, practically available and has to be used with extreme care.

-- Best Regards, Ulf Samuelsson snipped-for-privacy@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB

Reply to
Ulf Samuelsson

Hand-propagate errors? That's what signaling NANs an silent NANs were invented for.

Reply to
Guy Macon

Well, INF is propagated automatically as well, isn't it? Moreover, if you make further calculations with INF values (e.g. INF*0), NAN values often result...

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
 Click to see the full signature
Reply to
Andreas Huber

Exactly so. In many cases, no need to hand-propagate errors.

Reply to
Guy Macon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.