Monday, February 6, 2012

Display ON

I have been running my 30m Propeller QRSS, WSPR and OPERA Beacon the last few days, and have received many local and DX spots as reported on the web.

A periodic restart (reboot) or re-program of the beacon is needed to keep the beacon on frequency, to change the mode, and set the right time sequence - which is a bit of a pain. What is needed is a GUI with display and controls to make adjustments as necessary while the beacon is running. To that end, I have been attempting to build a standard GUI for the Propeller Microprocessor - sounds simple doesn't it. Well it maybe simple after I get over some initial hurtles.

The first GUI hurtle was to get a LCD Display to work correctly, there are many contributed LCD driver in the Propeller Object Exchange Library, most use conflicting pin connection or they do not provide the 4bit data path that I desire for my display.

The GUI
The real problem here is there are Too Many LCD contributed drivers from which to choose. all with conflicting pin assignments and programming interface. It is difficult to understand the difference between them without actually downloading and trying each - which is very time consuming.

After much searching I finally found "jm_lcd4_ez" REV 1.3 (see previous post), which is a LCD driver that meet my requirements. In the Object code the author provided additional entry point for alternate hardware configuration. Many of the available LCD drivers require adjacent data and control line connections to the micro as the data and control are transferred via one instruction as a full byte. The Propeller is more flexible than that, and there is no need to be that restrictive. The selected author recently added the required flexibility within the top level Initialization routines, I tried his driver and it worked most of the time, but it had problem at power up.

I almost gave up on this driver and starting looking for yet another, even though I liked the documented flexibility and implementation. The author forgot to do the same flexibility modification at the lower "lcdinit" level. With a little work and experimenting I was able to make the correction to the low level routine. And now,  all is well.

If there is interest, I will publish the corrections here, else I will try to chat with the author.

The next step for GUI development is to program the two Rotary Encoders.

UPDATE
I received an email reply from Jon, the author of  the "jm_lcd4_ez" LCD driver object, he has now confirmed the bug, and is going to fix and update his Object (to REV 1.4) on the Propeller Object Exchange. - Thanks Jon.

--

No comments:

Post a Comment