Well, blimey!
How hard can it be to get a piece of PIC assembler software to display some characters on an LCD display? The answer seems to be very.
I've started putting my power meter together, it's the one I started here:
http://g0mgx.blogspot.co.uk/2012/10/a-bit-of-power-struggle.html
Well, eventually I managed to assemble all the parts and put the boards into an enclosure I have here:
I've actually made quite a good job of the metalwork so far, I've intentionally not cut the hole for the display as I don't yet know which one of the many I have here I would end up using. Here's the view of the front panel as-is now, the meter looks OK but isn't the large meter I found, as that's just too big for the case!
So, PIC programmed, LCD display wired in, power on - nothing. Just some very faint black squares on the display that I can make more evident or go away using the on-board contrast control.
So, still not knowing if the software is intended to interface to an HD4470 compatible or not, the question was what to try next?
I ended up cutting the software back to just the display routines and simply programming the PIC with the code to display just a few characters on the LCD. Result - nothing.
So, next I added a simple loop at the end of the LCD routine calls to turn on and off one of the digital output ports every second. I attached a suitable LED to the port and tried again - as expected the LED started to flash. This told me a few things:
http://g0mgx.blogspot.co.uk/2012/02/four-isnt-quite-same-as-2.html
So from that messing about I had a reasonably good idea how the initialisation of these LCDs should look, and the code I was staring at didn't quite look the same. So I changed the sequence of numbers sent to the LCD to initialise it, re-programmed the PIC and tried again. Nothing.
Hmm, next I looked at the delays in the software between writing the Enable line on the LCD high and then low again - you kind of have to do an "open sesame" on the LCD every time you send it either data or a command and the delays in the assembly software I was looking at used the processor "nop" instruction. This is really a null operand and hence takes one (I think) clock tick to execute. I changed this to be a 1ms delay and.... Bingo! We have characters on the display:
So, my next puzzle was the fact that I could display the characters 0-9 OK, but any attempt at alpha characters resulted in, what looked very much like, Japanese characters appearing on the display. After much cursing, general muttering and many re-programming of the PIC to try different things, I found a short between two of the address lines on the board. Doh! It took me over 6 hours to find that as I was only looking in software....
So it does seem that I am moving in the correct direction. I have also found that the Assembly code I downloaded from the QST in-depth website for this project, doesn't assemble on my version of MPLAB. I've had to change a few things:
It's time to test the unit, I'll let you know how I get on. I suspect I need to re-make the directional coupler (again) as I posted a photo on the eHam.net homebrew forum and asked for some advice, here's a very polite post telling me what a pile of junk I have made:
eHam comments
Hard work, frustrating but all good though, egh?
How hard can it be to get a piece of PIC assembler software to display some characters on an LCD display? The answer seems to be very.
I've started putting my power meter together, it's the one I started here:
http://g0mgx.blogspot.co.uk/2012/10/a-bit-of-power-struggle.html
Well, eventually I managed to assemble all the parts and put the boards into an enclosure I have here:
I've actually made quite a good job of the metalwork so far, I've intentionally not cut the hole for the display as I don't yet know which one of the many I have here I would end up using. Here's the view of the front panel as-is now, the meter looks OK but isn't the large meter I found, as that's just too big for the case!
So, PIC programmed, LCD display wired in, power on - nothing. Just some very faint black squares on the display that I can make more evident or go away using the on-board contrast control.
So, still not knowing if the software is intended to interface to an HD4470 compatible or not, the question was what to try next?
I ended up cutting the software back to just the display routines and simply programming the PIC with the code to display just a few characters on the LCD. Result - nothing.
So, next I added a simple loop at the end of the LCD routine calls to turn on and off one of the digital output ports every second. I attached a suitable LED to the port and tried again - as expected the LED started to flash. This told me a few things:
- My PIC programming was working and my software was making it into the chip;
- The software was reaching my loop for LED flashing so it wasn't getting stuck anywhere;
- The routines for the LCD weren't working.
http://g0mgx.blogspot.co.uk/2012/02/four-isnt-quite-same-as-2.html
So from that messing about I had a reasonably good idea how the initialisation of these LCDs should look, and the code I was staring at didn't quite look the same. So I changed the sequence of numbers sent to the LCD to initialise it, re-programmed the PIC and tried again. Nothing.
Hmm, next I looked at the delays in the software between writing the Enable line on the LCD high and then low again - you kind of have to do an "open sesame" on the LCD every time you send it either data or a command and the delays in the assembly software I was looking at used the processor "nop" instruction. This is really a null operand and hence takes one (I think) clock tick to execute. I changed this to be a 1ms delay and.... Bingo! We have characters on the display:
So, my next puzzle was the fact that I could display the characters 0-9 OK, but any attempt at alpha characters resulted in, what looked very much like, Japanese characters appearing on the display. After much cursing, general muttering and many re-programming of the PIC to try different things, I found a short between two of the address lines on the board. Doh! It took me over 6 hours to find that as I was only looking in software....
So it does seem that I am moving in the correct direction. I have also found that the Assembly code I downloaded from the QST in-depth website for this project, doesn't assemble on my version of MPLAB. I've had to change a few things:
- declared names are clearly case sensitive in my assembler and not used in that way in the code - many capitalisation changed;
- literal values used with the "loadw" command - the decimal declarations used generated value too big warnings, all I have done is declare the values as the hex equivalent and prefixed with "0x" - I don't understand why this is different, but it assembles;
- The declared names in the .inc file for the processor are also case sensitive so again, a number of changes needed there.
It's time to test the unit, I'll let you know how I get on. I suspect I need to re-make the directional coupler (again) as I posted a photo on the eHam.net homebrew forum and asked for some advice, here's a very polite post telling me what a pile of junk I have made:
eHam comments
Hard work, frustrating but all good though, egh?
No comments:
Post a Comment