Searching \ for '[PIC]: PIC software' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC software'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PIC software'
2003\04\02@183608 by Konstantin Klitenik

picon face
Does anyone know of any sort of software for PICs (PIC16Fxx) that can grab
the data from the PIC memory?

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?

So I want a program to grab the data from the PIC without having to right
any kind of PIC - PC interface.  I think they have something like this for
BasicStamp.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\02@184622 by Olin Lathrop

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

2003\04\02@185729 by Kyrre Aalerud

flavicon
face
Ahhm, I think he wants to simply read the PIC with a programmer...

Why not use a external eeprom and read that instead ?

   KreAture

{Original Message removed}

2003\04\02@192343 by Jinx

face picon face
> Ahhm, I think he wants to simply read the PIC with a programmer...

This code for an F877 will do that. Bear in mind Olin's comment
about write endurance for Flash memory. The F877 manual says
> 1000 versus > 100,000 for EEPROM. This code was abandoned
in favour of external SRAM because Flash couldn't take the number
of re-writes required and there wasn't enough internal EEPROM

;================================================
;        Modify flash memory
;================================================

; data in dlo:dhi
; address to store it in addl:addh

writef   bank0                ;write modified bytes to Flash
        bcf    pir2,eeif
        movf   addl,w        ;get low byte of index
        bank2
        movwf  eeadr         ;into Flash storage address low
        bank0
        movf   add1h,w       ;get high byte of index
        bank2
        movwf  eeadrh        ;into Flash storage address high
        bank0
        movf   dlo,w         ;data low byte
        bank2
        movwf  eedata
        bank0
        movf   dhi,w         ;data high byte
        bank2
        movwf  eedath
        bank3
        bsf    eecon1,eepgd  ;select Flash
        bsf    eecon1,wren   ;start write
        movlw  0x55
        movwf  eecon2
        movlw  0xaa
        movwf  eecon2
        bsf    eecon1,wr
        nop                       ;don't recall why these NOPs here
        nop
        nop
        nop
        bcf    eecon1,wren
        bank0
        btfss  pir2,eeif     ;wait for write completion
        goto   $-1
        bcf    pir2,eeif
        return               ;done

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\02@192840 by Konstantin Klitenik

picon face
Is there any kind of interface for the PC that will read directly from
EEPROM chip?

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.


{Quote hidden}

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\02@195043 by Jinx

face picon face
> Is there any kind of interface for the PC that will read directly from
> EEPROM chip?

PICStart Plus ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\02@201629 by Bob Ammerman

picon face
If you write the data to program memory (remember limited number of writes!)
you can later read it back using, for example, MPLAB and a PICSTART plus.

Bob Ammerman
RAm  Systems

{Original Message removed}

2003\04\03@014247 by Wouter van Ooijen

face picon face
> > Is there any kind of interface for the PC that will read
> directly from
> > EEPROM chip?
>
> PICStart Plus ?

IC-prog?

Wouter

--
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

2003\04\03@073035 by Olin Lathrop

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

2003\04\03@084017 by erholm (QAC)

flavicon
face
Perhaps the PIC and the PC isn't located at the same place/site ?

Jan-Erik.

Olin Lathrop wrote:

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

--
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

2003\04\03@131544 by Konstantin Klitenik

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


{Quote hidden}

_________________________________________________________________

--
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

2003\04\03@160921 by Olin Lathrop

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

2003\04\03@163758 by Douglas Wood

picon face
This is true only for NT/2000/XP. Windows 95/98/Me do NOT require such a
driver.

Douglas Wood
Software Engineer
spam_OUTdbwoodTakeThisOuTspamkc.rr.com
ICQ#: 143841506

Home of the EPICIS Development System for the PIC
http://epicis.piclist.com

{Original Message removed}

2003\04\03@173735 by Jinx

face picon face
> I think I'm just going to write my own I2C interface and just
> get the data directly from EEPROM via Parallel Port Does
> anyone think that's not such a good idea and why?

It will be a lot less pain to use a PIC as the interface. It's better
suited to read the EEPROM, and then you have the choice of
RS232, parallel, or bit-banging collected data from the PIC to
the PC. The topic has come up before (last year I think), it'll be
in the archives

--
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

2003\04\03@194155 by Konstantin Klitenik

picon face
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.
{Quote hidden}

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

--
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

2003\04\03@194605 by Russell C. Hay

flavicon
face
Nope, it doesn't require a kernel mode driver if you are just doing standard
rs-232 communication..
If you want, I have a simple C++ wrapper around the serial port access
written for VC++..

-R

{Original Message removed}

2003\04\03@204810 by Herbert Graf

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

2003\04\03@213813 by Konstantin Klitenik

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

{Quote hidden}

_________________________________________________________________

--
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

2003\04\03@222623 by Herbert Graf

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

2003\04\03@224946 by Konstantin Klitenik

picon face
How do you go about talking to the serial port? Preferrably in C/C++?



{Quote hidden}

_________________________________________________________________

--
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

2003\04\03@230251 by Ned Konz

flavicon
face
On Thursday 03 April 2003 05:47 pm, Herbert Graf wrote:

>         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).

That's interesting.

I thought that the Win32 serial comms API wasn't too bad.

It provides for timeouts, overlapped reads/writes, and good control of
serial parameters.

What would you have done differently?

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

--
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

2003\04\03@232544 by Herbert Graf

flavicon
face
> How do you go about talking to the serial port? Preferrably in C/C++?

       For Windows GUI programming I exclusively use Borland C Builder. It is
kinda like VC, but MUCH better IMHO. The plugin I use is called TComPort,
you can find a link with google.
       The plugin itself is very versatile, usually I communicate through the
serial port on a character by character basis, it's not the most efficient
way (the plugin supports reading in as many bytes in at a time as you wish)
but it sure is the simplest way.
       Of course the way you can go about it depends on what programming language
you're using. 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

2003\04\03@232549 by Herbert Graf

flavicon
face
> On Thursday 03 April 2003 05:47 pm, Herbert Graf wrote:
>
> >         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).
>
> That's interesting.
>
> I thought that the Win32 serial comms API wasn't too bad.
>
> It provides for timeouts, overlapped reads/writes, and good control of
> serial parameters.

       Once you get things working it isn't too bad to work with, however it's the
"getting it working" that can be quite "fun".

> What would you have done differently?

       I don't know, I haven't used what's native for quite a while, personally I
use a 3rd party component in Borland C Builder that makes using the serial
port easier than using the keyboard... 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

2003\04\04@011320 by William Chops Westfield

face picon face
>>    How do you go about talking to the serial port? Preferrably in C/C++?

I think the main issues that that serial ports are much more likely to
be used in a "standard" fashion than a parallel port.  For many cases,
you simply open "com1:" as a file and read or write away.

With the parallel port, on the other hand, about the only "standard"
thing you can do is PRINT using the standard centronic handshaking,
which is seldom what us microcontroller folk want to do with it.
Indeed, we want control and access to the individual bits of the port,
which is far from standard.  Preferrably with relatively strict timing,
which is near impossible.

If you start doing that on the serial port (which some PIC programmers
DO, bitbanging random protocols on what ought to be the rs232
handshaking signals), you run into similar difficulties to what the
people trying to use the parallel port encounter.

BillW

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

2003\04\04@073432 by Olin Lathrop

face picon face
> Wouldn't access to serial port require a kernel mode driver as well?

No.  The standard app layer COM port interface gives you all the control
you need.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\04\04@074425 by Olin Lathrop

face picon face
> I thought that the Win32 serial comms API wasn't too bad.
>
> It provides for timeouts, overlapped reads/writes, and good control of
> serial parameters.
>
> What would you have done differently?

I agree.  Other than the usual Windows issue of too few calls that
therefore each end up being too complex, all reasonable control seems to
be there.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\04\04@074429 by Olin Lathrop

face picon face
> How do you go about talking to the serial port? Preferrably in C/C++?

Use CreateFile as usual, but also COM port specific routines like
GetCommProperties, SetupComm, GetCommState, etc.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\04\04@164259 by Pic Mailingliste

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

2003\04\04@170942 by Konstantin Klitenik

picon face
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.
{Quote hidden}

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail

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

2003\04\04@175950 by Jinx

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

2003\04\04@182443 by Konstantin Klitenik

picon face
It almost seems like either of us are missing something.  Let me try to make
it clear if I can.  First of all, to me it seems like it is easier to
program parallel port.  All it requires is a single call to
outportb(port, data), and the byte will appear on the parallel port.

Let me clarify why I want to set up EEPROM to PC communication.  I want some
remote system (PIC) to gather data to the EEPROM.  After that, I want to
read the data into PC to perform some sort of analisys (i.e. graph).  So
either way I will need to write I2C for the PIC.  The reason I want direct
EEPROM to PC is that I wouldn't have to right additional PIC to PC routines.
 I just want to take the EEPROM out of the system and plug it into the PC
and get the data.

A) Now, to set up EEPROM to talk to PIC and then the PC, it would require:
1.  Writing some sort of routines to send the data to PC.
2.  Writing some sort of routines for PC to accept the data.

B) To set up PC to talk to EEPROM:
1.  Writing I2C routines for PC.

For both A and B I would need I2C for the PIC so I omitted it from the
requirements.  But A would save me space on the PIC by not having to write
PIC to PC protocol.

Now, I don't think the choice of the port really matters since I would be
using 2 wires (data, clock) anyway.  Even if I use the parallel port, I
would be using in the serial (I2C) manner.  I decided to go with parallel
because I have some experience with it.  Also, it has an open-collector
output (for data) which can be bi-directional (for acknowledgement from
EEPROM).  I could probably do the same type of programming on the serial
port.

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.

Take care.

{Quote hidden}

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

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

2003\04\04@184155 by Olin Lathrop

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

Check out my HOS project at http://www.embedinc.com/pic/hos.htm.  It is a
template PIC project for communication to a host via RS-232.  It already
contains the UART interrupt routines, FIFOs, and host command dispatch
handler.  All you have to do is fill in the code for a host command that
requests data from the EEPROM, and the code to get the data from the
EEPROM via IIC.  You also have to write the host software that sends the
command(s) to the PIC and receives the responses and stores the data.
However, that is less code than implementing IIC on the parallel port,
sending the commands and receiving the responses from the EEPROM and
storing the data.

If you think this is difficult and you plan on using PICs in the future,
then this is a good opportunity to get more proficient at the PIC side.
This is frankly a very easy thing to do.  Anyone with reasonable PIC
experience can do this in less than a day.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\04\04@184823 by Herbert Graf

flavicon
face
> It almost seems like either of us are missing something.  Let me
> try to make
> it clear if I can.  First of all, to me it seems like it is easier to
> program parallel port.  All it requires is a single call to
> outportb(port, data), and the byte will appear on the parallel port.

       Yes, but how do you tell the other thing that the byte is ready? How does
that device tell you it's done reading your byte? Parallel com needs
handshaking, making it MUCH more complicated (especially if dealing with
speed issues), this is a major reason a serial interface is so much easier,
all the handshaking can be done virtually.

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

2003\04\04@190355 by Ned Konz

flavicon
face
On Friday 04 April 2003 03:46 pm, Herbert Graf wrote:
> > It almost seems like either of us are missing something.  Let me
> > try to make
> > it clear if I can.  First of all, to me it seems like it is
> > easier to program parallel port.  All it requires is a single
> > call to outportb(port, data), and the byte will appear on the
> > parallel port.
>
>         Yes, but how do you tell the other thing that the byte is
> ready? How does that device tell you it's done reading your byte?
> Parallel com needs handshaking, making it MUCH more complicated
> (especially if dealing with speed issues), this is a major reason a
> serial interface is so much easier, all the handshaking can be done
> virtually.

But he's not talking about parallel communications; he's talking about
using the parallel port bits to bit-bang I2C to a serial EEPROM.

Should work fine. There's already several Linux I2C drivers that use
various kinds of parallel port hardware.

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

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

2003\04\04@193104 by Jinx

face picon face
> I was just a little confused as to why everyone thinks it is simpler

"Simpler" to some extent depends on previous knowledge, but
look at it this way - if you went with RS232 it would've been
finished by now and you'd be happily graphing. Yes ? True, it
will use a PIC and a MAX232, but what price your time ?

> But A would save me space on the PIC by not having to write
> PIC to PC protocol

An RS232 routine for a PIC with a UART would be a dozen lines
more or less (plus set-up). The h/w does all the work, and you can
even perform other s/w tasks simultaneously with Tx/Rx because
Tx/Rx is being done in h/w. eg work out the bit times for 9600 baud
and that's a lot of usable instruction time while you wait for trmt or
rcif to set

b_out    movlw   'data'          ;send byte
        movwf   txreg
        bank1
        btfss   txsta,trmt          ;wait here until data sent
        goto    $-1

;==========

b_in  btfss   pir1,rcif          ;wait here until byte received
        goto    $-1
        movf    rcreg,w

The data indexing/retrieval routines are already there for the transfer
system you choose so they're irrelevant in terms of code size. However,
if you use RS232 the retrieval/storage can be performed whilst the
h/w is working, which could make data manipulation time = 000s

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

2003\04\04@194928 by Brendan Moran

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

2003\04\04@202509 by Konstantin Klitenik

picon face
Well, I understand what you are trying to say.  You're implying on using the
already built-in I2C to interface PIC to EEPROM. And then use built-in USART
to communicate to serial port.  That makes sesnse.

However, I have no exprience with serial port and USART.  I know what USART
is and how it works but I don't know how to program it in PIC and serial
port.  Also, I am using HI-TECH C compiler and I have basically no
experience with PIC assembly.  Are there any routines in HI-TECH C for I2C
and USART?

Thanks.

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 (without
getting into assembly).  I don't like using libraries and APIs that I did
not write because it makes me feel like I am cheating a bit.


{Quote hidden}

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

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

2003\04\04@213805 by Ned Konz

flavicon
face
On Friday 04 April 2003 05:23 pm, Konstantin Klitenik wrote:
> Well, I understand what you are trying to say.  You're implying on
> using the already built-in I2C to interface PIC to EEPROM. And then
> use built-in USART to communicate to serial port.  That makes
> sesnse.
>
> However, I have no exprience with serial port and USART.  I know
> what USART is and how it works but I don't know how to program it
> in PIC and serial port.  Also, I am using HI-TECH C compiler and I
> have basically no experience with PIC assembly.  Are there any
> routines in HI-TECH C for I2C and USART?

Probably. In any event, you should be able to use the USART and I2C
peripherals from C quite easily by writing to the appropriate control
registers and reading from the data registers.

> 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 (without getting into assembly).  I don't like using
> libraries and APIs that I did not write because it makes me feel
> like I am cheating a bit.

Well, you're going to have to deal with a similar amount of complexity
if you implement the whole Philips I2C spec. Of course, if you're
only talking to one device, it gets a lot simpler.

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

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

2003\04\04@221309 by Brendan Moran

flavicon
face
>Well, I understand what you are trying to say.  You're implying on using the
>already built-in I2C to interface PIC to EEPROM. And then use built-in USART
>to communicate to serial port.  That makes sesnse.

Even if you had to code the bit-banging approach for the micro, the savings
would offset any potential problems.

>However, I have no exprience with serial port and USART.  I know what USART
>is and how it works but I don't know how to program it in PIC and serial
>port.  Also, I am using HI-TECH C compiler and I have basically no
>experience with PIC assembly.  Are there any routines in HI-TECH C for I2C
>and USART?

Assembly isn't that bad.  You shouldn't need much of an introduction if
you're any good at programming in general.

As to hi-tech's C, I couldn't tell you.  I haven't ever used it.  Any
development with PICs that I do is done in assembly.  I did use CCS once,
and I remember finding a lot of routines for in their built-in library,
including USART use.

>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 (without
>getting into assembly).  I don't like using libraries and APIs that I did
>not write because it makes me feel like I am cheating a bit.

If you're going to go down that road, then you shouldn't use C.  Assembly
will give you a much better idea of what's going on.  Furthermore, you
shouldn't use a micro controller, you should design your on MCU on an
FPGA.  Wait, that's leaving something out too.  How about building the
micro controller from transistors.  Want to refine your own silicon?

I'm being facetious, but the point is that at some level, you have to let
someone else do the work, or you're going to get bogged down in the
details.  In fact, I recommend reading the spec, then getting as much done
by the hardware as possible.  I dislike bit-banging.  I prefer hard
implementations of anything I can get. Ignoring the code speed savings,
they make the code far cleaner. and allow tandem operation of the
peripherals, with far better performance.

Why do you think microcontrollers came onto the market to start with?  If
everyone did everything by bit-banging, all you would have is a glorified
processor core, with onboard memory.

My preference of peripherals over code is probably why I'm enamoured of
devices such as PLDs, FPGAs, and a certain non-PIC micro with movable
peripherals.

--Brendan

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

2003\04\05@081727 by

flavicon
face
Have you *ever* seen a carpenter build his own hammer and saw ?
Or a painter make his own brushes ?
No, of course not, they, as any other professionals, use
whatever tools are at hand.

Jan-Erik Söderholm.


Konstantin Klitenik wrote:
> I don't like using libraries and APIs that I did
> not write because it makes me feel like I am cheating a bit.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\04\05@090203 by Olin Lathrop

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

2003\04\05@134236 by Konstantin Klitenik

picon face
No need to get angry.  I was just trying to understand why people think
serial is easier to make sure i'm not missing anything.

sorry.






{Quote hidden}

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\04\05@193303 by Sean Alcorn - PIC Stuff

flavicon
face
--Apple-Mail-2-414908960
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
       charset=US-ASCII;
       format=flowed

Konstantin,

On Sunday, Apr 6, 2003, at 04:42 Australia/Sydney, Konstantin Klitenik
wrote:

> No need to get angry.  I was just trying to understand why people think
> serial is easier to make sure i'm not missing anything.

I don't think Olin was angry - yet. But I have to agree with him. You
asked a question, and I counted 32 responses to your post. You don't
have to take their advice, but this list can be a fantastic resource
for your learning. I often just read posts and don't make a post for
months!

I started with some basic high level language experience, then one day,
I just 'jumped in' head first into the assembly. Within 4 hours
(including getting coffee) I had my first project working and then
spent another 7 hours figuring out the Watch Dog Timer! If only I knew
about the list then! I could have saved myself about 5 hours of
stupidity! :-)

What you are trying to do is not rocket science. Plenty of great people
on this list have done what you want to do. I am sure that if you just
dive right in there will be plenty of engineers of Olin's calibre ready
to give you a hand if you get stuck. All I suggest is that you read and
re-read every text you've got before posting a question.

The list will welcome you, I am sure.

Happy PICin'

Sean

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body



--Apple-Mail-2-414908960
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
       charset=US-ASCII

Konstantin,


On Sunday, Apr 6, 2003, at 04:42 Australia/Sydney, Konstantin Klitenik
wrote:


<excerpt><fixed>No need to get angry.  I was just trying to understand
why people think

serial is easier to make sure i'm not missing anything.

</fixed></excerpt>

I don't think Olin was angry - yet. But I have to agree with him. You
asked a question, and I counted 32 responses to your post. You don't
have to take their advice, but this list can be a fantastic resource
for your learning. I often just read posts and don't make a post for
months!


I started with some basic high level language experience, then one
day, I just 'jumped in' head first into the assembly. Within 4 hours
(including getting coffee) I had my first project working and then
spent another 7 hours figuring out the Watch Dog Timer! If only I knew
about the list then! I could have saved myself about 5 hours of
stupidity! :-)


What you are trying to do is not rocket science. Plenty of great
people on this list have done what you want to do. I am sure that if
you just dive right in there will be plenty of engineers of Olin's
calibre ready to give you a hand if you get stuck. All I suggest is
that you read and re-read every text you've got before posting a
question.


The list will welcome you, I am sure.


Happy PICin'


Sean


--Apple-Mail-2-414908960--

2003\04\07@045917 by Alan B. Pearce

face picon face
>I was just trying to understand why people think
>serial is easier to make sure i'm not missing anything.

Because serial communication between computing devices is a universal
language - the Esperanto of computers.

Trying to talk any other way starts getting very confusing (is bit 0 the MSB
or LSB?) whereas any machine that talks serial is using a common format.

Sure there are differences in the way that handshake lines are used, but it
is generally possible to turn these off. It is easy enough to control the
data rate by changing the baud rate if you need to slow things down. Every
PC that you are likely to deal with has code to handle a serial port
(possible exception is USB, but a USB-serial adapter should come with a
driver). Then it is possible to talk to a PIC using only an ordinary
terminal program, taken to the extreme.

At the PIC end, if there is serial port hardware, then the programming is
simple, and small. Even if there is no serial port hardware doing a bit bang
routine is not too hard, but these days you would be better off getting a
new chip with the hardware in it.

Believe me, the serial port is your friend.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

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