> > The basic idea is that I want to use PIC to gather data and store it in
> > memory for later retrieval into the computer.  I know that I can store
> > that data in EEPROM.  Is it possilbe to store some data in FLASH memory?
>
>Yes, but note that the flash has a limited number of lifetime writes.  If
>you need more space than the internal data EEPROM, it would be best to use
>an external EEPROM.  There are some 8 pin EEPROMs that talk IIC.
>
> > So I want a program to grab the data from the PIC without having to
> > right any kind of PIC - PC interface.
>
>Then how do you expect to get it there?
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>
>--
>http://www.piclist.com hint: PICList Posts must start with ONE topic:
>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> > Is there any kind of interface for the PC that will read directly from
> > EEPROM chip?
>
>Some PROM programmers can probably do that.
>
> > For example, if I get an external EEPROM chip and have PIC gather data
> > on it. Then just simple take the EEPROM chip without the PIC and
> > transfer the data to my PC.
>
>If you're going to have a PIC gather the data and write it to EEPROM, just
>have the PIC send it to the PC.  In other words, the PIC that already
>exists anyway will also be the interface hardware that allows the PC to
>read the EEPROM.  This sounds too obvious and simple.  What am I missing
>here?
>
>See my HOS template project at http://www.embedinc.com/pic/hos.htm for the
>minimum hardware and firmware for a PIC to talk to a PC.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics

>
> > I think I'm just going to write my own I2C interface and just get the
> > data directly from EEPROM via Parallel Port.  I'm not positive, but I
> > don't think EEPROM chip cares or knows what is talking to it, the pic
> > or par port.  This will eliminate writing pic routines to talk to the
> > computer.  Does anyone think that's not such a good idea and why?
>
>It will be a lot easier to write PIC code to read from an EEPROM and write
>to the serial port than to get low level access to a parallel port in
>Windows.  The latter requires a kernel mode device driver.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics

>From: Herbert Graf <.....mailinglistKILLspam@spam@FARCITE.NET>
>Reply-To: pic microcontroller discussion list <PICLISTKILLspamMITVMA.MIT.EDU>
>To: .....PICLISTKILLspam.....MITVMA.MIT.EDU
>Subject: Re: [PIC]: PIC software
>Date: Thu, 3 Apr 2003 20:47:19 -0500
>
> > Wouldn't access to serial port require a kernel mode driver as
> > well?  I have
> > no problem with programming parallel port and I already have the
> > kernel mode
> > driver.
>
>         Technically no, Windows does provide serial support in the OS.
>However it
>is HORRIBLE in non MS languages (and the Microsoft languages component
>isn't
>the greatest either). While there are a few "schemes" out there that had
>made it easier to use I personally use a third party plugin for serial port
>access in Borland C Builder, it's just much easier. Plus it allows you to
>do
>"non standard" things with the port.
>
>         FWIW while a parallel port scheme seems easier in the end it is
>FAR easier
>to do anything PIC with a serial port, most especially if you have a PIC
>with an UART (which many do these days). TTYL
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics

>From: Herbert Graf <EraseMEmailinglistspam_OUTTakeThisOuTFARCITE.NET>
>Reply-To: pic microcontroller discussion list <PICLISTspam_OUTMITVMA.MIT.EDU>
>To: @spam@PICLISTKILLspamMITVMA.MIT.EDU
>Subject: Re: [PIC]: PIC software
>Date: Thu, 3 Apr 2003 22:24:28 -0500
>
> > I just use NTPort Library.  It has a kernel mode driver and a very nice
> > C/C++ interface similar to direct calls (outp, inp).  It allows
> > me direct IO
> > control in Windows XP, therefore, programming parallel port is
> > very simple.
>
>         I have used the same plugin, my statement about using a parallel
>port deals
>with prior experience: getting a PIC project working over a serial has
>proven less painful then using a parallel port, especially from the "number
>of wires" point of view. To each his own I suppose. TTYL
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics

>From: Pic Mailingliste <KILLspamlu01tsKILLspamGMX.NET>
>Reply-To: pic microcontroller discussion list <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU>
>To: spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU
>Subject: Re: [PIC]: PIC software
>Date: Thu, 3 Apr 2003 23:41:16 +0200
>
>KK> I think I'm just going to write my own I2C interface and just get the
>data
>KK> directly from EEPROM via Parallel Port.  I'm not positive, but I don't
>think
>KK> EEPROM chip cares or knows what is talking to it, the pic or par port.
>This
>KK> will eliminate writing pic routines to talk to the computer.  Does
>anyone
>KK> think that's not such a good idea and why?
>
>Hi,
>
>maybe you could tell us which type of eeprom you would like to address
>via the parallel port ... maybe I could provide you some routines and
>some schematic for this problem.
>
>Cheers,
>        Michael
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.

>From: Jinx <TakeThisOuTjoecolquittEraseMEspam_OUTCLEAR.NET.NZ>
>Reply-To: pic microcontroller discussion list <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU>
>To: PICLISTEraseME.....MITVMA.MIT.EDU
>Subject: Re: [PIC]: PIC software
>Date: Sat, 5 Apr 2003 11:00:11 +1200
>
> > I'm thinking of 24LC128.  I looked at the I2C protocol and it
> >doesn't seem like it would be difficult to write the interface for
> >it.  Since I can program Par Port bit by bit, I can just use 2
> >lines (clock and data) and just go according to the I2C protocol.
> >To me it just seems less work then writing interface for PIC to
> >talk to 24LC128 and then writing interfaces for both PIC and
> >PC to talk to each other.  Ofcourse, I will not mind any material
> >you could provide.  Thanks a lot
>
>Not wishing to appear critical or snippy, honestly, but you
>don't appear to be scared of a little programming - so what's
>holding you back ? An interest in masochism ? ;-)
>
>PIC-EEPROM and PIC-PC routines are reasonably trivial for
>a basic data reading project.  Coding the IIC routines to write
>to the EEPROM with the PIC in the first place is more than half
>the job done, and there are plenty of code examples to follow.
>Unless you have a good reason to do it, why go through the
>agony of writing PC port IIC routines ?
>
>Look around at data logging products. Every one of them AFAIK
>uses RS232 to get the data from memory into the PC, and there's
>probably a very good reason for that
>
>Anyway, despite coming off like a grump, I sincerely do hope you
>manage to accomplish what you set out to do by whatever means
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.

>From: Brendan Moran <EraseMEannirackSHAW.CA>
>Reply-To: pic microcontroller discussion list <RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU>
>To: RemoveMEPICLISTspam_OUTKILLspamMITVMA.MIT.EDU
>Subject: Re: [PIC]: PIC software
>Date: Fri, 4 Apr 2003 16:44:51 -0800
>
>>I was just a little confused as to why everyone thinks it is simpler to go
>>through the PIC.  It is obviously more complicated in this case, unless
>>I'm
>>missing something big.  Anyway, I just wanted to clear things up and make
>>sure I'm not messing up.
>
>You have read the I2C spec, right?
>www.semiconductors.philips.com/markets/mms/protocols/i2c/index.html
>www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFICATION_3.pdf
>Don't get your information anywhere other than that, unless you're looking
>at the specific behavior of a specific device.  I2C is Philips' protocol,
>so it only makes sense to get whatever info you need from them.
>
>I2C is a somewhat complex serial protocol.  The point is that the majority
>of current PICs implement I2C in hardware, and all you have to do is set
>some register values.  From a parallel port, you have to do FAR more than
>that.  And, besides, your transfer speeds would be abysmal since parallel
>ports (at least the figure I remember, though it may be better now) only do
>something like 5k refreshes/sec.  That limits you to a maximum of ~1.67kbps
>as opposed to the 100kbps from IIC through a PIC on *slow* mode, never mind
>FAST or HS modes. (well, you're actually limited by the serial port at
>those speeds.  115kbps is the limit on the PC, and most level converters
>only handle up to 250kbps)
>
>Implementing an I2C master on a newer PIC is relatively easy, as I have
>said.  So is implementing a serial transfer on a PIC.  They both take
>straight parallel data writes and a bit set or two for enabling after
>initialization is done.  If you're using either something from the 16F87x
>or (I think) 16F62x they have an I2C peripheral built in.  No bit twiddling
>for you.
>
>If you're using a 16F84, get a new micro.
>
>all you have to do to get an idea of what's needed is to read the MSSP and
>USART sections of the relevant PIC datasheet, and the communication section
>of the EEPROM datasheet.  They usually spell it out pretty well.  And, if
>you check microchip's appnotes, there's probably an example, though I
>haven't looked.
>
>I cannot see how you could consider it more difficult to use a micro you
>already need than to write all the code needed for a parallel port to do
>the same job.
>
>As you pointed out, there're only 2 places that you need to write software
>that's any different from what you already need.
>
>Start by using the UART receive interrupt.
>When it interrupts, check if it's the transmit character that's been sent.
>If it is the right character, read a burst of data from the EEPROM into a
>buffer, then send it over the serial port.
>Loop reading and sending bursts of data until you hit the end of the
>EEPROM.
>Go back to doing whatever it is that your micro does
>
>If both your micro and your software know in advance the size of the
>EEPROM, it makes data frames and all such similar ideas irrelevant.
>
>Another thing you could do is provide a simple text interface from the
>micro.  This is easy to do, just have the micro respond to a given
>character (say, a carriage return) by displaying its menu.
>
>You could make a menu item be to dump the data in an ascii encoded mode,
>where you convert each byte to its ascii hex value.  This doubles the data
>size, but makes the data more readable (and it's still easy to process in
>C++ with all the existing string manipulation)
>Then, you could use a terminal program on the PC side, and not even need to
>write any PC software to grab the data, only to manipulate it into whatever
>form you need.  You would also be able to use things like the End Of
>Transmission character to signal that it has reached the end of the
>available data.
>
>If you're worried about errors, use parity.  If you're getting any errors,
>you should really check the link between your PC and your micro and
>recapture the data, so additional framing becomes redundant.
>
>Handling things with the PIC is way easier and, from a speed point of view,
>way better than the parallel port idea.
>
>--Brendan
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.

>From: Olin Lathrop <RemoveMEolin_piclistKILLspamEMBEDINC.COM>
>Reply-To: pic microcontroller discussion list <PICLISTSTOPspamspam_OUTMITVMA.MIT.EDU>
>To: spamBeGonePICLISTSTOPspamEraseMEMITVMA.MIT.EDU
>Subject: Re: [PIC]: PIC software
>Date: Sat, 5 Apr 2003 09:00:52 -0500
>
> > Also, I am using HI-TECH C compiler and I have basically no
> > experience with PIC assembly.
>
>Are you doing this only to get it done, or are you also interested in
>becoming more proficient with PICs?  If the latter, this is a perfect
>learning project.  Ditch the compiler for now and learn the instruction
>set and assembler for this project.  That will give you good insight and
>gets you to a position where this project feels easy.  Then you can go
>back to the compiler on future projects if you still want to.
>
> > PS:  The reason I'm leaning towards bit-banging EEPROM from Par Port is
> > that
> > I like to get down the very details and understand how things work
>
>Again, ditch the compiler, at least until you gain that low level
>understanding.
>
> > (without getting into assembly).
>
>That's a contradictory statement.  You won't ever learn "the very details"
>without learning the instruction set and getting some experience in
>assembler.  You ask for knowledge but seem unwilling to learn.
>
> > I don't like using libraries and APIs
> > that I did
> > not write because it makes me feel like I am cheating a bit.
>
>But the compiler runtime library doesn't bother you?
>
>Look.  You asked for advice and got it.  You can take it or not, I don't
>care.  But arguing your point is an abuse of everyone's time.  You
>obviously had your mind made up before you asked.  It's rather rude to ask
>2000 people for a favor when you already know that there's nothing they
>can do to make a difference.  If your way is as easy as you say, then shut
>up and do it already.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email KILLspamlistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body