I've tried using pointers to access the msg char array but even that messes it up. I also tried making a function that returns the char but it didn't help either. Or even passing the msg into another array to manipulate it there. It seems very odd that whenever I use somethign somehow related to the char msg array in another array subscript and then print out the msg array it is nothing but spaces.

I find it frustrating that I know what is going wrong but not why or how to fix it.

 

Just to make this clear:

You work at a Visual Studio program to build a bitmap then send to Arduino.

On the Arduino you maintain a "sketch" (I used arduino just a few times), to transform the bitmap and shift it to the LED matrix.

So far you succeeded to let appear "Hello", but one line freaked and you can't gain control over it.

My recommendation is to download MPLABX, and the 3 C compilers:

XC8 : 8bit
XC16 : 16bit
XC32 : 32bit for PIC32

They all can use templates, which allow you to get a project going.

Try the XC8 for a start, choose a reasonable PIC, for instance the 18F.

Then you select not a hardware FLASH writer, but the MPLABX software simulator.

Set breakpoints, and you can simply hover over array and pointer compounds, and see their value.

Also you can observe the file registers (aka RAM).

It is possible even to set the ones and zeros so you can see the pattern in the file register view.

Or is there a good debugger/simulator for the Arduino IDE? Then if so, I'd recommend to use that if you can get along with that easier.

All the Microchip stuff is about 700 megabytes or so from their website, and free, no registration.

I think in your case you need to set breakpoints, single step, and observe the file registers (RAM).

 

Just to make this clear:

You work at a Visual Studio program to build a bitmap then send to Arduino.

On the Arduino you maintain a "sketch" (I used arduino just a few times), to transform the bitmap and shift it to the LED matrix.

So far you succeeded to let appear "Hello", but one line freaked and you can't gain control over it.

Yes that is right, except I work in a compiler called Code::Blocks its doesn't really make a difference though.

Or is there a good debugger/simulator for the Arduino IDE? Then if so, I'd recommend to use that if you can get along with that easier.

There isn't much debugging/simulating with the arduino IDE, except for printing and lighting LEDs in the actual code.


I thought I would try send it a ByteMap of the msg by column instead of a bitmap because:
a. It would be more efficient.
b. I wouldn't have to deal with dynamically Allocated memory on the arduino which I here can get horribly messy.

I am however having troubles creating the ByteMap as seen in my past couple posts.

 

I am not sure where your main problem lies.

-Difficulties with array/pointer
-Diffculty with PC/Arduino link
-Difficulty with LED matrix electrical

You showed a photo with a LED matrix, with "Hello" lightening up.

What about programming this software only on the Arduino?

It is possible to dump data over the serial port (Arduino) to the PC to a terminal program.

How about using ready-made modules?

When you get it working, start with the PC link, and build your own LED modules.

issues could be many different ones, just a few, or just one.

How many C programs did you write for Arduino? How would you speciffy your C knowledge?

Dont give up!

 

I am not sure where your main problem lies.

-Difficulties with array/pointer
-Diffculty with PC/Arduino link
-Difficulty with LED matrix electrical

You showed a photo with a LED matrix, with "Hello" lightening up.

What about programming this software only on the Arduino?

It is possible to dump data over the serial port (Arduino) to the PC to a terminal program.

How about using ready-made modules?

When you get it working, start with the PC link, and build your own LED modules.

issues could be many different ones, just a few, or just one.

How many C programs did you write for Arduino? How would you speciffy your C knowledge?

Dont give up!

I'm not giving up yet!

Thanks for all the help so far.

My main problem WAS with the arduino code.
I decided to revise and clean up all my code and instead of sending a bitmap a would combine the bits into bytes, and hopefully along the way my arduino code would fix itself.

Now my problem is with the revised computer end. The code is listed in my post at 02-15-2014 08:50 PM. Basically, I think I've narrowed it down to whenever I use something related to the char array that the user enters in another array subscript strange things happen such as the char array being erased. It could be just a discrepancy in the syntax of how I am doing it:

void DisplayFunctions::createByteMap(){
    int charColIndex =0;
    int Character = 0;


    for(int col=0;col<numberOfCol;col++){
            rmsgByteMap[col] = fontObj.ASCII[msg[Character]][charColIndex];
            charColIndex++;
            if (charColIndex==characterArrayLength[Character]){
                charColIndex = 0;
                Character++;
            }




    }
    
}

I have also tried using a pointer like this:

void DisplayFunctions::createByteMap(){
    int Character = 0;
    int charColIndex=0;

    char * msgPntr = msg;
    char msgCharacter = msgPntr[Character];



    for (int col=0;col<numberOfCol;col++){


        rmsgByteMap[col] = fontObj.ASCII[msgCharacter][charColIndex];
        charColIndex++;


        if(charColIndex == characterArrayLength[Character]){

            charColIndex = 0;
            Character++;
            msgCharacter = msgPntr[Character];
        }
    }
}

Once again you can see all of the code in the previous post.

A little clarification on the actual matrix:

I originally bought it off of Ebay. It came from a much bigger sign. About a year ago, I wrote code for it to scroll a predescribed message with a non-proportional font. I have tested the matrix both with this code and code that came with it when I bought it and it seems to be in perfect working condition.

 

I see you are workig on it.

I have not taken the effort to take a deep look or to simulate it myself, just a quick inspection.

in 2. you use a pointer.


A pointer is normally used like that:

const unsigned char txt1[]={"Text1","Text2") (to keep it simple only fixed length here)

unsigned char* txtptr= &txt1;
Also let's define a regular char: unsigned char txtdata;

Then you access individual chars with:

txtdata = *txtptr

You can increase or decrease the pointer:

txtptr+=1;

Or you can add an index in an expression:

txtdata= *(txtptr+2);

That about that.

2

To take care vriable length,

you need to use a terminator ccharacter, or you need to build up the strings individually, and then build an array of pointers.

I show you one definition for proportional font (each character bitmap has a variable size):

/* 
 * File:   chrset.h
 * Author: Max
 *
 * Created on 06 February 2014, 23:34
 */

#define chr_a 0b10011110,0b00101,0b00101,0b11110 //4
#define chr_b 0b10011111,0b10101,0b10101,0b01110 //4
#define chr_c 0b10001110,0b10001,0b10001,0b10001 //4
#define chr_d 0b10011111,0b10001,0b10001,0b01110 //4
#define chr_e 0b10011111,0b10101,0b10101,0b10001 //4

#define chr_f 0b10011111,0b00101,0b00101,0b00001 //4
#define chr_g 0b10011111,0b10001,0b10101,0b11100 //4
#define chr_h 0b10011111,0b00100,0b00100,0b11111 //4
#define chr_i 0b01110001,0b11111,0b10001 //3

#define chr_j 0b10011000,0b10001,0b10001,0b11111 //4
#define chr_k 0b10011111,0b00100,0b01010,0b10001 //4
#define chr_l 0b01111111,0b10000,0b10000 //3
#define chr_m 0b10111111,0b00010,0b00100,0b00010,0b11111 //5
#define chr_n 0b10111111,0b00010,0b00100,0b01000,0b11111 //5
#define chr_o 0b10001110,0b10001,0b10001,0b01110 //4
#define chr_p 0b10011111,0b01001,0b01001,0b00110 //4
#define chr_q 0b10101110,0b10001,0b10001,0b01110,0b10000 //5
#define chr_r 0b10011111,0b00101,0b01101,0b10110 //4
#define chr_s 0b10010111,0b10101,0b10101,0b11101 //4
#define chr_t 0b01100001,0b11111,0b00001 //3
#define chr_u 0b10001111,0b10000,0b10000,0b11111 //4
#define chr_v 0b10001111,0b10000,0b01000,0b00111 //4
#define chr_w 0b10101111,0b10000,0b11000,0b10000,0b01111 //5
#define chr_x 0b10110001,0b01010,0b00100,0b01010,0b10001 //5
#define chr_y 0b10010111,0b10100,0b10100,0b01111 //4
#define chr_z 0b10010001,0b11001,0b10101,0b10011 //4

#define chr_0 0b10001110,0b10001,0b10001,0b01110 //4
#define chr_1 0b01110010,0b11111,0b10000 //3
#define chr_2 0b10011101,0b10101,0b10101,0b10111 //4
#define chr_3 0b10010101,0b10101,0b10101,0b01110 //4
#define chr_4 0b01100111,0b00100,0b11111 //3
#define chr_5 0b10010111,0b10101,0b10101,0b01000 //4
#define chr_6 0b10011111,0b10101,0b10101,0b11101 //4
#define chr_7 0b10000001,0b00101,0b11111,0b00100 //4
#define chr_8 0b10001110,0b10101,0b10101,0b01110 //4
#define chr_9 0b10010111,0b10101,0b10101,0b11111 //4

#define chr_dc 0b01100000,0b01010,0b00000 //3
#define chr_sl 0b01100100,0b00100,0b00100 //3
#define chr_pt 0b00110000 //1
#define chr_empty 0b00100000 //1

const char s_chr_a[]={chr_a};
const char s_chr_b[]={chr_b};
const char s_chr_c[]={chr_c};
const char s_chr_d[]={chr_d};
const char s_chr_e[]={chr_e};
const char s_chr_f[]={chr_f};
const char s_chr_g[]={chr_g};
const char s_chr_h[]={chr_h};
const char s_chr_i[]={chr_i};

const char s_chr_j[]={chr_j};
const char s_chr_k[]={chr_k};
const char s_chr_l[]={chr_l};
const char s_chr_m[]={chr_m};
const char s_chr_n[]={chr_n};
const char s_chr_o[]={chr_o};
const char s_chr_p[]={chr_p};
const char s_chr_q[]={chr_q};
const char s_chr_r[]={chr_r};
const char s_chr_s[]={chr_s};
const char s_chr_t[]={chr_t};
const char s_chr_u[]={chr_u};
const char s_chr_v[]={chr_v};
const char s_chr_w[]={chr_w};
const char s_chr_x[]={chr_x};
const char s_chr_y[]={chr_y};
const char s_chr_z[]={chr_z};

const char s_chr_0[]={chr_0};
const char s_chr_1[]={chr_1};
const char s_chr_2[]={chr_2};
const char s_chr_3[]={chr_3};
const char s_chr_4[]={chr_4};
const char s_chr_5[]={chr_5};
const char s_chr_6[]={chr_6};
const char s_chr_7[]={chr_7};
const char s_chr_8[]={chr_8};
const char s_chr_9[]={chr_9};

const char s_chr_dc[]={chr_dc};
const char s_chr_sl[]={chr_sl};
const char s_chr_pt[]={chr_pt};
const char s_chr_empty[]={chr_empty};

const char* const alpha_chr[]  =
 {s_chr_a,s_chr_b,s_chr_c,s_chr_d,s_chr_e,s_chr_f,s_chr_g,s_chr_h,\
 s_chr_i,s_chr_j,s_chr_k,s_chr_l,s_chr_m,s_chr_n,s_chr_o,s_chr_p,\
 s_chr_q,s_chr_r,s_chr_s,s_chr_t,s_chr_u,s_chr_v,s_chr_w,s_chr_x,s_chr_y,s_chr_z,\
 s_chr_0,s_chr_1,s_chr_2,s_chr_3,s_chr_4,\
 s_chr_5,s_chr_6,s_chr_7,s_chr_8,s_chr_9,\
 s_chr_dc,s_chr_sl,s_chr_pt,s_chr_empty};

I solved it by embedding the size in the upper 3 bits of the first byte (it is not a string array, but can be accessed as such with the help of pointers. I get compiler warnings about illegal pointer usage, but it is OK, since I know what I am doing).

Also I show you how I generate the bitmap using this font data.
You can see I have to resort to individual characters in order to include a "0" for the scroll text, and also here I use a pointer array.

It is not that difficult to access llater, but you need some fluency using pointers and array together.

If you are desperate, you could use only pointer or only array, they are exchangeaable, but often it makes sense to use either one, or both together.

const unsigned char msg1[]={'K','A','W','A','S','A','K','I',' ',0};
const unsigned char* const msg_arr[]={&msg1};

#define display_buffer_size 10
unsigned char display_buffer[display_buffer_size];
unsigned char msg_buffer[80];
unsigned char msg_buf_idx;

unsigned char curr_msg_idx;
unsigned char curr_scroll_idx;

#define display_width 14

void configure_tris()
{unsigned char i;
 unsigned char* tris_reg;

 for(i=0;i<12;i++)
 {
  tris_reg=tris_port1;
  *tris_reg&=pin_bit_reset1;
  tris_reg=tris_port2;
  *tris_reg&=pin_bit_reset1;
 }

}

unsigned char reloc_ascii(unsigned char c)
{
    if(c>64)return(c-65);
    if(c>47)return(c-22);
    if(c==32)return(39);
    if(c==45)return(37);
    if(c==46)return(38);
    if(c==0)return(0xff);
}

void generate_scroll()
{
 unsigned char* curr_msg;
 unsigned char* font_data;
 unsigned char chr,chr_reloc,font_data_size,font_data_value;
 unsigned char i;

 curr_msg=msg_arr[curr_msg_idx];
 reloop:
  chr=reloc_ascii(*curr_msg);
 if(chr==0xff)goto rdy;

  font_data=alpha_chr[chr];
  font_data_size=(*font_data)>>5;
  font_data_value=(*font_data)&0b11111;

  for(i=0;i<font_data_size;i++)
  {
   msg_buffer[msg_buf_idx]=font_data_value;
   msg_buf_idx++;
   font_data++;
   font_data_value=*font_data;
  }
  msg_buffer[msg_buf_idx++]=0;
  curr_msg++;
  goto reloop;
 rdy:;
}

 

this is what i get from the memory view after running it in the MPLAB SIM.

I admit I had to set breakpoints, and run sinngle stepping a few times, but not that dramatic.

Without a software simulator/debugger, it is hard to play with pointers/arrays, in older days it was required to inspect the disassembly, and print out values directly on the screen, and simulate breakpoints with keyboard reads. Just takes much longer.

 

First off:

I'm not sure if you are saying I amusing pointers wrong or right, because you say

a pointer is normally used like that:

Is that referring to how I did it or did you mean to say this instead of that.

I can do this and get what I entered:

cout << msgCharacter << endl;
    msgCharacter = msgPntr[Character+1];
    cout << msgCharacter << endl;
    msgCharacter = msgPntr[Character+2];
    cout << msgCharacter << endl;
    msgCharacter = msgPntr[Character+3];
    cout << msgCharacter << endl;
    msgCharacter = msgPntr[Character+4];
    cout << msgCharacter << endl;

I tried using pointers exactly as you described in the example however it did not change anything. And in fact with the line commented out (see next paragraph) the msg did not print properly even. So quite frankly I like my way better and don't think it is wrong.




When ever I comment out this line:

rmsgByteMap[col] = fontObj.ASCII[msgCharacter][charColIndex];

The msg can still be printed to the screen in main as it should so that seems to be the problem.
If it is not commented out when I print the msg to the screen I get however many blank lines as characters I entered. i.e. Hello gives me 5 blank lines.

this is what i get from the memory view after running it in the MPLAB SIM.

I admit I had to set breakpoints, and run sinngle stepping a few times, but not that dramatic.

Without a software simulator/debugger, it is hard to play with pointers/arrays, in older days it was required to inspect the disassembly, and print out values directly on the screen, and simulate breakpoints with keyboard reads. Just takes much longer.

Are you talking about your code, or my code. My computer code? My arduino code? Sorry I am just not sure what you are trying to say here. The picture you included doesn't look like anything at all.

 

well the view is from my code.

I think you have a regular pointer, but then you use it like it would be an array containing pointers without dereference.

dont you get a compiler warning?

You normally "dereference" a pointer to obtain the value contained at the address where it points to.

That said, C knows pointers to arrays with pointer to structures which contain...something.

Do you have a copy of "C language" available?
The wikipedia article also is not bad.

Thing is, if your compiler is maybe sloppy and does not warn you about "illegal conversion", since the controller memory is small, the construct still obtains some values, but you get weird unexpected results.

In the MSDOS days you;d almost always know you made a mistake because dynamic allocation and when you accessed outside the bounds, the OS would crash + you had to reboot.

A controller may reset, and you dont even notice, except you obtain unexpected results.

2

Yes I suggested you dont use pointers correctly, because you add an array index for a pointer which normally should be dereferenced.

That said, there is some way to treat pointers like arrays, but you have to follow the guideline from the C language book.

I normally only dereference pointers + do arithmetic on them, and I use arrays which contain pointers.

If the compiler translates it as legal C, in most cases it means it is some possible way of casting or spelling, but that alone does not imply it makes sense or is correct according to the scheme you use for your constructs.

A single stepping session would be of help here.

I suggest to try MPLABX- you cant use C++, but when you remove the IO you can transfer the C, and you can set a breakpoint, then single step, and hover over each variable, and see it;s value.

Its a great tool.

Otherwise, when you have a screen, you;d have to print the values + wait for a key, or if you run on a controller, you need to send to a serial terminal.


Without debugging means, it is hard to figure out where the problems really lie.

I take a loook the wikipedia article of pointers now and maybe the book too- and see if I get any answer from meditating over that.

 

I am not getting any compiler warnings about my pointers.

They work perfectly I can print them out to the screen and they display as expected. I originally got this format for pointers form a different forum after a google search.

Thing is, if your compiler is maybe sloppy and does not warn you about "illegal conversion", since the controller memory is small, the construct still obtains some values, but you get weird unexpected results.

MY problem with pointers is on the computer. I don't thinks my computer can't handle it.

I have no background in C, except for what I know about C++ since they are quite similar.

 

Array-pointer interchangeability

http://en.wikipedia.org/wiki/C_(programming_language)#Array-pointer_interchangeabilitybility

http://www.physics.drexel.edu/courses/Comp_Phys/General/C_basics/c_tutorial.html#arrays


I'd recommend to dereference pointers, and use the index with arrays.


Well if you ever used assembler, you always had to use pointer registers (such as DS:SI, Data Segmet:Source index)


Some CPUs also allow an additional numerical index.


I am sure you will be able to locate the trouble soon.

 

Array-pointer interchangeability

http://en.wikipedia.org/wiki/C_(programming_language)#Array-pointer_interchangeabilitybility

http://www.physics.drexel.edu/courses/Comp_Phys/General/C_basics/c_tutorial.html#arrays


I'd recommend to dereference pointers, and use the index with arrays.


Well if you ever used assembler, you always had to use pointer registers (such as DS:SI, Data Segmet:Source index)


Some CPUs also allow an additional numerical index.


I am sure you will be able to locate the trouble soon.

I'll look over those materials.

Thanks so much for your help and patience.

 

I am not getting any compiler warnings about my pointers.

They work perfectly I can print them out to the screen and they display as expected. I originally got this format for pointers form a different forum after a google search.

Thing is, if your compiler is maybe sloppy and does not warn you about "illegal conversion", since the controller memory is small, the construct still obtains some values, but you get weird unexpected results.

MY problem with pointers is on the computer. I don't thinks my computer can't handle it.

I have no background in C, except for what I know about C++ since they are quite similar.

See my reply above.

Yes you can print them, that's at least something.

In the meanwhile, it is not totally clear which codes are working and which not, and what is the actual problem.

i understand the issue, you work at code, and you make changes, and you have C programs on the computer andd the Arduino.

Maybe make a new thread, where you isolate issues more. Only a single source, and a single problem- what you expect it to do, and what it does indeed, and the source.

C++ is nothing but C with an additional layer. Classes are just a way of using regular functions- given some effort, you could do it manually.

C++ contains C as a subset.

 

I figured it out!

At least my problem on the computer end.

rmsgByteMap did not have a declared size. Therefor memory was overflowing and overwriting so everything went haywire.



Thanks for all the help.


Now I am getting a segmentation fault that I can't figure out. This thread is very cluttered so I will start a new one.