Searching \ for 'PIC wish list' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC wish list'.

Truncated match.
PICList Thread
'PIC wish list'
1995\05\19@165202 by Kalle Pihlajasaari

flavicon
face
Hi to MICROCHIP,

It seems like you guys are going to be in the forefront of little chips
for a while at least, the PIC looks to be increasing in popularity as
far as the trade literature is concerned.

Just a few things that would be realy convenient on a new design :

       A Uart as suggested (in a 20 pin dip with extra rx, tx pins )
       EEPROM technology with partitioned protection like some of them)
       Flat address space, all the tools use 8/16 bits, sacrifice the
              chip real estate and make the mem 16 bit and use the
              extra 2-4 bits for getting rid of the address latches
              and allow the goto and gosub to be regular, a must for
              efficient high level languages.
       A larger full width return stack, 32 deep say so one does not
              have to worry about what happens when there is a table
              lookup and a simultaneous interrupt servicei, also makes
              a compiler more likely to generate secure code.
       A potential data stack (as mentioned by someone already, could be
              implemented with existing opcode set) also 32 deep to
              allow for packets of data or strings to be passed also
              vital for high level languages.

Basically what I suggest and what seems to be the general concensus, the
users want the chips to perform simple tasks well so that the code is
fast to develop.  I think that the better the ports of the 'high level'
languages are the more big money is prepares to use the devices, a lot
of people have a fear of a risk processor that has a non linear address space
and cannot hide this behind a well behaved compiler.

I love the speed of the devices but would be happy with a 40MHz device :-)

Kalle
--
Kalle Pihlajasaari     spam_OUTkalleTakeThisOuTspamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

1995\05\20@182405 by Eric Smith

flavicon
face
On 19 May 1995, Kalle Pihlajasaari <.....kalleKILLspamspam@spam@DEVICE.DATA.CO.ZA> said:
> Just a few things that would be realy convenient on a new design :
...
> A larger full width return stack, 32 deep say so one does not
...
> A potential data stack (as mentioned by someone already, could be

I can understand (and agree with) the desire for a data stack, but why does
everybody keep saying they want a really deep return stack?  I've written many
PIC programs for both the 5x and the 6x/7x/8x parts.  While I've often had to
go through contortions to make my code work on the 5x, I have yet to need
more than six of the eight levels available on the 6x/7x/8x, including some
non-trivial interrupt processing.  I'd really like to see some examples of PIC
code that need more than eight levels.

I'd personally much rather see extra transistors thrown at a data stack or a
second FSR and IND (like the 17C42) than more return stack I don't need and
won't use.

On the other hand, since the return stack couldn't be needed in the same
instruction cycle as a data stack access*, it could be turned into a combined
data/return stack and made deeper.

Cheers,
Eric

* except perhaps in the case of interrupts, but I wouldn't mind if it took
 one extra cycle to push the PC.  Since the current 14-bit core is broken in
 this regard anyhow (interrupting an instruction that changes PCL will push
 the wrong return address), this would actually be a win if it fixed the
 problem.


'PIC wish list'
1998\01\13@143935 by alex_holden
picon face
I was just wondering what things others would most like to see
implemented in PICs (or even other microcontrollers such as Atmel).
Perhaps the fabled 'Microchip Lurkers' could pass on the best ideas to
their R&D department! Here are some of my ideas:

Flash or EEPROM program memory in as many devices as possible. CERDIPs
are too expensive, and take too long to erase.
Fix the evil code protect fuse bug (or is it a _feature_??). I wonder
how many PICs have been needlessly trashed through the accidental
setting of the code protect fuse?
More counter/timers and more than one programmable prescaler in the
small devices. I always seem to run out of them!
14 bit 8 pin devices. I thought I had seen the last of TRIS instructions
;)

What other ideas do you have?
--
-----------------------------------------------------------------------
: Alex Holden- Electronics student, Caver, and Land Rover enthusiast. :
:        http://www.geocities.com/CapeCanaveral/Lab/1532/             :
------------  Linux- The choice of a GNU generation.  -----------------

1998\01\13@161332 by Andrew Mayo

flavicon
face
Hear hear!. But also my pet gripe. Please may we have a CMP instruction.
It is very aggravating that you cannot test a register for a value
without destroying W or another register (AFAIK). And could Mchip take
the individual responsible for the bizarre sublw instruction and the
backwards behaviour of the C flag and shoot him or her before they
design any more microcontrollers. Finally can we have an instruction to
save W and status when servicing an interrupt and another to restore
them to avoid this silly swapf mumbo-jumbo - ingenious but peculiar.

Take heart - code-protected devices *can* be saved - use a germicidal UV
lamp to restore them from the dead - takes about 10 mins. Feeble EPROM
erasers don't cut it for this task.

PS: has anyone heard any news about the Scenix chip - I still think its
the hardware equivalent of vapourware but others have said it does
exist.

{Quote hidden}

1998\01\13@182639 by davewave

flavicon
face
How about I2C interface on a low-pin-count PIC? Or dual I2C interfaces on
chip that could be either master or slaves? A PIC with both EEPROM memory
and A-to-D? Even better would be a PIC that had built in USB support, but I
am sure that I'll end up using Motorola 68HC705(XXX) MCU's for all my USB
projects. USB is the next big thing in PC peripherals, and Microchip will
probably miss the boat. For those unfamiliar with USB, check out
http://www.usb.org/

I agree with Andrew about sublw and the C flag. Here are two macros I use to
make my code more readable:

skpb    MACRO
       btfsc   STATUS,C        ; skip if borrow from last subtraction
       ENDM

skpnb   MACRO
       btfss   STATUS,C        ; skip if no borrow from last subtraction
       ENDM

Unbelievable that these macros are not built into MPASM.

Dave

Andrew Mayo wrote:

{Quote hidden}

1998\01\13@184204 by )

flavicon
face
Andrew Mayo wrote:

> Hear hear!. But also my pet gripe. Please may we have a CMP
> instruction.
> It is very aggravating that you cannot test a register for a value
> without destroying W or another register (AFAIK). And could Mchip take
> the individual responsible for the bizarre sublw instruction and the
> backwards behaviour of the C flag and shoot him or her before they
> design any more microcontrollers. Finally can we have an instruction
> to
> save W and status when servicing an interrupt and another to restore
> them to avoid this silly swapf mumbo-jumbo - ingenious but peculiar.
>
I'd go along with that 10,000%! While we're at it, how about being able
to indirectly address individual register bits, so you could step your
way through register bits for various bit tests and operations.

> Take heart - code-protected devices *can* be saved - use a germicidal
> UV
> lamp to restore them from the dead - takes about 10 mins. Feeble EPROM
> erasers don't cut it for this task.
>
And they're really really really sanitary when you're done, too! ;-)

-Frank


Frank Richterkessing

@spam@FRANK.RICHTERKESSINGKILLspamspamAPPL.GE.COM

1998\01\13@194049 by Walter Banks

picon face
> . . .   the bizarre sublw instruction and the backwards
> behaviour of the C flag

There are three common ways to do a subtract,Microchip uses
one of them in the PIC's and 6502 and 6805 use the other two.
They all treat the carry different. This is the main reason that
assembly code cannot be easily translated with macros from
one processor to the next.

1998\01\13@202755 by Andrew Mayo

flavicon
face
well, yes, but most mortals want to subtract literal x from the value y
in the accumulator, not the other way round, and to be honest I've never
seen another microcontroller with such a strange instruction. Apparently
it allegedly has a use, but what that is I can't remember. You end up
doing addlw -20 which hardly helps readability. Or defining a macro.

{Quote hidden}

1998\01\13@235115 by tjaart

flavicon
face
{Quote hidden}

My wish is that Mchip would listen to wish lists like this one in
stead of wasting time in court. There. I said it.

--
Friendly Regards

Tjaart van der Walt
tjaartEraseMEspam.....wasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26¡10.52'S 28¡06.19'E                 |
|_____________________________________________________________|

1998\01\14@024035 by »yvind Standal

flavicon
face
MORE INTERRUPT VECTORS.  PREFERABLY ONE VECTOR FOR EACH INTERRUPT

regards ¯yvind Standal

----------
From:   Alex Holden[SMTP:EraseMEalex_holdenspamGEOCITIES.COM]
Sent:   13. januar 1998 20:44
To:     RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU
Subject:        PIC wish list

I was just wondering what things others would most like to see
implemented in PICs (or even other microcontrollers such as Atmel).
Perhaps the fabled 'Microchip Lurkers' could pass on the best ideas to
their R&D department! Here are some of my ideas:

Flash or EEPROM program memory in as many devices as possible. CERDIPs
are too expensive, and take too long to erase.
Fix the evil code protect fuse bug (or is it a _feature_??). I wonder
how many PICs have been needlessly trashed through the accidental
setting of the code protect fuse?
More counter/timers and more than one programmable prescaler in the
small devices. I always seem to run out of them!
14 bit 8 pin devices. I thought I had seen the last of TRIS instructions
;)

What other ideas do you have?
--
-----------------------------------------------------------------------
: Alex Holden- Electronics student, Caver, and Land Rover enthusiast. :
:        http://www.geocities.com/CapeCanaveral/Lab/1532/             :
------------  Linux- The choice of a GNU generation.  -----------------

1998\01\14@032030 by John Payson

picon face
> > There are three common ways to do a subtract,Microchip uses
> > one of them in the PIC's and 6502 and 6805 use the other two.
> > They all treat the carry different. This is the main reason that
> > assembly code cannot be easily translated with macros from
> > one processor to the next.

> well, yes, but most mortals want to subtract literal x from the value y
> in the accumulator, not the other way round, and to be honest I've never
> seen another microcontroller with such a strange instruction. Apparently
> it allegedly has a use, but what that is I can't remember. You end up
> doing addlw -20 which hardly helps readability. Or defining a macro.

It is true that sublw is used much less frequently than addlw; it would
not be a particular loss had Microchip omitted it from the instruction
set.  On the other hand, there would be little reason for Microchip to
spend silicon on an instruction which--as you acknowlege--can be done
just as well with an assembler macro (which requires no silicon).  For
the "subwf" instruction, the operation [result=f-w] seems odd unless
you consider that, in practice, people are often going to want to subtract
one variable from another.  This takes two instructions on the PIC:

       movf    source,w
       subwf   dest,f  ; dest=dest-source

whereas if the instruction were instead "subfw" it would take three ins-
tructions:

       movf    dest,w
       subfw   source,w        ; Note: not a real PIC instruction
       movwf   dest

While I acknowlege that "subfw reg,w" would be perhaps more useful than
"subwf reg,w" the usefulness of "subwf reg,f" more than makes up for that.
As for the carry flag on subtract, it's 6502-style rather than Intel-style
but I don't see that as a real problem; you just need to remember how it
works when you code it.

1998\01\14@082437 by Walter Banks

picon face
>
> There are three common ways to do a subtract,Microchip uses
> one of them in the PIC's and 6502 and 6805 use the other two.
> They all treat the carry different. This is the main reason that
> assembly code cannot be easily translated with macros from
> one processor to the next.

It is the use of the carry bit I was refering to not the
instruction syntax (which is I believe unique) The carry
following subtract on the Microchip PIC's is one of the
three results possible in all of the implementations that
I have encountered. It is the same result as a 6502 except
for the subtract 0 case.

The difference is the carry bit shows the results of the
last operation in the process. Take the following examples
with both a and b set to 0

result = a + ~b + 1   Carry=1
 or
result = ~b + 1 + a   Carry=0

Walter Banks

1998\01\14@091319 by Keith Howell

flavicon
face
Andrew Mayo suggested shooting the person (ir)responsible
for the bizarre sublw instruction and
the backwards behaviour of the C flag

Personally I think this is far too quick.
Even if they were shot somewhere not swiftly fatal.
Some supernatural punishment would be appropriate.
Prometheus had his liver pecked out by a giant eagle
day after day (it grew back) for stealing fire from
the gods. Perhaps in an afterlife, the chip designers
will suffer the frustration of every programmer who had
to use their chips.

I can think of many moans about PICs.
Had the original architects ever seen other microprocessors?
This might explain why they have their own unique terms, i.e.
"file" where almost everybody else uses "register"
"w file" ... "accumulator"
"literal" ... "constant"

I'd like to see bit-operators that actually work on just the one bit!
I know the Read/Modify/Write cycle is fine on internal registers,
but it requires careful thought to avoid problems on I/O ports.
I know you can work-around this by byte operations.
I'd accept this if my program spent most of its time processing,
but the raison d'etre for most PICs is to twiddle I/O bits. A lot.
A pretty fundamental architectural screw-up I think.

I'd also like some proving code.
By this I mean that if a chip maker says it can drive the I2C bus,
lets see the code they used to prove that it works.
Don't say "read the application notes".
I have. They don't demonstrate the full I2C bus specification.
Either they have or have not got proving code.
If they have, why not publish it instead of these half-baked
application notes? It would sure be a help to PIC programmers.
If they have not, then they're not entitled to say the chip works
to spec.

I'd like to see instruction sets start to look a bit more like
       r[a]  = r[b]            r[a]  = constant
       r[a] += r[b]            r[a] += constant
       r[a] -= r[b]            r[a] -= constant
       r[a] |= r[b]            r[a] |= constant
       r[a] &= r[b]            r[a] &= constant
       r[a] ^= r[b]            r[a] ^= constant
       bit[a] = 1              bit[a] = 0
       bit[a] = bit[b]         bit[a] = !bit[b]
The bit copying instructions would be nice (copy true or inverted).
PICs do a lot of bit-level operations!

I wish they'd get rid of all the existing complaints mentioned
by others in this thread.

I wish that all PIC instruction sets had a register specification field
that was always wide enough to uniquely address any one of all
the registers it has. So nobody has the huge headache of
data page management.

I wish that all PIC instruction sets had a address specification field
that was always wide enough to uniquely address any one of all
the code locations it has. So nobody has the huge headache of
code page management.

I wish they had on-chip serially-programmed Flash code memory

I wish they had in-site programmability.
Not as easy as you think. You can't easily power the PIC in isolation,
and even if you could, how will the I/O pins behave? You don't want
them doing anything undesirable through the items they're
connected to. I've seen some published articles about how to
implement in-site programmability. Typically by having controlled
buffers surrounding the I/O pins. But of course this is prohibitive in
cost-sensitive apps requiring PICs.
If you have the ability to set the I/O pins during programming,
you're heading toward JTAG testing!

I wish they had verifiable code.
As it is, code-paging makes things such that you can't even
disassemble jumps and branches to unique locations!

1998\01\14@144740 by wwl

picon face
On Wed, 14 Jan 1998 13:49:51 +1300, you wrote:

>well, yes, but most mortals want to subtract literal x from the value y
>in the accumulator, not the other way round, and to be honest I've never
>seen another microcontroller with such a strange instruction.
doesn't mean it's not a good thing - skip instructions were also not
that common until recently

>it allegedly has a use, but what that is I can't remember. You end up
>doing addlw -20 which hardly helps readability.
OK, then write a 'subwl' macro then!

If they'd done it the other way round, it would be a waste of  silicon
as you can acheive the same thing using addlw. Having a literal - W
function provides extra functionality. I find it useful for doing 2's
complements with sublw 0 - very handy for finding absolute values :

movlw a
subwf b
skpc
sublw 0

    ____                                                           ____
  _/ L_/  Mike Harrison / White Wing Logic / RemoveMEwwlspam_OUTspamKILLspamnetcomuk.co.uk  _/ L_/
_/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...