Post by thread:Embedded assignment

Hi there I have an assignment for embedded systems titled "critical appraisal of Microchip PIC family" and thought that the PIC-list would be the best place in the world to get ideas on what the good and bad points of the PIC family are. Don't get me wrong, I'm no trying to get you to do my work for me, but what better place to get some feedback. I already have some ideas such as the I2C support on the PIC's, but what else don't you like and what do you think the really bad points are. I for one would love to have a larger stack and access to it for parameter passing. My embedded systems lecture doesn't like the PIC and I would like to change his attitude. Regards Gavin -------------------------- spam_OUTvulcanTakeThisOuTihug.co.nz ICQ# 18675389 www.geocities.com/TheTropics/Cabana/2625 --------------------------

Gavin The PIC line of processors in my opinion are the best value for the money. The only thing(s) that I wish were different or improved is (1) I wish there were more EPROM/EEPROM/FLASH program space available, (2) I wish there was more RAM available, and (3) I wish Microchip could afford to give away a good 'C' compiler or maybe a good 'BASIC' compiler or Assembler like they do the other development tools. Mind you, I don't believe the things I mentioned to be negatives, just improvements that I would like to have available. Presently, I use either Assembly Language or the CCS PCM 'C' Compiler, and I am very satisfied with both of these methods. By the way, I also think the CCS 'C' compiler to also be a good value for the money. Hope this helps you out, and I would like to read your finished product when it becomes available if that is possible. Regards, Jim {Quote hidden}> From: Gavin Jackson <.....vulcanKILLspam@spam@IHUG.CO.NZ> > To: PICLISTKILLspamMITVMA.MIT.EDU > Subject: Embedded assignment > Date: Saturday, October 17, 1998 9:21 PM > > Hi there > > I have an assignment for embedded systems titled > "critical appraisal of Microchip PIC family" and thought > that the PIC-list would be the best place in the world > to get ideas on what the good and bad points of the > PIC family are. Don't get me wrong, I'm no trying to get > you to do my work for me, but what better place to get > some feedback. > > I already have some ideas such as the I2C support on the > PIC's, but what else don't you like and what do you think > the really bad points are. I for one would love to have > a larger stack and access to it for parameter passing. > > My embedded systems lecture doesn't like the PIC and I > would like to change his attitude. > > Regards > > Gavin > -------------------------- > .....vulcanKILLspam.....ihug.co.nz > ICQ# 18675389 > www.geocities.com/TheTropics/Cabana/2625 > --------------------------

In a message dated 10/17/98 8:43:22 PM Pacific Daylight Time, EraseMEvulcanspam_OUTTakeThisOuTIHUG.CO.NZ writes: > I have an assignment for embedded systems titled > "critical appraisal of Microchip PIC family" and thought > that the PIC-list would be the best place in the world > to get ideas on what the good and bad points of the > PIC family are. Don't get me wrong, I'm no trying to get > you to do my work for me, but what better place to get > some feedback. > > I already have some ideas such as the I2C support on the > PIC's, but what else don't you like and what do you think > the really bad points are. It always bothers me when people feel that they have to emphasize bad points when reviewing products. Because you are specifically asking for the really bad points, I would like to provide some balance by stating that I appreciate the Microchip family for what it is. This family of processors is cheap, readily available in small quantities, and includes members with a wide range of capabilities. > I for one would love to have a larger stack and access to it for parameter passing. My favorite members of the Microchip family are the early models which only have a 2 level stack and 12 bit opcodes. While these chips offer more of a programming challenge (especially when crossing page boundaries), they are less expensive and operate over a wider voltage range. Although they are guaranteed to work from 3.0 to 6.25 V, I have found that by taking suitable precautions they will work reliably down to 2.5 V. This allows them to be run from a single Lithium battery. I would never attempt such a design with the newer members that are only guaranteed to operate with a 4 V supply as a minimum. > My embedded systems lecture doesn't like the PIC and I would like to change his > attitude. It's not fair for someone to simply state that he doesn't like the PIC without specifying the environment in which the PIC is being considered. The PIC is intended to satisfy a particular market. The best processor choice depends on many factors such as the quantity of units expected to be sold over the lifetime of the product and how long you can wait for delivery. I once designed a specialized PC keyboard using a Motorola processor. I spent a couple of months perfecting my design only to find that Motorola stopped producing the chip I needed while it fulfilled a large order from the auto industry. I was quoted vague lead time in excess of 6 months with possibilities of 9 months or more. The entire project was lost after I developed a working prototype just because I couldn't get reasonable delivery times for the controller. I have never had to wait for any Microchip controller. Bob

In terms of bang for the buck, you can't go wrong with PIC's. I have used only the 8 pin 12C508/9 and the 16 pin 16C(F)84, but have the following observations: ===WHAT I LIKE ABOUT PICS=== - A very easy to learn assembler language. - I love the fact that on a 4Mhz device, each instruction operates in 1 microsecond. This makes it extremely easy to calculate precise delays, loops, etc. - The amount of public domain support for PICs is phenomenal. There are literally thousands of web sites with programmer schematics, source code examples, and tutorials. With nothing more than an Internet connection and a few dollars of spare parts to build a programmer, a person can get started with PICs and can find the information needed to successfully complete PIC based projects. I doubt this support exists to the same extent for other microprocessors. - The number of different interrupt sources on the 16C(F)84 devices. This makes these devices very flexible and able to be applied to a wide range of problems. - The wide variety of PIC devices available. You can select a PIC with the number of pins and the features you need for your application. - The price of the PICs themselves, particularly the OTP versions ($1.79 for a 12C508). This can greatly reduce the price of a project. ===PIC WISH LIST=== - A single cycle/single instruction for moving one file register to another. - Interrupts for the 12 bit, 8 pin devices. - Multiple general purpose registers (instead of just W). - Better comparison facilities within the language. In PC assembler you have instructions (if I remember correctly) like JGT (jump greater than) JE (jump if equal), etc. On the PIC you need to perform some logical or arithmetic operation, then test status bits to determine whether or not to jump. If there were just a compare instruction and a few more status bits, you could then do a normal BTFSx instruction to determine where to branch to. - More EEPROM or Flash based devices (like the 16C(F)84). Particularly an 8 pin device. I realize that many of my wish list items are just not possible due to the architecture of the PICs (i.e. moving a file register to another file register in one cycle/instruction), but certainly expanding the range of EEPROM/Flash devices would only expand the appeal of PICs even more. Sorry for the long message, just my 2 cents worth. Adam vulcanspam_OUTIHUG.CO.NZ on 10/17/98 07:21:28 PM Please respond to @spam@PICLISTKILLspamMITVMA.MIT.EDU To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU cc: (bcc: Adam Bryant/PEAK/MOORE) Subject: Embedded assignment Hi there I have an assignment for embedded systems titled "critical appraisal of Microchip PIC family" and thought that the PIC-list would be the best place in the world to get ideas on what the good and bad points of the PIC family are. Don't get me wrong, I'm no trying to get you to do my work for me, but what better place to get some feedback. I already have some ideas such as the I2C support on the PIC's, but what else don't you like and what do you think the really bad points are. I for one would love to have a larger stack and access to it for parameter passing. My embedded systems lecture doesn't like the PIC and I would like to change his attitude. Regards Gavin -------------------------- RemoveMEvulcanTakeThisOuTihug.co.nz ICQ# 18675389 www.geocities.com/TheTropics/Cabana/2625 --------------------------

Adam Bryant wrote: > ===PIC WISH LIST=== Ah, I enjoy participating in these pointless wish lists ... ;-) Pointless only because I have *no idea* what the real volume market is asking for, nor do I believe Microchip should necessarily be listening to a PIC proponent such as myself. Product adoption population is a bell curve ... 5% evangelists, 25% early adopters, 60% core, 25% late adopters, and 5% laggards. You don't need to sell a product to the evangelists, they will sell it for you. You concentrate on the early adopters, because the core will follow them. Late adopters don't take on a product until the core has. Laggards can be safely ignored. I see the PIClist as the PIC product range's 5% evangelists. > - A single cycle/single instruction for moving one file register to > another. Yes, you are right, I'd say this isn't trivial to achieve. I've also been hard pressed to understand a situation in which I'd need to do this, other than when reading or writing to a port. > - Interrupts for the 12 bit, 8 pin devices. Yep, that'd be cute. Also eight level stack. > - Multiple general purpose registers (instead of just W). Um, that would achieve nothing. Access to file registers is just as fast as access to the accumulator. Adding multiple non-file registers would also cause an expansion of the instruction width. It would be more registers to worry about and save in an interrupt. > - Better comparison facilities within the language. Use macros. > - More EEPROM or Flash based devices (like the 16C(F)84). Particularly > an 8 pin device. Yes. Yes. Drool. Either take the 12C509 design and make it Flash, or take the 16F84 design and cram it down ... MCLR would have to go, and the OSC pins would have to be general purpose I/O as well. Internal trimmed R/C oscillator. But of course sell it for the same price as a 12C509. ;-) Yeah, right. ;-( -- James Cameron (spamBeGonecameronspamBeGonestl.dec.com) Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

>>QUOTE>> > My wish: literal with f operations; ANDLF, IORLF, especially XORLF, > etc. Um, dream on? Who wants to pay for 8 bits of literal _and_ n bits of file register address? That would make the instruction stream eight bits wider. ;-} <<UNQUOTE<< How about an instruction which specifies a literal or f-register to be used in place of the "W" source operand of the next inst- ruction? Registers could then be moved, and'ed, xor'ed, etc. with arbitrarily-selected other registers without affecting W (it would still be a 2-word 2-cycle operation though); better yet, when used with "movwf" it would allow registers to be moved around without trashing flags. Such an instruction would need some special logic in the ALU chain to latch W's "replacement", but there exists plenty of space in the existing 14-bit parts' opcode map to allow both literal and f-register versions. The second thing I'd like to see, though there's no room for it in the opcode map, would be an instruction which toggles bit 10 (or equivalent) of the next instruction in the prefetch queue if a specified bit in memory is set. This would allow a two-cycle bit- to-bit move (with or without complementing) as well as various other tricks. Finally, I'd like to see a better I/O banking scheme. The 14-bit parts are okay, but the 16-bit parts are really horrible in this regard. Especially if you have an 8-bit address, you should have IMHO at least three addresses always available for each port: [1] The "tristate" latch [2] The "output" latch [3] The input state (this address could be shared with a write- only register). Even on parts with eight I/O ports, that would be 24 addresses out of 256; I'd much rather have a slightly smaller direct-addressible memory space than have to bank switch any time I want to do I/O. Attachment converted: wonderland:WINMAIL.DAT 5 (????/----) (0001BE7B)

John Payson wrote: > >>QUOTE>> > > My wish: literal with f operations; ANDLF, IORLF, especially XORLF, > > etc. > > Um, dream on? Who wants to pay for 8 bits of literal _and_ n bits of > file register address? That would make the instruction stream eight > bits wider. ;-} > <<UNQUOTE<< I claim authorship of the second paragraph above. It was unattributed. > How about an instruction which specifies a literal or f-register > to be used in place of the "W" source operand of the next inst- > ruction? Perhaps we are falling for the view of the silicon from outside rather than from inside? I can imagine that plenty of optimisations have gone into the simple instruction model which may just prevent this sort of thing from working. -- James Cameron (RemoveMEcameronTakeThisOuTstl.dec.com) Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

John Payson wrote: > Even on parts with eight I/O ports, that would be 24 addresses out > of 256; I'd much rather have a slightly smaller direct-addressible > memory space than have to bank switch any time I want to do I/O. Hear hear! This is my biggest complaint with their stuff. If they want to get rid of option and tris, fine, but at least do it in a way where you don't have to go through a bunch of hoops to do I/O. Tris registers in the same order as the ports 16 or 32 spaces higher would have been a much better way to go. The compiler can keep track of ram well enough I don't care if it's not all contiguous, but two or three extra commands to get to the Tris registers is unreasonable.. Alan