uC lifetime
in [Embedded]
|
From: -jg on 13 Dec 2009 18:03 On Dec 14, 11:51 am, Jon Kirwan <j...(a)infinitefactors.org> wrote: > On Sun, 13 Dec 2009 14:41:34 -0800 (PST), -jg > > <jim.granvi...(a)gmail.com> wrote: > > > The ARM7TDMI is moving into NFND territory, as it > >is eclipsed by M3 and M0 cores. > > NXPs newest development tools underline this. > > NXP have largely pin-compatible migration pathways, > >but that does not mean the change will be painless. > > I'm out of date, then!! > > Thanks! More info is here: http://www.standardics.nxp.com/lpcxpresso/ I see Digikey now show two LPCxpresso part codes, the M3 LPC1343 at sub$30, and the M0 LPC1114 at Sub$23! I see the M0 claims a jitter free interrupt system. -jg
From: linnix on 13 Dec 2009 18:40 On Dec 13, 2:49 pm, Jon Kirwan <j...(a)infinitefactors.org> wrote: > On Sun, 13 Dec 2009 15:41:44 -0600, Vladimir Vassilevsky > > <nos...(a)nowhere.com> wrote: > >linnix wrote: > > >> On the other hand, my complaint with Atmel is that they are not moving > >> fast enough with AVR. > > >Being burned several times with obsoleteness of Atmel AVRs and flash > >memory chips (no replacement offered), I'd rather unrecommend Atmel. > > Completely agree. An other vote there. > > Jon We can't completely out of AVR yet. But we are working on it. First step is to phase out the high end AVR and replace it with a low end AVR and a custom demux chip for I/O. The customer wants AVR arch and we just can't change it totally. AVR is the case of a fine technical arch screwed over by Atmel managers.
From: Theo Markettos on 13 Dec 2009 19:38 Jon Kirwan <jonk(a)infinitefactors.org> wrote: > By comparison, I have a similar circumstance with Analog Devices, > using an old tool I also bought around 1991 for their ADSP-21xx line. > I was told that the tool was no longer supported, that I couldn't get > replacements, and that they couldn't help me with problems except to > suggest a couple of places where I visit their web pages. That's it. > The support staff was 'sorry' about it, but helpless. One useful precaution for this may be to grab any open source tools you can find, with all the documentation, and save them away for later. Then if you have a problem and your commercial compiler won't work on Windows 13, you still have the open source tools as a backup. It might not be pretty and you might have to spend a day recompiling them, but it might get you out of a pickle when the existing toolchain has bitrotted away. Alternatively install and test tools on a virtual OS, then file away the OS disc image for later so you can boot it in an emulator straight off, instead of having to worry about how you arrange the future equivalent of finding Windows 2.1 on 5.25" floppies. Theo
From: Jon Kirwan on 13 Dec 2009 20:13 On 14 Dec 2009 00:38:46 +0000 (GMT), Theo Markettos <theom+news(a)chiark.greenend.org.uk> wrote: >Jon Kirwan <jonk(a)infinitefactors.org> wrote: >> By comparison, I have a similar circumstance with Analog Devices, >> using an old tool I also bought around 1991 for their ADSP-21xx line. >> I was told that the tool was no longer supported, that I couldn't get >> replacements, and that they couldn't help me with problems except to >> suggest a couple of places where I visit their web pages. That's it. >> The support staff was 'sorry' about it, but helpless. > >One useful precaution for this may be to grab any open source tools you can >find, with all the documentation, and save them away for later. Then if you >have a problem and your commercial compiler won't work on Windows 13, you >still have the open source tools as a backup. It might not be pretty and >you might have to spend a day recompiling them, but it might get you out of >a pickle when the existing toolchain has bitrotted away. > >Alternatively install and test tools on a virtual OS, then file away the OS >disc image for later so you can boot it in an emulator straight off, instead >of having to worry about how you arrange the future equivalent of finding >Windows 2.1 on 5.25" floppies. You should see my office area. I've got 80386 machines with 8-bit and 16-bit ISA buses, that still run. I stopped using Windows after XP and can't see how I will ever proceed beyond that. I still install and use Win98SE, quite often. Boxes of full-product DOS 5.0 systems here, as well. And I use them. I have MPLAB installation files that Microchip no longer makes available -- and they still make a lot of them available. I have every revision of compiler tool I ever use, kept on several types of media. I still have a functioning Lattice C compiler toolset and I use it for a product that is STILL selling to this very day. Doesn't change any of my experience with Analog. In this case, it was an important hardware device I needed to use that was no longer supported. Not software. It ceased to function. Luckily, I had ONE more of them. ONE! But I got lucky. It might have turned the other way, though. They retire old DSPs (for example, I started using the ADSP-2111 when it was still just sampling and I watched as it became "unavailable.") And their new tools will not support some older devices. Anyway, it's a different world with Microchip. I've never even been scared, let alone truly jeopardized. They really know what it takes out in the field. Of course, their PIC10/PIC12/PIC14/PIC16/PIC17 families are bare-metal ALUs and some of their peripherals could use some sprucing. But that doesn't rank even 10th on my top list of concerns. It's so low down that I can't recall it noticing it as a concern to weigh amongst others. It's off the radar scope. Which brings up another thought. Silicon bugs. Unlike, for example, Texas Instruments which for all I can tell _never_ fixes any, Microchip keeps a long laundry list of them and actually _works_ at correcting them over time. Take a look at the A3 silicon errata for their PIC18F2525 part and compare it with the B5 stepping's errata, for example. They seriously work to repair errata in future steppings. Basically, they work hard for us. Really, really hard. And it shows like gang-busters. Jon
From: Vladimir Vassilevsky on 14 Dec 2009 00:24
linnix wrote: > AVR is the case of a fine technical arch screwed over by Atmel > managers. AVR is about 3 times faster then PIC18, and AVR core is nearly perfect for C programming. There is a class of problems (like small control systems, modems, encoders/decoders, etc.) for which the AVR is suited well, but, as you said, the stupid practices made Atmel an unreliable vendor. VLV |