Change variable allocation to save code space

[aberco]

Dear everyone,

I have a quick question regarding what could be a trivial problem, I am driving a complex LED matrix which is fed through a series of shift registers. The output are out of order, so I have to reconstruct the correct sequence using a brightness array. I then used some modifiers to get the right order:

LEDPattern VAR BYTE[80]

RedSegment1 VAR LEDPattern[23]
RedSegment2 VAR LEDPattern[21]
RedSegment3 VAR LEDPattern[15]
RedSegment4 VAR LEDPattern[12]
RedSegment5 VAR LEDPattern[6]
RedSegment6 VAR LEDPattern[4]
RedSegment7 VAR LEDPattern[26]
....

Now I have a series of subroutines designed to display a series of patterns. Some are quite complex, but some are simple like this one to turn all the red segments on:

RedSegment1 = 8
RedSegment2 = 8
RedSegment3 = 8
RedSegment4 = 8
RedSegment5 = 8
RedSegment6 = 8
....

Is there a better solution for doing this to save some code space? I could use a FOR loop but I cannot refer to the variable change as with an array...

Thanks for the help!

[Charles Linquis]

I don't know if it will work in your case, but you can use an array to point to an index in another array.

Something like

Arraywrite OffsetArray,[0,23,21,15,12,6,4,26]

For X = 1 to 8
Temp = OffsetArray[X]
LEDPattern[Temp] = 8
Next X

[aberco]

Good point, I thought about doing this, but it just transfer the program memory overhead into the RAM right as it will mean creating another whole 80 byte array, right? Also I will have to fill OffsetArray with a series of 80 constants which will go right into program memory.

I'm using a 16F648A with 256B of RAM and the compiler cannot fit two such large arrays into contiguous banks right now. Granted that I probably have some optimizations left on the program, I will not be able to free up much RAM space though...

[Charles Linquis]

Is it fair to ask why you don't simply use a big 18F part to begin with? Optimizing code to fit a small device might be rewarding, but it generally isn't cost-effective from a time standpoint uless you are making several hundred or more.

[aberco]

Yes, I have looked in microchip catalog, but there is no SOIC 18 pin compatible parts with more code memory... The 16F88 does have 384B of RAM and is the only 18 pin with better features. Of course I have already made 60x13 cm double sized PCBs which were quite expensive, so I have to use the SOIC18 layout. It seems that the 18F family has discarded the 18pin footprint.

I am reaching the 4k word limit which only restrain me from adding more animations. It is not a serious problem but I thought I could do a better job than having more than 200 lines of "Variable = Value" in my program.

[Jumper]

With some creative thinking and some luck you might add an EEprom. It could be possible to solder it directly onto the PIC itself. Piggy-back the EEprom and set the i2c bus to drivven and you might even get away without adding the pullup resistors for sda and scl.

It is only 4 pins (GND, VDD, SDA, SCL) you need to connect between the PIC and the eeprom, the other pins on the EEPROM you connect either to GND or VDD (address, RW). Microchip have alot of I2C eeproms in different sizes and packages so if you just have 2 un-used pins on the pic in a suitable position this might be an option.

Then you can add alot of LED patterns and use the I2C command to load them into the RAM variables when you need to display the pattern.