Re: data sheets for Sunplus microcontrollers?
Message #5 Posted by Bill Wiese on 13 June 2007, 2:18 p.m.,
in response to message #3 by DaveJ
Quote:
It is a most puzzling choice indeed by HP.
That statement astounds me. Surely you know HP did not make the choice of CPU??
They went out and looked for calculator mfgrs with certain competencies and volume and pricing, and said, "we want a calc that looks like <this> and does <that>". Part of <that> would include power consumption/battery life considerations, and some measure of operational speed (PRGM mode instructions per second, max times for some of the more complex functions, etc.)
If Kinpo decided to use a (mythical) ultrafast 4-bitter HP wouldn't care. If, say, Kinpo decided that a VAX emulation layer was appropriate, fine - just as long as cost & power considerations are met. These level details are left to ODMs/OEMs now; HP buys a 'package'. High-level price/power/operational targets are all that matter between the 'name brand' and the ODM vendor. Most of the design in fact was done by Kinpo, with the 'styling'/arrangement/packaging 'feel' done by HP in cooperation with a product design house like IDEO or Frog-something or SmartDesign. (They do this for their inkjet printers, which they make a helluva lot more money from...)
Quote:
It's not the worlds greatest micro,
Again, who cares? Absolutely irrelevant.
BTW, in terms of volume shipped, 6502 derivatives are way up there. *Tons* of modems, tons of toys, etc. have 'em. Mitsubishi has their MELPS 37000/57000 8 and 16 bit versions (their 16 bitter is roughly like the 65C816 that was in the Apple IIc) that ran Nissan engine control computers in the mid thru very late 90s (and probably beyond) vehicles. Many many VCRs and TV sets and some microwave ove
Many chip selections are made not for architecture, but simply for pricing, availability, power consumption, I/O driving or even package choice - even if the chosen register/instruction set makes a programming task more difficult.
Quote:
scalability to different products is limited,
Again irrelevant? This is not an academic school project with grade based on how ultraportable code, etc. It's about getting the job done at minimum cost.
Many of these type of designs are treated as one-shot products with no intention of code reuse, update, etc. As it is, the coding for the calc is most likely in C so that's "portable enough". Any portability concern is more toward doing the same product on a new chip if there are supply concerns, than reusing the code base for a new, different product. As it stands, they could do an initial re-port over to an 8051 or 6805 or H8 design in a few days max.
Quote:
and it's an obscure brand so presumably 3rd party tools would not be nearly as mature, and supply longevity would have to be questionable.
Obscure? The fact you haven't heard of them doesn't mean they don't ship in volume. I imagine there's could be 100 - 500 million shipped products with varioous Sunplus chips in them, and that could be on the low side. Calculators, translators, alarm clocks, talking & automated toys, cheaper appliances, etc. all use Sunplus CPUs.
Supply longevity to get thru a sequence of production runs is good enough. No one cares about 2 years from now.
Quote:
Although if it is truly 6502 compatible then that would solve the tool issue. [/quite]
Again irrelevant. Any CPU vendor will supply tools to a volume customer. They either create the tools themselves or have a relationship with a tool provider (like HiTech, who makes C compilers for various micros) It's almost a given - C compiler, assembler, linker and (maybe) some sort of debugger or monitor. Otherwise you can't sell your chip. [Maybe JTAG support added on bigger chips.]
[quote]Perhaps the choice came down to price?
Dude, it ALWAYS comes down to price - sometimes prior working relationships help, as Kinpo and Sunplus (or Sunplus') successor have had an ongoing relationship for some years.
Quote:
Anyone know if HP would code their calculators in C or assembler?
HP doesn't code anything anymore for this kinda product. Kinpo would be doing the work. 99% chance it would mostly be in C - some startup code in assembly, maybe some optimized I/O driver stuff, although I know it could readily be done all in C. A 1MHz 65C02 can reliably even 100% *emulate* an HP41C calc at full speed or more. Perhaps there some optimized BCD math routines in assembler, but there's probably not that much reason for it.
Having just about everything in standard C (plus or minus a few compiler+architecture dependent features) pretty much means architectural considerations are moot.
Bill Wiese
San Jose, CA
| 
Go back to the main exhibit hall