Stupid array question

[RUBiksCUbe]

I'm working on an LED matrix project that involves displaying data on an 8 x 80 LED matrix (multiplexed of course). I was planning on storing the data to be displayed in hex form in my PIC18F252s EEPROM, which I would then be able to look at using .Bit0 or .Bit1 to see if an LED needs to be on (for example, $AA in binary is 10101010, which would mean that every other LED is on). The only problem with this plan is that the EEPROM on the 18F252 is only 256 bytes, leaving room for less than 125 rows of LEDs, which just isn't enough.

If anyone knows a good way to somehow compress data, that might be usefull, but I was thinking about storing the display data in arrays, that way I could easily switch between different messages.

So, the real question now:
Is there any way to store a bunch of data in an array on one line?

In java you can do this:
Int[] test = {5, 6, 7};

Can you do anything like that in PBP? It would make coding much easier, as opposed to going like this:
message[0] = $AA
message[1] = $2C
message[2] = $4D

and so on...

[sayzer]

.... switch between different messages.
....

Will the "different messages" come from an external source or there will be a fixed pattern inside the program and once the PIC is programmed then that fixed pattern will never be changed?



--------

[paul borgmeier]

As Sayzer is hinting, if your data does not change after you do the initial programming, you could use the LOOKUP or LOOKUP2 command. (or just the READCODE command referenced below if you preloaded your data)

If your data is going to change, you could use WRITECODE and READCODE. Also see: http://www.picbasic.co.uk/forum/showthread.php?t=137 for reference

[RUBiksCUbe]

The READCODE command actually looks perfect for me. Thanks for pointing that out.

The PIC will switch between different messages when external buttons are pushed.

[RUBiksCUbe]

Well, it was too good to be true. Whenever I compile with this in my project:

Asm
CODE 1400
DB 0
DB 220
DB 476
DB 384
DB 384
DB 476
DB 220
DB 0
DB 999
Endasm

I get some nice errors:

Found directive in column 1. (CODE)
Directive only allowed when creating an object file
Found directive in column 1. (DB)
Argument out of range. Least significant bits used.

There are 15 errors total, but they're all just copies of those 4.

Am I missing something?

[paul borgmeier]

You need to indent your program like that below. However, I believe DB is used for bytes only and you must use packing to place the word (i.e., DB 476 will not do what you want)? Others with more 16 bit processor Assembly experience might be able to offer a (better) solution in ASM.

You might want to consider using PBP's WRITECODE instead of the ASM for the initial write. Look here http://www.picbasic.co.uk/forum/show...ight=writecode and also search “WRITECODE” on this forum for examples of how to write to the 18F family, which is not as straight forward as one might think.

Asm
     CODE 1400
     DB 0
     DB 220
     DB 476
     DB 384
     DB 384
     DB 476
     DB 220
     DB 0
     DB 999
Endasm

Good Luck

edit: or consider LOOKUP2 tables

[sayzer]

..........or consider LOOKUP2 tables

I also was going to suggest LOOKUP table but arrays can not be used with Lookup tables!
Say there are 90 messages.

'This code is just a part of the idea to start from somewhere.


Message     var byte[90]
MessageTemp var byte
Loop        var byte


for loop = 0 to 89
    lookup loop,[$AA,$2C,$4D,.....................], MessageTemp
    message[loop]=messageTEMP

next loop

This way,

........

Can you do anything like that in PBP? It would make coding much easier, as opposed to going like this:
message[0] = $AA
message[1] = $2C
message[2] = $4D

and so on...

can be achieved.


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



-------

[RUBiksCUbe]

I never knew about LOOKUP, but the lookup and loop should work perfectly. The intenting fixed the "DB"s but the "CODE" line still causes a problem, so I'm going to abandon READCODE and just stick with LOOKUP.

Thanks!

[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