M16C tool-chain: IAR Embedded Workbench or Renesas NC30?

Some years ago, Renesas (then Mitsubishi) recommended using IAR Embedded Workbench as a tool-chain for M16C. But now I see that Renesas has its own tool-chain (NC30, or something like that).

Well, now we have to develop a new product, and M16C is a good candidate for us. I have never used IAR E.W. or Renesas NC30 before. We also have an ICE from Renesas (PC7501), that seems to work with both environments.

I am planning to evaluate both tool-chains, but some comments from the knowledgeable people from here would be more than welcome.

Points that are important to me:

- Number and importance of bugs, already found and yet to be found :-)

- Compact code generation

- Good C support

- Locating capabilities

- Good debugging tool (I love traces, HW breakpoints when available, low download times and easy navigation through source files)

- Availability of drivers (I was told that both assemblers are quite different)

- Integration with uc/OS-II

- Support

Price is important, but I know how to get it :-)

Reply to
Ignacio G.T.
Loading thread data ...

In addition, Renesas sponsored a port of GCC to the r8c/m16c/m32c chips, which I now maintain. See

formatting link

gdb at the moment only supports its simulator.

Try it and see ;-)

GCC is very conformant.

I.e. locating code in memory? The GNU linker has a scripting language for laying out your code.

As I said, gdb only debugs the simulator. We've looked at supporting hardware debug, but Renesas decided to go with their own ICE-based platforms.

The GNU assembler uses the NC30 syntax, plus its own extensions.

I usually look at bugs right away, and if they're easy, fix them right away. Or you can buy a support contract (whatever level of support you wish :) from Red Hat.

The GNU tools are free downloads, Red Hat support is (of course) not.

Reply to
DJ Delorie

I use various versions of NC30 some years ago with very little problem.

We found NC30 to be pretty good.

IAR was abysmal (then, don't know now).

The only quirky bit was due to memory models. This code mean that sizeof(char *) != sizeof(const char *).

Linking? Did what I needed but that wasn't much.

Did use, or need a debugger. The hardware was up quite quickly. We code developed a PC simulation/demo from the same sources. So most debugging was done in the PC environment. Also must of the code had been ported and extended from a previous H8 based project.

M16C has built in download boot code - should be the same for both. Though we were early users and developed our own software update mechanism.

We required exactly 29 bytes of assembler code.

didn't use it.

never had a need any on the tools from. Some needed on the electronics.

NC30 was a free download. At least it was then for evaluation, but once I showed how crap the IAR compiler was they (Mitsubishi) said we could use NC30 for real.

Peter

Reply to
Peter Dickerson

Thanks for the info.

:(

Is it easy to locate code and data in several separated chunks? For instance: ROM1 0x00000-0x0ffff, RAM1: 0x10000-0x1ffff, ROM2:

0x20000-0x2ffff, RAM2: etc., you get the idea.

Sad, but commercially understandable (to a degree)

Thank you, DJ

Reply to
Ignacio G.T.

Peter Dickerson escribió:

Good to know. Thanks.

Which version? We have 2.12A (from 2003-2004). Now the have 3.12. Hopefully, things may have changed.

Curious.

It's still free for code size < 64 Kbytes. Sadly, we will surely cross that boundary.

May I ask you why IAR compiler upset you so much?

Thanks, Peter.

Reply to
Ignacio G.T.

No, I'm talking 1999-2000 timescale.

Not really. Look at the architecture of the M16C. Basically it is 16 bit with various memory models to extend addressing. You really want to avoid >64K data if you cans help it. On the other hand you want to have const data in ROM. So there is a memory model in which non-const data is considered near but const data is considerd far, by default.

We had used IAR for preious project using other processors. We didn't have too much trouble with that although code generation didn't seem that good. So when we went to M16C IAR made great claims for the M16C code but in reality code gen was aweful (effectively -O0) for non-small model. I complained about it in the UK and was told something like - the demo version we gave you is out of date and the real thing does much better. However, they were not able to provide anything better (even with the latest version) and when the questions were escalated to Sweden (or whereever it is that they do the dev) the reply came back that yes, all optimization had been disabled...

Note that that was a lot of years ago now.

Peter

Reply to
Peter Dickerson

In my compagny we "recently" (few months ago) starts a new project with a M16C and the M16C was never use before.

A test have been done (not by me) on different compilers : - NC30 - IAR - Tasking

NC30 performance in optimisation was medium. IAR and Tasking was close each over and Tasking has been finally choosen. It seems thatfew people use Tasking.

So, I use Tasking, it works very fine but it is really expensive...

GCC has not been tested.

Regards, Guillaume

--
Guillaume Chevillot
Reply to
Guillaume Chevillot

It won't do it automatically for you, but you can use wildcards or explicit names to tell the linker which objects should end up in which memory chunks. You can even tell it what order to put them in, if you want. It has a sort-by-name function it uses for constructor sequencing, you can use that too.

As for putting code in ROM and data in RAM, it already does that, and my default linker scripts support it, along with the syntax needed to tell the linker "link this data as if it were in RAM, but make it so it loads in ROM at first, and tell the program where you put it so it can move it at startup."

Reply to
DJ Delorie

"Guillaume Chevillot" wrote in message news:esrvnc$1694$ snipped-for-privacy@biggoron.nerim.net...

I'm quite a big fan of GCC. I'm using it for an ARM project. However, I wouldn't expect it to be a good match to the M16C architecture. GCC likes flat addressing with pointers and ints the same size, and ideally at least

32-bit. So my expectation for GCC wouldn't be high. If anyone has a pointer to a pre-built GCC for M16C for Cygwin (say) then I'm willing to try it out. The code I have builds to just under 600K of ROM using MC30.

Peter

Reply to
Peter Dickerson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.