DE FACTO STANDARD 8051 C COMPILER AND PCB LAYOUT S.W.?

Gosh, Linnix, have I confused you with Larwe?

I beg your pardon.

Joe

geda (and friends) is powerful, but harder to learn and work with. There are people using it even for very large multi-layer designs, but it is seldom used by professionals if their budget allows for tools like Altium. It is also most "at home" on Linux, though I believe it can be used on Windows (I don't know your preferences here).

Kicad is a more integrated and light-weight suite, that is easy to learn. It is suitable for smaller designs, and is cross-platform.

I don't know what low or medium budget packages are popular at the moment, if you are wanting something more than Kicad gives you but don't want to buy Altium. Perhaps Pulsonix is worth a look.

And so are a range of other compilers - from free gcc, paid-and-supported gcc, through low-cost tools like ImageCraft, and up to the expensive toolchains like Keil (ARM) and IAR.

in

Yes, if you are maintaining apps in assembler, for small devices. However, for large memory spaces and in C, it doesn't make sense to start new projects with 8051. There are plenty of devices supported by gcc, other than 8051. Even if you are not using gcc, you know that they are better suited for C.

I used C on the 8051.... no point in using assembler when the Keil C gives better code density and performance.

Gcc does not support the 8051 and what gcc supports is irrelevant.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Thanks, David. Well, I would like to get Altium and Keil if I can afford them. I have used both before. However, Altium was Protel then.

Tools are surely expensive today.

Dare I say it but, I am looking at the ARM xxxx1768. A lot of folks suggested ARM and at that time, I wanted to stay with 8051 cored micros. However, after a brief scan of the features of the ARM, I am going to take a more in-depth look at it.

Can anyone recommend a/some great books on the ARM micros?

Thanks all.

Joe

Also, any suggestions on ARM groups?

Joe

Thanks, D. I will be using it for business - eventually.

What micro/s are you using?

Joe

Sorry, David. However, I always top post. It makes more sense to a lot of folks. Note, I didn't say everyone. Some like seafood, some don't.

Joe

From the input that I am getting from folks kind enough to tell me of their preferences, it looks like Altium is the way to go. I used to use Protel before the Altium name.

Joe

The point is that for new (and/or large) projects, written in C, it makes no sense to pick a 8051 core.

I have the honor of maintaining a 30000+ line C program, running on a

8051, using the Keil C compiler. It's not fun. The poor Keil compiler takes about 4 minutes to recompile the whole tree. The limitations of the 8051, including switching 8 banks, are a regular source of problems. In addition, the 8051 is slow, and the memory is full.

My goal is to move this project to an ARM core. 90% of the project can be ported in an hour, and the rest will take a day or so. Besides getting rid of all the 8051 quirks and limitations, the whole project will then compile in a matter of seconds.

I know I promised not to mention it again, but I can't help myself...

There are situations where top posting is the norm (for good or for bad), and thus it makes sense to top-post. In this newsgroup, top-post is /not/ the standard - just look at how few others here top-post. And even if /you/, for some unfathomable reason, think top-posting suits /you/ better, it still doesn't matter. This group is not about /you/, or /your/ preferences. When you join a community and look for help, you should fit in with the norms of that community.

Rather than trying to detail all the arguments against top-posting, I'm going to give you a few links (top hits from google). Please read them and try to understand them.

If, having read /why/ people in groups like this dislike top-posting, you still think your desire to top-post overrules the group standard, then please continue to top-post. But at least then we know you have made an informed, rational decision to snub the group and make it harder for people to help you.

If your budget stretches that far, Altium is certainly one of the best EDA tools available. But beware that it has grown enormously since the Protel days - it is a much bigger and more demanding program, and can quickly be overwhelming due to its huge number of features. Make sure you have a powerful computer, plenty of screen real-estate, and plenty of time before you start.

That's no limitation of the 8051. In general a 8051 doesn't even know banking exists. The limitation, if any, can only exist in your board, or in the software toolchain. There are derivates that support several megabytes of banked memory each for code and xdata, and the Keil tools support that.

Not particularly. Not these days, if you pick a derivate for speed instead of 100% pin-for-pin plug-in compatibility with an existing design.

And the length of the piece of string is exhausted. Sure.

Sure, part of the limitations are due to the 8051 part that was used in this particular design.

But that doesn't change much. All the pin compatible parts have the same problems, and if I'm going to redesign the board anyway, there's no good reason to keep the 8051 core in there.

Actually several mega bytes of linear code and data...

Agreed. Also slow for what? Not everything needs a 32bit high speed part of PICs would have disappeared years ago.

:-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

The fact that not everything needs high performance, doesn't mean the

8051 isn't slow.

Only when compared to something faster.... When compared to some thing slower it is faster.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

One of the areas where the 8051 really sucks is in performing things like memcpy() when DPTR is needed. You set up DPTR from somewhere, read a byte and increment, save the DPTR, load DPTR from somewhere else, write a byte and increment, save the DPTR, and loop on some counter. The actual transfer is a tiny bit of the loop time.

Agreed that a great many better choices exist if that's common in your application. Even amongst 8 bit cpus.

Jon

True, the standard vanilla 8051 has only one DPTR. The memcpy() implementations that I've seen for this architecture reduce the problem by reading a number of bytes from the destination area into an equal number of registers, before swapping the DPTR value and writing the bytes to the destination area.

Many "8051" implementations today are extended to have two or more DPTR registers, which eliminates the problem.

But in general I agree that the 8051 architecture is awkward and that there are nicer processors.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .