Migrating from PIC18 to ARM: which MCU to choose?
in [Embedded]
|
From: Rich Webb on 10 Aug 2010 16:30 On Tue, 10 Aug 2010 20:27:09 +0200, Anton Erasmus <nobody(a)spam.prevent.net> wrote: >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. Ugh. Is that also the case for the vectored interrupts on the LPC2000 chips? > 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. Okay, that sounds significantly more comfortable. I avoid putting too much stuff in interrupt service routines but sometimes circumstances aren't as accommodating as one may prefer. > 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. Good information. Thanks! -- Rich Webb Norfolk, VA
From: Anton Erasmus on 11 Aug 2010 13:27 On Tue, 10 Aug 2010 16:30:56 -0400, Rich Webb <bbew.ar(a)mapson.nozirev.ten> wrote: >On Tue, 10 Aug 2010 20:27:09 +0200, Anton Erasmus ><nobody(a)spam.prevent.net> wrote: > >>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. > >Ugh. Is that also the case for the vectored interrupts on the LPC2000 >chips? > [snipped] On ARM7 and ARM9 cores, one has the FIQ and the IRQ vectors for handling Fast interrupts and other interrupts. The vectored interrupts on these controllers is an extra peripheral from which the address to be vectored to must be read by the IRQ or FIQ handlers. This can be done with one ARM instruction, so is not too much of a problem. Go too http://www.hitex.com/index.php?id=download-insiders-guides&L=1 And download the guides from Hitex. These guides are quite good and gives a good overview of all these things. AFAICR the older "The Insider's Guide To The Philips ARM7-Based Microcontrollers" gives examples of how to do interrupt servers on these devices using ARM7. They provide examples of typical assembly stubs as well as how to handle nested interrupts using gcc. Regards Anton Erasmus
From: Ulf Samuelsson on 11 Aug 2010 15:25 Stimpy skrev: > 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: > You may also want to consider the AVR based AT90CAN64 > 1) availability - having devices in stock at Digikey/Mouser is almost > a necessity since we can't wait 12 weeks for backordered parts from > some distributor; two weeks is probably the maximum Aviability is difficult for everyone at the moment > 2) price - since our original PIC18 is now at $9.47 each (qty 100) > pretty much any device that comes in under this price will be better > 3) 64K FLASH - since ARM code is more compact than PIC18 this should > be more than enough OK > 4) 4K RAM OK > 5) 128 bytes EEPROM 2 kB > 6) CAN controller OK > 7) timers with 1 output compare and 2 input captures 1 input capture > 8) SPI OK > 9) 2 UARTs OK > 10) 8-bit DAC (or PWM) PWM > 11) a DMA controller that works with the SPI would be nice but not > essential No > 12) two comparators Only one :-( > 13) 10-bit ADC 8 channel > 14) under 0.2 mA when stopped In the uA range > > Processing speed and power consumption aren't too critical. I've given > up trying to find built-in comparators on any ARM device so I guess > those will have to be external from now on. > Low standby current is > important, but I can always cut power to the whole device if required. > I've found one (LPC2364) that has a built-in DAC but those seem to be > rare. The only ones I've found with built-in EEPROM are the LPC2927/ > LPC2929. I also can't decide between ARM7, ARM9, Cortex-M0 and Cortex- > M3. Right now Cortex-M3 appears to be more popular and the three > leading choices are: > Texas Instruments - Stellaris > NXP - LPC series > ST - STM32 series > Given the above criteria there are still dozens of devices to choose > from that would fit most of the requirements. NXP seems to have the > best pricing; other than that I'm lost. > Any suggestions or are there any other choices that I've overlooked? -- Best Regards Ulf Samuelsson These are my own personal opinions, which may or may not be shared by my employer Atmel Nordic AB
From: Ulf Samuelsson on 11 Aug 2010 15:32 Stimpy skrev: > 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. They finally gave me total control over a peripheral definition ;-) > 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. There are development kits and samples shipped since last year. > 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. Atollic has a free unlimited version. It does not have the real fancy features like source code control etc. present in the pofressional version. Or use the WinAVR with the AT90CAN64 which I mentioned in another post. -- Best Regards Ulf Samuelsson These are my own personal opinions, which may or may not be shared by my employer Atmel Nordic AB
From: linnix on 11 Aug 2010 15:37
On Aug 11, 12:32 pm, Ulf Samuelsson <u...(a)a-t-m-e-l.com> wrote: > Stimpy skrev: > > > 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. > > They finally gave me total control over a peripheral definition ;-) > > > 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. > > There are development kits and samples shipped since last year. > But nothing available on Digikey yet. |