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?
Please forgive my unstructured initial problem report. I´ve got 2 issues:
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:
builds from my toolchain behave differently than TKs builds - my display stays dark after a power cycle
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…
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…
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
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 …
- 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).
