Prop UI Progress

It has been a grueling 18 days since my last post. The Propeller UI Board that I have been working on has provided some real challenges. All of the UI Board peripherals on wired to the same I2C Bus. Which means my standard method of debugging the code via a working a Display was not available. The Bus Pirate and a new VGA Display was necessary, which had to be configured which added to a already steep learning curve.

UI Board Installed on the Prop ProtoBoard

Coordinating and developing the Objects for the six UI peripheral was a challenge The task was a little easier thanks to Jeff - KO7M, who helped with the I2C Bus to Parallel Expander Code, and the necessary modification to his I2C LCD Driver.

Currently ALL six UI peripherals, which are on the same I2C Bus, are working in concert with each other without perceivable delays for; the two Rotary Encoders, four Push Buttons, eight LEDs, a Realtime Clock (RTC), and the LCD Display. Also there are the Sound (beeper) and the three I2C POTs that control the LCD Backlight Brightness, LCD Contrast, and Sound Volume - all working seamlessly together.

One of the Software Driver Goals is make moving the Programmed Display from LCD to VGA (and back) without difficultly, other than the obvious which are the Number of Lines and Number of Characters Per Line.

Note: my new I2C Huff-n-Puff board (see previous blog) will also be added to that same I2C Bus (external to the UI).

I had to learn a few new Propeller SPIN tricks to make it all work. Specifically how to coordinate and use "Locks" for Objects and COGs.

Only a few modifications were necessary to the UI PCB. I have already started the re-design with modifications for the next PCB. I will be adding more Pull-ups, and 0-Ohm Jumpers to make separation of circuits easier for future development and debugging.

I have several ideas and better organization of the current code, but that will wait for another day.

It has been a lot of fun. Now on to some projects that will use the Prop UI Board.

First, on the list to port are; my QRSS and WSPR Beacons, Jeff's Keyer, the Huff-n-Puff Freq Standard, and several other Prop Projects that are planned to use the new UI.


--

UI Project Update

Readers of this blog know that I have a Propeller UI Project in progress. The custom board that I created for that has been received and loaded with parts. Some simple parts of the board appear to function as can be seen, tested, and exercised with a clip on Bus Pirate. That is, the Real Time Clock (RTC) and the LED driver seem to work as expected.

The major elements of the board; which include the LCD Display and Knobs, have NOT been tested yet. Their control is complex enough that it will be necessary to tested them in conjunction with the Propeller processor. The eight interface wires for the connector have been installed on the Prop board.

Normally testing a new peripheral device is not difficult, but when the test and debugging involves the Display, which is used to Display the test results, it is problematic. It is a classic "Chicken and the Egg" problem.

To solve this dilemma, I am waiting for an ordered KVM connector for the Propeller (which should be here today). The KVM connector will allow the Prop to be connected to a dedicated VGA Monitor for display of debug information without the need of the LCD or Knobs.

Actually, I have been a little lax here, I could have used the USB TTY connection to do debug and testing, but in my Ubuntu Workstation environment using a single interface path for both; Prop Programming, and Displaying debug information, is a pain. Therefore I have been waiting for the KVM. And, I have also been diverted off to other projects and responsibilities.

My goal is to have UI working for Show-n-Tell at the next pQRP P&C meeting.

--

Parts Received and some Shop Work

I received parts from Mouser to complete the Propeller User Interface (UI). I was missing two I2C I/O Expanders and 3.3V Regulators (see previous post).

The Two New Parts

So far, I have been using the BusPirate to test the four devices on the I2C circuit, the LEDs and the Real Time Clock (RTC) works as expected.

The LCD and the Knobs which are on one of the I/O Expanders will require some new wiring on a new Propeller USB Protoboard that I plan to use. Software is about the only way to do real tests here.

The one part that I can not get to work is the I2C POT, which will control the Backlight and sound volumn, the POTs are not necessary to do the initial checkout. And, maybe I just have not found the magic that makes it work.

More testing needed.

A Day of Shop Work

Parts being Cut

While looking for my photos of the UI build progress, I found some photos that I had taken a few days ago. I helped my Son cut-out some parts using my PlasmaCAM. It was a long day, we cut about 96 square feet of parts out of 3/16 inch sheet steal. It is a fun process to watch.

When working correctly, the PlamaCAM creates a lot of dark smoke, which tends to collect on everything (nasty stuff). I was wondering what the smoke actually is? The only ingredients in the process are "Electrons, Air and Steel".  Although, at 10K degrees, almost anything could be being created.

Lots of Sparks and Smoke
(more smoke, less sparks,
makes for cleaner/better cuts)

I took some of the Smoke (black dust like stuff) that had settled on a surface, to my Lab where I could look at it under the Microscope at 30X. The smoke dust looks like very small, perfectly formed, black spheres (like ball barrings). They seem to be magnetic.

Later, I discovered they are very thin hollow spheres! Smashing a single sphere releases something that effect others in close proximity. Maybe they contain compressed gas, or maybe they release an electric charge, or collapsing magnetic field.

More investigation needed.

--

Encoders for the Prop

The last day are so I have been trying to get a Chronodot Real Time Clock (RTC) to interface with my Propeller beacon. The idea is to have it schedule the WSPR Transmit Cycle, which are required to start on the even minute of hour, plus 2 seconds (ideally plus or minus 1 second). In PC environment a WSPR beacon uses the system clock for scheduling. With my Propeller Microprocessor, a PC is not connected, and therefore the processor has to do the scheduling. Which can be done, but without a RTC, adjustment to the micro's clock it done by hand - what a pain.

But sadly, I can not get the RTC to talk back to the Propeller. Maybe my Chronodot is dead, I have ordered a Bus Pirate to help with diagnostics. Much more work is needed.

While awaiting the Bus Pirate order, I decided to tackle the next GUI item that is needed  for the Propeller Beacon Controller. Which is, the two Rotary Encoder Service Routine.

On a  previous projects based on the Arduino Board, I had to resort to a complex state machine programming to achieve the multitasking that I desired. The Rotary Encoders were a part of the state machine, and were interrupt driven.

With the Propeller, there are NO interrupts !, . . but there are eight processor where one processor (or more) can be dedicated to the Encoder task. Originally I thought it would take one whole processor for each (Arduino style) Rotary Encoder task. But more reading through the manual and Spin Programming Syntax, I found a "waitpne" (wait for pins not equal to mask) statement. This statement allows all of the Rotary Encoder (and push button) pins to act as one big switch. All that is needed is to decode (poll) which pin was changed, and increment counter as necessary. This was a 100% self written program/driver Object, a fun project, I will post the code later.

Two Rotary Encoder Knobs
with Integrated Push Buttons

The first thing did with my new programmed function was to implement a RF Frequency Calibration Offset, I have several Propellers that I have been using, and keeping track of the CAL Offset for each Prop Board has been a problem. Now if it is not exactly on Frequency it is just a quick twist of the knob to correct it.

The second programming function I implemented; was a reset of the Epoch clock on a push of a button,  which starts the WSPR time cycle. Until I get the RTC working a little manual intervention is still necessary.

It's just more fun stuff with the Prop !

--

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.

--

Propeller GUI

UPDATED, Feb 5, 2012 Rev C

I am planning a GUI for my Propeller Amateur Radio Projects. As show on the previous post, I have the hardware cobbled together, but was stuck on the strategy of assigning processor pin to the LCD Display and the Encoders. After more than several hours and reading conflicting strategies and OBJ(ect) module support documents. I decided to just pick a pin assignment and get things started. The wires that I will use behind the "Propeller Proto USB" board are small and can be changed if another more sensible strategy is discovered later. Note: first attempt was abandoned, this page has be updated.

See Propeller Object Exchange "jm_lcd4_ez" download file.

My current pin assignment plan is as follows:

Note: I have updated the following to reflect current project pin usage.

Schematics

       P8X32A
     ┌────┬────┐ 
     ┤0      31├ RS232         0V    5V    0V   P16   P17   P18   N/C   N/C
     ┤1      30├ RS232         │     │     │     │     │     │     │     │
     ┤2      29├ I2C           │VSS  │VDD  │VO   │R/S  │R/W  │E    │DB0  │DB1
     ┤3      28├ I2C           ┴1    ┴2    ┴3    ┴4    ┴5    ┴6    ┴7    ┴8
     ┤4      27├ RF         ┌────────────────────────────────────────────────┐  LCD 16X2
     ┤5      26├ Encdr1B    │ 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16│  HD44780-BASED
     ┤6      25├ Encdr1A    └────────────────────────────────────────────────┘  SSC2F16DLNW-E
     ┤7      24├ Encdr1P       ┬9    ┬10   ┬11   ┬12   ┬13   ┬14   ┬15   ┬16
     ┤VSS   VDD├               │DB2  │DB3  │DB4  │DB5  │DB6  │DB7  │A(+) │K(-)             
     ┤BOEn   XO├               │     │     │     │     │     │     │     │
     ┤RESn   XI├              N/C   N/C   P12   P13   P14   P15   5V    P19 via Transistor
     ┤VDD   VSS├                                                             and 2.2k 
     ┤8      23├ Encdr0B                                                  
 Kyd ┤9      22├ Encdr0A
KDit ┤10     21├ Encdr0P
KDah ┤11     20├ Speaker
 DB4 ┤12     19├ BackLight
 DB5 ┤13     18├ E
 DB6 ┤14     17├ RW
 DB7 ┤15     16├ R/S
     └─────────┘ 


PIN ASSIGNMENT
   VSS  - POWER SUPPLY (GND)
   VCC  - POWER SUPPLY (+5V)
   VO   - CONTRAST ADJUST (0-5V)
   R/S  - FLAG TO RECEIVE INSTRUCTION OR DATA (via 2.2k ohm)
            0 - INSTRUCTION
            1 - DATA
   R/W  - INPUT OR OUTPUT MODE (via 2.2k ohm)
            0 - WRITE TO LCD MODULE
            1 - READ FROM LCD MODULE
   E    - ENABLE SIGNAL (via 2.2k ohm)   
   DB0  - DATA BUS LINE 0 (not connected)    
   DB1  - DATA BUS LINE 1 (not connected)    
   DB2  - DATA BUS LINE 2 (not connected)    
   DB3  - DATA BUS LINE 3 (not connected)    
   DB4  - DATA BUS LINE 4 (via 2.2k ohm)
   DB5  - DATA BUS LINE 5 (via 2.2k ohm) 
   DB6  - DATA BUS LINE 6 (via 2.2k ohm) 
   DB7  - DATA BUS LINE 7 (via 2.2k ohm) (MSB)
   A(+) - BACKLIGHT 5V
   K(-) - BACKLIGHT - via 2.2K ohm and Transistor to GND, Base to P19 via 220 ohm Resistor

In addition to the above, I plan to use pin 19 for the LCD Backlight control (which is outside the scope of most published Objects), normally the backlight (LCD pin 15) is connected to a variable resister.

Note: Because the LCD is actually a TTL (5v) device, 2.2k ohm resisters are suggested in series with all data lines connected to the Propeller (a 3.3v device). These resistors will allow bidirectional level compatibility.

More research is needed before I assign of the Encoders and Speaker pins, but I think they will be in the 20 to 27 in range. My goal will be to reserve pins  0-7 for application I/O and 28-31 for standard Propeller Functions (i.e., I2C).

Note: There are many contributed OBJ's in the Propeller Object Exchange Library for an LCD Display, but many have conflicting pin assignments/usage. The above is just the strategy I selected.

UPDATE

The LCD Driver selection for my Arduino project GUI was much simpler - I have now invested about two days in this effort for the Propeller . And yet, the selected LCD driver does not always correctly initialize the LCD. More research and experimenting is necessary. :-(

--