Moving from 8051 to AVR

In article , Ulf Samuelsson writes

You said "a person educated at university on a PC" The rest of us read that as a PC programmer (it an IT programer) not some on targeting an MCU on a SBC or embedded systems.

Then again you also said "ANSI C requires "int" precision on certain operations." When most of us work to ISO-C Differences can be crucial...

SO you are talking about Electronics Engineers (not computer scientists) who are taught C.

I want them to fit The standards of Good Code. I guess you just train them to your standards instead....

Define "good code"? What my be good on a PC is not always good god on an 8 bit MCU.

I have seen universities teach ISO C on an 8051 where they ignored the Bit types as they were not ISO-C and therefore they could not write Good Code for them.

They then wanted to use 16bit Ints for everything on 8 bit systems rather than use the 8 bit integer types.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills
Loading thread data ...

In article , larwe writes

Ouch! SO where do they learn C that is used in most embedded systems?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Ulf Samuelsson writes

There have been several points in this thread where many of us have understood something different to that which you meant. Perhaps it is the phrasing of your emails?

This is just an observation not a dig at you.

Remember for many on this NG English is not their first language (this includes Americans :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Ulf Samuelsson writes

That does not make any sense at all.

hardly. IT programmers will but they don't do embedded work and employers don't employ them for that sort of thing... at least not more than once!

They don't write compilers at university.

This is ridiculous.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

I would agree but the problem is you start with a nice small 8 bit MCU and over they years add bits on and then you start code banking etc.

However... to go from a n 8051 to an AVR does not seem sensible. I would have thought a 16 or 32 MCU would have been more appropriate if you are going to port to a new architecture. It does make you wonder about the motives of those who suggested and supported the idea.

Some one else has suggesed that he meant 500K of source in which case this is another point at which Ulf seems to have differing terminology or perception to many of us.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Ulf Samuelsson writes

There are many religious meetings where people have narrow and fixed views.

EG the 8051 with over 600 variants from 40 odd vendors (including Atmel)

"nasty tricks" it depends what you mean here. there are some bad things that are bad no matter where they are then there are some things that are architecture specific. I have not yet found an MCU where there is not an architecture specific way of speeding them up of having smaller code.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

They may not "now" but the ARM parts are VERY cheap, as cost effective as using an 8 bit MCU, and give you room to expand with more "essential" features. Also if you are using ARM 7 now you can migrate to ARM9.... ARM54 later withthe same tools.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

C is often taught as a first-year undergrad course for CS students. At least, that is so in the case of Portland State Univerity where I have taught. It's not taught well and by 2nd year, when subjects like assembly code, floating point, and basic computer architecture are taught, they are expected to only have rather limited abilities with C.

Those taking EE courses will often be found taking courses from the CS department, like C or computer architecture. But I don't know if they were required. It was my experience, though, that the classes I taught had only a few EE students present -- about 10% of the class. So I think it may not actually be a requirement for an EE.

What I think happens to any EE, though, is that in today's world where micros are so prevalent and useful for many modern designs, it is almost inescapable that an EE will be personally driven to learn to program the devices. I've seen cases where they grew terribly frustrated trying to teach some computer science graduate very basic mathematics, analog and digital concepts, how to understand hardware peripherals in the micros, etc., that they just gave up and did it themselves. So, I think most EEs wind up going into programming, either willingly or else kicking and screaming. But one way or another.

They need to get the job done.

In teaching CS students, I tried to encourage any interests they might have in digging into embedded work. For the most part, though, they were making choices between being a "CS" student and being an accountant and just didn't have the mindset or interest for it. Sad to me, since I love the work.

Our school also offered CE coursework plans, which meant a mix of EE and CS. It's possible that this might be a source for embedded programmers, beyond EEs learning programming and CS students having some personal interest in developing their hardware, physics, numeric methods, and mathematical skills.

Jon

Reply to
Jonathan Kirwan

Because by writing a compiler you learn very valuable things about how compilers work, how CPUs work, and how languages work.

I completely dissagree. I think the compiler design class I took was extremely valuable (particularly in embedded work where you need to know how to think like a compiler).

--
Grant Edwards                   grante             Yow!  HOW could a GLASS
                                  at               be YELLING??
 Click to see the full signature
Reply to
Grant Edwards

Yes, but for those who did not have that education, you can always get them to READ the Assembler Code created by the compiler.

The better compilers include the Source code as comments, in an ASM listing, and that ALSO teaches them about assembler - as well as being very focused on the exact compiler they are using.

Then, you can, for example, grab the starting code, and if convinced it is a bottleneck, you can edit the tightest loops, and re-link.

ie projects do not have to be "All C" or "All Assembler".

Probably a good employment question :)

I will say most debuggers could do with a catchup, and support multiple source file types.

-jg

Reply to
Jim Granville

I remember the joys of hand-assembling. My old spectrum had an unreliable tape recorder, so a lot of my (admittedly rather short) assembly programs were written out on paper, hand-assembled, then entered using a small basic loader program. If I made a mistake, it was out with the power cord, and start typing again from scratch. I guess it taught me a lot about safe programming! The typing was a lot easier after I'd replaced the chewing gum keyboard with the keyboard from a broken TI-99/4A.

Reply to
David Brown

You had a keyboard??? You were so lucky. The first computer I programmed had a row of switches on the front panel that you used to enter code one word at a time. Took ages.

Ian

Reply to
Ian Bell

I think we could probably agree that all data should have its scope as limited as practically possible. And we can agree that global variables should be used with care. However, (small system) embedded programming requires a rather different balance between data abstraction and encapsulation and efficient implementation than is common in "big system" programming. Thus global variables are very much part of the toolkit of an embedded programmer.

That depends entirely on the situation. But I'd agree fully that readability is paramount.

There are plenty of other cases where "traditional" C programming would recommend passing a pointer, while efficient embedded programming could be better served with global data. Buffers, arrays, and strings are often candidates, especially if it avoids use of dynamic memory. Of course, it requires that the programmer knows how the global data is being accessed in every situation - writing tight embedded code requires more thought (or at least a different kind of thinking) than big system programming.

I'd disagree on that without the rest of the context (actual names of functions, parameters, and global data, along with any comments or other context). But again I'd agree that readability is vital.

They'll be worse with an 8051 in the sense of "abysmal" being worse than "horrendous". Neither is terribly impressive.

In the hands of a trained or experienced embedded C programmer (or a particularly open-minded, flexible and quick-learning PC-style programmer), the AVR is very nice for an 8-bit device. There's a fair amount that could have been done better (from the point of view of an assembly/C programmer - I don't know so much about the point of view of an ASIC manufacturer), but it's pretty good.

Reply to
David Brown

Life would be boring if it were all the same...

This is one of the reasons I find it amusing when people refer to C as "portable". For every C target-compiler combination you start using, you need to first run some tests and look at the generated assembly code (having first learned the assembly for the architecture, of course) and learn what sort of C code generates good object code. It gets less important for big micros, or for non-vital code, but for small micros it can make a huge difference.

Reply to
David Brown

The "obvious" way to write C code on an AVR is completely different from the "obvious" way to write C code on a PC. There is so little similarity that they might as well be different languages. There is a small overlap when you are doing things like kernel programming or device driver programming, but that's all. In fact, that's about the only time there is an overlap in the choice of language - C is seldom the right choice for programming on a PC (even under *nix), and is seldom taught as a PC programming language.

It's true that some "standard" C techniques, like using local variables whenever possible, work well on the AVR but badly on the 8051. But other standard techniques, like making everything an "int", instead of an "uint_8", generate terrible code on both the AVR and the 8051. Just because it would be worse on the 8051 does not make the AVR good!

Rubbish.

Complete rubbish.

People who learn programming at university learn, by and large, application programming. They would mostly be far happier with Visual Basic, or PHP than embedded C. Compiler writing, especially for anything half-way realistic rather than a mere demonstration, is a much more advanced skill than the majority of university-educated programmers would have in their training.

Reply to
David Brown

That's not really a great argument - it would be simple enough to drop a single register (say, r0) and make that refer to "direct memory" with the address given in the next instruction word. That would also have simplified a number of instructions - for example, the "LDS Rd, k" instruction would now be implemented simply "MOV Rd, R0, k".

If you want to argue that this would make a larger core, or increase the critical path lengths of the decoder, or cause problems for the pipelining logic (a more common reason for RISC architectures' omission of direct memory access instructions), that's fine. But there would have been no problem doing a little re-arranging of the opcode space to fit the addressing mode in.

Reply to
David Brown

While I agree with this in most cases, I might point out that I personally have a maths and theoretical computing degree. We were never really taught any programming languages, although we covered a few formal languages. For the most part, we only used computers to write up reports - programs were written on paper, and there was no need to test them since we had proved they were correct. Train the mind correctly, and it will pick up the details of programming languages (or electronics design, for that matter) easily enough. But given the choice of "most electronics graduates" or "most IT graduates", I'd certainly want the former - it's a matter of training in the attention to detail, and careful design and forethought, rather than a "through something together and see if it works - if not, add some more RAM" attitude.

Reply to
David Brown

Just to comment on your specific example, I have not found that I needed to bother with this on the AVR, whereas I did on the 8051. In fact for some programs I went back and converted my uint8_t into unsigned. C tends to promote chars to ints anyway, when you use them in arithmetic. So the code size does not change much. If the variables are static then it is true that you do lose a byte of RAM each time, which might be an issue on the smaller chips.

--

John Devereux
Reply to
John Devereux

Personally I think this is all part of a huge conspiracy to keep armies of programmers and silicon designers employed. Fast efficient programming techniques are sacrificed to the OO, C++, and Java gods of Bloat so we need ever faster processors to run the polymorphic, information free, multiply inherited code to achieve only the same functions of previous version of the application.

Ian

Reply to
Ian Bell

I just love a language that 'tends' to do things. Perhaps that's why windows 'tends' to crash?

Ian

Reply to
Ian Bell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.