Migrating from PIC18 to ARM: which MCU to choose?

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

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

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

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.

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

In message , vinnie writes

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

Not to forget a smooth upgrade path to 16 and 32 bits.

The German Forth users have done some Forth with it too. I have done some Forth with 16 bits Renesas (trying R32C now).

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

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

Ugh. Is that also the case for the vectored interrupts on the LPC2000 chips?

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.

Good information. Thanks!

--
Rich Webb     Norfolk, VA

[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

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

Stimpy skrev:

You may also want to consider the AVR based AT90CAN64

Aviability is difficult for everyone at the moment

OK

OK

2 kB

OK

1 input capture

OK

OK

PWM

No

Only one :-(

8 channel

In the uA range

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

They finally gave me total control over a peripheral definition ;-)

There are development kits and samples shipped since last year.

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

d

But nothing available on Digikey yet.

Got 'm. Thanks again!

--
Rich Webb     Norfolk, VA

The most popular "packaged gcc" suppliers are Code Sourcery and Code Red. Code Sourcery are the company that are responsible for gcc for the ARM (and MIPS, PPC, ColdFire, and a couple of others), and thus have the best knowledge and support for the compiler - when you ask them for help, you are talking to the people that wrote the tools. Most of the other "packaged gcc" companies base their tools directly on Code Sourcery's build rather than the official FSF tree.

I don't know much about Code Red, except that they are popular in the USA. But TI/Luminary provides evaluation kits and software for four toolchains - Keil, IAR, Code Sourcery and Code Red - which should give you an idea of the popularity.

I don't know how much the other "packaged gcc" suppliers actually contribute to gcc - they may be heavily involved, or may do very little. Some make their own libraries, others used pre-packaged libraries (such as newlib). Some make their own IDEs and/or debuggers, others use Eclipse and gdb (whether you call that a good thing or a bad thing is a matter of opinion).

(which planet are you from?),

You are kidding, right? Most selection and lowest cost comparing similar chips, yeah right. The fastest R8C is still slower than the slowest Cortex-M0 based chip I know, yet cost is higher than most M3 based devices providing 5-10 times the performance. Just one comparison: R5F21258SNFP#U0 an R8C with 64k Flash, 3k SRAM,

10-bit ADC, no CAN, running 20 MHz in an 8-bit core. Cost: $5.70 in 100-qty Versus: LPC1752, a Cortex-M3 with 64k Flash and 16k SRAM, 12-bit ADC, CAN, running 80 MHz in a 32-bit core. Cost: $5.25 in 100 qty

but not many with 64k Flash

mparators.

)

ARM, the company has been sponsoring GNU development for many years and the ARM GNU compiler is close to the top optimizing compilers in the market. The companies selling the top compilers have to do that for a living, that is slightly different than a company internal compiler division and I know what I am talking about, experienced both, would never ever go back to the company internal solution again.

An Schwob

d e e

IMHO, STM32 is still by far the leader in Cortex-M3 designs, well ahead of LM3 and LPC1000, that's why I would not use the package from TI as popularity test.

is one of the highest member count user groups around and that is all based on Raisonance compiler code That could give some idea about popularity too. btw. TI also supplies Code Composer, probably the most unpopular compiler for Cortex-M3. What one company supplies allows conclusions about their preferences much more than the popularity of the compilers. However, Keil and IAR are present with pretty much every vendor and I would also conclude that they are the most popular choices as long as your budget allows to buy them. An Schwob

Missing the CAN part hey? It is an MCU with industrial strength timers and strangled with a consumer (high) speed communication interface. CAN and/or Ethernet are missing.

That comes as a surprise that the strongest promoter of AVR in this forum got control of peripheral definition for ARM.

The OP asks for readily available ex. Digikey stock, and that would be a definite NOT REALLY

You mean it is not code size limited, try to use it and you will find enough limitations that really make you want to upgrade. After all they need to earn some money too.

Another one who is kidding himself. Come one Ulf, you should know better than to post the AT90CAN against a Cortex device. On the other hand the Atmel SAM3 is a lost step child could not get a CAN on-chip and can not really compete against other M3 offerings. Too bad Atmel decided to favor AVRs internally and underfunding the ARM team close to starvation :-(

An Schwob