The context of the conversation was that I was talking to him about my background and explaining that the one thing I hope to take away from this degree program (which is a sinecure for me, obviously) is a better grasp of analog stuff.
He's in his niche, and oblivious to the world. The worrying thing is that he runs an embedded consulting business!
I do have the sources too, so I could rebuild the binaries for a different architecture as you suggest. And of course they are archived all over the internet. Good point about the shell script. I was really making the point that you do *not* generally have to recompile everything in order to "switch" to an older compiler. Also that multiple versions can happily co-exist, and it is trivial to switch between them.
Of course this was in the context of a comparison with commercial compilers. I very much doubt that, with these, there is any option *at all* other than IA32 :)
-- John Devereux
Except that with current silicon densities, the cost of the silicon in low pin count devices significantly affected by the size of the bonding pads and the cost of packaging. In such devices, the ARM costs not more to make than the AVR.
Ian
When you are pad limited, you have space to waste. Smaller busses still means more memory at the same cost. ARMs typically have more aggressive technologies, and this makes them attractive in higher densities/(higher pincounts. Yet to see competitive pricing for low end ARMs in the major AVR projects I am working with.
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Best comment of the day!
There's torture and then there's torture...
Of course, programming Intell 8200-series peripheral chips is almost as bad as the 8051.
In article , larwe writes
Explain how then
that is true if you want them to supply an old version to you. (assuming you have lost the old version you had.
No so. #I have found it to work for anyone with most of the embedded compiler companies.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
As you can do with the commercial version of a compiler. Lots oc companies do so what is the difference?
That is the same for any application.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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).
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
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
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.
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?
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.
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
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
That's a rather different statement, and is perfectly true.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.