avr: asm vs. c

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hey there

Im all new to avr programming and i just want to hear som opinions on
what people perfer: asm or c?
Thanks :)

Toke Jansen


Re: 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 www.avrfreaks.net for informations on dev-tools, appnotes and
.....

- stef

Quoted text here. Click to load it



Re: avr: asm vs. c
Quoted text here. Click to load it


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


Re: asm vs. c

Quoted text here. Click to load it

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.



Re: avr: asm vs. c
Quoted text here. Click to load it

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


Re: avr: asm vs. c
Quoted text here. Click to load it
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



Re: avr: asm vs. c
:> 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.

<chuckle> 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         snipped-for-privacy@frii.com                www.techtoystoday.com   *
We've slightly trimmed the long signature. Click to see the full one.
Re: avr: asm vs. c

Quoted text here. Click to load it
familiar
microcontroller -
Quoted text here. Click to load it
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.



Re: avr: asm vs. c
On Wed, 24 Sep 2003 22:27:57 GMT, "Richard Haendel"

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: avr: asm vs. c

Quoted text here. Click to load it
familiar
microcontroller -
Quoted text here. Click to load it

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.







Re: avr: asm vs. c

Quoted text here. Click to load it
[...]
Quoted text here. Click to load it
[...]
Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

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.

Re: avr: asm vs. c
Quoted text here. Click to load it

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.


Re: avr: asm vs. c

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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



Re: avr: asm vs. c


Quoted text here. Click to load it

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.



Re: avr: asm vs. c

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



Re: avr: asm vs. c


Quoted text here. Click to load it
[...]
Quoted text here. Click to load it
[...]

It's not my field, but as I understand it, critical systems benefit much more
from redundancy than from perfection.



Re: avr: asm vs. c
Quoted text here. Click to load it

Modern compilers are very reliable, that's true.  However, there's
another thing to take into account (especially on small micros
with limited resources):  If you don't have the slightest idea of
how high-level language constructs map to the target hardware, you
won't write efficient code.  That might not be a problem when you
over-spec the hardware by a magnitude, giving you (or: the tools)
plenty of headroom in processing power and memory footprint.  It
IS a problem though, if you compete with those who did their
homework.

Marc

Re: avr: asm vs. c


Quoted text here. Click to load it

Recent I've worked on 80C51 and 80C167 without resorting to learning
the processor instructions. The processors fit the application, but I
find their instructions to be butt-ugly. I just don't want to learn
them, and the C written code works just fine. Of course I know about
native types and such. I'm not going to use longs everywhere.

An engineering professor once said it's about _money_. In my case,
development speed is important, and I have many other things to do
besides program these bit-twiddlers.


Re: avr: asm vs. c

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: avr: asm vs. c
Quoted text here. Click to load it

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


Site Timeline