'Wishlist for future PIC'
|I think the time has come for another wish list (IMHO). I guess I'm
provoking MicroChip a little bit by this list, but I still think it is
worth serious consideration. The opinions as expressed are my own, but
they are shared by several friends in small AND large companies here.
I welcome comments.
1) Fuse matrix for selection of peripherals
- One application seldom uses all features
- Reduces stock
- Map registers only to peripherals that are used
- Select pins for optimal layout
2) Fewer types of PICs
- Fewer bugs
- Don't want a zillion "family modules"
3) Map top-of-stack to register file
- Use PCLATH for high part
- For Multi-tasking
- Simplifies high-level language implementation
4) Multiply instruction (but not like 17Cxx)
- Separate instructions for low and high byte
- Can also be used as fast shifter
- Application: signal processing
5) Flash PROM (Yes, again :-)
1) Fuse matrix for selection of peripherals --------------------
I'd like a fuse matrix, where I can enable the peripherals that I need for a
application. I hardly ever use all peripherals in any application. It would mean
have to use so many different parts. If registers are mapped only to peripherals
that are used,
precious register space is saved. It is also useful to be able to connect
peripherals to pins
that are suitable for an optimal board layout.
(Obviously, it means a larger die. Die size must traded for the other
2) Fewer types of PICs --------------------
(Related to item 1.) Fewer PICs means there are fewer designs that
must be tested, which means more effort could be spent verifying the
designs, and perhaps correcting know mask bugs. Currently, we have to
get different "family modules" for nearly every new PIC we want to use
with an ICE. One vendor even requires both a family module and a
3) Map top-of-stack to register file --------------------
(Byron A Jeff <GEMINI.CC.GATECH.EDU> also mentioned this on the byron
PIClist recently.) The top-of-stack should be mapped on a register,
and the high part transferrable to/from PCLATH. This would make
multi-tasking possible, and simplify high-level language
4) Multiply instruction (but not like 17Cxx) --------------------
There should be a multiply, but I think it should be implemented as two
instructions: One for producing the low byte, and one for the high
byte. 17Cxx uses special registers for the result. I think it is
better with two instructions and ordinary registers, because in many
cases, one byte is necessary. Most of the cycles are taken by moving
data between registers, anyway. I guess this might also fit
the data paths better in the 16Cxx design.
Such a multiply could be also used as a fast shifter.
One of the major applications would be low-end signal processing. With
multiply, simple digital filtering of audio signals would be easily
within reach for the PIC 16Cxx. Imagine what could be done with a 16Cxx
with A/D, multiply, and D/A...!
5) Flash PROM --------------------
Once upon a time (actually about a year ago), someone @microchip.com wrote:
> However, we are still a relatively small company and out of the
> 1,000,000 things we have to do, program memory EEPROM PIC's are about
> number 736,492.
Byron A Jeff <GEMINI.CC.GATECH.EDU> wrote: byron
> > Is there
> > to be a EEPROM version of this chip in the future?
> Don't know. Most times whenever someone asks about more EEPROM parts
> The response from Microchip has been along the lines of "too slow, not
> cost effective, no request from real (read thousands of units).
Well, I think those days are now history. New Flash PROM
technology is approaching DRAM speed. Motorola, Siemens, Hitachi, and
Atmel are all releasing MCUs with FlashPROM. I have a news article
claiming that one of Motorola's has 256kbyte Flash with access time 20ns,
runs 33MHz, and takes a 3.3 V supply.
It is a pity MicroChip lost their early initiative here, but I'm sure
they are aware of the competition. If not, they may find themselves in
trouble. Cf. the following message from comp.robotics by
oms.de (Martin Luerssen): martin_luerssen
> > Now, Great idea, eh? But now how do I build it? I was thinking a
> >specificly a PIC(Why the PIC? Because it's the only one with a simple
> >that I could build, and find on the net)
> > Now my question would be- Is this possible? Would it be possible to build
> >device with a PIC or any other type of microcontroller?
> Sure. Personally I'd prefer an Atmel AT89C2051 or AT89C1051.
> They are easier to program than the PIC - Devices, are cheap and can be very
> easily programmed.
> They have 2K ( or 1K for 1051 ) of Flash-Memory integrated, so you can
> your Software, test it, program a new Version, program it, test it etc. until
> >through a parallel port but hey, I am not picky.
> You can use the On-Chip UART of the 89C2051 for a simple RS-232-Connect with
> another Computer.
I find Atmel interesting in particular because of their plans to
release an ARM with Flash PROM. I have previously used AMD 29k for my
high-end applications. After being let down by AMD (29k was really
great, >sigh<), I'm looking around for a successor. While Intel
80xxx, M683xx, Hitachi H8/H16, and PowerPC are less interesting for a
variety of reasons, ARM with Thumb stands out pretty clearly. It works
in variety of high-speed and/or low-power technologies, and exciting
new designs are based on it, e.g. the completely asynchronous AMULET
at the University of Manchester (UK). I wish MicroChip looked that way
for their high-end plans...
I would be interested in hearing opinions by any of you who have used
Martin Nilsson http://www.sics.se/~mn/
Swedish Institute of Computer Science E-mail: sics.semn
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
|Martin Nilsson <SICS.SE> wrote: mn
> I'd like a fuse matrix, where I can enable the peripherals that I need for
> a particular application. I hardly ever use all peripherals in any
> application. It would mean I didn't have to use so many different parts. If
> registers are mapped only to peripherals that are used, precious register
> space is saved. It is also useful to be able to connect peripherals to pins
> that are suitable for an optimal board layout.
> (Obviously, it means a larger die. Die size must traded for the other
You're talking about a *much* larger die. I mean, maybe it wouldn't be
a lot larger than a 16C74, but it would be a lot bigger than a 16C620. And
cost increases more than linearly with die area. I don't want to pay '74
prices for a '620; the reason I use PICs is that they are *cheap*; I don't
want to start paying more.
Maybe such a part would be useful for development; on the other hand, I would
never trust it to exactly match the actual behavior and performance of the
final part. As it is, I typically use a 16C74, 16C622, or 16C84 for
prototyping, even when I plan to use a smaller part. That way I can just buy
a lot of "JW" parts of only a few models (I don't believe in waiting for
the eraser to beep), and maybe just one or two each of the others.
Mark K Sullivan
I second Eric. I want PICs to get cheaper, not bigger.
- Mark Sullivan -
In message <brahma.sics.se> 199608251908.VAA23926MITVMA.MIT.EDUPICLIST
> I think the time has come for another wish list (IMHO). I guess I'm
> provoking MicroChip a little bit by this list, but I still think it is
> worth serious consideration. The opinions as expressed are my own, but
> they are shared by several friends in small AND large companies here.
> I welcome comments.
> 2) Fewer types of PICs
> - Fewer bugs
> - Don't want a zillion "family modules"
> 3) Map top-of-stack to register file
> - Use PCLATH for high part
> - For Multi-tasking
> - Simplifies high-level language implementation
I like the idea of this.
I would like a decrement if non-zero command. I use lots of down
counters in some of my projects, and would like a single instruction
to replace to following:
movf DownCtr, f
btfss sts, z
decf DownCtr, f
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...