Migrating from PIC18 to ARM: which MCU to choose?
in [Embedded]
|
From: Rich Webb on 30 Jul 2010 07:56 On Wed, 28 Jul 2010 11:49:50 +0930, "Chris Burrows" <cfbsoftware(a)hotmail.com> wrote: >"Rich Webb" <bbew.ar(a)mapson.nozirev.ten> wrote in message >news:gvvu46h5vre7kt0459iokgi49tqhs17b11(a)4ax.com... >> On Tue, 27 Jul 2010 16:52:06 -0700 (PDT), Leon <leon355(a)btinternet.com> >> wrote: >> >>>Rowley CrossWorks is very good, with good support. I've been using >>>their ARM and MSP430 tools for years. Their new ARM JTAG is nice, as >>>well. >> >> May I ask a couple of questions regarding their ARM compiler? (I suppose >> their support forum may be a better venue but usenet still gets wider >> distribution.) >> > >If I were you I'd contact Rowley directly by email regarding pre-sales >support. It's always a good test of how good their support is going to be >*after* they have got your money. However, from everything I've heard about >the quality of their support I don't think you will be disappointed. I know >that in our case we are more than happy to answer these sorts of questions >from prospective customers. I'm less interested, at this point, in the answer from Tech Support (which should be, more or less, what's stated in the FAQ or else there are larger problems) that in the experience and opinions from someone who has been using their ARM tools. I can't remember the last time that I did a non-trivial embedded project that didn't use a few interrupts and I'd be interested in hearing from experienced ARM CrossWorks users how easy (or cumbersome) it is to roll, for example, a standard NXP VIC IRQ or an IRQ with a Must Happen *NOW* FIQ layered on top of it, under the CTL and bare metal. -- Rich Webb Norfolk, VA
From: Albert van der Horst on 1 Aug 2010 09:52 In article <Goqdnd3Pxfv_BczRnZ2dnUVZ_vudnZ2d(a)giganews.com>, vinnie <ckgrier2(a)n_o_s_p_a_m.mailcan.com> wrote: >>We have a product based around the PIC18F6680 which is now becoming a >>rare and expensive part. Since it looks like ARM devices are winning >>the popularity war, the chips are cheap and plentiful. The question >>is, with so many vendors and parts to choose from which one should we >>go with? The main requirements for this application, in order of >>importance, are: >> > >For most selection, lowest cost, and free optimizing compilers and IDE: >look at Renesas R8C. Over 1000 variations of the R8C core, with many CAN, >VEEPROM, and small package choices. Some even have DTC (DMA), D/A, and >comparators. Not to forget a smooth upgrade path to 16 and 32 bits. > >http://www.renesas.com/products/mpumcu/r8c/r8c3x/r8c3x_landing.jsp > >It isn't ARM IP, but with a free optimizing compiler (and GCC support too) >you may want to request a quote to see how much money you save. The German Forth users have done some Forth with it too. I have done some Forth with 16 bits Renesas (trying R32C now). > >--Vinnie > >--------------------------------------- >Posted through http://www.EmbeddedRelated.com Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
From: Albert van der Horst on 1 Aug 2010 10:14 In article <epSR8dBOIrUMFArE(a)phaedsys.demon.co.uk>, Chris H <chris(a)phaedsys.org> wrote: >In message <Goqdnd3Pxfv_BczRnZ2dnUVZ_vudnZ2d(a)giganews.com>, vinnie ><ckgrier2(a)n_o_s_p_a_m.mailcan.com> writes >>>We have a product based around the PIC18F6680 which is now becoming a >>>rare and expensive part. Since it looks like ARM devices are winning >>>the popularity war, the chips are cheap and plentiful. The question >>>is, with so many vendors and parts to choose from which one should we >>>go with? The main requirements for this application, in order of >>>importance, are: >>> >> >>For most selection, lowest cost, and free optimizing compilers and IDE: >>look at Renesas R8C. Over 1000 variations of the R8C core, with many CAN, >>VEEPROM, and small package choices. Some even have DTC (DMA), D/A, and >>comparators. >> >>http://www.renesas.com/products/mpumcu/r8c/r8c3x/r8c3x_landing.jsp >> >>It isn't ARM IP, but with a free optimizing compiler (and GCC support too) >>you may want to request a quote to see how much money you save. > >To quote PJ Paluger " I can't afford to use free tools" > >Just because the tools a "free" does not mean you will save any money. >And just because they are expensive it does not mean they will solve >every problem. Free as in "free beer" not only comprises community supported tools. It also comprises tools developed under responsibility of the hardware vendor, and amortized over the sale of the hardware. Now Renesas provides a number of those and of course has a stake in the quality level of those tools. (If only they made them run on Linux). > >I spoke to some one last week who "saved" 40K on their tools... however >they have now discovered that the tool will not do something they need >and it will cost them well over 40K (per project!) to rectify the >problem. >Another company had a choice of a two compilers one 25% the cost of the >other. They bought the cheaper one. Now they have had to buy the more >expensive one as the cheap one just did not work well enough. This was not necessarily a bad decision. Like in poker one may bet some on getting a flush. If the expected revenues are high enough, go for it. In this case one must take into account time to market, which may be a big loss. > >In many cases the expensive tools are over kill and do too much. On the >other hand some inexpensive and free tools are really good. In many >cases they will do all you need. It depends what you need to do. > >So get the right tools for the job and remember "costs" are not just the >purchase price there is much more to it than that. This is of course a general truth. An advantage of free as in free beer is that one can investigate whether the tools will do, without committing a largish sum of money. Investigating free tools can be easier because no one is restrained from publishing opinions by EULA's or NDA's. Committing ones time one must do anyway, unless dealing with a *very* reputable company, like Microsoft ( ;-) ). >\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
From: Anton Erasmus on 10 Aug 2010 14:13 On Thu, 22 Jul 2010 11:41:08 -0700 (PDT), Stimpy <rjmvxlvzjqwi(a)mailinator.com> wrote: >Thanks to everyone for all the good advice. After doing more digging, >here's where I'm at: > >Luminary Micro (Texas Instruments) Stellaris LM3S2110: analog >comparators are nice, but the timer seems to be lacking the output >compare feature. I really need the set-on-match and clear-on-match >functions (with interrupt) to generate a pulse train with accurate >timing. I really don't want to bit-bang this since the timing >requirements are fairly tight. Unless there's a way to do this that's >not obvious from my quick glance at the datasheet, I don't think I can >use this part. All the Stellaris 2000, 5000, and 8000 seem to share >the same crippled timer peripheral. > >Cypress PSoC5: the built-in PLD would be nice to offload some of the >pulse generation stuff but otherwise it looks like overkill for this >product. Pricing and availability seem questionable as well. I'd also >be a little worried designing in such a specialized part, especially >from a single source. It would certainly save a bunch of PCB space >right now but having to substitute this later on would be a nightmare. > >Freescale Kinetis: doesn't appear to be available yet. > >Nuvoton: Pricing is excellent! But to get the CAN controller I would >need the NUC130 which isn't in production yet. The Canadian >distributor (Arrow) doesn't show ANY NUC1xx parts in their catalog >either. As an aside, Nuvoton appears to be a division of Winbond and I >still have a bad aftertaste in my mouth from Winbond's buggy IO >controllers in the early 90s. > >STM32: The STM32F105R8 looks really good, it even has a DAC and the >DMA can work on both the SPI and the DAC! The 20mA sink current on the >IO ports is nice too. I'm almost sold on this one but one year lead >time?? Please tell me that was a joke. > >NXP LPC1700 series: Fewer features than the STM32 but slightly lower >price and probably better availability. > >Regarding the lack of EEPROM on these devices, I realize I can use >part of the FLASH to hold data but typical usage requires 5-10 writes >per day and I'm not sure about the endurance on the FLASH; the PIC's >EEPROM is rated at 100K writes minimum. Also this product doesn't have >a battery and it can (and does) get unplugged at any time. On the PIC, >a write is only 4ms and losing power during a write will only lose one >byte which is not a big deal. Losing an entire sector of FLASH would >be catastrophic. An external EEPROM is not an issue, since they now >come in SOT-23 packages for pennies each. > >I guess it's really come down to STM32 vs. LPC1700. > >Has anybody had any experience with either or both in terms of >development, integration, and availability? I have used the NXP ARM7 and ARM9 devices and the STM32 Cortex-M3 devices. On paper the NXP devices looks good, but I have found quite a few simply inexcusable hardware bugs in their implementation. Enabling multiple interrupt sources guarantees a crash at some point. Even running the UARTS in polling mode, we traced a non responsive program to the fact that if one sits in a loop polling the FIFO Empty flag, it simply does not become active sometimes, even though the TX FIFO has long been emptied. The STM32 had non of these problems. Multiple interrupt sources caused no problems whatsoever. Regards Anton Erasmus
From: Anton Erasmus on 10 Aug 2010 14:27
On Tue, 27 Jul 2010 21:06:16 -0400, Rich Webb <bbew.ar(a)mapson.nozirev.ten> wrote: >On Tue, 27 Jul 2010 16:52:06 -0700 (PDT), Leon <leon355(a)btinternet.com> >wrote: > >>Rowley CrossWorks is very good, with good support. I've been using >>their ARM and MSP430 tools for years. Their new ARM JTAG is nice, as >>well. > >May I ask a couple of questions regarding their ARM compiler? (I suppose >their support forum may be a better venue but usenet still gets wider >distribution.) > >The FAQ indicates that an ARM FIQ handler *must* be written in ARM >assembler. Do you know if this holds only when running under the CTL >(the CrossWorks Tasking Library) or is it also a restriction when >writing "bare metal" (OS-less) C code like the classic One Big Switch? >Regarding "normal" interrupt service routines, the FAQ states that "If >you are not using a CPU or board support package then you will have to >write the irq_handler in ARM assembly code." I'm not sufficiently >familiar with CrossWorks to know whether or how much a CPU support >package for, say, an LPC2103 ties me to the CTL. Is it just the usual >runtime setup and a boatload of #defines? The ARM FIQ handler *must* be written in assembler is more of a gcc issue that a Rowley CrossWorks issue. The support for interrupt handlers in C has been improving. On ARM7 core I had to use assembler stubs, but the actual interrupt code was written in C. On ARM9 the "interrupt" attribute was good enough, and I did not need to write assembly stubs, except when I needed nested interrupts. On the Cortex-M3, interrupt handlers in C is no problem, even when nesting multiple interrupt handlers. If you use a lot of interrupts, the Cortex definitely is MUCH easier to use than an ARM7 or ARM9. Regards Anton Erasmus |