Jump to content

LCD Character Scrambling - Futaba VFD M402SD10FJ <-> Core32


Hawkeye

Recommended Posts

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 by Hawkeye
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Hawkeye
Link to comment
Share on other sites

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 by Hawkeye
Link to comment
Share on other sites

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 by Hawkeye
Link to comment
Share on other sites

: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 attached

app_lcd_diff.txt

post-7895-052275500 1289946857_thumb.jpg

Edited by Hawkeye
Link to comment
Share on other sites

  • 4 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...