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
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
> 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
> 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
> 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
> 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
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..
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..
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
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
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.
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.
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.
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.
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.
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).
>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
>
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.
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).
>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
>
>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?
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.
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.
interlog.com Info for manufacturers: http://www.trexon.com
