Assembler vs C

Go To Last Post
35 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is probably an old question but just for fun to see how people are programming their AVR. I searched the forum to see if this question was asked lately but I couldn't find anything.

hachey
... to boldly go where no AVR has gone before...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the ImageCraft ICCAVR C compiler.

But you probably succeeded in starting another C/Assembler war...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Really it boils down to the task at hand and the space you have to work with. I like the Bascom compiler for mega48's and program design as you can use both where needed. I use assembler in the tinys

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use assembler and AVRStudio for parts ranging from ATTINY13 to ATMEGA32. I have also prototyped a 4-phase power supply with load sharing using an AT90PWM3 in assembler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OMG not this hoary old chestnut yet again!

These kind of polls never seem to take account of the fact that some people use more than one language. I voted C because that's the one I use the most (GCC) but I do use ASM a bit too.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I voted C because that's the one I use the most
> (GCC) but I do use ASM a bit too.

Meetoo.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I couldn't resist to answer this poll any longer.

I go for "OTHER" which is a very good compiler. :D
So easy to use & no typing & no reading involve at all. :)
Best of all I don't get any error when compiling. :P
Completely foolproof. :wink:
URL site is unknown. :?

So, the Holy Grail still continue. :idea: :shock:

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hooboy - i'm staying out of it this time.

After all, we all know that C is the ONLY true embedded language!

- Dean :twisted:

[Above is a joke, PLEASE not another war about this!]

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh no, FORTH is.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was using ASM, but switched over to C and I find this much better and easier to use.

Alex

Cheers,

Alex van der Lans

You can find me @ skype as: alex1678

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I voted for C because
I use the ImageCraft ICCAVR
:D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kumquats!

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I voted for assembly, since its smaller and faster. Plus, I can calculate how many clocks each subroutine will use, so I know how long every thing takes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cjwillms wrote:
I voted for assembly, since its smaller and faster. Plus, I can calculate how many clocks each subroutine will use, so I know how long every thing takes.

I'm trying to remain silent but...

I can do that for C - I just look at the intermediate assembly generated by the C compiler or, better yet, load it into the AVR simulator - cycle calculation/stopwatch is one of the things the simulator generally seems to always get right.

I'm not entirely sure I agree with the "smaller/faster" thing either and if some part of the generated C code isn't as small/fast as I'd like there's always the possibility of coding some of it in separate .S assembler files or just using C's inline asm() function.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know what you mean, but it's much harder to even every thing out in C, when you dealing with time critial things.

For example, I'm currently working on a multi servo controller program. In order for it to work correctly with my bot, I have to constantly send a signal to the servos, so they will stay in the position I want. To do this, I made a huge loop that constantly runs, and turn on/off the servo signal when requried, and then updates the dealy values. By knowing how long everthing takes, I made it so that the entire cycle always takes the same amout of time, no matter what I'm doing (turn signal off, turn signal off, recieve input, change servo position). With that, I was able to calculate the how many times I need to loop the routine, in order to get my desired time (1 ms - 2ms, in .1 ms increaments).

In C, I'd have to write everything, and then I have the problem with the delay() function (used in c, but not sure if it's used in the GCC). Usually, it's only set up for ms and not µs, so I wouldn't only be able to set ther servos angle to 0 degress, or 180 degress. Plus, the code to turn the signal on or off, whould make everything off by a bit, giving me inaccurate results.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cjwillms wrote:
For example, I'm currently working on a multi servo controller program. In order for it to work correctly with my bot, I have to constantly send a signal to the servos...

Ummm - isn't this why God invented hardware timers / interrupts ?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't really use hardware timers. The servos for my project will be at different angles, which means that the dealy for each will be different. As of right now, its set up to control 6 servos.

Say the first servo is set to 0 degrees, and the second to 180. For the first one, I have to delay for 1ms on the on position, and then 2ms for the off position. For the second one, I have to delay for 2ms for the on and off period. In other words, I would need need to have at least 6 built in timers for my project. Plus, every now and then, 2+ of the servos signals will need to change at the same time. This will, of course, mess up my timeing, a bit.

Interrups would really mess up my timeing. If a function was called by a interput, it would most likely delay the some of the timers, causeing the bot to twitch.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cjwillms wrote:
I know what you mean, but it's much harder to even every thing out in C, when you dealing with time critial things.

In C, I'd have to write everything, and then I have the problem with the delay() function (used in c, but not sure if it's used in the GCC). Usually, it's only set up for ms and not µs, so I wouldn't only be able to set ther servos angle to 0 degress, or 180 degress. Plus, the code to turn the signal on or off, whould make everything off by a bit, giving me inaccurate results.

It's only hard in C if you do it the hard way. 1 timer, 1 interrupt and aout 10 lines of code will get you signal that will drive a servo, add another 6 lines of code and you can drive another servo. You can run up to 10 servos this way. There was a recent thread on exactly this subject.

BTW, you are doing it the hard way in assembler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't seem to find the thread you’re talking about. The closest one I could find was labeled "motor control", but I only really found a link to another forum. From there, they only multi servo controller code I could find, was written in asm, and not c.

If possible, could you point me into the correct thread?

Other then that, I can control about 11 servos @ 4mhz or 24 servos @ 8mhz, from 0 degrees to 180 degrees in 22.5 degree increments (9 positions).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

9 positions is about 3 or 4 bits. My car steering wheel can go +-45 degrees in what step size? .1 degrees? Thats about 9 bits. If you are flying along at 600 miles an hour in an F16 and you want to start rolling at 5 degrees a sec, how many degrees do you think you need on the ailerons? .1? If the total throw is +-60 deg, that's 1200 positions.. more than 10 bits.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use C most often, and my files are all consisted of asm(" "); ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cjwillms wrote:
I can't really use hardware timers. The servos for my project will be at different angles, which means that the dealy for each will be different. As of right now, its set up to control 6 servos.

Say the first servo is set to 0 degrees, and the second to 180. For the first one, I have to delay for 1ms on the on position, and then 2ms for the off position. For the second one, I have to delay for 2ms for the on and off period. In other words, I would need need to have at least 6 built in timers for my project. Plus, every now and then, 2+ of the servos signals will need to change at the same time. This will, of course, mess up my timeing, a bit.

Interrups would really mess up my timeing. If a function was called by a interput, it would most likely delay the some of the timers, causeing the bot to twitch.


That's funny - I've written multiple interrupt driven servo controllers that work great. If you just put a little thought into it it is quite easy to achieve very precise servo control with an interrupt driven AVR program.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
9 positions is about 3 or 4 bits. My car steering wheel can go +-45 degrees in what step size? .1 degrees? Thats about 9 bits. If you are flying along at 600 miles an hour in an F16 and you want to start rolling at 5 degrees a sec, how many degrees do you think you need on the ailerons? .1? If the total throw is +-60 deg, that's 1200 positions.. more than 10 bits.

.1 degrees?

For that to work on just 1 standard servo, with the signal between 1 - 2ms, you would need at least a 8MHz clock. I'm rather curius as to what frequency your micrcontroller is running at, and what servo your useing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think C and assembly each have their pros and cons and the best language to use is the one that we are more comfortable with for whatever reason. It could well be forth, Basic or any other language that we like. The bottom line is to make our project and have fun. Right?

I use C and Assembly depending of the project.

hachey
... to boldly go where no AVR has gone before...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hachey wrote:

Quote:
I think C and assembly each have their pros and cons and the best language to use is the one that we are more comfortable with for whatever reason. It could well be forth, Basic or any other language that we like. The bottom line is to make our project and have fun. Right?

That's really great! You start a flame war and then come off as the righteous preacher.

cjwillms wrote:

Quote:
I'm rather curius as to what frequency your micrcontroller is running at, and what servo your useing.

I'd much perfer 16MHz plus in a Mega32 or Mega64. But I've got a Mega8 running at 8MHz capable of controlling 32 standard servos. You can have one too, from Lynxmotion. They also make available the code, as well. You should check them out and see how the pro's do it.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am currently working with a Mega32, and I do have the 16MHz option aviable, but I don't need anything over 4MHz right now. I can control up to 32 servos @ 8MHz, with my current code, but I only get 7 different positions (30 degree increments).

On a side note, I found Lynxmotion rather interesting, especially the bipeds. I just hate their name though. It just reminds me of the old handheld console...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cjwillms wrote:
I am currently working with a Mega32, and I do have the 16MHz option aviable, but I don't need anything over 4MHz right now. I can control up to 32 servos @ 8MHz, with my current code, but I only get 7 different positions (30 degree increments).

On a side note, I found Lynxmotion rather interesting, especially the bipeds. I just hate their name though. It just reminds me of the old handheld console...

I bought one of the Lynxmotion six DOF Pick & Place robots that uses one of the SSC-32 servo controllers. The SSC-32 seems to work quite well. The SSC-32 isn't too expensive and will save you a tremendous amount of design work.

The command structure for the SSC-32 is very wast to use. Although I have the software that controls the robot, I was making manual command entrys wiht HyperTerminal in about 3 minutes after I finished building the robot.

In fact, I liked the SSC-32 servo controller so well, I purcahsed a second SSC-32 controller to use for another project.

If it craps out, I have the source code, the object code and, Mega8 is dirt cheap. It seems to me that they will be maintainable for a long time.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcarl wrote:
That's really great! You start a flame war and then come off as the righteous preacher.

:lol:

Having experienced both ASM and C programming (ASM on PICs back in my uni days and C on AVRs) I would have to say that whilst I do enjoy rolling up my sleeves and getting my hands dirty writing machine code, a higher level language is much easier to progress with writing macroscopic code blocks. In ASM you have to micro-manage. You can get fast at writing ASM, but it takes more practice.

For tasks where instruction timing is critical, I would use ASM. For everything else I would use C because its easier, and C compilers are good enough that the generated code would probably be smaller than me writing ASM. If you are good at writing ASM you can make code smaller but C compilers are written by people with an expertise of both ASM and C, so they usually know the quickest way of achieving a C instruction in ASM ;)

C also lets me be lazy, and write code that makes sense to me without having to think too hard. Thats probably the biggest reason I prefer it :mrgreen:

Note that this is my opinion based on projects I have worked on - different projects call for different approaches when writing code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IMO: These days, good compilers can keep track of dirty/clean registers and variables in a juggling act that an asm programme cannot do. Thus, without an inordinate number of coding hours, many non-0trivial programs are as good as or better in C than asm. Now there are cases of course where due to timing or high volume production come in to play and asm may be more prudent, at least for part of the program.

I wrote 100% asm for years and years back when high level languages were an impractical luxury (due to memory costs).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use C. I know an assembler too, because it is useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
(Sorry, my english is very bad because I study english)

???
Better stop studying it, then! :lol:

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do not keep track of which language I use most often. The language selection is driven by the current job requirements. Sometimes assembly gets mixed in with higher level code for critical applications. Just pick the best tool or tools for the job at hand. Letting any particular tool (language) exclusively drive how the job is done can seriously impair the job. The only exception I can think of is if you are writing demo software just to show off some particular language. Then the language itself becomes a critical part of the job.

If you believe being stuck with only one tool is a good thing, then I would like to see you build a house using only a nice new shiny power saw. I will be really fun watching you pound in nails with your saw :).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone program the AVR in LOGO
show turtle
move turtle 27,45
hide turtle
Jörg, I still have a copy of FIG FOURTH for my 8-bit Atari.

6502 forever....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You guys claim you can run 32 servos, but you don't give your resolution! If the servo has 300 deg travel, and the little pot in it must have at least 8 or 9 bits of resolution... thats about .5 degree. Good enough for some things, but not others! If you need .5 deg resolution, you need a 9 or 10 bit position and a timer with that res! But if you only need coarse positioning.... 16 or 32 or 64 positions, that's ok too. But I think we must specify the resolution!

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure about boat/car servos but the ones I use in planes dont have any where near 300 degrees of travel. More like 120 degress which can presumably be encoded in 7 bits for 1 degree accuracy.

Cliff