Developing/compiling software
in [Embedded]
|
From: ChrisQ on 28 Sep 2009 12:42 David Brown wrote: > > Personally, I think the general idea of "all global data is evil" is > silly, especially for embedded development. But if you've got a > programming method that helps you write better code, then that's far > more important than what other people think! Having had to wade through impenetrable code too many times in the past, where it's hard to tell what's poking what and when, I try not to inflict the same on others. One of the ways to do this is to encapsulate functionality, keep data local as possible and communicate through well defined inband interfaces. The typical embedded design can be split into subsystems - for example, uarts / comms, timers, ports etc. There's no reason why the internal data relating to a subsystem should be public, even though it may need to be visible internally. Avoiding this makes for a more reliable system design, it's easier to make changes, add modules and to keep track of the big picture. Of course, none of this is new, but it does seem to work... Regards, Chris
From: ChrisQ on 28 Sep 2009 13:12 Mel wrote: > ChrisQ wrote: > >> Stuff like that may be hidden by the compiler, much as one might stick a >> bandaid on a sore to hide it, but the inefficiency is still there. > > That's not really the C programming attitude. I don't care what steps to > the left or right the program takes while getting where I want it to go. If > it meets specs and performance targets, then it's a product, and that's why > we're there. Partly agree with that but having no idea what the complier is doing hardly sounds like due diligence to me. With Keil and 8051, I don't expect code efficiency and rarely if ever look at the asm output. That is, I have confidence in the tools. But as a hardware and software bod, have to decide on hardware / software tradeoffs for new projects. Cpu architecture and features are pretty important at that level, though modern micros often have far more grunt than is needed for the application. As a programmer, I want a broad canvas, big linear address space with no gotchas or speed limits, but engineering isn't like that. It helps to know what's going on under the hood. Besides, cpu architecture is interesting. Well, to some anyway... Regards, Chria
From: Jon Kirwan on 28 Sep 2009 15:11 On Mon, 28 Sep 2009 14:28:37 +0300, Niklas Holsti <niklas.holsti(a)tidorum.invalid> wrote: ><snip> >Although the AVR is register-rich, it is "pointer-poor". Some other >architectures, such as the H8/300, have more flexible interplay of 8-bit >and 16-bit computations. If my memory is right, I was playing with the H8/300 back in 1982 or '83. Regardless of the timing, I remember carefully wiring up an adapter so that I could program it in a standard EPROM socket. It was wonderful that they'd arranged it such that the standard EPROM sequences would work. And they did. And the instruction set was a dream, by comparison with many devices then (and sometimes, I think, even now.) I think I still have a few in a box of cpus, here. I've never used them for anything but play, but I am glad to hear they are still around. Jon
From: David Brown on 28 Sep 2009 16:05 ChrisQ wrote: > Mel wrote: >> ChrisQ wrote: >> >>> Stuff like that may be hidden by the compiler, much as one might stick a >>> bandaid on a sore to hide it, but the inefficiency is still there. >> >> That's not really the C programming attitude. I don't care what steps >> to the left or right the program takes while getting where I want it >> to go. If it meets specs and performance targets, then it's a >> product, and that's why we're there. > > Partly agree with that but having no idea what the complier is doing > hardly sounds like due diligence to me. With Keil and 8051, I don't > expect code efficiency and rarely if ever look at the asm output. That > is, I have confidence in the tools. But as a hardware and software bod, > have to decide on hardware / software tradeoffs for new projects. Cpu > architecture and features are pretty important at that level, though > modern micros often have far more grunt than is needed for the application. > > As a programmer, I want a broad canvas, big linear address space with no > gotchas or speed limits, but engineering isn't like that. It helps to > know what's going on under the hood. For small systems, I fully agree - it's good to be able to write neat, portable C code, but you should understand what your compiler is doing and how your target works. That's how you get the best from the combination of tools and targets. For larger systems, the details get less important (though not irrelevant - for example, you would want to know how well the target supports floating point before using floats and doubles). And for really "big" systems (such as a PC), just code in Python and forget the low-level details. > Besides, cpu architecture is interesting. Well, to some anyway... > Absolutely.
From: David Brown on 28 Sep 2009 16:09
ChrisQ wrote: > David Brown wrote: > >> >> Personally, I think the general idea of "all global data is evil" is >> silly, especially for embedded development. But if you've got a >> programming method that helps you write better code, then that's far >> more important than what other people think! > > > Having had to wade through impenetrable code too many times in the past, > where it's hard to tell what's poking what and when, I try not to > inflict the same on others. One of the ways to do this is to encapsulate > functionality, keep data local as possible and communicate through well > defined inband interfaces. The typical embedded design can be split into > subsystems - for example, uarts / comms, timers, ports etc. There's no > reason why the internal data relating to a subsystem should be public, > even though it may need to be visible internally. Avoiding this makes > for a more reliable system design, it's easier to make changes, add > modules and to keep track of the big picture. Of course, none of this is > new, but it does seem to work... > I agree 100% about encapsulation (at least, I agree about it as an ideal - sometimes you have to compromise in practice). What I take issue with is when people get obsessive about globals and think that it is somehow better to have functions called "SetUartTimeout" and "GetUartTimeout", doing nothing but accessing a static variable, instead of just using a globally visible variable "uartTimeout". The global must be part of the well-defined interface, not a backdoor into the module's interior, but there is absolutely no reason to pretend that having the global variable is somehow "riskier" or "unclear", or harder to use or change. |