Post by thread:PIC wish list

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_OUTkalleTakeThisOuTdata.co.za Interface Products Box 15775, Doornfontein, 2028, South Africa +27 (11) 402-7750 Fax: +27 (11) 402-7751

On 19 May 1995, Kalle Pihlajasaari <.....kalleKILLspam@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.

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. -----------------

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}> ---------- > From: Alex Holden[SMTP:alex_holdenKILLspamGEOCITIES.COM] > Reply To: .....alex_holdenKILLspam.....geocities.com > Sent: Wednesday, January 14, 1998 4:27 PM > To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.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. > : > : www.geocities.com/CapeCanaveral/Lab/1532/ > : > ------------ Linux- The choice of a GNU generation. > ----------------- >

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}> 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. > > > From: Alex Holden[SMTP:alex_holdenspam_OUTGEOCITIES.COM] > > > > 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?

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.RICHTERKESSINGKILLspamAPPL.GE.COM

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}> ---------- > From: Walter Banks[SMTP:KILLspamwalterKILLspamBYTECRAFT.COM] > Reply To: pic microcontroller discussion list > Sent: Wednesday, January 14, 1998 12:26 PM > To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: PIC wish list > > > . . . 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. >

{Quote hidden}> ---------- > From: Alex Holden[SMTP:spamBeGonealex_holdenspamBeGoneGEOCITIES.COM] > Reply To: TakeThisOuTalex_holdenEraseMEspam_OUTgeocities.com > Sent: Wednesday, January 14, 1998 4:27 PM > To: RemoveMEPICLISTTakeThisOuTMITVMA.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? 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 tjaartEraseME.....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 | |_____________________________________________________________|

MORE INTERRUPT VECTORS. PREFERABLY ONE VECTOR FOR EACH INTERRUPT regards ¯yvind Standal ---------- From: Alex Holden[SMTP:EraseMEalex_holdenGEOCITIES.COM] Sent: 13. januar 1998 20:44 To: RemoveMEPICLISTEraseMEEraseMEMITVMA.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. -----------------

> > 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.

> > 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

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!

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_OUTKILLspamnetcomuk.co.uk _/ L_/ _/ W_/ Hardware & Software design / PCB Design / Consultancy _/ W_/ /_W_/ Industrial / Computer Peripherals / Hazardous Area /_W_/