>
> >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!!
Reply by Dave Hansen●September 27, 20052005-09-27
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.
Reply by Dave Hansen●September 27, 20052005-09-27
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.
Reply by larwe●September 27, 20052005-09-27
> 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.
Reply by Jim Granville●September 26, 20052005-09-26
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
Reply by larwe●September 26, 20052005-09-26
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.
Reply by Gary Reichlinger●September 26, 20052005-09-26
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.
Reply by Dave Hansen●September 26, 20052005-09-26
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.
Reply by larwe●September 26, 20052005-09-26
> 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!
Reply by Dave Hansen●September 26, 20052005-09-26
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.