Hawkeye Posted June 14, 2011 Report Share Posted June 14, 2011 (edited) Hi there, I am a bit out of luck these days, last week or so I burned a 4x20 OLED (looking for a good LCD replacement for the MB6582). Well, SID happens :-), as I always wanted a VFD in the MB6582 anyways, I have ordered the Noritake CU20045-UW5J. Good news is, it will fit the MB6582 quite nicely without the need for a riser card and also I did not burn it just yet :-)... I´ve connected and wired it up in 4-bit mode to the MB6582, as usual. When turning it on (with the default mb6582.hex firmware) it shows very scrambled characters, looks like it has not been switched to 4-bit mode by the default display initialization routine. Consulting the datasheet, the first thing that is being sent to the VFD apparently needs to be the "Function Set to 4-bit mode" command. Here is the relevant section: 7.7.1 Function Set Command 20H to 3FH This instruction initializes the system, and must be the first instruction executed after power-on. So, I´ve ported the 4-bit lcd display routines from the MIOS basic driver to modules/app_lcd/clcd/app_lcd.inc (which by default contains an eight-bit driver), changed the initialization sequence to really send 0x02 nibbles at first (4-bit mode), have included the changed app_lcd properly, set the DisplayType to 7 (in main.inc) and have verified that this code really is executed (tested that by playing around with the initialization stuff). With the changed driver, I do get improved character output, but only some characters look ok, other characters are wrong (the "big D" as in MIDIbox is ok). So, changing to "my" 4-bit driver improved things a little and that indicates that the display can take a late switch to 4-bit-mode... but now I am utterly confused, if a "D" was written properly to the display, doesn´t that mean I am in 4-bit mode? Maybe I´ve screwed up the driver? Could it be a timing issue, probably with the "LCD_Busy" checking? And is there any other "USER_LCD" 4-bit demo code available, so that I can verify things? Maybe some MIOS-base-level routine sends data to the display before the user initialization and screws things up? Hmm, sorry for all the questions and the confusion! Thanks for any help :sheep: Bye, Peter PS: Thorsten, I´ve also got a 256x64 OLED evaluation display lying around, so if you are into a little bit of display code hacking, just tell me and I´ll come over :-) Edited June 14, 2011 by Hawkeye 1 Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted June 14, 2011 Author Report Share Posted June 14, 2011 (edited) Science breakthrough :-) It appears the "lcd_busy checking" is the problem, plz don´t ask me why... I have removed the checks and replaced them with yet too long (still need to find minimum delays) wait loops for every character printed/command sent. As the "driver" is for a specific display with a given timing, I hope this approach is viable. Hawkeye :frantics: (with a vfd in the mb6582, yay! pics soon!) Edited June 14, 2011 by Hawkeye Quote Link to comment Share on other sites More sharing options...
jojjelito Posted June 14, 2011 Report Share Posted June 14, 2011 凄ã„ã§ã™ã! That's orsome! é ‘å¼µã£ã¦ãã ã•ã„! (gambatte kudasai). We wan't some iThingy/Androgyny pixx taken with Hipstamatic and some nasty lens/filter approximation! :drool: Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted June 15, 2011 Author Report Share Posted June 15, 2011 Thx, dude... the "lcd ready" polling works now, too (fixed delays are not good for the performance). You can now haz Wilbas riser PCBs if wanted :) I´ve attached the updated driver for anyone interested. Ah... and the display is... NICE!!! :laugh: Picz later, gotta sleep nao :sleep: Best regards, Peterapp_lcd.inc.txt Quote Link to comment Share on other sites More sharing options...
mitcheaton1 Posted January 28, 2012 Report Share Posted January 28, 2012 Hi Hawkeye! I am having the exact same problem with the same lcd... im not too big of a programmer and was wonder if you could post a complied version of your mb6582.hex? Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted January 30, 2012 Author Report Share Posted January 30, 2012 (edited) Hi Hawkeye! I am having the exact same problem with the same lcd... im not too big of a programmer and was wonder if you could post a complied version of your mb6582.hex? Hi, but it is a VFD, not a LCD! Are you sure, you have exactly the same Noritake VFD? Under these cirumstances, i´d fire up tha compila the evening - as the code is pretty badly hacked together, you should install the modded version only on the first core, where the VFD is connected, if you install it on cores 2-4, they will unfortunately hang, but I did not have the time/nerves to debug it. So you´ll also need to install the unmodded standard .hex of the same version to the other cores and not flash the VFD version to all cores. It is a somewhat complicated process - please report back via forum message :-) Bye, Peter Edited January 30, 2012 by Hawkeye 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.