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 :-)
M16C tool-chain: IAR Embedded Workbench or Renesas NC30?
Started by ●March 7, 2007
Reply by ●March 7, 20072007-03-07
"Ignacio G.T." <igtorque.remove@evomer.yahoo.es> writes:> 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).In addition, Renesas sponsored a port of GCC to the r8c/m16c/m32c chips, which I now maintain. See http://people.redhat.com/dj/m32c/> 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.gdb at the moment only supports its simulator.> - Compact code generationTry it and see ;-)> - Good C supportGCC is very conformant.> - Locating capabilitiesI.e. locating code in memory? The GNU linker has a scripting language for laying out your code.> - Good debugging tool (I love traces, HW breakpoints when available, > low download times and easy navigation through source files)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.> - Availability of drivers (I was told that both assemblers are quite > different)The GNU assembler uses the NC30 syntax, plus its own extensions.> - SupportI 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.> Price is important, but I know how to get it :-)The GNU tools are free downloads, Red Hat support is (of course) not.
Reply by ●March 7, 20072007-03-07
"Ignacio G.T." <igtorque.remove@evomer.yahoo.es> wrote in message news:45eed6d9$0$97265$892e7fe2@authen.yellow.readfreenews.net...> 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).I use various versions of NC30 some years ago with very little problem.> 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 :-)We found NC30 to be pretty good.> - Compact code generationIAR was abysmal (then, don't know now).> - Good C supportThe only quirky bit was due to memory models. This code mean that sizeof(char *) != sizeof(const char *).> - Locating capabilitiesLinking? Did what I needed but that wasn't much.> - Good debugging tool (I love traces, HW breakpoints when available, lowDid 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.> download times and easy navigation through source files)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.> - Availability of drivers (I was told that both assemblers are quite > different)We required exactly 29 bytes of assembler code.> - Integration with uc/OS-IIdidn't use it.> - Supportnever had a need any on the tools from. Some needed on the electronics.> > Price is important, but I know how to get it :-)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 by ●March 9, 20072007-03-09
DJ Delorie escribi�:> "Ignacio G.T." <igtorque.remove@evomer.yahoo.es> writes: >> 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). > > In addition, Renesas sponsored a port of GCC to the r8c/m16c/m32c > chips, which I now maintain. See http://people.redhat.com/dj/m32c/Thanks for the info.>> 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. > > gdb at the moment only supports its simulator.:(>> - Locating capabilities > > I.e. locating code in memory? The GNU linker has a scripting language > for laying out your code.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.>> - Good debugging tool (I love traces, HW breakpoints when available, >> low download times and easy navigation through source files) > > 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.Sad, but commercially understandable (to a degree) Thank you, DJ
Reply by ●March 9, 20072007-03-09
Peter Dickerson escribi�:> "Ignacio G.T." <igtorque.remove@evomer.yahoo.es> wrote in message > news:45eed6d9$0$97265$892e7fe2@authen.yellow.readfreenews.net... >> 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). > > I use various versions of NC30 some years ago with very little problem.Good to know. Thanks.>> Points that are important to me: >> - Compact code generation > > IAR was abysmal (then, don't know now).Which version? We have 2.12A (from 2003-2004). Now the have 3.12. Hopefully, things may have changed.>> - Good C support > The only quirky bit was due to memory models. This code mean that > sizeof(char *) != sizeof(const char *).Curious.>> Price is important, but I know how to get it :-) > > 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.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 by ●March 9, 20072007-03-09
"Ignacio G.T." <igtorque.remove@evomer.yahoo.es> wrote in message news:45f13ef0$0$97265$892e7fe2@authen.yellow.readfreenews.net...> Peter Dickerson escribi�: >> "Ignacio G.T." <igtorque.remove@evomer.yahoo.es> wrote in message >> news:45eed6d9$0$97265$892e7fe2@authen.yellow.readfreenews.net... >>> 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). >> >> I use various versions of NC30 some years ago with very little problem. > > Good to know. Thanks. > >>> Points that are important to me: >>> - Compact code generation >> >> IAR was abysmal (then, don't know now). > > Which version? We have 2.12A (from 2003-2004). Now the have 3.12. > Hopefully, things may have changed.No, I'm talking 1999-2000 timescale.>>> - Good C support >> The only quirky bit was due to memory models. This code mean that >> sizeof(char *) != sizeof(const char *). > > Curious.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.>>> Price is important, but I know how to get it :-) >> >> 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. > > 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?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 by ●March 9, 20072007-03-09
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 by ●March 9, 20072007-03-09
"Ignacio G.T." <igtorque.remove@evomer.yahoo.es> writes:> 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.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 by ●March 9, 20072007-03-09
"Guillaume Chevillot" <Guillaume.nospam@chevillot.nospam.net> wrote in message news:esrvnc$1694$1@biggoron.nerim.net...> 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.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
