Moving from 8051 to AVR

People have schedules for products, and they generally do not want them to slip, to get lower cost products. I did not say that this is true in every case, did I? Has nothing to do with C or assembler...

No, the way to have optimize cost is to optimize on all levels. If a customer has a choice between meeting a schedule or reduce cost then if the customer chooses to meet the schedule, I think it is fair to say that time is more important than cost.

And an alternative is to use another C compiler for the 8088.

You gotta be joking. What possible DVD user interface would require an ARM??? Best laugh I've had in ages.

Ian

"Chris Hills" skrev i meddelandet news:zQm+ snipped-for-privacy@phaedsys.demon.co.uk...

So if you are not going to employ engineers, you are going to pick up the local pizza delivery boy?

I think in this case "getting rid of global variables" is not the same thing as "getting rid of *all* global variables".

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB

This most definitely is not true. It assumes assembly takes longer than C and that software is the only driver of timescale. In many high volume products neither is true.

Ian

The type of interface that is displayed on your TV screen for example. By using an ARM for that, you can have a single chip solution that produces the video in software and does the rest of the processing in the blanking intervals.

Meindert

IT programmers are NOT engineers. In fact I would employ engineers, ones with an engineering degree, preferably in electronics. It is cheaper to train them to write C than it is to train a IT programmer to write code for an 8 bit microcontroller.

Ian

This whole thread is about 8 bit microcontrollers like the 8051 and the AVR. Noone is talking about 500K of code.

Ian

Where have you been for the last 20 years. 8 bit micros with on screen TV output have been around for ages.

ian

A user interface that involves 24bpp icons and anti-aliased scalable fonts, which is to say practically all of them. The rest of the world has moved on from VFDs and 32 x 20 OSD text, you know. Even digital still cameras don't often use 8-bit processors any more, even at the low end.

The DVD chips are not just DVD chips any more, either. They are "media player" solutions used in set-top boxes and other appliances such as portable multimedia players. The real estate cost of the main micro core is presumably negligible compared to the overall ASSP dimensions. STBs are oftentimes required to run middleware that occupies considerable memory - futzing about with ridiculous 8-bit banking hardware would be silly. Ever tried to run a Java bytecode interpreter on an 8051?

For example kindly refer to which shows some more or less typical low-cost solutions. The ES6688A, for instance, has a 32-bit RISC core and a separate servo micro (that's probably an 8051). You'll be hard pressed to find an 8-bit solution in this day and age. Even the Visba 3 (ES3890) which is intended for ultra dirt cheap VideoCD applications has a 32-bit core.

Take a look at Sunplus, National Semiconductor , ST's STe5588 based on the ST20

32-bit RISC core

and click on the MPEG box, etc. etc. etc.

Hey, guess what? In all those vendors, I didn't see a SINGLE ONE listing an 8-bit core in their current product lineup. All of them are

32-bit RISC uCs. Maybe a little adjustment to the 21st century is in order.

Of course, maybe these vendors don't have a big sign on their website saying "WE'RE NOT LOCATED IN THE UK", which could be why you discount them.

No argument.

It seemed to me that you said "most significant driver" in disagreeing with Ian about unit cost, when the facts are that there are a number of constraints operating on any product and time to market is just one important one. I think it remains less extreme and more balanced to holds all important constraints in mind, including having the right product for market.

Which is what I'm saying. Glad to see you agree.

I don't know why you'd argue this. Do you make end-user products for sale? There are several cases I can cite personal experience on, where I was told that the cost target, if not met, would simply mean there was no point in offering it at all.

You continue to appear to have only one perspective. I don't disagree that it is reasonable in various cases. Just that there are many other reasonable ones which you seem to discount.

And I still don't find your argument persuasive.

Not so, Ulf. The very fact that you'd even consider suggesting this out of ignorance of the details (which I have and you do not), means to me that you continue to be very willing to risk telling others how they might better do things without knowing why you say so.

Here is the fuller context of my statement, which you snipped:

: I don't imagine things nearly as simple, black and white, as you seem : to, Ulf. My actual experience with these exact problems goes back : decades, as I am still to this very day supporting products using the : Lattice C compiler, old Intel tools, special customized software to : handle the unique OBJ formats of both, etc., all for cross-development : to an 8088 processor that is in a custom configuration totally unlike : a PC. There is no Lattice, anymore. They are gone. And this is only : one of many such examples. I also have had to deal with cases where : the old tools are no longer even _known_ about by the current support : staff and there is almost nothing they can even do, despite wanting to : help. And there are other different circumstances. : : Some foresight about these possibilities can help make a better choice : about which approach to take and how to hedge against future problems. : How that plays out, of course, depends on the circumstances and the : vendors and a lot of other factors.

Even from this tiny amount that I wrote, if you had had experience of a more general nature but good embedded experience all the same with various PC compilers, you'd have known that in a custom, non-PC system there would _have_ to be custom assembly code, as well. Even knowing nothing at all about the product I was talking about, it should be amply clear from what I wrote that this would need to be the case. If nothing else, in the crt0.asm code that was used. But in any real, practical system, probably more than that.

This is, of course, how things actually exist for this product. A mixed system of assembly and C. In the Lattice C compiler, it does not pass variables the same way as in the Microsoft compiler or the Borland C compiler or the Paradigm C (a derivative product, itself) or, in fact, any other C compiler I know of right now. It isn't the case that they just did things 'to be different,' just that there wasn't a de facto standard, yet, and they decided to do things in their own way.

In addition, I took the time to inform you that it combined "old Intel tools, special customized software to handle the unique OBJ formats of both." This should also tell you that there are some custom things going on. If you had been reading with understanding, you'd then very probably be able to judge reasonably that "an alternative is to use another C compiler for the 8088" isn't a viable alternative unless there are _other_ reasons for changing that just "to change, because the company is gone."

Frankly, only with what I'd already written, I cannot see a reasonable way to understand how you could make such a comment. That is, if you had honestly had any practical experience with real clients and real client motivations, in this regard. But I really wish you could have been present at several meetings about this product, so I could have watched you suggest it there. ;)

Jon

No, I didn't lose sight of that, Ulf. Bringing up an ipod doesn't help to make the point you just wrote that you think this is about. So it's about the subject you think it is.

But since you seem to have lost track of my point in saying what I did, I'll take a moment and restate it. I wrote elsewhere:

: On Thu, 9 Feb 2006 16:47:35 +0100, "Ulf Samuelsson" : wrote: : : >

: >> It won't excel on anything if you let PC-style C programmers anywhere near : >> the chip without proper re-education, although I'll agree they would do : >> even worse when faced with an 8051. : >

: >Which is the point... : : I generally agree with a lot of what you write, but this seems like a : thin point if you suggest that it is Atmel's intent to make a chip : that is friendly to C programmers who know as little about embedded : programming as a PC programmer without such education might... : : I haven't used C for the 8051 (always used assembly) nor for the AVR : (always assembly, as well -- which I enjoyed doing.) But every C : compiler I have used for small embedded CPUs, the vagaries of the : language implementation (#pragmas, special qualifiers, etc) was the : least of the issues I worried over. Pretty much, it was everything : else and little to do with whether or not the CPU was C-friendly at : the instruction level. I can't recall ever worrying much about that. : : If I were a compiler vendor considering porting an existing compiler : over to a CPU, then I'd probably care more. :) : : Jon

As you can see, my argument is that I don't care that much, one way or another. It's just not on my radar scope, and the 8051 is a class example of why. The existing C compilers are quite good with it. Another case would be the PICs. They have decent C compilers, as well, and can be well used with C.

As I pointed out, if you are porting a C compiler, you will care. And if you are creating a CPU and hope to encourage others to port their C compiler to your target without having to shell out cash to encourage them, you might want to consider that, too. But as an end-user of C compilers, not a compiler vendor or a CPU manufacturer, it all comes out in the wash. I will worry about the viability of the C compiler vendors, the quality of their products, my ability to hedge against risks later on with their products, etc.

But I cannot recall having a product business meeting where others at the table were asking me whether or not the CPU I had selected was "C friendly" or not. A lot of other things come up -- availability, sourcing, cost, power, size, etc., etc., etc. But no one really cares that much, except possibly for programmers. And I don't care. Being the programmer, that means no one cares, in my case.

Returning to my point and assuming for the moment that you are right about the topic (granting you that much), the ipod does not make a good example of cases. End of story.

Jon

And for CDs rather than DVDs, Karaoke?

Jon

Most embedded people come from electronics degrees (where they are taught C) whereas most IT people come out of Computer Science departments where they learn C++ /C# and JAVA, (not C any more) where they don't have the first idea about hardware or any platform other than Windows.

Added to which most new graduates have absolutely horrendous bad habits (you only have to see some of the home work questions we get on here!) that are not safe on any platform. New graduates need a period of engineering, real world and on-the-job training when they leave university.

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

Quite a few from what I have seen, certainly the new ones from several manufacturers.

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

Have been to multiple meetings where people like to hear about the AVR and do not want to hear about the 8051s even if they have the same set of peripherals.

To me, beeing C friendly means that you do get better code size and performance than C-Unfriendly architectures. It should also give effect in development time. People care about this factors as you say.

Typically you select the CPU on peripherals, preferably in a family of different memory sizes. Then you write the code, and finally you optimize to make it fit the smallest possible member of the family. If you can reach that without having to do nasty tricks, then your development time is reduced significantly.

ARMs are often very cheap now, in fact I'm considering migrating some

8051 flash based things to ARMs as they cost about the same, take about the same power, and are a lot more powerful.

Paul Burke

I've always wondered why "computer science" includes writing a compiler. The world market for compiler developers is extremely limited (10?) and the experience of doing such is of questionable value for the majority of programming.

Sadly, this is not a major surprise.

Ok, now I'm intrigued (and a little worried :-)).

What kinds of specific problems and bad habits are you or others actually seeing with current graduates ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
If Google's motto is "do no wrong", then how did we get Google Groups 2 ?

An electronic engineering degree in the United States includes typically twelve credit-hours of computer science (equivalent to approximately 75% of an entire semester full-time). These courses are almost exclusively Java in the institutes that I've examined.