sompost Posted January 11, 2013 Report Share Posted January 11, 2013 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted January 11, 2013 Report Share Posted January 11, 2013 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. Quote Link to comment Share on other sites More sharing options...
sompost Posted January 12, 2013 Author Report Share Posted January 12, 2013 Thanks, that explains it pretty much. I'll report on my progress, as soon as I get to it. :thumbsup: Ralph Quote Link to comment Share on other sites More sharing options...
sompost Posted January 16, 2013 Author Report Share Posted January 16, 2013 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... Quote Link to comment Share on other sites More sharing options...
TK. Posted January 16, 2013 Report Share Posted January 16, 2013 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. Quote Link to comment Share on other sites More sharing options...
sompost Posted January 18, 2013 Author Report Share Posted January 18, 2013 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted January 18, 2013 Report Share Posted January 18, 2013 I'm considering using the text mode of the T6963C for printing text Good decision! Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
sompost Posted January 19, 2013 Author Report Share Posted January 19, 2013 I know, it sounds kinda obvious, doesn't it... :rolleyes: Ralph Quote Link to comment Share on other sites More sharing options...
sompost Posted April 13, 2013 Author Report Share Posted April 13, 2013 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) Quote Link to comment Share on other sites More sharing options...
TK. Posted April 13, 2013 Report Share Posted April 13, 2013 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. Quote Link to comment Share on other sites More sharing options...
sompost Posted April 18, 2013 Author Report Share Posted April 18, 2013 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.