On Mon, 27 Dec 2010 19:55:45 +0000, Chris H wrote:>>> >> > Getting back into uc after a long Sabbatical. When I ventured >>> >> > into other things, Keil C compiler/assember was the standard 8051 >>> >> > varient s.w. Also, Protel was a very viable printed circuit board >>> >> > layout package. >>> >>> >Intel, along with others, stopped making 8051. >>> >>> However there are some 40+ manufactures producing some 600 odd 8051 >>> variants. The 8051 is still the most common MCU on the planet (and >>> in good numbers off the planet as there are several rad hardened 8051 >>> MCU's about >>> >>> >>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. > > I used C on the 8051.... no point in using assembler when the Keil C > gives better code density and performance.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.
DE FACTO STANDARD 8051 C COMPILER AND PCB LAYOUT S.W.?
Started by ●December 23, 2010
Reply by ●December 28, 20102010-12-28
Reply by ●December 28, 20102010-12-28
On 28/12/2010 03:15, justme wrote:> 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. >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. <http://idallen.com/topposting.html> <http://www.caliburn.nl/topposting.html> <http://en.wikipedia.org/wiki/Posting_style>
Reply by ●December 28, 20102010-12-28
On 28/12/2010 03:18, justme wrote:> 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. >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.
Reply by ●December 28, 20102010-12-28
On 28.12.2010 08:55, Arlet Ottens wrote:> 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,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.> are a regular source of problems. In addition, the 8051 is slow,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 memory is full.And the length of the piece of string is exhausted. Sure.
Reply by ●December 28, 20102010-12-28
On Tue, 28 Dec 2010 13:24:03 +0100, Hans-Bernhard Bröker wrote:>> 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, > > 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.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.
Reply by ●December 28, 20102010-12-28
In message <ifcksp$rsd$02$1@news.t-online.com>, Hans-Bernhard Br�ker <HBBroeker@t-online.de> writes>On 28.12.2010 08:55, Arlet Ottens wrote: > >> 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, > >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.Actually several mega bytes of linear code and data...>> are a regular source of problems. In addition, the 8051 is slow, > >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.Agreed. Also slow for what? Not everything needs a 32bit high speed part of PICs would have disappeared years ago.>> and the memory is full. > >And the length of the piece of string is exhausted. Sure.:-) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●December 28, 20102010-12-28
On Tue, 28 Dec 2010 14:09:09 +0000, Chris H wrote:>>> are a regular source of problems. In addition, the 8051 is slow, >> >>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. > > Agreed. Also slow for what? Not everything needs a 32bit high speed part > of PICs would have disappeared years ago.The fact that not everything needs high performance, doesn't mean the 8051 isn't slow.
Reply by ●December 28, 20102010-12-28
In message <4d19f6bc$0$81476$e4fe514c@news.xs4all.nl>, Arlet Ottens <usenet+5@c-scape.nl> writes>On Tue, 28 Dec 2010 14:09:09 +0000, Chris H wrote: > >>>> are a regular source of problems. In addition, the 8051 is slow, >>> >>>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. >> >> Agreed. Also slow for what? Not everything needs a 32bit high speed part >> of PICs would have disappeared years ago. > >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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●December 28, 20102010-12-28
On 28 Dec 2010 14:39:56 GMT, Arlet Ottens <usenet+5@c-scape.nl> wrote:>On Tue, 28 Dec 2010 14:09:09 +0000, Chris H wrote: > >>>> are a regular source of problems. In addition, the 8051 is slow, >>> >>>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. >> >> Agreed. Also slow for what? Not everything needs a 32bit high speed part >> of PICs would have disappeared years ago. > >The fact that not everything needs high performance, doesn't mean the >8051 isn't slow.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
Reply by ●December 28, 20102010-12-28
Jon Kirwan wrote:> 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.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 . @ .
