Okay, David and thanks for your input, too.
I will keep your suggestions in mind and may try them out. Keil and
Altium are very expensive.
Joe
On Mon, 27 Dec 2010 09:51:24 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:
>On 26/12/2010 20:39, Chris H wrote:
>> In message<if21md$nc7$1@news.eternal-september.org>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>>> On 2010-12-23, justme<jbleaux@gmail.com> 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.
>>>>
>>>> I don't know what is best or available and accepted today. Could
>>>> someone give me their advice?
>>>>
>>>
>>> I can't help you with the 8051 compiler, but there are open source PCB
>>> packages these days which may be suitable for you. Google for geda and
>>> kicad.
>>>
>
>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.
>
>>> If you follow the ARM recommendations in the other thread, then gcc is
>>> available for ARM
>>
>> SO is Keil.
>>
>
>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.
>
>
Reply by Niklas Holsti●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
. @ .
Reply by Jon Kirwan●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 Chris H●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 Arlet Ottens●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 Chris H●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 Arlet Ottens●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 Hans-Bernhard Bröker●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 David Brown●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 David Brown●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>