I was not aware of the different write order. This can kill you in any language. Seriously, you may consider learning a HLL. After 20 happy years using a 6809 assembler, I doubt that AVRs will still be commonly used in another 20 years time. especially the mega162. C is after all just a glorified macro assembler. Or at least you can treat it as such. David.

C is anything but a glorified macro assembler

1: you cant access the SREG in C.

2: un-optimized C is highly inefficient

3: you have no control over what the optimizer produces and are therefore at the mercy of the optimizer.

Yes: C can get the job done, it lets any "idiot" think they are a master coder and that is GOOD for the industry as it means more people can get the job done. C is also extremely difficult to MASTER. Its like the Guitar, almost anyone can play it, almost nobody can play it right, it is one of the most difficult instruments to master.

On the other hand, ASM is simple, elegant, easy to master and gives you fine grained control over EVERYTHING. You dont need to learn horrendously complex and obfuscated / badly documented libraries like ASF to use it.

If something can be read without effort then great effort has gone into its writing

Was about to make some snarky comments but this thread is probably best if it is simply allowed to die. Recent posts tread, very close to that issue of "best" (language, compiler, what-ever). Either put on the Nomex or let it sleep!

The SREG is the processor status register, it has the carry flag, overflow flag, t flag etc etc. You can access with with inline asm in c but in pure C you have no access to ANY registers. well, I suppose on an AVR you could set up a pointer to the SREG memory location but that would be a hack not available on any other arch I know of.

2: un-optimized C is highly inefficient

Only idiots would use un-optimized code.

Not true. I have yet to see any microchip PIC 24 application over 8k in size that could survive turning on even O1. Thats down to the utter garbage they are pushing as their version of the GNU C compiler, its VERY broken. With optimizations turned on, you make a change to module A and suddenly module B, a totally unrelated module STOPS WORKING. It becomes like tuning a guitar, tune up string A and string B de-tunes.

Also, there is alot to be said about writing your code with optimizations turned off, getting it as fast/small as YOU can get it and only then turning on optimizations. Understand though that doing this requires you re-test everything :)

C is also extremely difficult to MASTER.

semi agree with that, but it's only a matter of practice like any other language.

C has too much in it that makes it trivial for the inexperience to shoot themselves in the foot repeatedly!

short data = join_bytes(read_data(), read_data() << 8) or the like. very bad coding but ive seen this sort of thing countless times. The problem is, you dont know which call to read_data is going to happen x++ + ++x is another classic example of stupid C code that is again, exactly the sort of thing an inexperience C coder will do. But its not all down to experience. Its also down to the examples other people make.

i have a T-Shirt that reads /* No Comment */ and I call that a C coders coding standard. C Coders are of the opinion that the code should be 100% self documenting and there is NO SUCH THING as self documenting code. Just because you can understand your code does not mean anyone else will. Comments need to be there to make the purpose of the code easier to understand. Code should be as self documenting as you can make it but using entire sentences as function names is just idiotic.

Mastering C takes decades and most people will never get above "ok" level (including me, i dont like C for embedded). This means that the majority of example code is BAD example code... thus continually propagating the bad examples.

Edit hmm I see that this is a 7 year old thread with a YO reply. Better late than never.

I only just got here :P

If something can be read without effort then great effort has gone into its writing

so your OK with the fact that GCC injects copious amounts of opcodes on every ISR that really have no reason to exist :)

C is good... asm is just way better for some things and gives you a greater degree of freedom and control. But I hate it when people try to tell me that C is just a macro assembler.. thats simply not true.

If something can be read without effort then great effort has gone into its writing

You're not telling us anything new- many of us have years of assembler programming under our belt but we choose not to use it unless necessary. Considering modern compilers can do a whole swag of optimisations that would be labourious and/or error prone in assembler.
The gcc I use is quite good with isrs. What gcc do you use?

In my opinion, even if most of the critical parts of the program are made up by asm functions/modules/routines, I think C is still very useful to glue everything together in a more readable way. I don't see any advantage in 100% assembly.

I realized later that on an AVR it IS possible to access SREG directly because the SFRs are mapped to I/O space so all you need is a pointer to that register or as shown some macro to facilitate reading of it. Also, yes this is not PIC but AVR and the GCC compiler for AVR is orders of magnitude better than the one for PIC but I stand by my "c is not efficient in all situations" statement. Im not anti C. Im anti "ant asm" and anti "c = macro assembler" which it is not.

C and ASM as stated above are both good tools just like a hammer and a screw driver are good tools. Unless you are from Manchester England you use the right tool for the job. You dont drive screws with a hammer (Called a Manchester Screwdriver :).

If something can be read without effort then great effort has gone into its writing

You're not telling us anything new- many of us have years of assembler programming under our belt but we choose not to use it unless necessary. Considering modern compilers can do a whole swag of optimisations that would be labourious and/or error prone in assembler. The gcc I use is quite good with isrs. What gcc do you use?

using avr-gcc that comes with avr studio 7, with -o3 it pushes about 20 items onto the stack in the ISR entry point, then calls the actual service sub-routine then pops them all off the stack again and most of them are never touched in the ISR itself.

If something can be read without effort then great effort has gone into its writing

But that's because you CALL'd a function from an ISR. It does not try to analyze whether the call target is in the current compilation unit or one it may link to later. As such it has to make the worst assumption for the code it cannot see and assume it uses all the registers

C is supposed to be this wonderful processor-independent universal language, but it isn't. You get different results from different compilers, and even different results from the same compiler by fiddling with options - on the very same target MCU. Write assembler, and you know every opcode you're going to get, and when.

As an anecdotal aside, I had a large assembler program of my own "rewritten" in C, and everywhere I used a jmp (or rjmp) he put in a function call(). JMPs don't 'return'. Function calls do. Naturally, this smashed the stack something fierce. Fixing it was a right royal pain.

(This guy also wrote a brilliant "passcode" routine that he tested with the correct passcode, and it passed. He apparently neglected to test that it didn't pass with incorrect passcodes. It turned out that ANY passcode would be accepted as valid! But nobody noticed because all the other testers were carefully inputting the correct code! It wasn't until they came back to me asking me to change the passcode (in the EEPROM) that I noticed their EEPROM file already contained the code they wanted me to change it to! My assembler version worked fine, pass AND fail. Humph. A pox on your C house. ;-P

@Scrounge: your arguments seems to be re quality of some compiler implementations, and some stupid coders. Not re the C language as such.

And arguing that compiler options should not affect the generated code? That is the point with them!

Tbe one true fact you argue is: With assembler you get full control. That is 100% true.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Here's another: Including assembler code in C requires much more fussing about than straight assembler. Just look at the syntax.

What I'd really like is an easy way to incorporate C into an assembler program. The project being basically done in assembler, with snippets of C here and there for things that are NOT speed-constrained (and there's a handy library for). Unfortunately, all the IDEs I've met go very strongly the other way - If you want to write a mixed C/asm program thou shalt start in C and then insert bits of asm. Humph again.

S.

PS - Yep, there's lousy code in C, and there's lousy code in assembler. I've even looked at some of my own stuff six months later and wondered "What was that moron thinking?". S.

Since, for most applications, the time-critical code is a small fraction (<10%?), I see it the otger way around. Write bulk in C, analyze time-critical parts, rewrite in assembler.

First optimization is always for maintenance. This rule is no free card for incompetent idiots, though.

Just my $. 05..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

so your OK with the fact that GCC injects copious amounts of opcodes on every ISR that really have no reason to exist

mark4th wrote:

[from the moderator] This deserves it's own thread, haven't had a decent war lately.

Here we go again -- a poster that equates "GCC" with "C".

Apparently >>you<< have >>chosen<< to use the infinite-value toolchain. And then complain about one corner of it?

I'll opine that with any of the mainstream C toolchains with AVR target, "clean" C, written with the underlying architecture in mind, will turn into very predictable opcode sequences.

When >>you<< decide to play fast-and-loose (a simple example is mixed signedness) then yes, the compiler must play by the language rules. In ASM, you can say to yourself "I know abc holds a small positive value as does def. So I'll use the unsigned arithmetic operation, even though at other points abc (and/or def) may hold negative values.". You do the same in C with a cast, to treat the signed operand as unsigned. Just one simple example of 'think in machine code; write in C'.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

I'll opine that with any of the mainstream C toolchains with AVR target, "clean" C, written with the underlying architecture in mind, will turn into very predictable opcode sequences.

I was of the general impression that GCC IS the mainstream AVR C toolchain, at least for hobbyists. IAR is US$4,000 a seat, and I dunno about Codevision, but I'd rather spend that on a new oscilloscope than a more efficient compiler.

If you're not content with the compiler you've chosen the ask for your money back.
Or accept that you will have to tweak your code so that the compiler does something closer to what you want. Eg declaring your ISRs 'naked' (and take full responsibility yourself to eg restoring registers) .

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

As long as the pot is being stirred, this is just so "retro"? "Luddite? Something. Back when I was your age, about 30 years ago, and "IBM PC" ruled the world, and C compilers were being rolled out left-and-right -- the one that could indeed take the same Towers of Hanoi source code and get it some cycles shorter would survive. That was done by having the code generator use standard compiler techniques, and inventing new ones. Fast-forward 30 years, and what do we get?

Scroungre wrote:

C is supposed to be this wonderful processor-independent universal language, but it isn't. You get different results from different compilers, and even different results from the same compiler by fiddling with options - on the very same target MCU.

I'll still stand behind

I'll opine that with any of the mainstream C toolchains with AVR target, "clean" C, written with the underlying architecture in mind, will turn into very predictable opcode sequences.

Scroungre wrote:

I was of the general impression that GCC IS the mainstream AVR C toolchain, at least for hobbyists.

I've been told many times here that the beauty of that infinite-value toolchain is that given the open-source nature, anyone an adapt it to their needs and preferences.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

[Indeed, I've worked with a handful of gurus that think in machine op codes. You may well be one of them. Us mere mortals can never hope to match your efforts, no matter what language and toolchain. But the majority of programmers, ASM or not, are not such gurus. And so the old argument goes...the ASM program has many more lines thus many more chances for error. But putting that aside for now...]

Related:

Scroungre wrote:

The project being basically done in assembler, with snippets of C here and there for things that are NOT speed-constrained ...

Perhaps you live in a very different microcontroller application environment than I do. I just flat-out don't have many "speed-constrained" pieces in my AVR apps, and I have many scores of production AVR8 apps over the past 15+ years. We've only had two apps that have clock faster than 8MHz; most are 3.68MHz. Still plenty of cycles.

That's not to say that I don't have e.g. "important" pieces of code. Take a quadrature encode app--the ISRs for the edges are important. Indeed one could say "speed-constrained", as the cycle count of the ISRs gives nearly directly the max edges/second that can be handled. But I still write those in C, and examine the results. As I opined above, sometimes a hint is needed for the C compiler with a cast or selecting variables to live in registers.

The result for the quadrature is an ISR with no fat. And in straight C. Posted several times here in similar discussions/"contests". There is nothing wrong with the code generation of the matured mainstream C compilers with AVR8 target support.

But indeed, you may live in a different app world. Can you give a hint?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

yes. So what? As long as the generated code adheres to what the C standard promises, and the compiler produces reasonably efficient code that's no problem. Things that the C standard does not make any promises about: Code efficiency (that is up to the compiler implementor to deliver). Timings - the C standard gives no guarantees for any absolute timings. It only guarantees that the interfacing with the world outside the program will be done as the C code describes. It might take one millisecond or three days to execute. The standard does not care. Again, delivering reasonably performing machine code is up to the implementors.

This is snot specific to C. It holds for more or less any "compiled language".

Scrounge wrote:

even different results from the same compiler by fiddling with options

If there was no difference in results then why would there be options? They are there for just that purpose.

It seems to me that you want the determinism that only coding in assembler can offer. Then stay with assembler.

Meanwhile an awful lot of people actually succeed in writing good functioning programs using C. Speaking only for myself (but I assume it goes for a lot of us) I code much faster in C than in assembler. I have an easier time maintaining code I've written in C, as compared to assembler. I have a decent collection of code that is fully portable between different compilers and target platforms.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

After a deep breath, Scroungre may well be one of the gurus that thinks in opcodes. As I've opined over the years:

...

But indeed, you may live in a different app world. Can you give a hint?

You are correct there.

I come "up from below" as I put it, from a world of dedicated gates. From 74xx chips to PALs, GALs, CPLDs, and FPGAs. ABEL, VHDL and Verilog are my languages. Write your own opcodes! At whatever bit width you feel like! And they're fast (well, FPGAs not so much) - Even cheap'n'cheerful 22V10s have a 25 nanosecond cycle time, and good ones can be less than 5ns. Moreover, everything gets done in one cycle, every time.

I (almost) always run my AVRs absolutely flat out, and sometimes even that isn't fast enough (back to the CPLDs!). I have boxes of 16- and 20MHz crystals and oscillators. I (almost) never use the internal clocks because they're not fast (nor stable) enough. Similarly, I have little truck with the low-voltage versions.

One system I am tinkering away with will use the internal RC because it's stringently space- and power- constrained (and not speed-sensitive at all) but it's quite an exception.

The idea of getting opcodes that you didn't ask for bothers me akin to a guy from the sales department coming in and just randomly soldering a few logic chips to the board here and there. It gets up my nose; I don't like it. I am slowly starting to learn to live with it.

Have fun, S.

PS - As far as errors? Oh, there have been some beautiful bloomers that would never have gotten through even ASM, let alone C.

I should also point out that it's rarely about sheer data crunching speed. It's more about precision timing. Even a hardware interrupt on an AVR isn't deterministic, because you don't know what instruction you interrupted, how many cycles that instruction was, and where it was when you interrupted it. S.

Again: C does not in any way guarantee precision timing. If you need that it's either pure hardware or assembly coding.

Scroungre wrote:

The idea of getting opcodes that you didn't ask for bothers me akin to a guy from the sales department coming in and just randomly soldering a few logic chips to the board here and there.

LOL! A wonderful scene you painted there. (-:

But the bucket is not holding water well.. He's actually not throwing in completely random chips. Somehow he manages to set up the hardware so that it's working to the specs. And since he's a lot faster doing that than us doing the "perfect minimal" hardware design, and since the added cost of his design is negligible most of the time we're happy. We get to the end result faster, the hardware is easier to maintain and modify if needed.

We also know enough about the hardware and the sales guys "patterns" to understand when his actions will be malign rather than benign. And we have ways of stopping him from altering the hardware when that is the case.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

JohanEkdahl wrote: theusch wrote: Did I really write those? Or are you quoting whaat I quoted from the scroungemeister?

You're right. My mistake. Will correct.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

PS - Yes, FPGAs are miserably inefficient transistor-wise, although compared to an ARM that's running a delay loop, I'm not so sure, and yes, sometimes I do my own manual place'n'route. It's a drag. Kinda like doing my own PCBs when I own a good autorouter - It's vastly faster and doesn't make stupid blunders, but my layouts are still better. Generally I try to avoid FPGAs, but sometimes they're necessary. You would not believe what radiation-hardened ones cost. S.