
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
"Alan Balmer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Wed, 19 Nov 2003 09:02:30 +0100, "David Brown" > <[EMAIL PROTECTED]> wrote: > > > > >"Alan Balmer" <[EMAIL PROTECTED]> wrote in message > >news:[EMAIL PROTECTED] > >> On 18 Nov 2003 06:46:31 -0800, [EMAIL PROTECTED] (Ken Asbury) > >> wrote: > >> > >> >> You'll find a lot of people here who disagree with you. > >> > > >> >Yes, he will, but I'd bet that all of those are already > >> >highly proficient in C or masochists, not that those are > >> >mutually exclusive conditions. > >> I'd take that bet. The experts in comp.lang.c almost unanimously > >> recommend the book to newbies, and the newbies praise it as well. > >> > > > >We are not in comp.lang.c, but comp.arch.embedded. > > First, I'll need a list of the masochists in the group, so as to > eliminate them ;-) Anyway, I should have realized that Chris was > setting me up - obviously those who recommend K&R2 *are* highly > proficient in C, because they learned it from K&R2. > I must confess to having read only the original K&R, and not the new one. I would probably have posted differently had I known of the differences earlier. > > I'm sure the experts > >over there know all about learning and working with C as it was originally > >intended and mostly used - i.e., on computers. They (for the most part) get > >to work with 32-bit systems, solid, standards-conforming compilers, good > >debuggers, logging files, printf, malloc, and all the rest of it. In > >comp.arch.embedded, the emphasis is somewhat different, and the requirements > >are somewhat different. I know there is a fair amount of overlap in the > >groups, but the O/P posted here, so we answer here with embedded experiance > >rather than general C experiance. > > > Ain't that much different. It's clearly possible to write good code > for embedded systems, and a large portion of that code can be > standards-conforming. > There's a lot in common between "big" computer programming and embedded programming, and there are a lot of general good software development techniques and practices that apply to both of them. And most embedded code will be pretty much standards-conforming since most "bare metal" hardware access will be abstracted to some extent. But there are differences in the way you have to think about programming for small systems. There's another thread in this group regarding the use of (1UL << i) within a loop (where i could be 0..31) on an 8-bit AVR micro (actually its a subthread of "Imagecraft ICCAVR & ANSI Standards compliance"). On a PC (or a PPC, or an ARM, or any other 32-bit cpu with a barrel-shifter), such an expression would be fine, and if its use makes the code clearer then it should be used. On an AVR, it is extremly inefficient - you are talking about something like 250 clocks for the shift when i is 31, and therefore around 2000 clocks in total. A little thought in the algorithm, keeping a 32-bit mask register and shifting it once per loop would use 4 clocks per loop. That is a *very* big difference, and it comes from thinking small, knowing the processor, and thinking about what the cpu has to do, rather than thinking PC-programming style. > What C tutorial would you recommend for a beginner destined to work in > embedded systems? > Unfortunately, I have no idea. I mostly make things up as I go along. I'd recommend learning assembly as a kid with ZX Spectrums and BBC Micros - it worked for me. > -- > Al Balmer > Balmer Consulting > [EMAIL PROTECTED]
| <-- __Chronological__ --> | <-- __Thread__ --> |