Migrating from PIC18 to ARM: which MCU to choose?
in [Embedded]
|
From: Leon on 27 Jul 2010 19:52 On 26 July, 21:57, Stimpy <rjmvxlvzj...(a)mailinator.com> wrote: > On Jul 26, 8:46 am, rickman <gnu...(a)gmail.com> wrote: > > > BTW, I don't see Atmel in this list. They are a major ARM vendor and > > should not be discounted. The SAM7 parts are still very viable > > devices and the SAM3 parts are the hot, new products in their ARM > > lineup. > > You're right, I completely forgot about Atmel. The SAM3 looks quite > good, it also has the DAC and DMA and SPI and probably the most > flexible timer / waveform generator that I've seen so far. The butilt- > in ROM bootloader is nice too, although not very useful for this > product. Now I've checked Digikey, Mouser, Arrow, Future, Farnell and > other than the development kit, no parts in stock anywhere. Are these > things actually available yet? If not, then I think I'll go with the > STM32. > > Now the question is which toolchain/JTAG to go with. I don't really > feel like mucking around with the DIY Eclipse/GCC/GDB/OpenOCD/Wiggler > solution and things like Keil, IAR, Greenhills, and Tasking are well > outside the budget. This leaves me with one of the "packaged" GCC > offerings like Rowley, Raisonance, Hitex, iSystem, Atollic, Aiji. > Does anybody have any experience with any of those? After reading a > few past discussions on here it looks like Rowley is a good choice, > Raisonance is OK but slow, and the Hitex IDE isn't all that great. 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. Leon
From: Rich Webb on 27 Jul 2010 21:06 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? -- Rich Webb Norfolk, VA
From: Chris Burrows on 27 Jul 2010 22:19 "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. If ever you do receive incorrect or misleading information from a vendor you would be in a good position to get your money back. Regards, Chris Burrows CFB Software http://www.cfbsoftware.com
From: vinnie on 29 Jul 2010 11:04 >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. --Vinnie --------------------------------------- Posted through http://www.EmbeddedRelated.com
From: Chris H on 30 Jul 2010 07:05
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. 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. 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. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |