avr: asm vs. c

An ASM programming tool is for free from Atmel. Codevision C Compiler is free if your code is less than 2 kb or something. Check out

for informations on dev-tools, appnotes and .....

- stef

"tjh" schrieb im Newsbeitrag news:3f718564$0$54787$ snipped-for-privacy@dread11.news.tele.dk...

I doubt if any of us has a particular preference. They both have their uses. Whether to use one, the other or both is very project specific.

Ian

Since the instruction set in AVR was developed with C in mind, I vote C as it's a high-level language which is easier to modify and maintain. Go for C.

ASM is very compact and simply required to understand the architecture. Have a look at it first, then have a look at C when you're familiar with the ASM.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

with

I disagree. Use C first. After you become comfortable the microcontroller - or you need more speed and/or smaller code - then learn assembler.

Richard

Richard Haendel wrote: :> Have a look at it [ASM] first, then have a look at C when you're familiar : with :> the ASM.

: I disagree. Use C first. After you become comfortable the microcontroller - : or you need more speed and/or smaller code - then learn assembler.

I'd disagree with you here. You need to know the asm so that you can understand the hardware and know what your tradeoffs are when you are using C. You don't have to be good at it, or love it, but you really should be able to read it and understand it.

IMO, DLC

--
============================================================================
* Dennis Clark         dlc@frii.com                www.techtoystoday.com   * 
* "Programming and Customizing the OOPic Microcontroller" Mcgraw-Hill 2003 *    
============================================================================

I disagree. I saw many programmers going this way and they struggled heavily when it came to low-level debugging. They simply could not even check the produced code to find bugs. Note: Often a "correct" C program shows its bugs when you look at the assembly output. (Well lint would help here as well :-)

It is the same in school, first learn to calculate using brain and fingers, then use a electronic/mechanic calculator.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !

As for me writing RTOS kernels, I'd say : asm.

But my other half, writing device drivers says: C.

My hint: Read the assembly manual carefully, try to understand each instruction and then single-step on assembly level through some C code to get a feeling for the CPU.

The write your code in C/C++ unless you really need assembly.

But check you algorithms first.

And: You'll have to be a real real good assembly programmer to be better than most C compilers.

Amen.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !

familiar

microcontroller -

I disagree. Although I know AVR assembler, I rarely look at the assembly output as the compiler always seem to work correctly. If there's a problem, then it's ussually a coding or configuration error.

familiar

microcontroller -

you

should

I disagree.

You certainly need to have the datasheet or user manual for the AVR by your side to know how the internal hardware functions, but assembly isn't an issue. And speed is rarely an issue, I'd rather opt for a faster part or crystal frequency than coding part in assembly.

When integer is not sufficient, some other datatype is required. There are indeed prominent compilers that offer float at a price of

8k to be linked in. Even when you only need some scaling, no division. IMO, not useable, sorry.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

[...] [...] [...]

I disagree. (I had to say it ;-)

Ten or more years ago, if a program didn't work, it was my fault. The tools (nearly) flawlessy did exactly what I told them to do, even if it wasn't exactly what I wanted them to do.

Over the past decade or so, bugs in development tools seem much more common. The ratio of my bugs to tool bugs went from something like

5000:1 to 10:1. I'd like to think it was because I'm making so many fewer errors, but I doubt it. And it's not just AVR tools.

That said, I think the answer to the OPs question is "mu." He is making incorrect assumptions that make it impossible to answer the question.

There's no reason to learn C OR assembly. Learn both. Concurrently. Each will teach you much about the other and the target platform as well. And you *will* need both if you ever plan to do serious work.

Regards,

-=Dave

--
Change is inevitable, progress is not.

[...]

Kind of hard to argue. Not very profound...

Non sequitur? There are indeed prominent compilers that offer float at a much lower price (at least in terms of code space). But float is very often the wrong solution. Especially if you're talking about "scaling."

Regards,

-=Dave

--
Change is inevitable, progress is not.

There is nothing else supported in C. There is such a strong tendency to stick to the standard that nothing else is thinkable. I tend to use my own implementation of fractional, in ASM of course. Another datatype I miss in C is 'non-wrapping integer'. Easily doable in ASM, but unthinkable in C.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

"tjh" skrev i meddelandet news:3f718564$0$54787$ snipped-for-privacy@dread11.news.tele.dk...

You want C for sure. There is a free C compiler on

You will also need the AVR Studio.

There will be AVR Seminars in Denmark early November, if you are interested.

Attend the seminar, and get a development board.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

Ouch. Using any tool without being able to check the validity of what it does is seriously non-professional.

I'm sorry, but I personally wouldn't hire anyone who would use the words "always seem to work correctly" while describing their work.

No, I'm perfectly capable of checking the validity. I just rarely need to.

Why would I need to check the generated code if it works as expected?

I understand that. It's the previous statement that's a problem.

What do you mean by checking the validity of a tool? Do you inspect the bitstream output of your HDL compiler?

When you are using an automaton such as a C compiler, how many C to ASM statements do you inspect before you trust the compiler? Do you verify that the ASM produces the right opcodes?

"Provable correctness" is a mathmatical concept. Proving correctness from the HLL level to the ASM level to the opcode level to the gate level is quite outside the bounds of human capacity for anyone that wants to write more than one or two HLL lines per week.

That's where testing comes in. And "always seem to work correctly", while a naive sounding statement, is what comes out of testing. "Fix it until it works correctly" sounds more realistic.

When I was doing a fair amount of VHDL / Verilog coding I did two sanity checks on any synthesis: a) I checked the number of flops and logic generated to make sure the number was close to what I was expecting and b) I often imported my synthesized netlist into a schematic program to make sure the resulting circuit looked believable. But heck, I starting playing with VHDL synthesis tools in '94 and they weren't all that trustworthy back then.

It's certainly doable, it just costs money and time. In terms of where the bugs come from, though, "bad tools" account for a lot fewer bugs industry-wide than "dumb/careless programmers". If I was doing an ASIC with a lot of exposure (maybe human lives or huge dollars at risk) I'd definitely use model checkers and theorem provers where appropriate in the design process.

A common optimization of the FM process is only to formally prove those correctness properties that you care about early in the game: deadlock conditions, race conditions, sequencing, etc. Proving an 80x80 multiplier correct is likely going to take a huge amount of effort, and since multipliers are usually easy to test it might make more sense to prove something else (like the OpCode generator) and rely on testing for the boring, easy stuff.

Nothing wrong with fixing it until it works correctly. The goal of the formal methods tools is exactly that. A difference between FM and traditional testing is that you can find bugs earlier in the process, and that means cheaper development. A second difference is that one proof might take a lot less time than a suite of regression checks - that means faster testing. I can't tell you how many FM proofs I've done have failed because the problem was I didn't know exatly what 'correct' meant. Or, as a much wiser man said, "The virtue of mechanical proof is not that it compels belief, but that it suggests doubt."

Formal methods isn't just a research game any more - it's out in the world and working for a living. It's just that it costs a lot and requires well-trained practitioners. Maybe the tools will get cheap enough over time that small shops will start to use them.

Kelly