Embedded programmers? (Atmel) [nerd topic]

[j]

Just wondering if we have any programmers who are familiar with embedded programming. I have been working on a project that requires some [I think] pretty simple programming for Atmel AT 8-bit chips involving MIDI and USB and I could use some help if anyone is experienced with this stuff. I would really like to avoid learning C or assembly for the chip if at all possible as I already spent the last two days soldering.

Anyone? Reply or PM.

 

[bbaquiran]

Originally Posted by j

Just wondering if we have any programmers who are familiar with embedded programming. I have been working on a project that requires some [I think] pretty simple programming for Atmel AT 8-bit chips involving MIDI and USB and I could use some help if anyone is experienced with this stuff. I would really like to avoid learning C or assembly for the chip if at all possible as I already spent the last two days soldering.

Anyone? Reply or PM.

Well I wrote a bootstrapping code in x86 assembly for a couple of set-top boxes (think WebTV), when the web was young. That was pre-USB though.

What are you trying to accomplish?

 

[unpainted huffheinz]

Looks like Atmel has a good set of tools for the AVRs now:

http://www.atmel.com/dyn/products/to...?family_id=607

Learning a bit of C is not that difficult, especially if you know Java or a scripting lang (Python, Perl, RUby, etc), and you are pretty limited in what you can do with an AVR. C is a good skill to have particularly the memory management concepts. Programming directly in asm will result in smaller and potentially faster code if you need that, but you should not need that.

I used to use some Atmel devices over a decade ago. A coworker actually wrote a C compiler for them though. The number of opcodes is pretty small as I recall, but I forgot nearly everything in order to shove as much Altivec asm in my head as possible. Now I just write fragment shaders for GPUs which is really easy.

 

[totally epic]

I took an embedded systems course in grad school. It was fun.

 

[A Y]

Sorry to say this, but you really need to use C or assembly on an 8-bit micro. There's really no other way to get decent performance out of them. Sometimes even C is pushing it.

--Andre

 

[j]

Originally Posted by Andre Yew

Sorry to say this, but you really need to use C or assembly on an 8-bit micro. There's really no other way to get decent performance out of them. Sometimes even C is pushing it.

--Andre
I know, I just don't want to learn it myself. My application should be quite simple for someone who's familiar with the stuff - I may just post a paid request on the AVR freaks site. BTW, the Atmel chips are really quite powerful now especially considering the price. The one I'm planning to use has USB 2.0 on board with bootstrapper etc. and 16MIPS (IIRC) for like $4. Just having the USB sorted from the start will save tons of programming expense.

 

[tiecollector]

Originally Posted by Andre Yew

Sorry to say this, but you really need to use C or assembly on an 8-bit micro. There's really no other way to get decent performance out of them. Sometimes even C is pushing it.

--Andre

Really? I thought the days of beating out the compiler were over.

 

[furien]

Heh its not that hard I learnt it in 40 min. Well I cant program eloquently but I can get the job done. For one of the mechanical eng units we have they gave us an AT Mega 8 AVR ,a bred board and some wires and told us to figure it out. Its not that hard here is a crash course in microelectronics
(http://www.mech.uwa.edu.au/NWS/How_t...crash_course/). And here is a link to using C http://www.mech.uwa.edu.au/NWS/How_t...se/c_language/

now if only our robot would drive straight/ control systems would work.
Mech engineers> elec eng

 

[A Y]

Originally Posted by tiecollector

Really? I thought the days of beating out the compiler were over.

I was thinking more about the overhead of the C runtime: all the stuff you need to support the various language features, like the stack and heap primarily. If you just want to write tight code, C is absolutely fine with a decent compiler for most people if your CPU architecture isn't too weird (ie. it can be represented easily with the standard C data types).

--Andre

 

[GQgeek]

andrew is definitely the king nerd on this forum. I learned C when I was 16 but i never did anything useful with it. I made some 3d objects bounce around a screen and that was it. I also looked at the quake source, but I quickly lost my motivation when I got in to MMORPGs.

It's really amazing how much easier the modern high-level languages have made it to get things done.

 

[A Y]

Originally Posted by GQgeek

andrew is definitely the king nerd on this forum.

Dude, the correct term is "alpha nerd", and I'm sure there are nerdier people here than me.

--Andre

 

[tiecollector]

Originally Posted by Andre Yew

I was thinking more about the overhead of the C runtime: all the stuff you need to support the various language features, like the stack and heap primarily. If you just want to write tight code, C is absolutely fine with a decent compiler for most people if your CPU architecture isn't too weird (ie. it can be represented easily with the standard C data types). --Andre
I just assumed gcc would have an embedded optimization setting, especially with all this embedded Linux stuff going on. I would have thought with the C compiler that comes with the chip, that they would have already taken into account the overhead. In any case, the embedded chips are so fast now that I don't think it is that much of an issue. I have an embedded chip in my closet right now that runs Java code!

 

[lakewolf]

I did plenty of embedded programming in assembler and many cross-assemblers back then when only real men dared to enter the computer geekdom.

Now a days I am working as project manager of systems that involve embedded programming using ARM processors.

The full developments is done on C and the low level drivers still in assembler.

But there are some very good simulators so you can develop your code in Visual Studio 2005, debug it on the simulator and then finally do cross-compilation to the target platform.

But you'll need to get or develop the virtual hardware modules.

Today it is possible to use .NET programming in C# to do embedded development on platforms like cell phones and pocket pcs but the performance is poor in my experience.

 

[unpainted huffheinz]

For embedded processors the reason to use asm over C is code size and/or some sort of restriction like register count. The compiler can only do so much and in many cases the fallbacks when it exceeds the register count or other limitation can be disastrous. Also, cranking up the optimization flags will produce suboptimal code almost as often as good particularly with hotrod compilers like ICC or XLC. The former has a long track record of just giving flat out wrong output. Everyone who relies on performance of a particular chip knows how to check the asm.

J, if you really need an AVR to work at least know how to debug the thing in some way or be prepared to shell out some bucks to someone who can. The more you can do yourself the quicker the development time.

 

[A Y]

Originally Posted by tiecollector

I just assumed gcc would have an embedded optimization setting, especially with all this embedded Linux stuff going on. I would have thought with the C compiler that comes with the chip, that they would have already taken into account the overhead.

If by "taken into account", you mean "assume I have enough memory", then yes, I suppose that's right.

It's easy to blow your stack with C, especially if you're coming from an applications programming background. gcc or really any other compiler doesn't really watch any of that stuff for you --- it relies on you to have the board setup and startup code correct. It depends on you not doing stuff like declaring a gigantic array as a local variable, or using malloc() indiscriminately. C will hand you enough rope to hang yourself 10 different ways, and that's before we get to the bullets for your feet!

There are smart ways to program in C, too. If you know how a particular compiler works, you can write C code that will persuade the compiler to generate optimal code. Of course, that doesn't tend to be portable or sometimes even readable --- think of Duff's Device as an early example.

Also if you can run embedded Linux on your target, you have plenty of memory and CPU to burn already. I was thinking about J's 8-bit system which doesn't tend to have much of either.

In any case, the embedded chips are so fast now that I don't think it is that much of an issue. I have an embedded chip in my closet right now that runs Java code!

For the most part, that's usually true especially for 32-bit embedded CPUs, but it depends on the application. I know some people who use assembly on their 32-bit CPUs because the chip can barely accomplish what they need it to do, while others use things like Java and embedded Linux, and their system runs along fine because it doesn't have any speed-critical functions. Others have speed bottlenecks in areas that aren't affected by the speed of the code running on the CPU --- I/O latency for example --- and those problems require a different solution.

--Andre