Microcontroller Project

In article , David L. Jones wrote: [....]

Lots of people eat tripe too. C isn't a very nice language at the best of times. The ones for 8051s have to have all kinds of funny tricks in them to make them work well.

The program doesn't need to be strange, it just needs to nest fairly deep, include an interrupt or two and need a fair amount of variable space. The Keil compiler-linker pair actually overlays the allocations for noninterrupt code. Interrupt code can't be overlayed and hence uses up a chunk of memory.

If you are new to the 8051, it is best to not do interrupt code for the first few tries.

If he doesn't have something like that, I suggest he get the Cygnal kit. for about $100US you get everything you need. (except for the PC that is)

In article , Keith wrote: [....]

I guess you're calling me insane then...... but then you go on to say:

I've had to agrue with "programmers" who write code on PCs. They don't seem to understand that a 32 bit fixed point number won't fit into a 32 bit float. Trouble shooting math in an 8051 is a lot easier than in a CPLD.

of

level

It

The argument was (and is) going nowhere.

Your choice, and that's fine. I'd rather halve my development time than save a few bytes of RAM. A heck of a lot of poeple will use C on micros because it provides many advantages.

Assembler is NOT required for a microcontroller. Thousands of embedded engineers who use C almost exclusively will tell you the same thing.

If you cannot see how C can potentially offer the improvements I have listed (plus many others), then you are either not familiar enough with it to comment, or you simply don't know much about real practical embedded programming meeting tight deadlines and providing maintainable and peer reviewable code, or you are simply one of those stuck-in-your-ways assembler guys. I suspect the later, it's a relatively common affliction.

LOTS of embedded engineers use C on 8 bit micros and there ARE very good reasons for it as I've listed. That might not be the case for you and your situtation, and that's understandable. Just don't try and push that one-sided view on others who are able to gain these big advantages.

I've listed many advantages. I didn't just make these up, they are well known advantages of using a high level language on embdedd micros.

I don't know about you, but every project I've ever worked on is maybe

Dave :)

Compiled code is usually a bit *better* at RAM usage because the compiler very agressively overlays automatic variables in functions. Of course that doesn't help you with statics and globals.

OTOH, examples that show C being similar to assembly in code memory usage and performance are usually contrived or do things that C does rather well (eg. a TCP/IP stack).

Best regards, Spehro Pefhany

Good luck with automatic variables in an 8051. Remember, you only have 128 bytes and about half of that taken for other purposes. It's been a few years since I used an 8051, but I don't recall any sort of stack frame either. Being this limited I simply can't see how C is going to save much of anything.

I don't think I'd care to do a TCP/IP stack in an 8051 either. ;-)

Now you're thinking like a PC programmer. When you don't have re-entrant code (a rather typical, and acceptable, limitation for

It's possible, but an ARM makes a lot more sense IMO.

Best regards, Spehro Pefhany

How do automatic variables differ from static then?

Or a PowerPC. ;-)

Sorry, I meant floats.

There's a Wally in every group.

Sure, because the basic instructions are guaranteed to work, unless you're programming on a Pentium. Once you have the building blocks in a CPLD the differences shouldn't be too big. Debugging a microprocessor efficiently requires some sort of an ICE, a CPLD (or FPGA) a simulator. Different tools, similar process.

If you're looking at the emitted code, they don't (much). They're not in the data area initialized by the startup code because they're not "C" statics, but they are statically allocated.

But the compiler builds a call tree and overlays whichever variables it can (given that each variable only has scope within the given subroutine), so that RAM usage is minimized.

Eg. main routine calls function A (which calls D) and function B.

There have to be unique variable locations for each variable in (A and D) OR B. So if the automatic variables in A require 10 bytes and D requires 3 bytes and B requires

In article , Keith wrote: [....]

If the code doesn't recur, the overlay method works ok. Its interrupts and recuring code that really makes it big trouble.

You can do stuff like:

mov A,SP add A,#(0-something) mov R0,A mov A,@R0

I don't see why not. You'd have to have external RAM anyway so you can have a micro with 128 registers and 512K of RAM. That would be room enough.

In article , Keith wrote: [....]

I usually find it is faster to route out the signals on a real CPLD and program the part than it is to trouble shoot things with a simulator.

The tools take a huge amount of time to actually run and most of the problems turn out to be mistakes in the "test bench". Only when things get too busy to run out to spare pins does the simulation route seem to save anything.

Easier still is just not to put the bugs in, in the first place. That saves way more time. I usually end up with more lines of comments than lines of code. Writing down what I'm trying to do seems to help.