YACVASMW

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

This deserves it's own thread, haven't had a decent war lately. devil

 

 

david.prentice wrote:
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

Last Edited: Thu. Jun 15, 2017 - 07:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1: you cant access the SREG in C.

?? What?  Why not?

2: un-optimized C is highly inefficient

Only idiots would use un-optimized code.

C is also extremely difficult to MASTER.

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

 

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

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. Jun 15, 2017 - 03:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

js wrote:

1: you cant access the SREG in C.

?? What?  Why not?

 

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

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

mark4th wrote:

 

C is anything but a glorified macro assembler

 

I agree, but that's a point in favor of C in my opinion.

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

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>

int main(void) {
        SREG = (1 << SREG_V) | (1 << SREG_T) | (1 << SREG_I);
        if (SREG & (1 << SREG_C)) {
                //soemthing
        }
}

C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 -g -Os avr.c -o avr.elf

C:\SysGCC\avr\bin>avr-objdump -S avr.elf | tail -n 20
#include <avr/io.h>

int main(void) {
        SREG = (1 << SREG_V) | (1 << SREG_T) | (1 << SREG_I);
  6c:   88 ec           ldi     r24, 0xC8       ; 200
  6e:   8f bf           out     0x3f, r24       ; 63
        if (SREG & (1 << SREG_C)) {
  70:   8f b7           in      r24, 0x3f       ; 63
                //soemthing
        }
}

 

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

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?

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

Kartman wrote:
The gcc I use is quite good with isrs.
Yeah but it still does:

C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>
#include <avr/interrupt.h>

ISR(INT0_vect) {
}

int main(void) {
}


C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 -g -Os avr.c -o avr.elf

C:\SysGCC\avr\bin>avr-objdump -S avr.elf | tail -n 30
0000006c <__vector_1>:
#include <avr/io.h>
#include <avr/interrupt.h>

ISR(INT0_vect) {
  6c:   1f 92           push    r1
  6e:   0f 92           push    r0
  70:   0f b6           in      r0, 0x3f        ; 63
  72:   0f 92           push    r0
  74:   11 24           eor     r1, r1
}
  76:   0f 90           pop     r0
  78:   0f be           out     0x3f, r0        ; 63
  7a:   0f 90           pop     r0
  7c:   1f 90           pop     r1
  7e:   18 95           reti

None of which I asked for or that I actually want. This is one of the few cases where I'd use a .S rather than a .c/.cpp if there was a time critical ISR.

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

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.

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

 I don't see any advantage in 100% assembly.

what!

 

If you want Y for something useful you can't use GCC ;) 

 

add:

In ASM you will structure a way that is best for the job, in C you need to follow the basics for that compiler.

 

 

Last Edited: Thu. Jun 15, 2017 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, that's not the gcc i was referring to! Something other than avr.......

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

mark4th wrote:
the fact that GCC injects copious amounts of opcodes on every ISR
If it matters, then do the ISR as ISR_NAKED and roll your own. Or  as clawson said, just do the ISR in a .S file.

 

<FOR MY PROJECTS>

    C allows me to code the non-critical sections quickly and then iff something needs optimization, do it in assembly (whether in-line or separate .S file).

    I have had projects where there was no choice but pure assembly because EVERY cpu cycle was critical, fortunately (for me) that is very seldom.

</FOR MY PROJECTS>

David (aka frog_jr)

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

I have yet to see any microchip PIC 24 application over 8k in size that could survive turning on even O1

why do you post this in a AVR forum, the GCC for the AVR's don't have any problems. 

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

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

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

Kartman wrote:
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

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

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

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

In this thread:. Guy doesn't know how to use avr-gcc, tells us why avr-gcc is terrible.

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

Rezer - sounds like a meme!
Here's another:
"I don't always do asm, but when I do, I use C"

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

devil

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

 

S.

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

mark4th wrote:
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 :).

 

Of course not.  You use a wrench to bang in a screw.

 

One for the meme box:

 

"A wench is what you use to turn the head of a dolt".

 

S.

 

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

@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.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

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

Ayup, most of that was a cheery rant.

 

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.

 

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

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..

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

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

Scroungre wrote:
Here's another: Including assembler code in C requires much more fussing about than straight assembler. Just look at the syntax.
Strong argument for .S files then! The only time to start casting the runes with inline assembler is when you absolutely cannot afford the overheard to CALL/RET to separate code.

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

Generally, I write the time-critical bits first.  And test them all alone.

 

All the rest is window dressing.

 

S.

 

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

mark4th wrote:
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.

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

theusch wrote:

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.

 

S.

 

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

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) .

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

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

#$%$%&&#$@%$ !!! 

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

If that ability is important or crucial to you, THEN WHY DID YOU CHOOSE THAT TOOLCHAIN?!?

 

#asm("sei")
...looks like fairly straightforward syntax to me.

interrupt [UART_TXC] void uart_tx_isr(void)
{
#asm
    .equ __tx_buffer_size=8
    push r26
    in   r26,sreg
    push r26
    lds  r26,_tx_counter
    tst  r26
    breq __uart_tx_isr1
    dec  r26
    sts  _tx_counter,r26
    push r27
    push r30
#endasm
...

... and so does this.

But then perhaps I chose the toolchain because...

 

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.

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

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

http://www.avrfreaks.net/comment...

theusch wrote:
[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.

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

theusch wrote:
You get different results from different compilers

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.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

Last Edited: Thu. Jun 29, 2017 - 08:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

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.

 

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

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.

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

Scroungre wrote:
It's more about precision timing.

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.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

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

Fpgas use a load more gates than what you actually use! Do you place and route by hand?

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

JohanEkdahl wrote:
This is snot specific to C.

I love the typo, especially in the context of this thread.

 

JohanEkdahl wrote:
theusch wrote:

Did I really write those?  Or are you quoting whaat I quoted from the scroungemeister?

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.

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

Scroungre wrote:
I (almost) always run my AVRs absolutely flat out, and sometimes even that isn't fast enough (back to the CPLDs!).

You gave a long answer, but still not a hint of what class(es) of microcontroller apps all need to run "flat out".

 

 

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.

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

theusch wrote:
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.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"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]

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

Scroungre wrote:
I should also point out that it's rarely about sheer data crunching speed. It's more about precision timing.

I just noticed that answer.  But I'll pose the same question:  Give a hint of your class of apps that often/always requires precision timing?

 

 

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.

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

theusch wrote:

Scroungre wrote:
I should also point out that it's rarely about sheer data crunching speed. It's more about precision timing.

I just noticed that answer.  But I'll pose the same question:  Give a hint of your class of apps that often/always requires precision timing?

 

Industrial automation.  Robotics, basically.  Occasionally aerospace stuff.  My job is basically making the wheels go round.  S.

 

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.