# Multidimensional arrays with XC8

#### portreathbeach

Joined Mar 7, 2010
143
Been playing with C for a week now and have managed to get i2c protocol working along with serial i2c LCD adaptor board. I was looking at the Nokia5110 LCD which uses a serial data communication to display stuff on the screen. I found some code that is used on the Auduino, and tried to use some of it but the way the character array is set up won't work in XC8.

Here is a little bit of code from the Auduino:

Rich (BB code):
static const byte ASCII[][5] = {
{0x00, 0x00, 0x00, 0x00, 0x00} // 20
,{0x00, 0x00, 0x5f, 0x00, 0x00} // 21 !
,{0x00, 0x07, 0x00, 0x07, 0x00} // 22 "
,{0x14, 0x7f, 0x14, 0x7f, 0x14} // 23 #
,{0x24, 0x2a, 0x7f, 0x2a, 0x12} // 24 $,{0x23, 0x13, 0x08, 0x64, 0x62} // 25 % ,{0x36, 0x49, 0x55, 0x22, 0x50} // 26 & ,{0x00, 0x05, 0x03, 0x00, 0x00} // 27 ' ,{0x00, 0x1c, 0x22, 0x41, 0x00} // 28 ( ,{0x00, 0x41, 0x22, 0x1c, 0x00} // 29 ) }; etc...... This is not accepted by XC8, but if I do Rich (BB code): const char byte[][5]; byte[0][0] = 0x00; byte[0][1] = 0x01; byte[0][2] = 0x02; it will compile and the correct data is in the array. How can this be done simpler and quicker, like in the Auduino code? #### ErnieM Joined Apr 24, 2011 8,005 This can this be done simpler and quicker by doing it exactly like in the Arduino code. The only thing is, "byte" makes sense to Arduino but not to XC8. Rich (BB code): static const unsigned char ASCII[][5] = { {0x00, 0x00, 0x00, 0x00, 0x00} // 20 ,{0x00, 0x00, 0x5f, 0x00, 0x00} // 21 ! ,{0x00, 0x07, 0x00, 0x07, 0x00} // 22 " ,{0x14, 0x7f, 0x14, 0x7f, 0x14} // 23 # ,{0x24, 0x2a, 0x7f, 0x2a, 0x12} // 24$
,{0x23, 0x13, 0x08, 0x64, 0x62} // 25 %
,{0x36, 0x49, 0x55, 0x22, 0x50} // 26 &
,{0x00, 0x05, 0x03, 0x00, 0x00} // 27 '
,{0x00, 0x1c, 0x22, 0x41, 0x00} // 28 (
,{0x00, 0x41, 0x22, 0x1c, 0x00} // 29 )
};
but that is an assault on the eyes, so do this instead:
Rich (BB code):
static const unsigned char ASCII[][5] = {
{0x00, 0x00, 0x00, 0x00, 0x00},  // 20
{0x00, 0x00, 0x5f, 0x00, 0x00},  // 21 !
{0x00, 0x07, 0x00, 0x07, 0x00},  // 22 "
{0x14, 0x7f, 0x14, 0x7f, 0x14},  // 23 #
{0x24, 0x2a, 0x7f, 0x2a, 0x12},  // 24 \$
{0x23, 0x13, 0x08, 0x64, 0x62},  // 25 %
{0x36, 0x49, 0x55, 0x22, 0x50},  // 26 &
{0x00, 0x05, 0x03, 0x00, 0x00},  // 27 '
{0x00, 0x1c, 0x22, 0x41, 0x00},  // 28 (
{0x00, 0x41, 0x22, 0x1c, 0x00}}; // 29 )

#### portreathbeach

Joined Mar 7, 2010
143
Thanks ErnieM. I tried that last night, and it kept saying 'Unable to resolve identifier'. Just reloaded MPLab this morning and it works!

I've had the same problem with a line OSCCONbits.IRCF0 = 0, it was complaining about the IRCF0 even though I had included the right files. When I quit MPLab and reloaded it, everything was OK again! Strange

One last thing.... Is there a way of using a command in XC8 that displays something on the screen in the output window for debugging purposes. For example, in XCode for the iPhone development, the command NSLog("hello") would display the word 'hello' in a window. It would be handy for debugging.

Thanks again ErnieM

Last edited:

#### ErnieM

Joined Apr 24, 2011
8,005
Is there a way of using a command in XC8 that displays something on the screen in the output window for debugging purposes. For example, in XCode for the iPhone development, the command NSLog("hello") would display the word 'hello' in a window. It would be handy for debugging.
No, not exactly want you want as the code must fit inside the memory space of a real PIC. You could use say the printf standard C library function but you have to be able to fit that library, and it is quite sizable at some 5K+. I did this once on a PIC32 debug where there was lots of resources, including a full RS232 port I wasn't using so I could send real time debug info back to the PC

However, the Watch window does give lots of good info. You can have it display "char" so you see the characters inside the string. They read out vertically but it's still pretty good.

#### Potato Pudding

Joined Jun 11, 2010
688
According to the notes I have read on the compiler, it will only patch in functions that are actually used to be part of the generated hex.

Reference listing every library you have should make no difference to the code unless you start using functions from those libraries. Assuming those are efficient functions used appropriately, they will just provide the needed code efficiently and the rest of the library doesn't exist as far as the compiled code is concerned.

It should be easy to test - so easy that I should have tested it myself - but if I am wrong I will be too angry and shocked to enjoy the rest of my weekend.

Tests:
Just throw every library as included that you can into the top of some existing program. Don't change the code otherwise. Compile and it should produce the same version as it made without the extraneous libraries.

Now try and use a few of the simpler functions from different libraries to do anything at all that will impact the outcome, and the output code should not bloat too much even though you are drawing from several libraries.

Even potentially huge functions like Printf are self pruning. If you only need to write "Temperature "&\TempVariable/&"C", it will cut out all of the possible stuff from Printf that is not relevant.

Now that means that you can be aware of what the compiler does and be proactive. You can have the string handling done elsewhere and create a msgTemp string, just pass that to Printf without inline concatenation, and the Printf might compile in a simpler smaller version.

Your string handling functions may or may not be co-opted by the Printf function when it does inline concatentation. Creating a message string might actually produce the exact same code as the inline concatenation because that is something that the compiler will look for - variables that are only used in one place.

Last edited: