Update

Switched to the 16F1827 that allows having PWM on RA4 for backlight (BL) dimming. Also changed the display crystal to 16 MHz for better compatibility with other devices running on 4, 8, 16, etc. MHz.

Here's a short video of the dimming. I need a lot more practice making videos. A repurposed command (0x16) is used. PWM frequency is 500 Hz, In the video, the BL begins at 30% on time. Then goes to full on, then 10% on (quite dark), 0% on, and ends back at 30% on.

I cannot see the need for many BL levels, so will probably just have full on, one level of dim, and full off. The 30% on seems about right to me. Other ideas?

John

 

Almost DONE
Rained all day, so I worked on my little project and special characters (8 are allowed in CGRAM by Hitachi).


Here are the modules that are working. Most are controllable by the sending unit with single-entry, ascii-like 8-bit codes. The one exception is the special character table, but that is really easy for any user to access (attached).
1) Backlight dimming (useful?)
2) Change baud (9600-76800)
3) Current baud is saved in EEPROM and shown on the start-up screen and whenever changed.
4) Special characters are saved in the LCD program memory as an 8x8 table and loaded at startup. Decided to use LCD memory rather than sending unit, as program memory in the sender is probably more valuable, and it was easier not to have to load it to the LCD each time. Simply sending 0xF8:0xFF as an "ascii" will print the special characters (only 6 are designed at present).
5) The usual Hitachi LCD controls are preserved. I added a special one to erase a line as mentioned earlier.

Can anyone figure out what the first special character above is without looking at the following table? The version I found on the Internet was even worse.
All I need is another rainy day to get it all put together and cleaned up.

Regards, John

brw
     dt   0x0E,0x11,0x1D,0x19,0x1D,0x11,0x0E,0x00 ;copyright symbol 0xF8
     dt   0x00,0x09,0x15,0x12,0x12,0x0D,0x00,0x00 ;alpha 0xF9
     dt   0x00,0x0E,0x11,0x1E,0x11,0x1E,0x10,0x10 ;beta 0xFA
     dt   0x00,0x11,0x11,0x11,0x13,0x1D,0x10,0x10 ;mu 0xFb
     dt   0x00,0x0E,0x11,0x11,0x0A,0x1B,0x00,0x00 ;ohm 0xFC
     dt   0x00,0x04,0x00,0x1F,0x00,0x04,0x00,0x00 ;divide 0xFD
     dt   0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
     dt   0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

 

Refer to the schematic in Post #1. Note that SF in its wisdom uses RA4 to control the backlight and uses the low nibble of that port for sending data to the lCD. End result, any character with bit 4 or bit 0 set has the potential to turn off the backlight (BL) and did.

Here is the relevant portion of the schematic (chip = 16F1827) :


The BL problem has been solved. I considered a few options and simply decided to use PWM for all BL control with settings of 0% and 100% for on and off. PWM runs continuously and momentary writes to RA4 are not noticeable on the LCD. I also turned MCLR off as a precaution; although, I did not encounter a problem with resetting. Device seems to be working with all commands, including the BL, baud setting, and baud display.

My code for 4-bit mode does a swapf on the byte in WREG, moves it to PORTA, toggles E, to send the high nibble, then does another swapf, move to the port, and toggle E for the low nibble. RA7 (OSC1/CLKIN) and RA6 (OSC2/CLKOUT) are being written to but so far I have not seen a problem.

One could copy the high nibble of the port, pair that with the high and low nibbles of the data, then move that to the port for every write. Even if that were to be done, however, the oscillator may have changed state in the interim.

I suspect that potential problem really isn't a problem and is ignored. Any comments or experience to share?

Thanks.

 

Hola John

Long time ago I replaced the checking of the BUSY flag with a fixed delay. Right now, I cannot say how long it is but it always worked well.

 

Writing 8 bits to port A won't affect RA6 & RA7 (osc) pins, nor will it affect RA5 when configured as either MCLR or an input. If RA4 is a PWM output then writing to RA4 will not affect the output.

If you want to control RA4 without using PWM and you want to write to the RA3..RA0 bits in your LCD driver without affecting RA4 you should limit PORTA writes to just the RA3..RA0 bits. Here's an example (though you're probably writing LATA rather than PORTA);

        swapf   data,W          ; hi nibble in b3..b0          |00
        xorwf   PORTA,W         ; delta wreg & porta           |00
        andlw   b'00001111'     ; update b3..b0 bits only      |00
        xorwf   PORTA,F         ; write hi nibble              |00
        bsf     LCD_E           ; clock LCD 'E' pin            |00
        bcf     LCD_E           ;  "                           |00
        movf    data,W          ; lo nibble in b3..b0          |00
        xorwf   PORTA,W         ; delta wreg & porta           |00
        andlw   b'00001111'     ; update b3..b0 bits only      |00
        xorwf   PORTA,F         ; write lo nibble              |00
        bsf     LCD_E           ; clock LCD 'E' pin            |00
        bcf     LCD_E           ;  "                           |00

 

@atferrari
I have done it both ways; however, if you want to read the LCD, the code for doing that is almost identical to just reading the busy flag. In fact, in reading the BF, you read the whole port.

@MMcLaren
I played with all sorts of versions. Yours is nice and shorter than what I had for preserving the port's high nibble. Thank you for the insight on the osc pins. As it turns out, having PWM active continuously is not bad.

Project is basically done. I will try to get some video of the "new" commands before posting in completed projects.

Thank you both.

John

 

"Final" Update
Attached is a table of control codes. Most are the standard Hitachi codes. Codes that have been added and/or changed are shaded. I would appreciate any suggestions or comments about them before submitting this as a completed project. "Available" in the comment column means that code performs the same function as another code and can be repurposed.

John
Edit: Typos in 0x1B and 0x1F have been corrected.