Post by thread:Greetings from Microchip !!!

Hello, PICLISTER's. Yes, the factory is actually listening. We have been duly monitoring the various conversation threads looking for your great ideas for improvements to our products, etc. On Friday, I asked if a moderator was present. We absolutely do not intend to pollute the list with marketing type stuff. We maintain a BBS for that. Other than some very specific items, we will rarely post here. We also won't be doing customer support here either. By the way, it is my job to specify the new PIC devices. So, if there's a PIC you want.... Regards, Brian Boles. spam_OUTbbolesTakeThisOuTmicrochip.com

Brian Boles wrote : > BBS for that. Other than some very specific items, we will rarely > post here. We also won't be doing customer support here either. That's a pity - I find email a lot more accessible than the BBS, since it integrates with the rest of my work environment. Using the BBS is only possible from home, and requires a standalone comms program so it isn't easy to include examples or save useful tips. FTP is a good deal more user-friendly than BBS protocols, too, so it's a shame that the FTP filebase seems to lag behind. Perhaps a more automatic gateway could be set up, so that both sorts of users could benefit equally ? Of course, I'm not suggesting that all the BBS comments should be echoed to _this_ list, nor that all customer support should be conducted in public - but I do think that internet-based forms of communication are a good deal more convenient than a standalone BBS, even given the convenient access via Compuserve. -adrian

> By the way, it is my job to specify the new PIC devices. So, if > there's a PIC you want.... What about an onboard CAN controller ? Henri -- ==============> the sanest place is still behind a trigger <================= []-----------------------------------[]-------------------------------------[] || Henri Schultze ||Magdeburg D 39122 Alt-Fermersleben 88|| || henriKILLspamipe.et.uni-magdeburg.de || The Cracker Company || []-----------------------------------[]-------------------------------------[]

> By the way, it is my job to specify the new PIC devices. So, if > there's a PIC you want.... > > Regards, Brian Boles. .....bbolesKILLspam.....microchip.com Brian, I want a PIC with a 12-bit A->D on it instead of an 8-bit! -- -- Paul Greenwood -- (EraseMEpablospam_OUTTakeThisOuTaustin.ibm.com) AAAAAAAAAaaaaaaaaaaaaaaaccccccccckkkkkk!!!!!!!!! You brute! Knock before entering a ladies room!

>Brian Boles wrote : >> BBS for that. Other than some very specific items, we will rarely >> post here. We also won't be doing customer support here either. > >That's a pity - I find email a lot more accessible than the BBS, since >it integrates with the rest of my work environment. Using the BBS is only >possible from home, and requires a standalone comms program so it >isn't easy to include examples or save useful tips. FTP is a good deal >more user-friendly than BBS protocols, too, so it's a shame that the >FTP filebase seems to lag behind. > >Perhaps a more automatic gateway could be set up, so that both sorts of >users could benefit equally ? Of course, I'm not suggesting that all the >BBS comments should be echoed to _this_ list, nor that all customer support >should be conducted in public - but I do think that internet-based forms >of communication are a good deal more convenient than a standalone BBS, >even given the convenient access via Compuserve. > >-adrian I agree with adrian. An FTP server would be much more friendly to use. I have used your BBS, and it is somewhat obnoxious to use. I used the Microchip web site a few times and liked it alot. However, I stopped since it never seem to be completed. Does anyone know when it will be completed? -Maurice Rabb ---------------------- Maurice Rabb Totem Consulting (312) 281-6003 @spam@totemKILLspammcs.com ----------------------

>> By the way, it is my job to specify the new PIC devices. So, if >> there's a PIC you want.... >> >> Regards, Brian Boles. KILLspambbolesKILLspammicrochip.com > >Brian, > > I want a PIC with a 12-bit A->D on it instead of an 8-bit! > >-- > > -- Paul Greenwood -- (RemoveMEpabloTakeThisOuTaustin.ibm.com) Hi Brian, For my two cents (designing high temperature furnace and pressure controllers), a 12 Bit A/D with 8 channels would be worth alot. But then again, what makes the PIC so interesting is how cheap it is and its simplicity. But its nice to dream..... -George Risch (spamBeGonegar110spamBeGonepsu.edu)

Much of my stuff is interconnected with other gizzmos via serial connections (RS232, RS485 etc) and I have to write bit-bashing code for the small parts. This eats into the limited RAM and cycles and must be scheduled by the timer interrupt if you want to do much else. Nirvana for me is a modified 16C84 with: 20 pin skinny = 16C84 + rx and tx pins. On-chip UART More on-chip data EEPROM (maybe 256 bytes rather than 64 bytes) A bit more RAM (128 bytes?) A 28 pin variant of the above with 8 more IO pins would also be major cool! While I'm being greedy, maybe this beast could have 2k program memory. I really think that the small PICs (16x) are great in their niche. I would not use the 17x in a hurry, rather using other devices such as the 8051. -- Charles

> Hello, PICLISTER's. Yes, the factory is actually listening. We have > been duly monitoring the various conversation threads looking for your > great ideas for improvements to our products, etc. > > On Friday, I asked if a moderator was present. We absolutely do not > intend to pollute the list with marketing type stuff. We maintain a > BBS for that. Other than some very specific items, we will rarely > post here. We also won't be doing customer support here either. > > By the way, it is my job to specify the new PIC devices. So, if > there's a PIC you want.... > > Regards, Brian Boles. RemoveMEbbolesTakeThisOuTmicrochip.com I'd like EERAM on a few more low cost devices. Doug Sellner Beach Tech 4131 Vincent Avenue South Minneapolis MN 55410 Voice (612) 924-9193 x 521 Fax (612) 926-1145 Internet: dsellnerEraseME.....embay.com

> By the way, it is my job to specify the new PIC devices. So, if > there's a PIC you want.... > > Regards, Brian Boles. EraseMEbbolesmicrochip.com I have a feeling you may have a large number of requests ;-) Note, I think some of people may go over the top, I hope these ideas are both reasonable and salable to 'Big' customers. So here goes: 1) A 14 bit PIC with 2/4k of EEPROM, a 'real' i2c port, 128 bytes of RAM and a stack (* see below) 2) The above with OTP/EPROM and 20MHz 3) A couple of 14bit processors with a CAN bus (18pin small resource and 40pin l arge resource) 4) A Low voltage (sub 1.5 volt) processor would be really nice sometimes. Thanks =%-) Ian (*) A stack would be really useful for producing high level languages/forth's a nd clean up interrupt code. I figure a 16 byte stack would be OK on a PIC type of device. The optimal interface would be two registers one pushes w (when wri tten to i.e. movwf'ed) and pops into w (when read i.e. movf reg, 0'ed) A second reg ister would be the current top of stack for read and write. This would mean no new instructions would be required and the stack could be made from 8x16bit shift registers + glue logic.

> By the way, it is my job to specify the new PIC devices. So, if > there's a PIC you want.... > I echo other writer's enthusiasm for the EEPROM PICs, though they're made less useful by the lower speed - if this limitation is an inherent problem with putting EEPROM on chip, then the EPROM and OTP parts will stay important. I do find the timer structure on the PICs too simple - capture and one-shot functions would be useful (I think this is partly addressed by the 16c64 timer block so the wider use of this design would be good). Almost all uC timers seem to suffer from speed limitations due to the need to synchronise incoming edges to internal clocks. How about a timer block that can : - use a long prescaler, synchronised by the read operation rather than during counting, so it can count as fast as the crystal prescaler. I know that the - perform phase comparisons between a pair of timer registers so the PIC can be used as a single-chip frequency synthesiser (this might be possible in software using a processor loop as one counter, but I don't know if the phase comparison can be done without introducing jitter. - provide outputs from the timers as well as inputs, so that PWM and PPM can be generated without an interrupt or polling loop latency between the timer overflowing and the output bit changing. For the R/C people who read this list, I'm thinking of an R/C receiver with a single-chip decoder/synthesiser, performing any mixer / trim adjustments in the decoder instead of the transmitter so that there's no need for multiple model memories in the TX. A related application is a decoder with soft error detection : instead of falling back to fixed servo positions when the signal is lost, error correction should be performed to get limited functionality from a poor signal - slowed servo movement perhaps, or coarser positioning. -adrian

> Subject: Re: Greetings from Microchip !!! > By the way, it is my job to specify the new PIC devices. So, if > there's a PIC you want.... > > Regards, Brian Boles. RemoveMEbbolesEraseMEEraseMEmicrochip.com The small ones are good (18 pin), and the large ones look good (40 pin) but I think you 28 pin middle line could use some 'beefing up'. If you put your 14 bit core with 128/36 bytes of ram, eeprom program memory version and eprom program memory versions (1K/2K versions), maybe an SCI or SPI port, one TMR0, into a 28 pin package (20 i/o's), that'd be good. Any 14-bit eeprom program memory version with a little more i/o would be good. Any 12-bit version with eeprom program memory would be good. Adding serial programmability to the above 12-bit eeprom version would be good. Tim Braun | Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228 1900-155 Carlton St | FAX: 204-942-3001 Winnipeg, Manitoba, Canada R3C 3H8 | Email: RemoveMEtimspam_OUTKILLspamchs.mb.ca

> One of my visions of nervanah [sic], is a way to use multiple > PICs, via a 1 or two wire network, that takes little or > no CPU time on the PIC to interface with. Preferably > allowing the PIC to set an 'address' in a control > register, then pick up data a byte at a time that has > been addressed to it, or to a 'broadcast' address that > all controllers on the same network would pick up. I don't know what the current geometries Microchip is using in the PIC but it is certainly technically feasible to put a limited CD/CSMA network interface into a small piece of silicon. (not full blown ethernet, just what Jack wants, one or two bytes of address, one or two bytes of data, and two new interrupts for transmit buffer empty and receive buffer full. --Chuck