Searching \ for '[PIC:] Not about Olin, but a PIC question :)' 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: 'Not about Olin, but a PIC question :)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Not about Olin, but a PIC question :)'
2004\02\16@180719 by Jim Franklin

flavicon
face
Hi,

I am working on a project around an 877A PIC.
Having started using assembler on the coding of it, I remembered how
laborious a task
it was. So I bought firstly the C compiler from PICant's website, but I
outgrew that fairly quickly (although I must say it's pretty good for the
price).
I am now using the PICC C Compiler and find this an excellent tool.

As I am trying to shoehorn the project into an 877A, would you guys out
there recommend using a second PIC (F84A or something - i'm using this as
it's in my parts box) as a slave to the "master" 877A.

I have an LCD display on the slave communicating via serial to the master
PIC.
I found that this saves me ports on the master and a whole heap of code, LCD
routines etc.
On startup, the slave writes a string to the first line of the LCD. The
message is pulled from the first 16 bytes of the internal EEprom (or up to
the first 0x00 found)

I have created a pseudo command language like this
Mxxyy   <-- Move to row xx, column yy
Dzzzzzzzzz (up to 20 chars) <-- display the message zzzz... onto the current
LCD location
X        <-- Clear display
Wxxyy    <-- Write yy to location xx in the internal eeprom
Rxx      <-- return value in location of xx to the serial port as hex chars
Z150163  <-- reset the eeprom byte 0 to 0xff (seeminly random sequence-a
magic date (my           birthday)).

Ok the question, does this make sense, or would you guys suggest something
else? have I lost the plot?

I have already coded and tested the slave PIC but I thought, before i go too
far down this route, is there a better way?

(incidentally I *have* been called an idiot before, sometimes it was
offensive, sometimes not, sometimes deservedly, depends upon their mood, and
mine).

Regards
Jim

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

2004\02\16@180719 by Jim Franklin

flavicon
face
Hi,

I am working on a project around an 877A PIC.
Having started using assembler on the coding of it, I remembered how
laborious a task
it was. So I bought firstly the C compiler from PICant's website, but I
outgrew that fairly quickly (although I must say it's pretty good for the
price).
I am now using the PICC C Compiler and find this an excellent tool.

As I am trying to shoehorn the project into an 877A, would you guys out
there recommend using a second PIC (F84A or something - i'm using this as
it's in my parts box) as a slave to the "master" 877A.

I have an LCD display on the slave communicating via serial to the master
PIC.
I found that this saves me ports on the master and a whole heap of code, LCD
routines etc.
On startup, the slave writes a string to the first line of the LCD. The
message is pulled from the first 16 bytes of the internal EEprom (or up to
the first 0x00 found)

I have created a pseudo command language like this
Mxxyy   <-- Move to row xx, column yy
Dzzzzzzzzz (up to 20 chars) <-- display the message zzzz... onto the current
LCD location
X        <-- Clear display
Wxxyy    <-- Write yy to location xx in the internal eeprom
Rxx      <-- return value in location of xx to the serial port as hex chars
Z150163  <-- reset the eeprom byte 0 to 0xff (seeminly random sequence-a
magic date (my           birthday)).

Ok the question, does this make sense, or would you guys suggest something
else? have I lost the plot?

I have already coded and tested the slave PIC but I thought, before i go too
far down this route, is there a better way?

(incidentally I *have* been called an idiot before, sometimes it was
offensive, sometimes not, sometimes deservedly, depends upon their mood, and
mine).

Regards
Jim

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

2004\02\16@181755 by piclist

flavicon
face
On Mon, 16 Feb 2004, Jim Franklin wrote:

> As I am trying to shoehorn the project into an 877A, would you guys out
> there recommend using a second PIC (F84A or something - i'm using this as
> it's in my parts box) as a slave to the "master" 877A.

Two PICs invariably makes the software larger and more complicated,
and makes the hardware more complicated and more expensive.  I would
consider it a "last resort" solution, especially given the selection
of PICs available with large code space and generous I/O counts.

--
John W. Temples, III

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

2004\02\16@181755 by piclist

flavicon
face
On Mon, 16 Feb 2004, Jim Franklin wrote:

> As I am trying to shoehorn the project into an 877A, would you guys out
> there recommend using a second PIC (F84A or something - i'm using this as
> it's in my parts box) as a slave to the "master" 877A.

Two PICs invariably makes the software larger and more complicated,
and makes the hardware more complicated and more expensive.  I would
consider it a "last resort" solution, especially given the selection
of PICs available with large code space and generous I/O counts.

--
John W. Temples, III

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

2004\02\16@182345 by Jan-Erik Soderholm

face picon face
Jim Franklin wrote :

> As I am trying to shoehorn the project into an 877A,...

What's limiting ? Speed, flash, RAM, I/O ?

> would  you guys out
> there recommend using a second PIC (F84A or something - i'm
> using this as it's in my parts box) as a slave to the "master" 877A.

Depends on the answer to Q1 above, but probably no.

>
> I have an LCD display on the slave communicating via serial
> to the master PIC.

There are also "serial-LCD's" that perhaps could do a fair deal of
the job of the "slave-PIC".

[snipped a lot of details...]

But easiest seems to simply use a more capable PIC from the
18-family.

Jan-Erik.

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

2004\02\16@182345 by Jan-Erik Soderholm

face picon face
Jim Franklin wrote :

> As I am trying to shoehorn the project into an 877A,...

What's limiting ? Speed, flash, RAM, I/O ?

> would  you guys out
> there recommend using a second PIC (F84A or something - i'm
> using this as it's in my parts box) as a slave to the "master" 877A.

Depends on the answer to Q1 above, but probably no.

>
> I have an LCD display on the slave communicating via serial
> to the master PIC.

There are also "serial-LCD's" that perhaps could do a fair deal of
the job of the "slave-PIC".

[snipped a lot of details...]

But easiest seems to simply use a more capable PIC from the
18-family.

Jan-Erik.

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

2004\02\16@183005 by Spehro Pefhany

picon face
At 03:17 PM 2/16/2004 -0800, you wrote:
>On Mon, 16 Feb 2004, Jim Franklin wrote:
>
> > As I am trying to shoehorn the project into an 877A, would you guys out
> > there recommend using a second PIC (F84A or something - i'm using this as
> > it's in my parts box) as a slave to the "master" 877A.
>
>Two PICs invariably makes the software larger and more complicated,
>and makes the hardware more complicated and more expensive.  I would
>consider it a "last resort" solution, especially given the selection
>of PICs available with large code space and generous I/O counts.

Agree. *However*, the compiler that Jim is using won't handle the
18F parts, and there are no available (AFAIK) 16F parts with larger than
the 8K-word code memory that he's got now. A messy solution for a messy
situation? Of course, there's always the 17C, but..

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

2004\02\16@183005 by Spehro Pefhany

picon face
At 03:17 PM 2/16/2004 -0800, you wrote:
>On Mon, 16 Feb 2004, Jim Franklin wrote:
>
> > As I am trying to shoehorn the project into an 877A, would you guys out
> > there recommend using a second PIC (F84A or something - i'm using this as
> > it's in my parts box) as a slave to the "master" 877A.
>
>Two PICs invariably makes the software larger and more complicated,
>and makes the hardware more complicated and more expensive.  I would
>consider it a "last resort" solution, especially given the selection
>of PICs available with large code space and generous I/O counts.

Agree. *However*, the compiler that Jim is using won't handle the
18F parts, and there are no available (AFAIK) 16F parts with larger than
the 8K-word code memory that he's got now. A messy solution for a messy
situation? Of course, there's always the 17C, but..

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

2004\02\16@183215 by Jim Franklin

flavicon
face
[snipped a lot of details...]

hehe looks like I talk too much :)

Thanks Jan-Erik & John W. for your speedy replies, I haven't lookied at
serial LCDs but thought as I had a few 84A's in my box use those and save a
few quid. It looks like the slave is working ok here, the "language" is
fairly simple. and on a serial port, it takes just 2 pins on the 877A.
the limit on the 877 is the I/O, but perhaps I should look to expanding that
another way. I haven't looked at the 18's yet, but perhaps I should also
look there.

Again,
thanks for your replies, I will keep looking (and lurking here).
Regards
Jim

{Original Message removed}

2004\02\16@183215 by Jim Franklin

flavicon
face
[snipped a lot of details...]

hehe looks like I talk too much :)

Thanks Jan-Erik & John W. for your speedy replies, I haven't lookied at
serial LCDs but thought as I had a few 84A's in my box use those and save a
few quid. It looks like the slave is working ok here, the "language" is
fairly simple. and on a serial port, it takes just 2 pins on the 877A.
the limit on the 877 is the I/O, but perhaps I should look to expanding that
another way. I haven't looked at the 18's yet, but perhaps I should also
look there.

Again,
thanks for your replies, I will keep looking (and lurking here).
Regards
Jim

{Original Message removed}

2004\02\16@184041 by Jim Franklin

flavicon
face
Spehro,

I am using the PCWH compiler and it supports all of the 12-bit, 14-bit and
PIC18 parts.
(I splashed out a bit, and it was worth it IMHO)

(what was the but about the 17C ?)
Jim

{Original Message removed}

2004\02\16@184041 by Jim Franklin

flavicon
face
Spehro,

I am using the PCWH compiler and it supports all of the 12-bit, 14-bit and
PIC18 parts.
(I splashed out a bit, and it was worth it IMHO)

(what was the but about the 17C ?)
Jim

{Original Message removed}

2004\02\16@184251 by Kenneth Lumia

picon face
Jim,

Extending the abilities of a processor with external logic (in
this case another processor) is a time honored technique.
Multiprocessor systems are common, however there are
several points worth considering.

1. Cost - not too important for a "one-of", potentially
   critical for a low-margin, high-volume design.

2. Complexity - Is the additional hardware complexity worth
   the savings in an easier software design, or vise-versa?

3. Was the first processor a poor choice for this design?
   Should you have chosen one with more memory/functions?
   What's the impact of switching processors now (you said
    it was written in 'C', so it should be relatively portable).

4. Given the choice of the first processor, have you reviewed
   your symbol table and tried to determine if there are any
   functions that are really program space intensive?  If so,
   can you figure an alternate method of performing the required
   function?  Exactly how short are you on memory - 10%,
   50%, etc.?  That would give you a clue as to the possibility
   of crunching the code to fit.

Ken



{Original Message removed}

2004\02\16@184251 by Kenneth Lumia

picon face
Jim,

Extending the abilities of a processor with external logic (in
this case another processor) is a time honored technique.
Multiprocessor systems are common, however there are
several points worth considering.

1. Cost - not too important for a "one-of", potentially
   critical for a low-margin, high-volume design.

2. Complexity - Is the additional hardware complexity worth
   the savings in an easier software design, or vise-versa?

3. Was the first processor a poor choice for this design?
   Should you have chosen one with more memory/functions?
   What's the impact of switching processors now (you said
    it was written in 'C', so it should be relatively portable).

4. Given the choice of the first processor, have you reviewed
   your symbol table and tried to determine if there are any
   functions that are really program space intensive?  If so,
   can you figure an alternate method of performing the required
   function?  Exactly how short are you on memory - 10%,
   50%, etc.?  That would give you a clue as to the possibility
   of crunching the code to fit.

Ken



{Original Message removed}

2004\02\16@210839 by Spehro Pefhany

picon face
At 11:37 PM 2/16/2004 +0000, you wrote:
>Spehro,
>
>I am using the PCWH compiler and it supports all of the 12-bit, 14-bit and
>PIC18 parts.
>(I splashed out a bit, and it was worth it IMHO)

My mistake, I thought it was the Hitech compiler.

>(what was the but about the 17C ?)
>Jim

It's a fine part, lots of pins and so on but no flash version. If you
can use the 18F series, just forget it exists, IMHO.

>{Original Message removed}

2004\02\16@210839 by Spehro Pefhany

picon face
At 11:37 PM 2/16/2004 +0000, you wrote:
>Spehro,
>
>I am using the PCWH compiler and it supports all of the 12-bit, 14-bit and
>PIC18 parts.
>(I splashed out a bit, and it was worth it IMHO)

My mistake, I thought it was the Hitech compiler.

>(what was the but about the 17C ?)
>Jim

It's a fine part, lots of pins and so on but no flash version. If you
can use the 18F series, just forget it exists, IMHO.

>{Original Message removed}

2004\02\17@094202 by Roland

flavicon
face
part 1 3803 bytes content-type:text/plain; charset="us-ascii"Hi Jim

This may be old hat, or old?

If you're putting the LCD on serial, i think this would be at least, a far
cheaper option. The coding would be about the same length. Not my idea, but
pulled it off the net the other day.

This is presuming its a HD44780 type.

Circuit, and text, was posted by; stefan_heinzmannspamKILLspamyahoo.com

Text from the page:
____________________
"- Replace the HEF4094D with a plain 8-bit shift register like the 74HC164
(it will be slightly cheaper). It has no STR input, so the PIC's RB3 just
connects to the LCD module's EN signal.

- Connect RB1 to the RS signal of the LCD module, and to the two data
inputs of the 74HC164. After having shifted out a byte into the 74HC164,
you can put the state of the RS signal on this line.

You don't need a transistor and such, and the timing isn't critical.

You operate it like this:
With EN inactive, you shift out a byte into the shift register in the same
way as you did before. This byte defines what's on the DB0-7 signals. Of
course, DB0-7 will wiggle while you're shifting, but the LCD will not care
as long as EN is inactive. Then, with EN still inactive, you put the state
of RS on the PIC's RB1 pin, but you don't toggle the clock line (RB0).
Then, you pulse the EN line (RB2) to make the LCD module accept the byte.

It should also be possible to use this technique with a hardware SPI port,
which is available in some PICs (or other controllers).

Cheers Stefan
____________________________

Regards
Roland


At 11:05 PM 16/02/04 +0000, you wrote:
{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



part 2 39414 bytes content-type:image/jpeg; name="Lcd on three lines.jpg"; (decode)


part 3 292 bytes content-type:text/plain; charset="us-ascii"

Regards                                    \o
Roland                                      l>
                                          < \

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



part 4 2 bytes
-

2004\02\17@094202 by Roland

flavicon
face
part 1 3803 bytes content-type:text/plain; charset="us-ascii"Hi Jim

This may be old hat, or old?

If you're putting the LCD on serial, i think this would be at least, a far
cheaper option. The coding would be about the same length. Not my idea, but
pulled it off the net the other day.

This is presuming its a HD44780 type.

Circuit, and text, was posted by; .....stefan_heinzmannKILLspamspam.....yahoo.com

Text from the page:
____________________
"- Replace the HEF4094D with a plain 8-bit shift register like the 74HC164
(it will be slightly cheaper). It has no STR input, so the PIC's RB3 just
connects to the LCD module's EN signal.

- Connect RB1 to the RS signal of the LCD module, and to the two data
inputs of the 74HC164. After having shifted out a byte into the 74HC164,
you can put the state of the RS signal on this line.

You don't need a transistor and such, and the timing isn't critical.

You operate it like this:
With EN inactive, you shift out a byte into the shift register in the same
way as you did before. This byte defines what's on the DB0-7 signals. Of
course, DB0-7 will wiggle while you're shifting, but the LCD will not care
as long as EN is inactive. Then, with EN still inactive, you put the state
of RS on the PIC's RB1 pin, but you don't toggle the clock line (RB0).
Then, you pulse the EN line (RB2) to make the LCD module accept the byte.

It should also be possible to use this technique with a hardware SPI port,
which is available in some PICs (or other controllers).

Cheers Stefan
____________________________

Regards
Roland


At 11:05 PM 16/02/04 +0000, you wrote:
{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



part 2 39414 bytes content-type:image/jpeg; name="Lcd on three lines.jpg"; (decode)


part 3 292 bytes content-type:text/plain; charset="us-ascii"

Regards                                    \o
Roland                                      l>
                                          < \

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


2004\02\17@144205 by Dwayne Reid

flavicon
face
At 04:05 PM 2/16/2004, Jim Franklin wrote:

{Quote hidden}

Hi there, Jim.

Your approach seems quite reasonable and is similar to what I do on a
regular basis.  Make sure that you have a way of setting the display cursor
position - I don't see anything in your list above for doing this.

One thing to consider: text strings can eat a lot of program space -
storing them on the slave micro that also drives the display is a great way
to simplify the master.  Just call them up by number.  In other words, add
another function to your command language where you simply specify the
message id.  That message is then displayed from text strings stored (hard
coded) on the slave.  Note that you should still be able to compose and
send messages from the master to the display.

The version I use on a regular basis assumes that the entire serial string
is intended for the slave.  The command byte is the first thing in the
string, followed by any data parameters.  I use either <cr> <lf> *or* an
idle period of x milliseconds as the string terminator, depending on the
project.

One example: the slave resides in a hand held pendant connected to the
master via a 4 conductor cable (gnd, +16V unreg, TX, RX).  In this project,
the slave (12c508) functions as a simple serial terminal that writes the
LCD display and LED indicators and reads any button presses.  The master in
this project is a 16c73 - about 1/3 the code space is text strings.  If I
was to do this project again, I'd put a larger PIC in the pendant and store
most of the text strings there.

dwayne

--
Dwayne Reid   <EraseMEdwaynerspam_OUTspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 20 years of Engineering Innovation (1984 - 2004)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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

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