Post by thread:[PICLIST] EEPROM <-> PIC

Hi, I'm new to PIC. I am planning to implement a control system using PIC16F877. I'll be using a keypad, LCD, almost all I/O pins (to input the control variables, operate four switches, PWM etc.). The code for all this is going to be large, no doubt. A PIC expert could optimise it to fit in the 8K ROM of the PIC, but as I'm a novice I'm not sure I'll be able to do so. In any case, since I'll either use JAL or a C-compiler, the code will be more than 8K. So now my question is: Can we interface an EEPROM [specifically: 24LC256, 32Kbyte Flash EEPROM (I2C)] to the PIC in such a way that the firmware code can be written in the EEPROM, from where the PIC can fetch it in packets and run it? It doesn't matter to my application if the effective operating speed decreases, because I'll be controlling pH, temperature, dissolved oxygen (all these take few minutes to adjust). If no, and the firmware is greater than 8K, then what should I do? Is there anything available with Microchip that has a larger (flash) ROM and as many I/O as the PIC 16F877? I've read about PIC18F242, but it still isn't out in the market. Peace, Mohit Mahajan. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi Mohit, From what you've said it sounds like the unknown variable is the size of you code. If you have access to a C compiler then I'd suggest making a start on the program to get a feel for how much space you'll need, you might be pleasantly surprised. If you do exceed 8K then a least you'll know more accurately what your requirements are. Have you looked at the PIC17C756 & 766? They're not Flash but they would give you 16K to play with and they're available now. I have no experience of using EEPROM to hold program code but it sounds messy. Good luck. Nigel On Friday, February 22, 2002 12:09 PM, Mohit Mahajan [SMTP:spam_OUTm0h1tTakeThisOuTYAHOO.CO.IN] wrote: {Quote hidden}> Hi, > > I'm new to PIC. I am planning to implement a control system using PIC16F877. > I'll be using a keypad, LCD, almost all I/O pins (to input the control > variables, operate four switches, PWM etc.). > > The code for all this is going to be large, no doubt. A PIC expert could > optimise it to fit in the 8K ROM of the PIC, but as I'm a novice I'm not > sure I'll be able to do so. In any case, since I'll either use JAL or a > C-compiler, the code will be more than 8K. So now my question is: > > Can we interface an EEPROM [specifically: 24LC256, 32Kbyte Flash EEPROM > (I2C)] to the PIC in such a way that the firmware code can be written in the > EEPROM, from where the PIC can fetch it in packets and run it? > > It doesn't matter to my application if the effective operating speed > decreases, because I'll be controlling pH, temperature, dissolved oxygen > (all these take few minutes to adjust). > > If no, and the firmware is greater than 8K, then what should I do? Is there > anything available with Microchip that has a larger (flash) ROM and as many > I/O as the PIC 16F877? I've read about PIC18F242, but it still isn't out in > the market. > > Peace, > Mohit Mahajan. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Fri, 22 Feb 2002, Mohit Mahajan wrote: > I'm new to PIC. I am planning to implement a control system using PIC16F877. ... > Can we interface an EEPROM [specifically: 24LC256, 32Kbyte Flash EEPROM > (I2C)] to the PIC in such a way that the firmware code can be written in the > EEPROM, from where the PIC can fetch it in packets and run it? What you propose is *more or less* what is done in a Basic Stamp, a circuit where you have a pic, an EEPROM, a max232 (iirc) and something more to let it work. You download your BASIC source into the EEPROM, then the BASIC interpreter living in the pic firmware retrieves the source and interpretes it. It works, quite slowly of course, but it works. I don't remember what is the eeprom size for your source code. It is quite costly, too (say 50 USD for a Basic Stamp II, in a rough estimate considering the approximate price in Italy - used one, but never bought one...). I had the same idea as yours some months ago, but I have never had the time to try and develop something like that: the eeprom would become a sort of hard disk for the pic, with all the difficulties involved in building up a firmware that has to retrieve the executable (not a BASIC source code) in blocks when needed. You need of course a kind of operating system acting as a supervisor. Never found (nor searched...) something like that on the Net, but as I have sometimes seen a pic talking to an ide disk interface (similar problem) that could be a start point to develop a system like that. Not a easy task for a beginner, I think. Anybody has ever found a system like that? Ciao Giorgio -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Fri, Feb 22, 2002 at 05:38:57PM +0530, Mohit Mahajan wrote: > Hi, > > I'm new to PIC. I am planning to implement a control system using PIC16F877. > I'll be using a keypad, LCD, almost all I/O pins (to input the control > variables, operate four switches, PWM etc.). > > The code for all this is going to be large, no doubt. A PIC expert could > optimise it to fit in the 8K ROM of the PIC, but as I'm a novice I'm not > sure I'll be able to do so. In any case, since I'll either use JAL or a > C-compiler, the code will be more than 8K. So now my question is: > > Can we interface an EEPROM [specifically: 24LC256, 32Kbyte Flash EEPROM > (I2C)] to the PIC in such a way that the firmware code can be written in the > EEPROM, from where the PIC can fetch it in packets and run it? Not with the standard midrange PICs. The 17C (and 18C series I think) have such a microcontroller mode. But I think you may be making a faulty/hasty assumption by presuming that the code won't fit. Being a novice you simply don't have enough expertise to make that presumption. Nothing that you listed above consumes a significant amount of code. The only variable is your application code computation. So why not simply get the project started and see how far you get. I have a sunrise/sunset controller with display, knob/pushbutton interface, timer code, calandar, sunrise/sunset interpolation, and relay control interface. It takes barely 600 bytes of assembly. Even at 3x code bloat by switching to an High Level Language, that's less than 2K. > > It doesn't matter to my application if the effective operating speed > decreases, because I'll be controlling pH, temperature, dissolved oxygen > (all these take few minutes to adjust). > > If no, and the firmware is greater than 8K, then what should I do? Is there > anything available with Microchip that has a larger (flash) ROM and as many > I/O as the PIC 16F877? I've read about PIC18F242, but it still isn't out in > the market. Simple. Split the tasks between two PICs. It effectively doubles your code space and I/O space. Use the USART for the two parts to communication to one another. But frankly I think you're overanalyzing the problem. 8192 instructions will take you a lot further than you think. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Sat, Feb 23, 2002 at 03:34:58PM +0100, Joris van den Heuvel wrote: > You cannot use external code memory on a 16F877 or any 16-series PIC for > that matter (someone correct me if I'm wrong). I think you have to qualify that with the adjective 'directly'. There are any number of bytecode interpreters that can do the job. I'm 90% finished with my NPCI project, which is a bytecode interpreter for a minature high level language. You can see the language overview here: http://www.finitesite.com/d3jsys/README-NPCI.html You can run it out of an external memory, or internal memory for that matter. One intriguing possibility is borne from the fact that PICs have reprogrammable program memory. So in theory one could download code segments from an external memory into the internal program memory and then execute it. However the limitation of 1000 writes nominal doesn't make it an effective idea. > > You will be quite amazed at how efficient a PIC uses its program memory, > even in C. I'm fairly experienced with PICs, I have done a project for which > I also doubted whether 8k (in an F876) would be enough, and was planning on > adding an external EEPROM for data. I ended up using about 1.25k for the > program and about as much for the data. > > This is the project: http://home.planet.nl/~heuv0283/scan_cl/scan_cl.htm Agreed. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

At 10:14 AM 2/23/02 +0000, you wrote: >I have no experience of using EEPROM to hold program code but it sounds messy. I've done a tokenized custom language that was interpreted by a program in a micro. The data was stored in a SEEPROM, SPI type for fast access, and interpreted by runtime code. Kind of like a Basic Stamp but totally different application-specific language. Really three or four projects- design the language, write the compiler (in Borland C), write the interpreter (in assembler), and finally write the program (in the custom language) to do the job. It took about 2 months total, plus the hardware design and system design. I'd suggest staying with the PIC only as long as you are comfortably (no more than 75% or so) within the memory size (to leave room for the inevitable feature creep and changes). Don't forget that 8K on a PIC is about 14K bytes. If you really need more like 32K than 16-18K, I'd suggest the 8051 series that has lots of memory and is reasonably priced. Or the MSP430 (60K, 16bits) for a reasonable price. The PIC17C756a has 16k words (28K bytes) of memory, and lots of I/O, but is OTP only. It's a useful micro, nice and fast. A bit expensive, and you need a socket adapter to program it with a Picstart+. BTW, if a lot of your memory is actually strings for display, storing those in EEPROM is not a bad idea. You could also use it as a way of making the display language easily changeable. But, be sure to take extra extra extra precautions in any of these cases to make sure the data is secure in your EEPROM. You don't want factory returns because of something silly like that. The amount of controller you're talking about would probably take less than 8K bytes of assembler code, but HLL might stretch it to 8K words, plus if you have a lot of alphanumeric display strings, it might be a lot more. Just guesses (but based on quite a few years of designing industrial instrumentation). Best regards, {Quote hidden}>Good luck. > >Nigel > > >On Friday, February 22, 2002 12:09 PM, Mohit Mahajan [SMTP:.....m0h1tKILLspam@spam@YAHOO.CO.IN] >wrote: > > Hi, > > > > I'm new to PIC. I am planning to implement a control system using > PIC16F877. > > I'll be using a keypad, LCD, almost all I/O pins (to input the control > > variables, operate four switches, PWM etc.). > > > > The code for all this is going to be large, no doubt. A PIC expert could > > optimise it to fit in the 8K ROM of the PIC, but as I'm a novice I'm not > > sure I'll be able to do so. In any case, since I'll either use JAL or a > > C-compiler, the code will be more than 8K. So now my question is: > > > > Can we interface an EEPROM [specifically: 24LC256, 32Kbyte Flash EEPROM > > (I2C)] to the PIC in such a way that the firmware code can be written > in the > > EEPROM, from where the PIC can fetch it in packets and run it? > > > > It doesn't matter to my application if the effective operating speed > > decreases, because I'll be controlling pH, temperature, dissolved oxygen > > (all these take few minutes to adjust). > > > > If no, and the firmware is greater than 8K, then what should I do? Is there > > anything available with Microchip that has a larger (flash) ROM and as many > > I/O as the PIC 16F877? I've read about PIC18F242, but it still isn't out in > > the market. > > > > Peace, > > Mohit Mahajan. > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > -- > > http://www.piclist.com hint: The PICList is archived three different > > ways. See http://www.piclist.com/#archives for details. > >-- >http://www.piclist.com hint: The PICList is archived three different >ways. See http://www.piclist.com/#archives for details. Spehro Pefhany --"it's the network..." "The Journey is the reward" speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com 9/11 United we Stand -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> On Sat, Feb 23, 2002 at 03:34:58PM +0100, Joris van den Heuvel wrote: > > You cannot use external code memory on a 16F877 or any 16-series PIC for > > that matter (someone correct me if I'm wrong). > > I think you have to qualify that with the adjective 'directly'. There are > any number of bytecode interpreters that can do the job. I'm 90% finished > with my NPCI project, which is a bytecode interpreter for a minature high > level language. You can see the language overview here: > > http://www.finitesite.com/d3jsys/README-NPCI.html > > You can run it out of an external memory, or internal memory for that matter. > Sounds very interesting. Will look at it! Regards, Joris. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

On Sun, Feb 24, 2002 at 04:55:26PM +0100, Joris van den Heuvel wrote: > > On Sat, Feb 23, 2002 at 03:34:58PM +0100, Joris van den Heuvel wrote: > > > You cannot use external code memory on a 16F877 or any 16-series PIC for > > > that matter (someone correct me if I'm wrong). > > > > I think you have to qualify that with the adjective 'directly'. There are > > any number of bytecode interpreters that can do the job. I'm 90% finished > > with my NPCI project, which is a bytecode interpreter for a minature high > > level language. You can see the language overview here: > > > > www.finitesite.com/d3jsys/README-NPCI.html > > > > You can run it out of an external memory, or internal memory for that > matter. > > > > > Sounds very interesting. Will look at it! It's not ready yet. I'm still working on integers. However if you're content to beta test programs with chars and global integers only, let me know. I'm still shaking the bugs out. BAJ -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

Byron A Jeff wrote, in part >[ In response to Mohit Mahajan's question about needing more than 8k for his project] >But I think you may be making a faulty/hasty assumption by presuming that >the code won't fit. Being a novice you simply don't have enough expertise >to >make that presumption. Nothing that you listed above consumes a significant >amount of code. The only variable is your application code computation. I agree!! To cite another example, my datalogger project has a keypad, LCD, multiple sensors, 8-bit upload-to-AIM65 capability, and the whole thing fits into about 1K! It's in assembly, written by someone who is new to PICs, all the code is self-written and could probably be further optimized. I was truly amazed when I discovered how much code space was left over (this is a 16F877). I *did* manage to use almost all of the data EEPROM for user i/o messages, as well as every single i/o pin, but I sure wasn't hurting for code space!! Michael V Thank you for reading my little posting. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

On Mon, 25 Feb 2002 08:22:55 -0800, Michael Vinson wrote: >Byron A Jeff wrote, in part >>[ In response to Mohit Mahajan's question about needing more than > 8k for his project] >>But I think you may be making a faulty/hasty assumption by presuming that >>the code won't fit. Being a novice you simply don't have enough expertise >>to >>make that presumption. Nothing that you listed above consumes a significant >>amount of code. The only variable is your application code computation. > >I agree!! To cite another example, my datalogger project has a keypad, >LCD, multiple sensors, 8-bit upload-to-AIM65 capability, and the >whole thing fits into about 1K! Amen to that! I've got a project going now that reads a set of thumbwheel switches, a serial ADC, and a GPS module. It stores the data in a serial EEPROM and allows user data retieval over either RS-232 or USB. With the exception of Microchip's USB code and a few functions I have yet to complete, I'm not quite up to 1K now (and even less without all of my debug code). Even after working with these things for quite a while, I'm still frequently surprised at just how little code space a PIC program requires. Regards, Bob -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

At 09:14 AM 2/23/02 -0500, you wrote: >So why not simply get the project started and see how far you get. I have >a sunrise/sunset controller with display, knob/pushbutton interface, timer >code, calandar, sunrise/sunset interpolation, and relay control interface. >It takes barely 600 bytes of assembly. Even at 3x code bloat by switching to >an High Level Language, that's less than 2K. I've not found a straightforward way to compare the two. Without "control" stuff, the ratio is nowhere near 3:1, but I find that C forces me to use floating point for things I would have used very compact 32-bit fixed-point integer routines for such as polynomial evaluation and precision PID control. Using library functions like printf and sscanf can increase the code size quite a bit (the MSP430 with IAR printf has an overhead of several K (bytes) just for printf(!), not nearly so bad on the PIC, but it's not as complete an implementation. You can get around most of this by writing your own stuff, but that takes away a lot of the advantages of using a HLL. These fixed overheads don't show up until you actually use those functions, because the relevant code isn't linked in unless the compiler finds that it is required. Looking at a real example right now, a controller design that would easily fit into 2K of PIC words using assembler is now taking up about 3,400 words, using C, so about double, overall. When I look back and see what I've been able to squeeze into 2k of assembly code, it's pretty amazing, but it definitely takes longer to write and is harder to maintain, even with copious comments. I also find it harder to evaluate when someone else has written it for me. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" RemoveMEspeffTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com 9/11 United we Stand -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu