sompost

GLCD initialization

11 posts in this topic

Hi all,

 

I am building a controller for a DB60XG card using a midibox core8 unit (PIC18F4620) and a T6963C-compatible GLCD (though TK advises against using it). I wrote my own driver in C, and it appears to work fine so far (graphics and text).

 

My only issue so far is that I had to bypass the MIOS GLCD initialization sequence to have full control of the T6963C (and to save memory of the MIOS graphics routines and fonts that I don't use). This would be fine by me, but now I don't see the MIOS copyright message at startup anymore, which is somewhat unsatisfactory.

 

I tried different methods such as enabling the text mode of the T6963C, which did show the copyright message but left the device in a state where I didn't see my stuff. I also tried to route the USER_LCD_PrintChar function through my routine, but get only garbage on the screen.

 

Here's my question (finally...): What is the initialization sequence in MIOS, i.e. which of the following functions is called when?

 

USER_LCD_Init

USER_LCD_Clear

USER_LCD_PrintChar (to write the copyright message)

Init (within main.c)

DISPLAY_Init (within main.c)

 

Note that the init and clear functions call into my own C routines which appears to work fine.

 

Any advice would be appreciated.

 

Thanks, Ralph

Share this post


Link to post
Share on other sites

Hi Ralph,

 

after startup, MIOS initializes the basic resources, calls Init() (to initialize additional resources), then USER_LCD_Init, then it displays the copyright message, and finally DISPLAY_Init is called.

 

For your case, it could make sense to re-initialize the display during runtime, e.g. in Tick()

 

E.g. with:

void Tick(void) __wparam
{
   static char init_done = 0;
 
   if( !init_done ) {
      init_done = 1;
 
      // switch to my own LCD driver
      MIOS_LCD_TypeSet(0x07, 0x00, 0x00);
   }
}

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Thanks, that explains it pretty much. I'll report on my progress, as soon as I get to it. :thumbsup:

 

Ralph

Share this post


Link to post
Share on other sites

All's not well with my GLCD driver. From the observed erratic behaviour it appears that I might be low on stack space. So I increased it as proposed in the Wiki pages:

 

Makefile:

MIOS_WRAPPER_DEFINES = -DSTACK_HEAD=0xeff -DSTACK_IRQ_HEAD=0xe3f
 

p18f4620.lkr:

DATABANK   NAME=gpr3       START=0x300          END=0x37F
...

DATABANK   NAME=stack      START=0xE00          END=0xEFF          PROTECTED
 

I.e. I removed the stack at 0x300 and moved it to 0xE00. Note that the IRQ stack is still only 64 bytes large, and the normal stack 3 times that. Is that OK so far? IRQ routines don't call into LCD routines, or do they? Would you make both stacks the same size?

 

Programming close to the bare metal is fun, but the fun starts wearing off...

Share this post


Link to post
Share on other sites

By default, the T6963C driver allocates some additional memory between 0x378..0x37f, see also:

http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fapp_lcd%2Ft6963c_h%2Fapp_lcd.inc

This clashes with the stack in C applications (I just notice, that this isn't properly documented!)

 

Solution: either specify:

 

GPASM_DEFINES += -DAPP_LCD_DONT_LOCATE_VARIABLES=1

 

in your Makefile, or change the stack locations there -- in your case (very good idea to use 0xe* for PIC18F4620!):

 

MIOS_WRAPPER_DEFINES = -DSTACK_HEAD=0xeff -DSTACK_IRQ_HEAD=0xe80 
 
Note that the linker file modification only reserves the stack memory.
The defines do the actual initialisation.

 

 

Note that the IRQ stack is still only 64 bytes large, and the normal stack 3 times that. Is that OK so far? I

 

yes, this would also be ok

 

 

 

IRQ routines don't call into LCD routines, or do they? 

 

No, they should never! (only a single thread should access the LCD)

 

 

 

Would you make both stacks the same size?

 

It really depends on your application... but usually the main program needs more stack than a IRQ routine

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Thanks for your assistance, but I cannot get it to work the way I wanted. Here's what I discovered: as soon as execution coming from USER_LCD_PrintChar runs into any of the following, the system goes berserk (instead of the copyright message I get random bytes from the memory thrown at me):

  • CALL    __gptrget1
  • BANKSEL    foo
  • TBLRD*+ (and/or the setting up of the table pointer)

I suppose that whatever is printing the copyright message via USER_LCD_PrintChar is not expecting any of these changes to the global state, and is subsequently confused as to what it wanted to print.

 

There's no need to investigate (unless you cannot help it :whistle: ). For this and other reasons, I'm considering using the text mode of the T6963C for printing text (I might even sacrifice a pin of the DOUT to enable run-time-switching between 6 and 8 bit modes).

 

Thanks again for your help.

 

Ralph

Share this post


Link to post
Share on other sites
I'm considering using the text mode of the T6963C for printing text

 

Good decision!

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

I know, it sounds kinda obvious, doesn't it... :rolleyes:

 

Ralph

Share this post


Link to post
Share on other sites

OK, I'm back. After a timeout caused by my buying and subsequent (ab)using of a Yamaha MOX6 (Yes!!!) I returned to my midibox project. As noted above and implemented in the meantime, all text output (as for now) goes to the text area of the T6963C. I can see all the MIOS messages now, while also being able to do graphics, including text-as-graphics. Think of it like a PC: first booting in text mode and then switching to graphics mode. Just for the looks, I seriously consider dumping screens full of fake driver initialization messages on the display while booting, like on a unix system.

 

Anyway, the next item on my list before starting the project for real is driving an SD card. I bought one of these cheapo SD card holders for $2 on ebay, the sort that don't work because there's a missing ground connection on them. So I fixed that, and while being at it also breadboarded a level shifter using diodes and a transistor. That's the short version of where I'm now. Don't ask for the long one.

 

The basics seem to work: I can write bits to the card using the MSSP module (SPI) of the 18F4620, and get as far as the card responding to the GO_IDLE_STATE request (CMD0). Then I get illegal command responses for everything else. I understand that "older" cards are quite sensitive to the initial bit rate not being to high, so I'd like to use the TMR2/2 option using Timer2, but get an infinite boot-reset loop.

 

Timer2 is not used in MIOS, is it? What are the minimum steps to setup the timer2 to, say 500kHz, no interrupt. Yes, I do read the data sheet, but that also lied about the SPI setup.

 

Thanks for suggestions (also tricks/need-to-knows about SD card communication)

Share this post


Link to post
Share on other sites

Good progress! :)

 

Maybe the MIOS32 based SD Card driver gives you some helpful inspirations: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_sdcard.c

 

Note especially the difference for HCSD devices.

 

Yes, Timer2 isn't used by MIOS8.

I've only an example based on assembly code: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fmbsid_testtone%2Fmain.asm

 

For 500 kHz following configuration should work:

        movlw   0x04
        movwf   PR2
        movlw   0x24
        movwf   T2CON
        movlw   0x0f
        movwf   CCP1CON
        movlw   0x02
        movwf   CCPR1L

 

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Rock'n'Roll!

 

I can get at the boot sector now. Thanks for your help (SD and Timer)!

 

There's still one small problem: I seem to be unable to switch to higher bit rates, perhaps because of the level shifter, but that can wait. I'll get FAT done first.

 

Ralph

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now