C / C++ skills

I guess you don't know assembly very well then. Anything you can do in C/C++ you can do in assembly. However, you will be much more productive using C/C++ so I'd recommend you learn C.

On 11 Aug 2006 17:41:30 -0700, " snipped-for-privacy@gmail.com" wrote in comp.arch.embedded:

I never heard of "assembly". Did you mean for one particular processor? Did you think there was only one? There are literally thousands.

Almost certainly, the one assembly language that you do know will not work on any microcontroller, so at the very least you will need one new assembly language if you don't want to program in C.

Get a book called "C++ from the ground up". I found it very good, starting from zero.

C++? Bah humbug. C is fine. Assuming a decent s/w architecture, of course. (Which statement includes all the good bits of OO, stripped of the hype...)

K&R 2nd edition. Period. (And develop an interest in e.g. Dijkstra, Wirth etc...)

Steve

The thing is it seems most companies with job positions are requiring a high level of C or C++ for firmware developement.

schreef in bericht news: snipped-for-privacy@75g2000cwc.googlegroups.com...

Sure, assembly is as dead as can be. If you are an excellent assembly programmer, you will also do very well in C. Learning C is not that difficult. C++ is a lot more complicated.

For personal projects you can use assembly if you want. If you're looking for employment in the sector then C is a must and C++ is definitely a plus.

Besides, C is pretty easy to learn (but hard to master) and much more readable than assembler.

hype...)

I agree, C is fine for most firmware projects. But these days embedded systems are turning into small PC's with GUI's and GUI's are ussually programmed in C++.

Both. "Embedded systems" covers a huge range of applications. Some use the full range of C++ features, while others just use C++ as a "better C". I tend to the latter, since I like namespace, encapsulation of data and functions into a class, clearing variables before their first use, etc. But others have to do more rapid prototyping to keep up with changing sets of ill defined requirements on a tight deadline, so all available tools get used.

Surely you just mean "Java" (which was well designed and then hijacked for a different purpose than its designers intended).

C# was designed solely because Microsoft needed a new way to entrap programmers since they weren't allowed to make incompatible versions of Java.

Java runs on mobile phones, which definately counts as an embedded system.

-- Darin Johnson

So the doctrine here is that Delphi is great and C# is awful, even though they are the work of the same designer and are semantically very similar?

BTW, in response to another message, C# is not interpreted. It is compiled; usually JIT-compiled while loading and running, but it can be precompiled.

Thanks guys, ive never used a forum before and got such an informative response. I guess i better go to all my c++ lectures then ;) I actually have to write a driver and/or application to talk to a driver to recieve data over USB from a PIC 18F4550 (Thesis). I do however have favours owing fom a c++ expert...

In article , mc writes

I think the implication is that c# was designed to meet a political need. The wanted to mould Java in the same way they are moulding C++ (C++/CLI) However as JAVA was more rigidly controlled they could not so developed a "new" language.

If you can write in assembly you'll do fine with C.

A lot of "embedded" developers start writing code for large systems (PCs) using C++, java etc, then start writing embedded code and its usually a BLOATED mess. They don't know how to write efficient code that fully utilizes the processor and end up using a processor many times the size thats needed.

A good grounding in assembler should be a must for any embedded developer (it still has its uses) but C can give you more readable portable code thats almost as efficient.

Learn C, but don't forget how to read in hex...

Allan

You need C in today's world. I learned C a number of years ago by studying the Small C compiler. At first I compiled the demo programs and compared the output ASM code with the input C code to see what it was doing. Then I started analyzing the copiler itself, because it was written in Small C and I could see what Asm was being generated for the compiler.

Later I compiled it with a Borland C compiler and started experimenting with the more advanced feature Small C didn't have.

Now there are various versions of Small C that target many embedded processors.

Eric

This is funny! C# is an open standard that anyone is allowed to support without the fear of being sued. Java is a proprietary language controlled by Sun. Just try selling your own homegrown Java compiler in the marketplace without paying royalties to Sun and see how far you get!

Microsoft themselves not only give away their compiler and tools for free, they also provide the source code to at least 3 different C# compilers, one of which is completely public domain.

And the Mono effort on linux is completely independent of Microsoft.

Eric

I agree with this statement - this is no secret. However, regardless of "why" they did it originally, you need to look at what they ended up with. Their final result fixes the #1 problem with Java (a lot of competing small frameworks, each of which isn't big enough to meet most needs), and a lot of smaller problems in Java (like the lack of OOP Properties).

Despite my love for C# in today's Windows and Web applications (I'm an MCSD and I use it every day), I have to say that it's not ready for small embedded applications. It doesn't have a good equivalent for Sun's J2ME yet, and Microsoft hasn't really been interested in targetting these small devices. Microsoft thinks of embedded Windows when they talk about "embedded" in general, and the devices I work with on the embedded side don't have enough memory to run any flavor of embedded Windows. I typically use ARM7TDMI and MSP430.

If you target a device that can run linux (meaning your targets are beefier than mine, maybe Arm9's or x86), you can possibly run embedded Windows, also. But I wouldn't go there myself. Linux offers a lot more to an embedded programmers, not the least of which is total access to the OS source code. People who write code to control devices absolutely require the ability to know what each bit is doing. You normally don't have to get into the OS code, but it's nice to know that you can if you need to.

The bottom line: C# isn't suitable for embedded development in today's world. But it's among the best options for PC's.

Eric

Eric

Well said! C has a lot of behaviors that people take for granted until it bites them. You need to spend a lot of time testing your apps when you are first learning C. And even later after you've used it a lot. it's still a wise choice to test early and test often.

A good lint program can also help avoid some of the gotchas. A lot of people swear at their lint programs, but in the end it can save their job so they keep using it :-)

This is a good company that makes lint programs:

Maybe someone can post links to free lint programs. I generally use Gimpel and I don't know what free options are out there.

Some people also use MISRA checking in their C compilers, but I tend to dislike it myself.

Eric

Which group is the best for asking questions with regards to Lint? I have the Gimpel flavour and it works great after I've just installed it but once I've restarted the PC it packs in. I'm sure it is to do with the std file not being in the system path but I can't crack how to get it to take it.

There is Gimpels support forum but I've never got an answer there in a reasonable amount of time. I post a question check for a few days and then forget about it. If I go back and check some time later there is sometimes an answer but by then I've usually lost the context. On the other hand the product itself is solid enough this doesn't usually matter and they do produce maintenace versions regularly.

I use PC-Lint heavily but I've never used a std.lnt file (I assume that's what you are referring to). I always reference the processor/compiler definitions explicitly, my makefile sets up the appropriate command line parameters based on the processor I specify.

Robert