PIC18F4620 Problem: scrambled display GLCD

Testing/Troubleshooting
1

Hi everyone!

Our university project is nearing it´s completion, which is good, as our given time runs out in two weeks  ;D

We are building a MIDI Controller based on MIOS with two cores and two 240x64 Pixel GLCDs that show parameter names and values. The box is being programmed with a Java software for 16 devices with up to 1024 parameters per device. More about this in a User-Wiki, in two or three weeks, after we´ve finished…

Our big problem:

we have migrated to a PIC18F4620 (including the IIC workaround) two days ago as our code size exceeds the limits of the PIC18f452 by far. We have made all the adjustments from the PIC18F4620 Wiki

(http://www.midibox.org/dokuwiki/doku.php?id=using_pic18f4620), and we are using the special 18F4620 versions of MIOS 1.9c and the bootstrap loader. The chip´s got the ID 0 and the display type in the header is set to 7.

Now we get a strange error, that the display only shows scrambled stuff. Our guess is that our code size overwrites the GLCD font from MIOS, as it does not happen when we strip our code to fit into the 0x7BFF range (everything works fine again!). Also we noticed that during upload of the MIOS, it is writing MIDI data to the space of 0x7C00-… (or similar), space that should now be reserved for our code, no???

Is our code only overwriting the GLCD font (we could include it “custom-made” in our code again) or is any other part of the MIOS also overwritten?

Do we need to make other adjustments to the MIOS files for it to work correctly?

Sorry if I was missing something in the forums, but we searched them and the websites for half a day yesterday, and we cannot afford to lose much more time…

Best regards,

Christian

2

Hello Christian,

here is a quick guess from someone who never worked with a PIC 18F4620:

As GLCDs are rarely used with MIOS projects (CLCDs are a lot more common), I can imagine, that some instructions on updating the MIOS-Code are missing in the WikiPage. And even more uncommonly are two GLCDs on one core…

-> As for MIOS_HELP_Dec2BCD is a changement in the wrapper required, I think maybe this may also be the case with some GLCD functions?

-> I suppose you checked the wirings of the GLCDs and make sure, they work?

-> And you took the original precompiled MIOS, now also available for the PIC18F4620? …or a custom modified version?

-> AFAIR there is a conversion flag in the hex2syx-script: the MEM64k-option; have you set that?

Regards,

Michael

3

Hello audiocommander,

thank you for your quick reply!

Just to clarify again: we use two cores that communicate over MIDI and each is connected to one of the GLCDs.

Maybe something was missed indeed in the wiki page, good to know that GLCDs are not that common, and might have been missed…

-> good hint, we will look into that

-> we checked the wirings, they are working correctly. The displays actually do work fine (even with PIC18F4620), as long as the code size doesn´t exceed 0x7BFF. This is true both for ucapps example apps as well as our own app.

-> we took the original, precompiled MIOS v1.9c for PIC18F4620 (and the corresponding Bootloader as well)

-> we have already set the conversion flag -mem_64k. It did not work at all before.

If there are any other ideas or suggestions, we would be very grateful…

Best Regards,

Christian

4

Hi Christian,

you need to relocate the font to another location, so that it doesn’t overlap with the program code.

Here a quick & dirty solution (I will provide a proper solution for C programs later)

  • copy the mios_glcd_font.inc file from the MIOS release into your application directory, rename it to mios_glcd_font.asm

  • add following code to the file header:

          LIST P=PIC18F4620, R=DEC

    DEFAULT_FONT code

    FONT_ENTRY MACRO width, height, x0, char_offset
    dw ((height) << 8) | (width), ((char_offset) << 8) | (x0)
    ENDM
    [/code]

  • change the “org” (start address) from 0x7cfc to 0xfcfc

  • add a “END” at the file footer

  • add the new .asm file to the MAKEFILE.SPEC (behind the MK_SET_OBJ statement)

  • change the font pointer within the Init() routine:

[code]
void Init(void)
{
  MIOS_GLCD_FontInit(0xfcfc);
}

  • if you are working under MacOS or Linux, type “perl tools/mkmk.pl MAKEFILE.SPEC; make”, under DOS just type “make”

Hope this is all (I haven’t tried it)

Some more fonts and icons can be found within the midibox_lc project

Best Regards, Thorsten.

5

Hi Thorsten!

Thanks for your reply!

We actually found another solution in the last 5 minutes, which I was just typing up here.

What do you think of this:

The linker script in project.lkr had to be modified.

In the wiki it was described like this:

Change

CODEPAGE  NAME=page      START=0x3000        END=0x7FFF

To

CODEPAGE  NAME=page      START=0x3000        END=0xFFFF

But what really had to be done was to create another additional page and modify the first one, so you´d have these two lines:

CODEPAGE  NAME=page0      START=0x3000        END=0x7BFF

CODEPAGE  NAME=page1      START=0x8000        END=0xFFFF

This is to leave out exactly the space in the PIC, where MIOS is written to (the GLCD Font I guess).

Which one would be the more recommendable solution?

Can anyone change that in the wiki?

Can/should we do it?

Best Regards,

Christian

6

Hi Christian,

both solutations have their advantages and disadvantages, therefore it would be nice if you could document both in the Wiki (yes, everybody is allowed to change existing pages)

Your method has the advantage, that it isn’t required to upload the font again and again with each program update.

My method has the advantage, that new fonts can be inserted into the project in a similar way. The only thing I would change is the way how the base address of the font is specified. With relocatable code, it makes sense to let the linker decide at which location the font should be stored, by exporting/importing the label of the base address, you can use for example ‘MIOS_GLCD_FontInit(font_big);’, ‘MIOS_GLCD_FontInit(font_small);’, ‘MIOS_GLCD_FontInit(icons_knobs);’ without knowing the absolute address

Best Regards, Thorsten.

7

Hi Thorsten,

I will document both solutions in the Wiki then.

However I didn´t completely understand the last paragraph you wrote…

The thing you would change, does it refer to our or to your solution? And how could the base address be ex-/imported? Is it done in the project.lkr file? Would you have a code example?

Oh, and by the way, are the font_big and icons_knobs fonts already part of the MIOS? I remember we always had trouble using those in C.

Best Regards,

Christian

8

The thing you would change, does it refer to our or to your solution?

It refers to my solution

And how could the base address be ex-/imported?

within the assembly code, you can export a label (= address which will be determined during the link stage) with “global <label-name>”. Within the C program, you can import the label with “extern”

Is it done in the project.lkr file?

no, this is not required

Would you have a code example?

general examples how to import/export labels between assembly and C code can be found in sm_c_example1_v1, sm_c_example2_v1, midi_router_v1_0b

Oh, and by the way, are the font_big and icons_knobs fonts already part of the MIOS?

It doesn’t make much sense to bring this into MIOS, it would blow up the code size and wouldn’t have any advantage for people who don’t use a GLCD (more than 99%)

You can just add the additional fonts to the application

I remember we always had trouble using those in C.

When you are including the fonts like I have described in my first article, you won’t run into problems - and when you replace the “org” by a global, you don’t need to calculate an address

Best Regards, Thorsten.

9

Ok, thanks again Thorsten.

And congratulations to your 5555th post  ;D