Stupid array question

[SteveB]

There have been a number of solutions to this type of problem. If the messages you plan on displaying won't be changed once the pic is programmed, These may work:

STRINGS - How to store and retrieve strings in Code Space by Darrel Taylor.

Here is a thread which deals with the storage of strings as well.


One other possibility is use an external EEPROM. Limit all the messages to X number of characters (say 255). Then, depending on the message, go to the designated starting address for that message (0 for message A, 256 for message B, ...) Also store a "stop" character to know where the message ends. This would allow something like (This is an example, not a completed program):

MessageString VAR BYTE[256]
StartAddress  VAR WORD
cnt           VAR BYTE
StopChar      CON 3

MessageNumber = 1
StartAddress = MessageNumber * 256
cnt = 0
ReadMessage:
     I2CREAD DataPin,ClockPin,Control, (StartAddress+cnt) ,[MessageString(cnt)]
     IF MessageString(cnt) <> StopChar THEN ReadMessage

HTH,
Steve

EDIT: Added varible declaration for StartAddress

[RUBiksCUbe]

I'll definetly switch to an EEPROM for storage once I get the rest of the circuit working. I thought about using an EEPROM but I wasn't sure how to interface with one. Thanks for the code.

[SteveB]

Some of the nice things about using the external EEPROM:
- I2C or SPI Interface. (both of which have built in PBP software base routines. Or roll your own hardware interface since most, in not all, 18Fs have this.)
- Up to 1024Kbit (with I2C). More than enough for your intended use.
- You can change messages and store new messages. A little more work to program this, but more than likely worth it for your applications. (EDIT: You could do this with ERASECODE/WRITECODE as well)

Best of luck,
Steve

[SteveB]

As my previous reply ratteled around in my head some more (Hard to do while chasing around my little ones on a Sunday afternoon), the method I mentioned relating to the EEPROM could be implemented with READCODE and WRITECODE as well. Definately have a look the link to Darrel Taylor's stuff. You could use the techniques he has come up with to set your initial messages, then later use the ERASECODE/WRITECODE if you want/need to change things (EDIT: But you have to write in 64 byte blocks, which should not be such a limiting factor in your case. See the Datasheet!). If you have lots of extra code space available, why not use it and avoid adding another component to the project.

Steve

[sayzer]

RUBiksCUbe,

I think you now are like a kid in a candy shop and you are allowed to get only one candy but there are hundreds of different candies around you.

You can not decide which one to get???

You came down to two choices; Lookup or EEPROM?





------------------

[RUBiksCUbe]

Lookup or EEPROM
....hmmm....

Well, I already wrote a java applet that exports designes straight to the form of Lookup tables (based off of the one used here: http://www.sparkfun.com/commerce/pre...20LED%20Client)

So for now I'll stick with Lookup, but eventually I'll run out of code space and migrate over to an EEPROM. I'm planning on having a lot of messages available to be cycled through. I guess I could just adapt my applet to export just the hex characters without the Lookup code around it for EEPROM use.

So until I run out of space, I'll stick with Lookup