Forums

Development Tools for NEC 78K

Started by Dave Hansen September 26, 2005
We're considering an NEC 78K microcontroller for a new project.  We've
not used this chip before, and we've no tools in-house.

It looks like we can get compilers from (at least) 3 sources: NEC
themselves, Gaio, and IAR.  I've dealt with IAR before, and have my
own opinions (spendy for what you get, but not a complete disaster),
but don't really know anything about the other two.  

I'm less than certain NEC is the best choice since they're not in
business to sell compilers, but their stuff looks reasonably good from
the documentation I've been able to download, and I've a feeling it
will have the lowest entry cost.

I've even heard of Gaio before today.  

Anybody used any of these enough to form a strong opinion?  Any
options out there I've overlooked?

Thanks,

                               -=Dave
-- 
Change is inevitable, progress is not.
> We're considering an NEC 78K microcontroller for a new project. We've
Danger, Will Robinson! After working with the series for a while, I will never design them in again. Local support consists of people saying "We never got that to work, let us know if you make it happen". The tools are twitchy at best; the IAR C compiler generated all sorts of weird and dysfunctional code (fortunately most of our code was in asm but there was much groveling through asm listings of the C code trying to patch problems). No on-chip debug capabilities, the only way to debug your code is by soldering a huge, expensive and non-reusable ICE adapter onto your circuit, etc. etc. Plus of course nobody else in the English-speaking world is using the parts, so there's nobody to talk to once you hit problems. As a perfect example of NEC's support: They supply a little board with a QFP ZIF socket on it to program flash micros from the regular ICE board. This is a breakout board; the pins of the ZIF socket run to pads, and you have to put jumper wires between the ICE (actually ICP) port and the correct socket pins. Now, the micro requires a clock signal (not serial clock, but core clock) to execute programming ops. The ICE board supplies this signal and it looks nominal on a scope. However it is impossible to flash chips using the clock off the ICE. By dumb luck I found that if I put an xtal and startup caps on the breakout area, and disconnected the ICE clock, I could burn chips. NEC's guys were astonished, since they never managed to get the board working themselves. Of course, doesn't stop them from selling it. The ICE consists of a half-dozen FPGAs and a buttload of SRAM on a board that gets so hot you can feel it beating on your face from a distance. Endurance tests of our hardware (on the ICE) kept failing. NEC's response? Well, it's probably the ICE PSU, we shipped a lot of them that don't really work too well... Or maybe it's a problem with the USB driver for the interface. Just keep testing, let us know, huh? Leadtimes are insane. It's not significantly faster to use the flash part than to use mask-ROM. These parts exist to remind us why we don't use micros intended for the Japanese market. Next time round I'm going with AVR which is cheaper feature-for-feature, has on-chip JTAG, and is much better supported!
On 26 Sep 2005 10:25:39 -0700, "larwe" <zwsdotcom@gmail.com> wrote:

>> We're considering an NEC 78K microcontroller for a new project. We've > >Danger, Will Robinson! After working with the series for a while, I >will never design them in again. Local support consists of people >saying "We never got that to work, let us know if you make it happen".
Swell. But I don't have much influence in the device selection. Much more in the tools...
>The tools are twitchy at best; the IAR C compiler generated all sorts >of weird and dysfunctional code (fortunately most of our code was in >asm but there was much groveling through asm listings of the C code >trying to patch problems).
Did you get a chance to try the NEC tools? I was going to avoid IAR if at all possible.
>No on-chip debug capabilities, the only way to debug your code is by >soldering a huge, expensive and non-reusable ICE adapter onto your >circuit, etc. etc. Plus of course nobody else in the English-speaking >world is using the parts, so there's nobody to talk to once you hit >problems.
Well, they do have chips with on-chip debug support (including the one we're looking at), but they don't want you to ship them. You're supposed to use the debug part for development, but ship with non-debug parts. Looks like a 6 wire system: power, ground, 2 serial I/O, reset, and "Flash Programming Mode," whatever that is. [...]
>These parts exist to remind us why we don't use micros intended for the >Japanese market. Next time round I'm going with AVR which is cheaper >feature-for-feature, has on-chip JTAG, and is much better supported! >
Our prototype uses an ATmega16. Our customer has a list of "approved" micros. NEC is on the list. Atmel isn't. The NEC is quoting out at about half the price of the Atmel. We have quote requests out to a couple more vendors, but those aren't expected to be any cheaper. At the volumes they're talking about (I'll believe it when I see it...) a buck off the BOM will buy quite a bit of developer time... Thanks for your response, just wish the news was better.. -=Dave -- Change is inevitable, progress is not.
On 26 Sep 2005 10:25:39 -0700, "larwe" <zwsdotcom@gmail.com> wrote:

>Danger, Will Robinson! After working with the series for a while, I >will never design them in again. Local support consists of people >saying "We never got that to work, let us know if you make it happen".
It sounds like they must be rerunning Lost in Space. I am actually old enough to remember it from prime time. I have been using the K series for a number of years and have been satisfied. The support from NEC was good, but I have not used it for a long time so I cannot comment on where it stands now. I use C++ for PC programs (Borland Builder), but have never been interested in using C in microcontrollers.
Hi Dave,

Well, if it's a fait accompli that the 78K is designed in, feel free to
talk to me by email if you get into weird situations like the ones we
hit (temperature, EMI, ESD susceptibility). At least I can provide a
shoulder to cry on, if nothing else :)

> >The tools are twitchy at best; the IAR C compiler generated all sorts > >of weird and dysfunctional code (fortunately most of our code was in > > Did you get a chance to try the NEC tools? I was going to avoid IAR > if at all possible.
My team doesn't use them (we use 78K0 parts). However another team (using 78K0S) uses the NEC compiler and gets generally good results. The NEC linker output is better integrated with the debugger IDE than IAR's, especially if you're using C. Come to think of it, IAR might have discontinued their 78K product. If you have the choice of toolchains, go NEC. It's not a part family that's attracted much third-party interest and with NEC tools you have a single point of complaint for any problems you might hit. I never heard of that third vendor you mentioned, but I doubt they can offer anything compelling enough to overcome the single-point advantage.
> >No on-chip debug capabilities, the only way to debug your code is by > > Well, they do have chips with on-chip debug support (including the one > we're looking at), but they don't want you to ship them. You're
We use the 7800xx series, which has mask versions and flash versions. The flash version has no on-chip debug. You solder down a QFP device that connects to the ICE board. It's like the M16C debug hardware I've seen except that the disposable part of NEC's kit is much more complicated and expensive.
> non-debug parts. Looks like a 6 wire system: power, ground, 2 serial > I/O, reset, and "Flash Programming Mode," whatever that is.
Sounds like the 78F00xx series. All that interface gives you is ability to flash the flash variant.
> micros. NEC is on the list. Atmel isn't. The NEC is quoting out at > about half the price of the Atmel. We have quote requests out to a
Mmm, they did that to us too, three years ago - now Atmel has come down in price and NEC has gone up. Cost of a 32K Atmel flash part is < the cost of an 8K NEC part. More I/Os and peripherals on the Atmel too. In the 78K series you pay extra for hardware I2C (Atmel gives it to you for free)... I could go on and on.
Dave Hansen wrote:

> On 26 Sep 2005 10:25:39 -0700, "larwe" <zwsdotcom@gmail.com> wrote:
<snip
>>No on-chip debug capabilities, the only way to debug your code is by >>soldering a huge, expensive and non-reusable ICE adapter onto your >>circuit, etc. etc. Plus of course nobody else in the English-speaking >>world is using the parts, so there's nobody to talk to once you hit >>problems. > > > Well, they do have chips with on-chip debug support (including the one > we're looking at), but they don't want you to ship them. You're > supposed to use the debug part for development, but ship with > non-debug parts. Looks like a 6 wire system: power, ground, 2 serial > I/O, reset, and "Flash Programming Mode," whatever that is.
If you don't debug with what you ship, how do you know WHAT you have debugged ? Fine for SW only problems, but the nasty SW-Peripheral interactions might work on one, and not on the other.... Do they target MASK for volumes ? - many asians do that, pitch mask prices, and loss-lead FLASH to get the design win, and if you want to STAY on flash, and not move to mask, prices start climbing on the flash, and specs get softer....
>>These parts exist to remind us why we don't use micros intended for the >>Japanese market. Next time round I'm going with AVR which is cheaper >>feature-for-feature, has on-chip JTAG, and is much better supported! >> > > > Our prototype uses an ATmega16. Our customer has a list of "approved" > micros. NEC is on the list. Atmel isn't. The NEC is quoting out at > about half the price of the Atmel. We have quote requests out to a > couple more vendors, but those aren't expected to be any cheaper. At > the volumes they're talking about (I'll believe it when I see it...) a > buck off the BOM will buy quite a bit of developer time... > > Thanks for your response, just wish the news was better..
Get them to add Atmel to the approved list :) .. and look at the newest AVRs, they'll have the best volume prices. .. and look at the newest Philips LPC210x ? -jg
> Do they target MASK for volumes ? - many asians do that, pitch mask > prices, and loss-lead FLASH to get the design win, and if you want
They don't even loss-lead flash, at least on the parts we're using; the flash part is REALLY expensive. There is a single flash part in the family, which has all the peripherals and memory of the high-end mask version. It has emulation bits to cut pieces out of the memory map in order to emulate the various smaller mask flavors. The idea is to set the emulation registers for the mask version you eventually intend to use, and prototype with flash while you're waiting the 18 weeks for some mask parts to arrive. BTW, I'm told that NEC licenses their flash technology from someone else, which is why their flash parts are very expensive.
On 26 Sep 2005 15:54:52 -0700, "larwe" <zwsdotcom@gmail.com> wrote:

>Hi Dave, > >Well, if it's a fait accompli that the 78K is designed in, feel free to >talk to me by email if you get into weird situations like the ones we >hit (temperature, EMI, ESD susceptibility). At least I can provide a >shoulder to cry on, if nothing else :)
Thanks. It's not a sure thing yet. Only sure thing is it's not Atmel or Microship. As of today, there is slight pressure towards NEC, tomorrow might be towards Freescale.
> >> >The tools are twitchy at best; the IAR C compiler generated all sorts >> >of weird and dysfunctional code (fortunately most of our code was in >> >> Did you get a chance to try the NEC tools? I was going to avoid IAR >> if at all possible. > >My team doesn't use them (we use 78K0 parts). However another team >(using 78K0S) uses the NEC compiler and gets generally good results. >The NEC linker output is better integrated with the debugger IDE than >IAR's, especially if you're using C.
We're looking at uPDF050x, which is a 78K0/Kx2 part if I'm not mistaken. There was talk of "free tools," which is somehow not comforting. But it sounds like your colleagues have had reasonable luck with the NEC tools, which is what I would expect would be "free" in this case...
> >Come to think of it, IAR might have discontinued their 78K product.
NEC still lists it on their web page. Though some vendors _seem_ to discontinue their tools right after they sell them to you. Not naming names, here...
> >If you have the choice of toolchains, go NEC. It's not a part family >that's attracted much third-party interest and with NEC tools you have >a single point of complaint for any problems you might hit. I never >heard of that third vendor you mentioned, but I doubt they can offer >anything compelling enough to overcome the single-point advantage.
Gaio. I'd never heard of them before yesterday. I'm not in the mood to experiment unless someone says their stuff is better than sliced bread.
> >> >No on-chip debug capabilities, the only way to debug your code is by >> >> Well, they do have chips with on-chip debug support (including the one >> we're looking at), but they don't want you to ship them. You're > >We use the 7800xx series, which has mask versions and flash versions. >The flash version has no on-chip debug. You solder down a QFP device >that connects to the ICE board. It's like the M16C debug hardware I've >seen except that the disposable part of NEC's kit is much more >complicated and expensive.
NEC has a "cute" little "On-chip Debugger Minicube" in a translucent orange plastic box that communicates to the PC over USB, and comes with debugger and flash writer software. The chips are supposed to be in-system flash writable. All very pretty. Even better if it acutally works.
> >> non-debug parts. Looks like a 6 wire system: power, ground, 2 serial >> I/O, reset, and "Flash Programming Mode," whatever that is. > >Sounds like the 78F00xx series. All that interface gives you is ability >to flash the flash variant.
There is a seperate PG-FPL flash programming box to write flash in-system. It's in a slighly smaller translucent green (for 78K0S) or blue (for 78K0) plastic box.
> >> micros. NEC is on the list. Atmel isn't. The NEC is quoting out at >> about half the price of the Atmel. We have quote requests out to a > >Mmm, they did that to us too, three years ago - now Atmel has come down >in price and NEC has gone up. Cost of a 32K Atmel flash part is < the >cost of an 8K NEC part. More I/Os and peripherals on the Atmel too. In >the 78K series you pay extra for hardware I2C (Atmel gives it to you >for free)... I could go on and on.
You don't have to sell me on AVRs. But I'm the software guy. Thanks again, -=Dave -- Change is inevitable, progress is not.
On Tue, 27 Sep 2005 12:20:39 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Dave Hansen wrote: >
[...]
>> >> Well, they do have chips with on-chip debug support (including the one >> we're looking at), but they don't want you to ship them. You're >> supposed to use the debug part for development, but ship with >> non-debug parts. Looks like a 6 wire system: power, ground, 2 serial >> I/O, reset, and "Flash Programming Mode," whatever that is. > > If you don't debug with what you ship, how do you know WHAT you have >debugged ?
That's always the problem with emulators that replace the microcontroller, which is essentially what you get -- a special micro with a debugging interface replacing the production micro for development purposes.
> Fine for SW only problems, but the nasty SW-Peripheral interactions >might work on one, and not on the other....
Agreed, it's a software tool, but that's all I'm looking for. Unless something really weird happens. I'm the software guy. The hardware is just supposed to work. ;-)
> > Do they target MASK for volumes ? - many asians do that, pitch mask >prices, and loss-lead FLASH to get the design win, and if you want >to STAY on flash, and not move to mask, prices start climbing on the >flash, and specs get softer....
I don't see any mask part in the brochure they gave me. The cover says "ALL FLASH" in all caps. [...]
>> Our prototype uses an ATmega16. Our customer has a list of "approved" >> micros. NEC is on the list. Atmel isn't. The NEC is quoting out at >> about half the price of the Atmel. We have quote requests out to a >> couple more vendors, but those aren't expected to be any cheaper. At >> the volumes they're talking about (I'll believe it when I see it...) a >> buck off the BOM will buy quite a bit of developer time... >> >> Thanks for your response, just wish the news was better.. > >Get them to add Atmel to the approved list :)
Our customer is hundreds of times larger than the company I work for. AIUI, Atmel once p*ssed off this customer, though I'm not sure how. I'm not saying they'll never get on the "approved" list, but I know we're not going to get them there.
> >.. and look at the newest AVRs, they'll have the best volume >prices.
The mega168 would probably be a good match.
> >.. and look at the newest Philips LPC210x ? >
I'm forwarding An Schwob's announcement to the appropriate people. ;-) Though I expect the LPC210x hasn't made it to the "approved" list yet either... Regards, -=Dave -- Change is inevitable, progress is not.
Gary Reichlinger wrote:
> > >Danger, Will Robinson! After working with the series for a while, I > > It sounds like they must be rerunning Lost in Space. I am actually
I don't know, I average about one hour of TV per six months. I'm remembering watching it, sometime in the 1980s, on a 2" black and white TV my parents got as a premium from some dental supplies company many years ago.
> Builder), but have never been interested in using C in > microcontrollers.
I simply can't get people in my group to work on asm projects. It seems like any project written in C is automatically "easy" but a project to blink an LED is "hard" if it's in asm. This attitude has percolated way beyond my company, too. I'm writing a series of articles for IBM that discusses tying an AVR-based sensor board to a PowerPC SBC (see http://www-128.ibm.com/developerworks/library/pa-migrate7/ which is the seventh article in the series - and be warned that IBM's graphics people totally screwed up the block diagram). I did a brief survey and found that unless I wrote the AVR side in C, people wouldn't read it because they would regard it as "too vendor-specific". Ridiculous!!