> David Brown wrote:
>> Jim Granville wrote:
>>
>>> ziggy wrote:
>>>
>>>> Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>>>>
>>>>> I would add that 8051 cores are available from such a wide variety of
>>>>> sources, too. They are quite modern, in many of these incarnations.
>>>>> Even Atmel has them, if that is one of the reasons ziggy is
>>>>> considering a change towards AVR.
>>>>>
>>>>> If you already have excellent development tools for the 8051 family,
>>>>> part of the cost of shifting will be both the new costs for equipment
>>>>> as well as the learning curve and possibly for developing software
>>>>> that may be needed to fill in the gaps. The change takes time and
>>>>> money and always adds risk.
>>>>>
>>>>> For merely a "concern of 'falling behind' a bit" I don't think I'd
>>>>> change.
>>>>>
>>>>> Or is this about getting ready for a job move?
>>>>>
>>>>> Jon
>>>>
>>>>
>>>>
>>>> Nah, no job change in the near future, just was getting concerned
>>>> about the '51 getting long in the tooth..
>>>>
>>>> But the way it looks, i might as well stick with what i know and be
>>>> happy :)
>>>
>>>
>>> As a good example of just how cutting edge 80C51's are :
>>>
>>> SiLabs have now released the C8051F410, which is an advanced 0.25u
>>> process 80C51, with on chip regulators - so you get the Low power
>>> of a MSP430, with faster core (50MHz), and 5V capable IOs.
>>>
>>> This advanced process means they can get 32KF/2.3KRam in a tiny 5mm
>>> MLF package.
>>>
>>> MUCH higher analog performance than the AVR (or MSP430) - 24 Channel
>>> 12 bit ADC & iDAC, _and_ Silabs will put numbers in the MAX column.
>>>
>>> On chip regulators also allows 5V drive without the cost of
>>> high Icc, and RFI, and gives a definable speed for battery use.
>>> PR says from $2.56/10K,
>>>
>>> -jg
>>>
>>
>> This is not an example of how "cutting edge" 8051's can be - there is
>> nothing "cutting edge" about the 8051 core. This is an example of a
>> company that makes very good analogue components, on small fast chips,
>> and they felt (correctly) that the device would be much more flexible
>> with a cpu core on board. So they picked one for which there are
>> tools available, with which a lot of people are familiar, and which is
>> relatively small and easy to put in the device. The qualities (or
>> lack thereof) of the core architecture itself are not of significant
>> interest in choosing a core for such a chip.
>>
>> You see the same thing in many such devices - powerful analogue,
>> wireless, or USB devices, with a microcontroller core
>> copied-and-pasted into the middle as an extra to give you a complete
>> solution. Atmel often choose the AVR for such devices - for others,
>> the 8051 is often the cheapest and most convenient solution.
>
> Hmm.. OK, for those that might confuse the implementation, and the core,
> I'll rephrase this very carefully, as
> "A good example of just how cutting edge a modern microcontroller that
> uses the widely supported and multisourced 80C51 core can be."
>
That's a rather different statement, and is perfectly true.
> The OP was concerned that the available 80C51's were "falling behind".
>
> -jg
>
This thread (admittedly on a different branch) had long degenerated into
a discussion of the merits (in particular, the C-friendliness or lack
thereof) of the 8051 as a CPU core architecture, compared to other small
cores, which was why I made the distinction between cutting-edge chips
that use the 8051, rather than the 8051 being cutting-edge itself.
Like programming in C, or the x86 architecture, or running MS Windows,
the 8051 core is widely used because it is widely used, rather than for
any technical superiorities. But since since technical merits are never
more than a small part of decision making, I guess it will be around for
a while yet.
Reply by Jim Granville●March 7, 20062006-03-07
David Brown wrote:
> Jim Granville wrote:
>
>> ziggy wrote:
>>
>>> Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>>>
>>>> I would add that 8051 cores are available from such a wide variety of
>>>> sources, too. They are quite modern, in many of these incarnations.
>>>> Even Atmel has them, if that is one of the reasons ziggy is
>>>> considering a change towards AVR.
>>>>
>>>> If you already have excellent development tools for the 8051 family,
>>>> part of the cost of shifting will be both the new costs for equipment
>>>> as well as the learning curve and possibly for developing software
>>>> that may be needed to fill in the gaps. The change takes time and
>>>> money and always adds risk.
>>>>
>>>> For merely a "concern of 'falling behind' a bit" I don't think I'd
>>>> change.
>>>>
>>>> Or is this about getting ready for a job move?
>>>>
>>>> Jon
>>>
>>>
>>>
>>> Nah, no job change in the near future, just was getting concerned
>>> about the '51 getting long in the tooth..
>>>
>>> But the way it looks, i might as well stick with what i know and be
>>> happy :)
>>
>>
>> As a good example of just how cutting edge 80C51's are :
>>
>> SiLabs have now released the C8051F410, which is an advanced 0.25u
>> process 80C51, with on chip regulators - so you get the Low power
>> of a MSP430, with faster core (50MHz), and 5V capable IOs.
>>
>> This advanced process means they can get 32KF/2.3KRam in a tiny 5mm
>> MLF package.
>>
>> MUCH higher analog performance than the AVR (or MSP430) - 24 Channel
>> 12 bit ADC & iDAC, _and_ Silabs will put numbers in the MAX column.
>>
>> On chip regulators also allows 5V drive without the cost of
>> high Icc, and RFI, and gives a definable speed for battery use.
>> PR says from $2.56/10K,
>>
>> -jg
>>
>
> This is not an example of how "cutting edge" 8051's can be - there is
> nothing "cutting edge" about the 8051 core. This is an example of a
> company that makes very good analogue components, on small fast chips,
> and they felt (correctly) that the device would be much more flexible
> with a cpu core on board. So they picked one for which there are tools
> available, with which a lot of people are familiar, and which is
> relatively small and easy to put in the device. The qualities (or lack
> thereof) of the core architecture itself are not of significant interest
> in choosing a core for such a chip.
>
> You see the same thing in many such devices - powerful analogue,
> wireless, or USB devices, with a microcontroller core copied-and-pasted
> into the middle as an extra to give you a complete solution. Atmel
> often choose the AVR for such devices - for others, the 8051 is often
> the cheapest and most convenient solution.
Hmm.. OK, for those that might confuse the implementation, and the core,
I'll rephrase this very carefully, as
"A good example of just how cutting edge a modern microcontroller that
uses the widely supported and multisourced 80C51 core can be."
The OP was concerned that the available 80C51's were "falling behind".
-jg
Reply by David Brown●March 7, 20062006-03-07
Jim Granville wrote:
> ziggy wrote:
>
>> Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>>> I would add that 8051 cores are available from such a wide variety of
>>> sources, too. They are quite modern, in many of these incarnations.
>>> Even Atmel has them, if that is one of the reasons ziggy is
>>> considering a change towards AVR.
>>>
>>> If you already have excellent development tools for the 8051 family,
>>> part of the cost of shifting will be both the new costs for equipment
>>> as well as the learning curve and possibly for developing software
>>> that may be needed to fill in the gaps. The change takes time and
>>> money and always adds risk.
>>>
>>> For merely a "concern of 'falling behind' a bit" I don't think I'd
>>> change.
>>>
>>> Or is this about getting ready for a job move?
>>>
>>> Jon
>>
>>
>> Nah, no job change in the near future, just was getting concerned
>> about the '51 getting long in the tooth..
>>
>> But the way it looks, i might as well stick with what i know and be
>> happy :)
>
> As a good example of just how cutting edge 80C51's are :
>
> SiLabs have now released the C8051F410, which is an advanced 0.25u
> process 80C51, with on chip regulators - so you get the Low power
> of a MSP430, with faster core (50MHz), and 5V capable IOs.
>
> This advanced process means they can get 32KF/2.3KRam in a tiny 5mm MLF
> package.
>
> MUCH higher analog performance than the AVR (or MSP430) - 24 Channel 12
> bit ADC & iDAC, _and_ Silabs will put numbers in the MAX column.
>
> On chip regulators also allows 5V drive without the cost of
> high Icc, and RFI, and gives a definable speed for battery use.
> PR says from $2.56/10K,
>
> -jg
>
This is not an example of how "cutting edge" 8051's can be - there is
nothing "cutting edge" about the 8051 core. This is an example of a
company that makes very good analogue components, on small fast chips,
and they felt (correctly) that the device would be much more flexible
with a cpu core on board. So they picked one for which there are tools
available, with which a lot of people are familiar, and which is
relatively small and easy to put in the device. The qualities (or lack
thereof) of the core architecture itself are not of significant interest
in choosing a core for such a chip.
You see the same thing in many such devices - powerful analogue,
wireless, or USB devices, with a microcontroller core copied-and-pasted
into the middle as an extra to give you a complete solution. Atmel
often choose the AVR for such devices - for others, the 8051 is often
the cheapest and most convenient solution.
Reply by Jim Granville●March 6, 20062006-03-06
ziggy wrote:
> Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>>I would add that 8051 cores are available from such a wide variety of
>>sources, too. They are quite modern, in many of these incarnations.
>>Even Atmel has them, if that is one of the reasons ziggy is
>>considering a change towards AVR.
>>
>>If you already have excellent development tools for the 8051 family,
>>part of the cost of shifting will be both the new costs for equipment
>>as well as the learning curve and possibly for developing software
>>that may be needed to fill in the gaps. The change takes time and
>>money and always adds risk.
>>
>>For merely a "concern of 'falling behind' a bit" I don't think I'd
>>change.
>>
>>Or is this about getting ready for a job move?
>>
>>Jon
>
>
> Nah, no job change in the near future, just was getting concerned about
> the '51 getting long in the tooth..
>
> But the way it looks, i might as well stick with what i know and be
> happy :)
As a good example of just how cutting edge 80C51's are :
SiLabs have now released the C8051F410, which is an advanced 0.25u
process 80C51, with on chip regulators - so you get the Low power
of a MSP430, with faster core (50MHz), and 5V capable IOs.
This advanced process means they can get 32KF/2.3KRam in a tiny 5mm
MLF package.
MUCH higher analog performance than the AVR (or MSP430) - 24 Channel
12 bit ADC & iDAC, _and_ Silabs will put numbers in the MAX column.
On chip regulators also allows 5V drive without the cost of
high Icc, and RFI, and gives a definable speed for battery use.
PR says from $2.56/10K,
-jg
Reply by Ian Bell●February 20, 20062006-02-20
Colin Paul Gloster wrote:
> Grant Edwards posted in news:comp.arch.embedded on Thu, 09 Feb 2006
> 15:36:40 -0000:
>
> "I always thought that Modula-2/3 would have been ideal
> languages for embedded systems: much safer than C."
>
> On Fri, 17 Feb 2006, Chris Hills posted in news:comp.arch.embedded :
>
> "In theory but not in practice."
>
> Crossposting to news:comp.lang.modula2 and news:comp.lang.modula3 ...
> I am unaware of Modula-2 or Modula-3 being unsafe for embedded systems in
> practice. Please provide details.
I think perhaps you read too much into the OP. I think he meant it is not
ideal (in practice) rather than it is not safe (in practice). That's how I
read it anyway.
Ian
Ian
Reply by Dave Hansen●February 20, 20062006-02-20
On Sun, 19 Feb 2006 15:16:36 +0000 in comp.arch.embedded, Chris Hills
<chris@phaedsys.org> wrote:
>In article <1140199462.062052.186990@g47g2000cwa.googlegroups.com>,
>larwe <zwsdotcom@gmail.com> writes
>>
>>Chris Hills wrote:
>>
>>> >If you are doing maintenance on an old project, it is essential
>>> >*anyway* to use the original version of the tools. And you can do this
>>> >very easily with gcc.
>>>
>>> Actually it is almost impossible to do with Gcc.
>>
>>Not true.
>
>Explain how then
I don't know about where you work, but where I've worked, company
policy says that everything required to generate the executable image
gets burned on the CD that gets released to Document Control. That
includes a copy of the tool binaries. With gcc, that means zipping up
a single directory tree. When maintenance is required, installing the
old version of gcc requires unzipping the tree.
Trivial.
We've done similar things with commercial compilers, but they tend to
spread required files further afield, and modify the registry under
Windoze. It's generally more difficult, but possible. Sometimes, we
just have to archive the installation disk with network backups
off-site.
And then, there's copy protection.
My current job requires me to use an old version of a well-known
commercial compiler (the latest version is 8.5-something, I'm using
7.01). My employer uses this vendor's tools extensively, and all out
support is paid and up-to-date. I have an original installation CD.
This is a fine tool, but copy protected. Because I'm using an old
version, support had an, um, difficult time generating the required
license key to allow the software to operate on my system. It took
over a week and a dozen attempts before I was running. They worked
hard for me, and got it done, but it was painful for both of us. And
even their support recommended against attempting to port the existing
code to the newer version of the compiler. Fortunately, I wasn't
under any time pressure, or I might not be so complementary.
Not trivial. Possibly very difficult. Maybe even impossible.
Especially if the tool vendor has been assimilated into a larger
company between then and now.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Reply by Grant Edwards●February 20, 20062006-02-20
On 2006-02-19, Chris Hills <chris@phaedsys.org> wrote:
> In article <1140199462.062052.186990@g47g2000cwa.googlegroups.com>,
> larwe <zwsdotcom@gmail.com> writes
>>
>>Chris Hills wrote:
>>
>>> >If you are doing maintenance on an old project, it is essential
>>> >*anyway* to use the original version of the tools. And you can do this
>>> >very easily with gcc.
>>>
>>> Actually it is almost impossible to do with Gcc.
>>
>>Not true.
>
> Explain how then
You want us to explain how to archive a gcc toolset?
I usually use the "tar" command.
--
Grant Edwards grante Yow! Do you need
at any MOUTH-TO-MOUTH
visi.com resuscitation?
Reply by Colin Paul Gloster●February 20, 20062006-02-20
Grant Edwards posted in news:comp.arch.embedded on Thu, 09 Feb 2006
15:36:40 -0000:
"I always thought that Modula-2/3 would have been ideal
languages for embedded systems: much safer than C."
On Fri, 17 Feb 2006, Chris Hills posted in news:comp.arch.embedded :
"In theory but not in practice."
Crossposting to news:comp.lang.modula2 and news:comp.lang.modula3 ...
I am unaware of Modula-2 or Modula-3 being unsafe for embedded systems in
practice. Please provide details.
Reply by Andy Sinclair●February 20, 20062006-02-20
John Devereux wrote:
>You just set the path appropriately (according to which version you
>want to run), in the Makefile. Since this is version controlled along
>with the rest of the source code, the correct compiler gets run
>automatically.
>
>Actually I have been thinking of checking in the binaries of the
>tools, too, along with my own source code. (Has anyone done this with
>svn? Is it too slow?)
I keep gcc binaries under source control, but in a special tools
project. The same tools are used for many projects and this approach
avoids filling the source tree with compilers.
If you do go this route though, it is worth trying your setup on a
machine which hasn't been used for software development. That way you
can be sure the build process isn't relying on something in your
environment. This is especially true for cygwin cross-compilers.
Andy
Reply by John Devereux●February 19, 20062006-02-19
Chris Hills <chris@phaedsys.org> writes:
> In article <877j7t977j.fsf@cordelia.devereux.me.uk>, John Devereux
> <jdREMOVE@THISdevereux.me.uk> writes
>>Chris Hills <chris@phaedsys.org> writes:
>>
>>> In article <873bin9hh2.fsf@cordelia.devereux.me.uk>, John Devereux
>>> <jdREMOVE@THISdevereux.me.uk> writes
>>>>If you are doing maintenance on an old project, it is essential
>>>>*anyway* to use the original version of the tools. And you can do this
>>>>very easily with gcc.
>>>
>>> Actually it is almost impossible to do with Gcc.
>>
>>Impossible? What is the problem? You can just archive and copy the
>>binaries. I do this all the time.
>
>
> As you can do with the commercial version of a compiler. Lots oc
> companies do so what is the difference?
It was *you* that claimed that "it is almost impossible to do with
gcc". I was reacting to that statement, showing that it was in fact
easy to do.
However it is *not* generally that easy with the commercial compilers
I have used (dongle problems etc).
>> E.g for me each version of the
>>> However for most for the commercial compilers I know it is easy to get
>>> EXACTLY the old version you need.
>>
>>I have *got* the old versions. Why would I not? It is *running* them
>>that is the problem!
>
> That is the same for any application.
Not when one class of applications (commercial compilers) are
*deliberately designed* to disable themselves unless they see the
hardware and software environment that they expect. In general a
compiler is one of the most portable programs there is. But commercial
compilers have hardware dependent dongle or license management code
that seems very fragile. I have upgraded a CPU and had the dongle
suddenly not work, because my system is now "too fast" for it.
--
John Devereux