propgcc LCD driver for HD44780/KS0066

bgp

Does anyone know of a driver for a HD44780/KS0066 LCD (any of the usual ) for Propeller C?

I'm trying to decide if I should code my project in C or Spin. The project requires and LCD and I want to use one that doesn't have a backpack, which means I need an actual driver for the various RW, E, and data pins, etc. - not I2C or SPI or anything like that.

There's this, written in Spin: http://obex.parallax.com/object/337

In terms of languages I'd much prefer to write C, just because I know it so much better. But this driver is a major factor.

Any ideas?

Best, Brad

Bob Lawrence (VE1RLL)

[h=3]If you have a Spin version you can try to convert it.

Using spin2cpp to Convert Spin Files[/h]
https://sites.google.com/site/propellergcc/documentation/tutorials/spin2cpp

jazzed

Try the attached files.

The files make up "a Spin program that runs in a COG" callable by C wrapper functions. The code was created by David Betz' spinwrap tool.

If you need a special version with spin edits, you can download and build David's spinwrap tool and create another copy of these files.

A recent build of openspin supporting the -s option will be required to run spinwrap.

I used this command.

sh-3.1$ spinwrap -c LCDBase_4bit_direct_HD44780.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.70 Compiled on Mar 20 2014 11:35:10
Compiling...
LCDBase_4bit_direct_HD44780_proxy.spin
|-LCDBase_4bit_direct_HD44780.spin
Done.
Program size is 828 bytes
sh-3.1$

While the spin2cpp converter program is useful, the output is not maintainable. Like most converters, the output is fairly obscure. Several people have tried to use spin2cpp output as source code ... that is really the wrong thing to do.

One can argue that spinwrap output should not be used as source code as well; however, the generated C code is readable and maintainable if that's what you want to do (the actual spin code is obscured).

The spinwrap code should also create smaller programs than spin2cpp because it is spin, but it will also run about the same speed as spin. Normal C code even with the slowest memory model beats spin performance.

jazzed

David's spinwrap tool and repository location is described here.

http://forums.parallax.com/showthread.php/153919-SpinWrap-a-tool-for-allowing-C-or-C-to-use-Spin-Objects?p=1243144&viewfull=1#post1243144

bgp

@jazzed - Thanks very much for the info and for converting this! I see what you mean - looks like the spin bytecode is just right in there as a big array. For my application, on something like LCD output performance is not really a concern at all, so the spinwrap approach is just fine. Will definitely test this approach out (I've been using bst, not openspin, but I'm sure I can figure that out). It wasn't clear from checking out the github repo if this will work with files that have pasm embedded in them, but luckily I don't need that for this driver.


@Bob - great, will check that out too, tks.



Best, Brad

jazzed

Spinwrap works with PASM VGA demos etc....

bgp

I tried running this code created with spinwrap, didn't have too much luck.

After trying some things, it boils it down to this simple test: This code in C:

  LCDBase_4bit_direct_HD44780 lcd;
  
  init_LCDBase_4bit_direct_HD44780(&lcd);

  LCDBase_4bit_direct_HD44780_Init(&lcd,
     TRUE, // LCD is 2 lines tall
     2,    // E
     0,    // RS
     1,    // RW
     6,    // data high pin
     3     // data low pin
  );

does not clear the LCD.

This code in SPIN does:

  OBJ
     LCDBase : "LCDBase_4bit_direct_HD44780"

  pub main
    LCDBase.Init(true, 2, 0, 1, 6, 3)

Those should be effectively the same thing.

Some things I tried in order to debug:

* I checked and double checked my pins, etc., and as you can see above it's the same params being passed.
* I thought maybe things are running at different timings, but my full LCD Spin test program runs with _CLKMODE = XTAL1 + PLL16X and from my understanding of the docs that's the same setting propgcc uses unless you specify otherwise.
* The guts of the calls have this "mailbox" variable where the caller waits for the spin code to complete, I tried doing some debug in there to see if I could gather more data but the "print" command was acting very odd (i.e. I got it to print jibber once but could not seem to get any sensible output, mostly it prints nothing).
* I tried adding usleep()s in various places to see if it's some odd timing issue, no difference.
* As a note, the calls do definitely complete, the program carries right on through and in my main C function I can do stuff after calling the LCD Init function, so it's not locking up.

I'm at a bit of a loss as to what to try next or what might be wrong. Any suggestions?

Best, Brad

bgp

As a note on this - I was able to get this working using spin2cpp. One minor source mod required (didn't seem to like reading from a range of pins when the pin numbers were in variables - changing pin numbers to constants fixed it). But otherwise that did work out. It's true that the C++ (or in my case I generated C code) is not all that readable, in this case that's a totally acceptable tradeoff.

Best, Brad

jazzed

Try using the full lcd demo with spinwrap just to eliminate variables. If that doesn't work, then there are bigger issues.

One word of warning though. I suggest copying the spin files used by the demo file to the local build directory so you don't have to use the spinwrap -S option (you can try it though). The -S,"blah" option seems to have all kinds of trouble with spaces and other characters in windows.

bgp

Solved this same problem again recently by stealing from PropWare and converting C++ -> C - leaving a link here for posterity.

https://gist.github.com/bradleypeabody/56080ea360a5d5fe4e7a6dce4b9c3a9f

laurent974

nice +1

DavidZemon

Nice Brad! Not that I like seeing C++ get turned into C, but as C goes, it looks great! Naming the struct method parameters "this" was very clever - probably saved you a lot of typing!