Someone commented in a previous post about the possibility of having an inverted colour display so I have now enabled this in the OpenGD77 display options.
The UC1701 display controller IC used in the GD77 has an option to display inverse colour, i.e black background with white pixels, and I had already added some support for this feature when I wrote the display driver for the OpenGD77 firmware, however I had not added this feature to the Display Options menu .
I couldn’t remember why I had not added inverse colour as an option, so I modified the Display options screen to include changing this option.
This which actually turned into rather a major rework of that screen to use the same functionality which I now use on the other “option” screens e.g. the Utilities menu screen.
So what I thought would take half an hour at the most, started taking much longer…..
This functionality does not give result in the display looking exactly the same as the GD-77 “black” display version.
That radio has a different LCD panel, which has a black background, all the way to the edge of the LCD panel.
Hence you’ll see a white border around the edge of the display, and the darkness of the black background colour is not as dark as in the “black” LCD panel. It may be possible to adjust the contrast to achieve a slightly darker background colour, at the expense of making the white pixels a bit less bright, but its never going to be quite as good as the dedicated hardware version.
Initially I thought the new feature was working, as I was able to change the mode to Inverse video. However I noticed that it was not possible to change back to non-inverse video without completely turning the radio off and on again.
Digging a bit deeper into the UC1701 data sheet, it wasn’t entirely clear why changing the “inverted” flag to 0, did not disable inverse video, and I found that even performing a full reinitialisation of the UC1701 still did not change the video back to normal. Then I noticed on page 33 of the datasheet a table that showed that some options required a full hardware reset to take effect, and although the inverse video was not in the list, I think that this must be the reason why I was not able to change to normal video.
So after even more modification to the source code, I am now able to do a full hardware reset on the UC1701 when changing video modes, and also when exiting from the Display Options screen, and this seems to have done the resolved the problem
Whilst I was looking at the initialisation of the UC1701 I noticed that one of the time delays was far longer than the data sheet said it needed to be. Specifically that after a hardware reset only a 1uS delay is needed and the firmware was using 100mS. Also that the source code was missing a 5mS delay after the reset line was released, before data can be sent to the IC. So I modified the display’s hardware initialisation to match the data sheet specification, and this results in the display not taking so long to perform its hardware reset when I change video modes.
I also did some experiments with disabling and enabling the Chip Select (aka Chip Enable) control, because currently the CS is permanently enabled, and I wondered if possibly some erroneous data caused by RF pickup, could be set to the display and which could be causing the occasional display corruption I see when updating the display especially during Tx when the Talk Timer is updated.
However disabling the CS when the display was not being updated, didn’t seem to have any effect, and possibly made things worse, as possibly an additional display would need to be added between enabling CS and sending data.
So I ended up not changing the source code related to the UC1701 Chip Select .
This change has only been applied to the Tier2 Alpha Latest version, which can be downloaded from here
I won’t be updating the Tier1 version with any new enhancements as its too time consuming, and I am also going to start work soon to get the Hotspot mode working with the Tier2 version.
I have already tried enabling Hotspot mode with the Tier2 version, but when I re-enabled it in the source code I found that Hotspot mode would not transmit, so will need some bug fixing and quite a lot of testing before I can release it.