Searching \ for ' EEPROM <-> PIC' 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/memory.htm?key=eeprom
Search entire site for: 'EEPROM <-> PIC'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] EEPROM <-> PIC'
2002\02\23@044213 by Mohit Mahajan

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


2002\02\23@051252 by NDuckworth

flavicon
face
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_OUTm0h1tTakeThisOuTspamYAHOO.CO.IN]
wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\02\23@054027 by Giorgio De Nunzio

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


2002\02\23@055732 by Claudio Tagliola

flavicon
face
Why not step up to a bigger pic? Even a PIC18 with 32K seems to be a
cheaper solution that creating all this. And 32K is a LOT of code to
write for a micro.

{Original Message removed}

2002\02\23@060423 by uter van ooijen & floortje hanneman

picon face
> 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?

Simple answer: no.

But - depending on your application - you might be able to put a lot of data
in the eeprom, or maybe put some of the 'propgram' and interpret it by the
real program.

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl
Jal compiler, Wisp programmer, WLoader bootloader, PICs kopen

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\02\23@092241 by Byron A Jeff

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


2002\02\23@093938 by Joris van den Heuvel

flavicon
face
You cannot use external code memory on a 16F877 or any 16-series PIC for
that matter (someone correct me if I'm wrong).

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

Regards,
Joris.





{Original Message removed}

2002\02\23@095244 by Byron A Jeff

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


'[PIC]: Re: EEPROM <-> PIC'
2002\02\23@101808 by Jims Mail

flavicon
face
If it were me, I'd write it in aassembly.   I've tried sevehigh level
languages, and have been satisfied by none.   And I have been using assembly
for a long enough time that I can write in assembly almost as fast as
someone in a high level language.   But it's your call.


                                                                   Regards,

                                                                       Jim
{Original Message removed}

2002\02\23@102802 by Rick C.

flavicon
face
dittos!
Rick

Jims Mail wrote:

> If it were me, I'd write it in aassembly.   I've tried sevehigh level
> languages, and have been satisfied by none.   And I have been using assembly
> for a long enough time that I can write in assembly almost as fast as
> someone in a high level language.   But it's your call.
>
>                                                                     Regards,
>
>                                                                         Jim
> {Original Message removed}

'[PIC]: EEPROM <-> PIC'
2002\02\23@140543 by Spehro Pefhany

picon face
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}

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.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.


2002\02\23@181245 by Olin Lathrop

face picon face
> The PIC17C756a has 16k words (28K bytes) of memory,
> and lots of I/O, but is OTP only.

No, like most PICs that aren't flash, it's available in UV erasable versions
for development.  I've done at least two projects with these that I can
remember and have about 12 of the JW parts left.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\02\24@113244 by Joris van den Heuvel

flavicon
face
> 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_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\02\24@121415 by Byron A Jeff

face picon face
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 listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\02\25@112351 by Michael Vinson

picon face
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-requestKILLspamspammitvma.mit.edu


2002\02\25@115654 by Bob Barr

flavicon
face
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-requestKILLspamspammitvma.mit.edu


2002\02\25@133553 by Spehro Pefhany

picon face
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"
RemoveMEspeffTakeThisOuTspaminterlog.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-requestspamBeGonespammitvma.mit.edu


2002\02\25@163154 by Tony Nixon

flavicon
picon face
> >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!

I did a programmable ignition controller in less than 1K. 1021 words to
be exact ;-)

http://www.bubblesoftonline.com/projects/ignition.html



--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
TakeThisOuTsalesEraseMEspamspam_OUTbubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


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