Hawkeye Posted November 15, 2010 Report Share Posted November 15, 2010 (edited) Hola, I tried to connect the abovementioned Futaba VFDs (datasheet) to the Core32... when running the current MBSeqV4 app, some characters are scrambled, it appears that always a few of the characters are replaced by different ones "close to" the original when examining the character table... an example photo is shown in The cabling is fine, i built another, shorter cable with the exact same problems. Trying to hack things, I then installed the Windows-based dev toolchain, which works fine (respect on the code documentation, svn structure and nice build system!). When I build an MBSeqV4 or the tutorial #20 (lcd test) and I power-cycle the Core, the display stays dark (the mbseq app runs though, it can be queried via mios studio). When I don´t power-cycle after flashing tutorial #20 from a TK-built SeqV4, the display stays on and shows increased garbage - it creates "animated" strange looking special characters... There seems to be a difference between my build and TKs build... when I build apps, things are getting much worse... :-( - are the any defines/environment variables which i am missing (i set clcd as lcd environment variable and the rest of the environment variables from the toolchain documentation). Edit: I suspect some timing issues... could it be that my toolchain (gcc 4.4 based) produces differently optimized code than TKs variant which is faster or slower leading to different behaviour on the vfd? I saw some loop-based sleep code and maybe that got optimized away? Thx for help! Peter Edited November 15, 2010 by Hawkeye Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted November 15, 2010 Author Report Share Posted November 15, 2010 Please forgive my unstructured initial problem report. I´ve got 2 issues: 1) some, but not all characters are replaced by alphabetically close characters (TKs MBSeq Build) - i wanted to fix this with a char replacement hook, but then this happened: 2) builds from my toolchain behave differently than TKs builds - my display stays dark after a power cycle Thanks and sorry for double posting. Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted November 16, 2010 Author Report Share Posted November 16, 2010 (edited) to keep you up-to-speed, I made some progress on the toolchain side... managed to get it up and running under FreeBSD, which i prefer to code on - now this toolchain uses the gcc 4.3 compiler and i am able to get the scrambled screen outputs again instead of a blank screen - looking into app_lcd timings and if adjusting them does not work, will try out a character replacement hook... I would bet, that TKs build toolchain also still uses gcc 4.3 :-) btw., when attaching a normal lcd, the outputs are fine, so no problem on the core32 side of things... this vfd surely is a bit bitchy ;-)- but what i love in this vfd is that there is no afterglow, new characters are displayed instantly - comparing to my 9US$ LCD, this is better by magnitudes... Edited November 16, 2010 by Hawkeye Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted November 16, 2010 Author Report Share Posted November 16, 2010 (edited) ok, further investigation - the problem occurs reproducably in 8-bit data transfer mode for all characters where D1=0 and D0=1, so to say A, E, I, M ... they are replaced by the predecessors where D1=0 and D0=0, which are @, D, H, L... That´s why a character replacement hook won´t work... i am not able to send any char in 8-bit mode with d1=0, d0=1... that looks a lot like a bug on the vfd side... i have also switched cables and measured for unwanted bridges twice... Now investigating 4-bit transfer mode, where d4-d7 are used... Edited November 16, 2010 by Hawkeye Quote Link to comment Share on other sites More sharing options...
nILS Posted November 16, 2010 Report Share Posted November 16, 2010 Does this only happen when D1 is low or is D0 simple always low? Either way this points towards a short on the hardware side of things. Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted November 16, 2010 Author Report Share Posted November 16, 2010 (edited) thiz only happenz when D1 is low... i am able to display a "C" for example (D1: 1 D0: 1) - i measured cables and the vfd pins, no shortage... But... I have the feeling that 4-bit mode will help. In the tech docu the motorola mode is only depicted in 4 bit mode, if that is true, those suckers... ;-)... if it works, ofc i will offer a clcd4bit driver for TK. The pinsavingz would enable the core32 to drive 3 CLCDs right? ;-) Plz get back to your diploma thesis so we can meet in Munich and have a beer ;-) Edited November 16, 2010 by Hawkeye Quote Link to comment Share on other sites More sharing options...
Hawkeye Posted November 16, 2010 Author Report Share Posted November 16, 2010 (edited) :frantics: YESSS! it workz :frantics::sorcerer: haz i earned coder status nao? :rolleyes: if there is interest - i could either create a clcd4bit module or as there are only a few lines changed handle it with the preprocessor and check via #ifdef CLCD_4BIT ... svn diff and picture of working vfd is attachedapp_lcd_diff.txt Edited November 17, 2010 by Hawkeye Quote Link to comment Share on other sites More sharing options...
nILS Posted November 17, 2010 Report Share Posted November 17, 2010 Pretty :) Quote Link to comment Share on other sites More sharing options...
quakitsduck Posted March 29, 2015 Report Share Posted March 29, 2015 hi, i have issues with my noritake vfd can you hold my hand and break down what i need to do to get the display to work? Thanks 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.