 |
 |
| View previous topic :: View next topic |
| Author |
Message |
sahu77
Joined: 08 Sep 2011
Posts: 202
|
| display on 16*2 LCD some message |
 Posted: Tue Sep 17, 2013 10:30 am |
 |
|
dear friend
I want some message display on 16*2 LCD, like display message
but I want message stored in internal eeprom.
Normal technique are as
| Code: |
LCD_PutChar("INPUT= "%ld ",volt");
|
word "INPUT=" & "volt" are consume some data area in Program code.
If i use Eeprom Data for word "INPUT=" & "volt", i can save some Program code.
Anybody can give some sample code ?
_________________
sahu |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Tue Sep 17, 2013 1:45 pm |
|
|
The amount of code needed to get the values from the EEPROM, and generate the RAM strings, will almost certainly be larger than the size of the program memory solution. You'll also need a RAM buffer large enough as well.
If you want to store much larger strings, it could be worthwhile, but for the size you show, probably not.
Best Wishes |
|
|
sahu77
Joined: 08 Sep 2011
Posts: 202
|
|
| Posted: Tue Sep 17, 2013 1:52 pm |
|
|
| Ttelmah wrote: | The amount of code needed to get the values from the EEPROM, and generate the RAM strings, will almost certainly be larger than the size of the program memory solution. You'll also need a RAM buffer large enough as well.
If you want to store much larger strings, it could be worthwhile, but for the size you show, probably not.
Best Wishes |
I can use I2c memory for this ?
Because message has large strings.
_________________
sahu |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Wed Sep 18, 2013 1:02 am |
|
|
Same applies.
However 'large strings' changes things.
The point is that there is an 'overhead' to everything. The 'smallest' way, would be if you are prepared to build the table in EEPROM, or I2C EEPROM, and 'hard code' the locations where the strings sit. So:
| Code: |
#include <18F4420.h>
#FUSES NOWDT
#FUSES NOBROWNOUT
#FUSES NOLVP
#FUSES NOXINST
#FUSES PUT
#use delay(crystal=20000000)
#use rs232(baud=9600,parity=N,UART1,bits=8,stream=PORT1,errors)
#define VOLT_MESSAGE (0)
#define INPUT_MESSAGE (8)
#define NEXT_MESSAGE (16)
//Now, if you put the messages in the ROM at the locations, and terminate
//with \0 characters
#ROM int8 getenv("EEPROM_ADDRESS")+VOLT_MESSAGE = {"volts"}
#ROM int8 getenv("EEPROM_ADDRESS")+INPUT_MESSAGE = {"INPUT= "}
#ROM int8 getenv("EEPROM_ADDRESS")+NEXT_MESSAGE = {"word"}
//It doesn't matter if there are extra gaps between the messages
//but they must not overlap, and you must remember the space for
//the '\0' which the compiler will automatically generate
//Now have done the code for RS232, not LCD, but the principal remains the same.
void output_message(int16 location)
{
int8 chr;
if (location >= getenv("DATA_EEPROM")) return;
while (TRUE)
{
chr=read_eeprom(location++);
if (chr=='\0') return;
if (location >= getenv("DATA_EEPROM")) return;
putc(chr);
}
}
void main()
{
int16 volt=23;
while(TRUE)
{
output_message(INPUT_MESSAGE);
printf("%ld ",volt);
output_message(VOLT_MESSAGE);
//printf("INPUT= %ld volts",volt); //same message using ROM
delay_ms(1000);
}
}
//As written here, this would display "INPUT= 23 volts"
//With the words 'INPUT', and 'volts' being read from the EEPROM
|
Since you have not said what chip you are using, I've just chosen a generic PIC18.
However the standard 'ROM' way, uses 422 bytes, while using the EEPROM, increases this to 448.
_But_, if you have say 200bytes of messages, the EEPROM way won't grow by much (about 4 bytes every time a whole message is sent), while the ROM way will grow by about 10+no of characters in the message, for each message.
You can do exactly the same using I2C EEPROM, but the initial overhead will be greater, and if there are a lot of variable length messages, you then have to work out how the code is going to find them. Hard coding the start addresses of each message as I show, becomes laborious after a few messages.
Generally, it is much easier/cheaper, unless you are talking dozens of KB of messages, to just use a PIC with more ROM. Modern PIC's with dozens of KB of ROM, are often cheaper than older smaller chips. I have done external storage like this where I had a project with over 20KB of messages, that had to be stored in four different languages as well. However I then wrote a little PC application to actually generate the message tables, and automatically produce the code, since doing it manually was going to be 'insane'...
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Sep 18, 2013 4:24 am |
|
|
I suggest having a look at the recent thread where the most universal chips for use in new products were discussed: http://www.ccsinfo.com/forum/viewtopic.php?t=51047
For example the PIC18F46K22 has 40 pins and 64kbyte ROM for $3.82 at Digikey.
Or smaller, a PIC18F25K22 has 28 pins and 32kbyte of ROM for $2.96
Compare that to the price of an 24LC256, 8kbyte external I2C EEPROM for $0.98. I see you use the PIC16F676, costing $1.56 and total price becomes $2.54 for just under 10kbyte of Flash memory.
The whole point is that the old (PIC) chips are still for sale but because of older production technology use more chip area which makes them more expensive. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Wed Sep 18, 2013 4:59 am |
|
|
Add the Ckielstra's comments:
The real cost will be much more than the chip cost. If you are going to program the external EEPROM, it ends up having to go into a socket. Then needs board area, and holes. Then the pull up resistors. Then you lose two pins on the PIC. etc. etc. etc....
Then the extra development time, and code complexity.
Best Wishes |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 18, 2013 5:23 am |
|
|
also...
...if you change over to the 18F46k22 for ALL your projects, you'll have a solid base of common code!That PIC seems to be the 'Swiss army knife' of PICs.While 'bigger and better' than needed for 99% of the PIC projects(probably 100% of projects presented here),you always need a 'couple more pins', more memory or another peripheral.It's better to upgrade now,before spending a LOT of manWEEKS trying to squeeze code into a smaller PIC and come up short.
The extra cost of less than $2 for the PIC is quickly saved by having a common PCB design for all projects,YOUR library of code,routines, etc. that you KNOW work.
It's hard to imagine a 'project' that won't fit into this PIC.
I 'upgrade' 2-3 years ago, and haven't regretted it.This from a guy with a drawer full of 16F877s and 16C71s!
hth
jay |
|
|
sahu77
Joined: 08 Sep 2011
Posts: 202
|
|
| Posted: Wed Sep 18, 2013 4:49 pm |
|
|
| ckielstra wrote: | I suggest having a look at the recent thread where the most universal chips for use in new products were discussed: http://www.ccsinfo.com/forum/viewtopic.php?t=51047
For example the PIC18F46K22 has 40 pins and 64kbyte ROM for $3.82 at Digikey.
Or smaller, a PIC18F25K22 has 28 pins and 32kbyte of ROM for $2.96
Compare that to the price of an 24LC256, 8kbyte external I2C EEPROM for $0.98. I see you use the PIC16F676, costing $1.56 and total price becomes $2.54 for just under 10kbyte of Flash memory.
The whole point is that the old (PIC) chips are still for sale but because of older production technology use more chip area which makes them more expensive. |
thank u sir
for ur saseation & deep observation me whats controller i use.
those item price in my country are as
24LC256 $ 0.1
pic16f676 $ 0.45
& PIC18F25K22 $ 5.5
_________________
sahu |
|
|
sahu77
Joined: 08 Sep 2011
Posts: 202
|
|
| Posted: Wed Sep 18, 2013 4:52 pm |
|
|
| Ttelmah wrote: | Same applies.
However 'large strings' changes things.
The point is that there is an 'overhead' to everything. The 'smallest' way, would be if you are prepared to build the table in EEPROM, or I2C EEPROM, and 'hard code' the locations where the strings sit. So:
| Code: |
#include <18F4420.h>
#FUSES NOWDT
#FUSES NOBROWNOUT
#FUSES NOLVP
#FUSES NOXINST
#FUSES PUT
#use delay(crystal=20000000)
#use rs232(baud=9600,parity=N,UART1,bits=8,stream=PORT1,errors)
#define VOLT_MESSAGE (0)
#define INPUT_MESSAGE (8)
#define NEXT_MESSAGE (16)
//Now, if you put the messages in the ROM at the locations, and terminate
//with \0 characters
#ROM int8 getenv("EEPROM_ADDRESS")+VOLT_MESSAGE = {"volts"}
#ROM int8 getenv("EEPROM_ADDRESS")+INPUT_MESSAGE = {"INPUT= "}
#ROM int8 getenv("EEPROM_ADDRESS")+NEXT_MESSAGE = {"word"}
//It doesn't matter if there are extra gaps between the messages
//but they must not overlap, and you must remember the space for
//the '\0' which the compiler will automatically generate
//Now have done the code for RS232, not LCD, but the principal remains the same.
void output_message(int16 location)
{
int8 chr;
if (location >= getenv("DATA_EEPROM")) return;
while (TRUE)
{
chr=read_eeprom(location++);
if (chr=='\0') return;
if (location >= getenv("DATA_EEPROM")) return;
putc(chr);
}
}
void main()
{
int16 volt=23;
while(TRUE)
{
output_message(INPUT_MESSAGE);
printf("%ld ",volt);
output_message(VOLT_MESSAGE);
//printf("INPUT= %ld volts",volt); //same message using ROM
delay_ms(1000);
}
}
//As written here, this would display "INPUT= 23 volts"
//With the words 'INPUT', and 'volts' being read from the EEPROM
|
Since you have not said what chip you are using, I've just chosen a generic PIC18.
However the standard 'ROM' way, uses 422 bytes, while using the EEPROM, increases this to 448.
_But_, if you have say 200bytes of messages, the EEPROM way won't grow by much (about 4 bytes every time a whole message is sent), while the ROM way will grow by about 10+no of characters in the message, for each message.
You can do exactly the same using I2C EEPROM, but the initial overhead will be greater, and if there are a lot of variable length messages, you then have to work out how the code is going to find them. Hard coding the start addresses of each message as I show, becomes laborious after a few messages.
Generally, it is much easier/cheaper, unless you are talking dozens of KB of messages, to just use a PIC with more ROM. Modern PIC's with dozens of KB of ROM, are often cheaper than older smaller chips. I have done external storage like this where I had a project with over 20KB of messages, that had to be stored in four different languages as well. However I then wrote a little PC application to actually generate the message tables, and automatically produce the code, since doing it manually was going to be 'insane'...
Best Wishes |
thank u sir now may be my problem solve as per ur guidance .
_________________
sahu |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
