CFAF176220M with PIC18F4550

[cpefrank]

The error w/o the " " says Error [1105] symbol 'demoBG' has not been defined BUILD FAILED

Yes the images are super fast but two problems are still here...

I still cannot print two different images, wrong image data.

The other is very funny... I'll illustrate it first:
take this image:
|abc.......d|
|e..........f|
|g..........h|

it prints out as:
|c......d.ab|
|.........f.e|
|.........h.g|

In words it seems to be shifted a few pixels to the right and what is cut off is put at the beginning...

Very strange.

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[cosmicvoid]

The error w/o the " " says Error [1105] symbol 'demoBG' has not been defined BUILD FAILED

That's a sure sign that your image file is not being included in your project. Have you gone into the MPLAB Project menu, and clicked on "Add files to project"?

take this image:
|abc.......d|
|e..........f|
|g..........h|

it prints out as:
|c......d.ab|
|.........f.e|
|.........h.g|

One thing I notice is that the sample code has the display window initialized values such that the 0,0 origin seems to be in the lower right corner.

    write_command(0x36);    // Horizontal Window Address 1 (P32)
    write_data(0x00,0xAF);    // Start of window at rightmost column

    write_command(0x37);    // Horizontal Window Address 2 (P33) 
    write_data(0x00,0x00);    // End of window at left column

    write_command(0x38);    // Vertical Window Address 1 (P33) 
    write_data(0x00,0xDB);    // Start of window at bottom row

    write_command(0x39);    // Vertical Window Address 1 (P33
    write_data(0x00,0x00);    // End of window at top row

That might make sense if the display was rotated 180 deg in usage. Would that affect your image placement?

Meanwhile, I am trying to obtain a CFAF176220M from CFA to use to experiment with the code. So, maybe in a few days I can try to duplicate your issue. I will not be using a PIC cpu, but I don't think that would matter. Since you are not revealing what your actual image files are, you will need to supply images that exhibit your problem. Do the image01.c and image02.c demonstrate the problem? Are the x and y coords in your code correct?

    display_bg(55,55.....);
    display_bg(0,10.....);

 

[cpefrank]

I do not get that error because I include the source file images in my project. The previous post you asked me to show you what the error message said if I didn't include the " ". That's all : )

Your right that is odd that the sample code put the x and y starting axis at that position. But if I picture it correctly, it is still correct since that the image will begin on 0,0 because 0-175 and 0-219 are the sizes and it it starts on 175 and 219 so the first pixel will print on 0,0... So it should make a problem occur but I could mess around with it to see.

The thing is the image seems to be shifted right till some of the image spills over to the other side... Now I've came to this conclusion:

I made an image 176x37... perfectly displayed onscreen.
Then an image 80x40... Thats where the shifting to the right and some spilled over.

It seems to work perfectly on images with the width at 176 (max width).

And for the pic mcu I am using the max image it can hold is 176x88.
I plan to have just a few small images, the memory on the pic can handle.

Ok tested image01 and image 02 i sent and they do print at the specified locations but the images are the same and messed up....
I print a different image (demo) before image01 and image 02... The demo image printed correctly(except the shifter to the right) but the image01 and image02 printed in there specific locations but with the first few colors of demo!

It's like they take on the colors of the first image... Even though I added the totally different source files and names.

very strange.
I will test some more things.

 

[cpefrank]

So I put an image as a header file and it didnt shift.... which is another odd thing...
I also decided to make just one image and the other small images I made by hand with for loops.

I also have an analog input with varying voltage to display numbers. And buttons to turn a hand made image on or off.

But another very very odd thing... I had the color yellow on the image and image2lcd.exe makes yellow as
0X80,0XFF
which if you think about it thats way too dark. And yes it turns out blue green as I imagined.. So I guess I cannot have yellow images.

If you can figure out adding image source files(.c) and have it displaying correctly, I would like to know.

Thanks a bunch for all your advice!

 

[CF Tech]

In a Visual C project, I had a problem that sounded a bit like this one.

It turned out that the compiler alignment was set for 32 bits, instead of the 8-bits I expected. Is it possible that there is some compiler setting that is responsible for this odd behavior?

 

[cosmicvoid]

I received a CFAF176220M and put together a test jig, and tried out your code. Of course, there are some changes in the defines to make it work on an AVR platform. I tried putting the image files in both ram and rom, and there was no difference in result.

The images are very small and inscrutable, but it is obvious that they are not the same.

Attached is my code, and visual results. I didn't bother zipping the two image files, as they have not changed.

 

[cpefrank]

Wow great job
Those two images still come out the same image for me.

I see you have something different in the display_bg: pgm_read_byte(pPat++)
Is this part of the AVR header?

What I have is a background image ( the colors are off by a little bit from using image2lcd.exe), numbers.c (which has 0-9 pixel x pixel not images), a file that reads in analog inputs using a sensor and the second is using a potentiometer, which are both working and printing to glcd.

I wish there were another program besides image2lcd because I see a lot of mess ups in converting the image to hex. I could try MATLAB. The best one turned out to be the one saved as 24 bit .bmp.

I just dont get why your two images printed out different and mine did not. Maybe its the PIC, as you mentioned you dont like working with them ... But on the IDE when I add one image and check the space left, then another image and check the space, the ram does diminish but yet no two separate images print.

 

[cosmicvoid]

I see you have something different in the display_bg: pgm_read_byte(pPat++)
Is this part of the AVR header?

pgm_read_byte() is a macro that tells the AVR compiler to generate code to fetch data from program flash instead of ram. The rom (flash) variables use the keyword "PROGMEM" in typedefs.h to define "PBYTE".

As to why your images are not correct, I can not say. Have you tried stepping thru your program in debug mode, and seeing where the data is being fetched from?

As for putting numbers to the screen, you are welcome to look at my AVR c code for text placement, and use my font editor to pick a nice looking font. You could save out the bitmap data for the number characters. I didn't put that code into this sample as it didn't seem relevant
https://forum.crystalfontz.com/showpost.php?p=28164&postcount=28

 

[cpefrank]

I will step through it soon to check, before that I want to see if i can find the <avr/pgmspace.h> equivelent for PIC.

I'll get back to you this weekend.

 

[cpefrank]

Alright I put breakpoints at:

display_bg(0,0,14,16,&image01[0]);
display_bg(0,0,14,16,&image02[0]);

Bare with me I am new to this PIC C18 compiler. I took an image shot of the disassemble listing and program memory... As I step through it doesnt really show what color that is going into the LCD_DATA to verify if it will go into the second image at all.

I assumed if I step through it till it called pPat++ (image pPAssem.jpg attached) I would see the hex values of the image. I did not.

 

[cosmicvoid]

Looking at your screen captures (nicely done, BTW) reminds me why I absolutely hate the PIC instruction set (and I have used it a little in years gone by). In some ways, it is very clever usage of indirect register addressing to accomplish indirected pre/post inc/dec data accesses. But to the casual viewer (you & me) it is very obscure what the compiler is doing. I looked at the data sheet for your cpu, and I pretty well understand what the compiler is doing to impliment the C code statements. Some of the info needed for analysis is not shown in the code you captured (i.e. some index register contents are set prior to those statements).

... I assumed if I step through it till it called pPat++ (image pPAssem.jpg attached) I would see the hex values of the image. I did not.

They way the code operates, with indirect file to file (aka register to register) data moves, the only way you can see the data is to open a memory dump window (or a watch window) and monitor the contents of certain SFR addresses (special function registers).

I could give you a blow-by-blow description of what the assembler instructions are doing, but since you posted screen images instead of text dumps, it would be clumsy to reference the comments to the instructions. So I won't try.

One FSR to watch is 0xF8C, which is LATD, your data bus port to the LCD. You would see the image data there.

It looks like image01[] is being stored at 0x00A60, and image02[] is stored at 0x00C20. I assume those are program memory locations; you could look at them in a memory window and see if the data matches your image arrays.

I don't know what further help I can offer at this point.

 

[djautoclinic]

Watchlist

You should be able to bring up a variable watch list as you step through your code. Yes you will get the compiled asm code with your c code in the window you are watching but you are more concerned with the watch list than the code if you want to see what values are being tossed around. As cosmic mentioned you can also watch the latch register or the port registers to see what is being sent to the display.

I have not used this display but do use a PIC 18f series to run a cfaf320240f-t and display multiple graphics, text, and colors with no problems. I know Cosmic is not a PIC fan but they work great for me.

Brian

 

[cpefrank]

Thanks guys.

So viewing port D on the Watch I came to the conclusion that at image01 breakpoint and at image02 breakpoint they sent the exact same data when displaying the images while stepping through. But the thing that I dont get is that following the hex values in the Watch on port D and looking at the image01 hex values they never matched...

Shouldnt the values in the image01 file be sent through port D as I'm stepping through?

And viewing in program memory at A60 I have SUBLW 0x41 and at C20 I have NOP

Now is there any way on MPLAB IDE I can view what is in the memory at a certain breakpoint?

 

[cosmicvoid]

... But the thing that I dont get is that following the hex values in the Watch on port D and looking at the image01 hex values they never matched...

Then the pointers to the program memory are probably not correct. For the statement

     LCD_DATA = *pPat++;
movlw 0xf9                    ;loads an offset into W reg
movff 0xfdb, 0xff6  (movff PLUSW2, TBLPTRL)   ;moves a byte from memory pointed to by FSR2 + W  (FSR2 is at 0xFD9-FDA) into TBLPTRL (low byte of table pointer).
nop       ;is actually the 2nd word of the previous movff instr.

movlw 0xfa                    ;loads an offset into W reg
movff 0xfdb, 0xff7  (movff PLUSW2, TBLPTRH)   ;moves a byte from memory pointed to by FSR2 + W  (FSR2 is at 0xFD9-FDA) into TBLPTRH (high byte of table pointer).
nop       ;is actually the 2nd word of the previous movff instr.

TBLRD           ;reads program memory into TABLAT (0xff5)
movf 0xff5,W    ;moves TABLAT to W
movwf 0xf8c     ;moves W to LATD (the port pins)

You would have to examine SFR2 and TBLPTR while stepping thru the assembly instructions to see what addresses are pointed to. TBLPTR should have 0x0A60 or higher for image01.

Shouldnt the values in the image01 file be sent through port D as I'm stepping through?

Supposedly.

And viewing in program memory at A60 I have SUBLW 0x41 and at C20 I have NOP

That's encouraging, as the first byte of image01 is 0x41, and the first byte of image02 is 0x00. You would need to look at those areas as a memory dump, not as a program listing.

Now is there any way on MPLAB IDE I can view what is in the memory at a certain breakpoint?

I don't know what features MPLAB offers.

 

[djautoclinic]

Mplab

Frank,

You should be able to view your program and the assembly listing while stepping through th program. Looking at your screens it appears the is a .cof file created by your compiler that links you source code to the .asm file for debugging. You should also be able to use the watch list as you step through to see the values of your special function registers and your variables by name while you step through.

I do not program in C but use mplab for debugging so I can't really help with your code. That being said it looks like you have a problem with the lookup on your second graphic. Something like maybe you are referencing the second graphic when you call the display routine but the routine does not use the reference for which graphic to display as if it is hard coded to only look up the first graphic. Honestly getting the display to work and write any pixel at all is the hard part. Displaying 2 different graphics should be the easy part.

Brian

 

[cpefrank]

Hi,
At the moment I am busy with so many things, I need to hold off on trying to get two images to appear without duplicate.
But I do have one large image (the largest the PIC can hold) with all of my digital and analog inputs working and displaying on the screen.
Of course it would have been nice to have my large image split up as multiple images so I can use the full screen, but half works fine.
But I will check this page frequently just in case some one who has had experience with PICs that may have an idea why my PIC isnt letting the second image print its own hex values.

Thanks again for all the help, great learning experience especially when I have never used the PIC or GLCD before.
~Frank.

 

[cpefrank]

Wow after finishing my project and designing the pcb for the whole design... I said what the heck lets change the software... I have the full version of the C18 upgraded compiler now and put in the 8.36v of MPLAB IDE (older version) and voila... the two images can show up without mimicking the other...

Lol a bit too late but at least it works perfectly!

Thanks again for everything.

~frank.

 

[cosmicvoid]

So it was the new compiler version that made it work correctly?