Learning embedded systems

Often those 20 lines of assembly either makes the other 16000 lines work correctly or not. i.g. if the startup code is not correct, then one can either not even reach main, or one can have very strange and difficult bugs to debug. On a normal OS, those issues are sorted out. On many embedded systems, that is the most difficult part to sort out. Unless one has got fairly expensive equipment, the startup portion has to be debugged blind.

Regards Anton Erasmus

I expected the disagreement, Dan. No problem.

I'll just say that packing 16k lines of C++ into a project, with only 20 lines of assembly, this means to me that you are probably programming on a relatively general purpose computing platform and perhaps even with some unstated library or operating system support that you forgot to mention, as well.

I tend to define embedded programming as a matter of degree that an environment is UNLIKE a general purpose computing platform. The more it is different from this type of programming, the more "embedded" it is. This is, in fact, why embedded programmers require other skills. It is this requirement for special skills, in fact, that helps to define embedded programming for me.

Those special skills may include: * analog and digital design skills * schematic reading skills * hardware tools familiarity (o'scope, signal gen., etc.) * understanding locating linker semantics * being familiar with assembly on a variety of CPUs * soldering skills * mechanical/construction skills * familiarity with common hardware functions (like USARTs, timers, etc.) * willingness to learn things *before* they are needed...

These are the kinds of things that separate embedded from general purpose and gives different meaning to the terms. Highly embedded is at one end of the spectrum, general purpose computing at the other end.

Jon

I should have added the point that the very fact that there IS any assembly at all in Dan's project points up the need to be familiar with assembly. If you need it, you need it. And chances are, what you need cannot be fabricated well if you are a neophyte in assembly. They will be *choice* assembly lines, formed well only through a thorough and burnished knowledge from good experience.

Jon

Probably the biggest benefit to learning assemler is that it forces you to gain an understanding of how a microprocessor works. C/C++ allows you to code away without any real knowledge of the architecture, register sets, addressing modes, interrupt structure etc. Once a person has learned a micro inside and out by developing a significant amount of code in assembly or machine language, learning a new device is just a matter of perusing the databook. The core knowledge is pretty much transferrable from one chip to the next.

Bob

You dont have to develop a lot of code. I started by writing compilers, and this works as well. Only did two significant projects in assembler in my life.

My favorite was 22kB of assembler code (libraries not included) developed in less than 24 working hours... That is almost 1 kB of tested assembly code per hour...

One project I did which never would have worked in C was a multitasking program running on a 2-3 MIPS machine doing 250,000 task switches per second... Hairy, but got the job done...

Was thinking along the line: What happens if I jump to the status register... When an input port change, this is reflected in the status register so you could conceivable set the flags to "jump to self" if the bit is clear, and jump elsewhere when the bit changes. Almost worked...

Not possible in C

Rob,

How about a free online tutorial for Pic chips. It should get you started in asm.

HTH

Mike.

Speaking of Hitachi, the Lego Mindstorms might be a possibility for learning embedded systems. It uses the Hitachi H8/300. The disadvantages are that the ROM documentation is lacking, but there are lots of web sites out there that could help. There's no debugger interface either. There are definately better systems to learn on. However, it's relatively inexpensive and can be a lot of fun.

Even Linux uses assembler. And even the C++ has some inline assembler as well. It depends upon where the focus is. The boot up code almost always has some sort of assembler in it, as well as core OS routines. Pre-canned operating systems take away much of the need for assembler though.

Even if one doesn't have to write assembler well, one should definately know how to read it! Also it's very useful to be able to understand the assembly output from the compiler, to know where it does a good job and where it is inefficient, and how things are layed out on the stack.

If I were looking at job candidates, I would feel much more confident that candidates that knew assembler had a better feel for low level machine concepts than candidates that only knew C. It isn't a matter of whether they'd actually have to _use_ assembler or not, but if they know that the board is not just a black box to put applications on top of.

Ie, a C-only programmer is more likely to think that "count++" is an atomic operation than a C programmer who's had exposure to assembler.

Even if it is a 20 lines versus 16,000 lines issue, those 16,000 lines probably weren't written by someone with C-only experience.

I had a feeling I might cause a bit of controversy with my original statement. :-) Thanks for you thoughts.

I'm using a 16 bit processor with a bit of memory and some serial ports and i/o pins. If that's not embedded I don't know what is. The only os type support that I have, queues and timers and such, is what I've written myself. The compiler has some standard C library routines, all the more reason to use C.

I agree with you here, these are all useful skills. But knowledge of assembly would be at the bottom of my list. I'll pick up an oscilloscope lead 100 times before I'll look at the assembly output of the compiler.

Even 8 bit processors and little PICs have C compilers. People keep telling me how you need assembly to optimise for either speed or size, but I've never found a need for it. Maybe that was the case 20 years ago when memory size and processor speed and was more of an issue.

It's much more difficult to write structured code in assembly language. It takes way longer to write and it's harder to debug. It's also a lot harder for someone else to come in afterwards and look at the code. I can't imagine anyone writing anything in assembly unless they absolutely had to, and I can't see very many places where there's really a need.

Dan

You are in the wrong market. You need to go to india if you really want to be in this market. Good luck!

YOU HAVE "an embedded application on a Hitachi processor with close to 16,000 lines of C++ code"

Try a few 1000 on a PIC, or 8051 (low end 8 bits) you can not use C++ You can avoid asm but why? It can simplify the project. And if you have no Idea how the C will compile to asm your Interrupts can be too long and you will not know why. Look at the PSoC. The code the IDE gives you must be in asm. How many bits is your Hitachi CPU.

Embedded can mean 1K of asm in a 8 bit CPU or 100meg app running on embedded XP, or even bigger.

No problem, as I said.

Sounds embedded.

That's not what I brought up, though.

I've written, many times here in this group in the past, specific and useful semantics that simply are not available via a C or C++ compiler. Look it up via google. That you are NOT aware of them makes my point clearly.

Which, true or otherwise, doesn't bear at all on why I said what I said.

Sometimes. But that statement is most certainly true if you refuse to become competent at it. When you aren't skilled at it, it's a given that you'd be right.

... and if you are hiring, it may be easier to find programmers who are familiar with C. I won't argue.

My point is that good familiarity with assembly, whether or not it is required for a specific project I have in mind, is valuable in my mind. Having more thinking tools, not less, is better.

I'd suggest to you that you think about the fact you don't even recognize some of the unique values concerned. I fully understand your points about C/C++ and I agree with the value of using such languages in embedded work. Yet you do NOT understand my points. Perhaps this is because of your lack, not mine. Just a thought for you to ponder.

Jon

This is a bit dangerous example, since if the programmer is first exposed to a processor with atomic memory location increments, this assumption may be permanent, unless he/she studies to code for any future processor as thoroughly as the first processor :-)

Paul

If you search around for RCX Forth you probably will find a nicer environment for the little Lego block. I think it may give you some debug capability (although I haven't tried it myself). Best to read the comp.lang.forth newsgroup archive on Google first as there have been a few threads on that topic.

I just finished a project (MSP430) that's about 98 % C and 2 % assembly, but I think that an understanding of assembly is essential. I may code the application in C, but I think in assembly.

-Hershel Roberson

Not if you know how to code.

Yes and No.

Not if you write structured code and comment it properly

Yes. That's it exactly.

Bob

Dan wrote in news: snipped-for-privacy@4ax.com:

I have, specifically, using the Keil C51 for an 8051. I found that I could significantly improve the size and speed by tweaking the C code based on looking at the assembly output. Memory size and processor speed is still a very significant issue in many applications.

If you are well versed in the particular assembly language, and your predecessors documented it reasonably well, then it is not at all difficult to debug, or come along afterwards and modify the code. I speak from many years of experience at working on poorly, and incorrectly documented assembly language code as well as well documented assembly language code.