what's wrong with a pic ?

I believe it. AVR isn't a very C friendly architecture.

--
Grant Edwards                   grante             Yow!  You were s'posed
                                  at               to laugh!
                               visi.com

What really made the difference here was being able to use different groups of registers for different purposes. Interrupts only needed to preserve the status register - everything else they needed to use was already present in registers that were never touched by the main program or other interrupt functions, so the 32 registers of the AVR were put to much better use than a compiler could manage. There were also a number of parts of the code that can be better described in assembly - things like crc routines that make use of rotates and the carry flag, that are really messy in C but only take a couple of assembly instructions.

For most programming tasks, I couldn't beat avrgcc by anything like that much without a great of effort - the AVR is not *very* C friendly, but it is a lot better than most 8-bit micros.

It beats PIC and 8051, but as soon as you start doing anything with pointers, the AVR hits the wall due to the pointer register bottleneck (IMO, a major design flaw in what's touted as being a C-friendly architecture). Even something as seemingly register-starved at least has an HC11 has the advantgage of being able to do a load/store of a pointer value in a single atomic operation.

--
Grant Edwards                   grante             Yow!  Do you think the
                                  at               "Monkees" should get gas on
                               visi.com            odd or even days?

In article , Frank Bemelman writes

Wrong on both counts according to the annual trade survey. ASM is (from memory) about 20%

HLL was used in embedded systems a long time bask. Mainly BASIC and FORTH I think

guessing again?

Written in C and asm

So C will go but not php despite the fact that the use of C is far more wide spread than php... also the "glue" is going to have to do a lot more than php.

I think you will find that most of those with blinkers are a hell of a lot younger and still working.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

And I have a C compiler for the RS08! :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Did I mention that all the code was all in a single source file?

--
John W. Temples, III

The mind wobbles.

--
Grant Edwards                   grante             Yow!  I was making donuts
                                  at               and now I'm on a bus!
                               visi.com

The IAR C compiler allows you to use R4..R15 as you please. Personally, I'd like to get access to a few registers in the upper area as well.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

A 16 bit micro would typically use 3-4 bytes to load a pointer so it would do two instruction fetches to load that pointer. The AVR will do two instruction fetches to load the same pointer. It is not atomic, but does that matter a lot?

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

You're right. It doesn't matter for pointers, but for other things having atomic 16-bit atomic operations can eliminate a lot of mutexes or disable/enable interrupt sequences. One of the things I really like about the H8 is atomic 32-bit operations: reads and writes of 16 and 32-bit variables (even floating point) are atomic. It eliminates a whole category race conditions that you have to guard against in a pure 8-bit machine like the AVR.

--
Grant Edwards                   grante             Yow!  What PROGRAM are
                                  at               they watching?
                               visi.com

I take that back. There are times (rather rare) that I need atomic writes for pointers. On an AVR, I'd have to disable and then restore interrupts. Requirements for atomic read/write operation for "data" values is far more common.

--
Grant Edwards                   grante             Yow!  "THE LITTLE PINK
                                  at               FLESH SISTERS," I saw them
                               visi.com            at th' FLUROESCENT BULB
                                                   MAKERS CONVENTION...

"Chris Hills" schreef in bericht news: snipped-for-privacy@phaedsys.demon.co.uk...

Making a 15-20 years forecast always is.

Yes, but how many folks are involved in writing tool chains.

That's what I think is going to happen, yes. An impressive set of libraries and a bit of glue. Compare it with the API for windows 3.0 and the incredibly large API we have for windows today.

There is still too much reinventing of the wheel going on. Lack of powerful tool chains is still a valid excuse, but I doubt that will still be the case in 15-20 years. Too many programmers are working on too many similar problems, such a waste of time...

--
Thanks, Frank.
(remove 'q' and '.invalid' when replying by email)

I disagree.

The "incredibly large API" for Windows may be fine for desktop, but not (most) embedded - which tends to mean lean and mean. Dependence on convoluted libraries is *not* the way to go. Even if the linker only uses the bits that are used, those bits will have dependencies, and one runs into the C++ syndrome - you add one inoffensive looking routine, and suddenly the code size doubles. Besides: I'm not terribly trusting of 3rd-party libraries.

Re PHP etc: I'm very familiar with PHP, I've written many 10s of thousands of lines of the stuff. It's an interpreted web scripting language. If you take away the interpretedness (tm), you're left with a C-like language with a smattering of OO - and a large library of built-in routines, which is maybe your point. But again, it's not terribly applicable to embedded work.

Maybe you'd argue that "lean and mean" is becoming less relevant in the embedded arena. To an extent, this is true. But again I disagree that assembler is obsolete - I've been hearing this for years, and it hasn't happened yet. There are still, and will almost certainly continue to be, applications that require it, in full or in part. Again compilers are way better now than they were - but certain things are more simply expressed in assembler than in a HLL.

T'was ever thus, and again I've heard this all before many times over the years. There *are* ways in which the current development process can be improved, and indeed is improving; but I don't currently think it's possible to generalise to the point that one large group of library routines will happen to be optimised for the myriad applications out there. I re-use a lot of code, but I often tweak it for the current application.

Steve (in haste)

For more than 30 years ago most embedded "processors" were just simple state machines, e.g. in disk controllers. etc. more or less programmed in binary to set up the tables. Some high end devices might use something like the DG Nova or the DEC PDP-11 minis with mostly assembler and possibly Fortran.

About 30 years ago 8080/6800 emerged and they were programmed in assembly. However, 25 years ago PLM-80 was quite popular on 8080/8085, while 680x systems still used mainly assembler, since no usable HLL was available.

Paul

[...]

On which planet was that??

--
http://www.flexusergroup.com/

I am not disagreeing with you. If you have something that requires a lot of code you shouldn't be using a PIC. Just suit the chip to the job. I don't think quasi-C compilers are the answer, because you have no standards on which to rely. Assembly, however, is quite suitable and fairly simple if you can organize your software (possibly by writing a C version).

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see

Nonsense. C is thoroughly defined, but possibly imperfectly so. However C is not a well designed language, when compared to such as Pascal. You can get an idea of the complexities of the "grew like Topsy" design by comparing the size of the Pascal standard (standard or extended) with the size of the C standard. Pascal was designed.

The great advantage of C is simultaneously the insecurities of its imperfect design, which allows it to be coerced onto many diverse architectures, and reach into those architectures guts.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see

Huh? Strange question.

I was involved in projects using the 6802, and more latterly the Hitachi

6301X/Y, during the period '79 through to about '90. We used assembler exclusively. We had 128 bytes of RAM on the 6301X, and 192 bytes on the 6301Y - and that was it. I think we started out with 4k of ROM and eventually moved up to 16k by the time of the 6301Y.... AFAIR. Might be wrong. Been a while.

At that time there were no, I repeat *NO*, HLLs that were suitable for these micros in our applications with those resources.

Yes, I remember Flex. Very nice on a 6809 with oodles of RAM and ROM. Which we didn't. These were true high-volume OS-less embedded products (1/4-DIN and 1/*8 DIN 3-term temperature controllers). Not desktop machines.

Steve

Yeah, but "680x systems" include systems with the 6800 and 6809 chips, and Paul Keinanen was comparing with the situation on the

8080/8085 side. I began working with the 6800 in the mid-seventies -- I don't remember exactly when they appeared, but there were at least two PL/x compilers (MPL and SPL/M), a few compiling Basics, a couple of Forths, and a few Pascal compilers available during the seventies.

Well, "oodles"... ;-) In the beginning, I ran FLEX 6800 on a machine with 12 kB of RAM and 2 kB of ROM.

And I developed quite a few 6800 "embedded" systems with 128 bytes of RAM and 2 kB of ROM, running Microware's RT68/MX small realtime kernel. Some of the applications were developed with their "Tiny" Basic compiler, that had constructs for multitasking built-in.

--
http://www.flexusergroup.com/