Display module support

[diyelectromusic]

I believe I have updated the addon/display/hd44780display driver to allow the configuration and support of the I2C version of the HD44780 LCD module. I have some code on this branch here: https://github.com/diyelectromusic/circle/commits/hd44780i2c

My C++ and github abilities are relatively primitive still, but if this seems desirable or useful and looks ok, please let me know how best to proceed (the changes are relatively simple if it is easiest to just reimplement them yourself at some convenient point).

I have performed simple testing of both the I2C and non-I2C sample applications on a RPi 4 with a 1602 LCD but nothing more complex.

Many thanks,
Kevin

[rsta2]

Thanks for this contribution! I can merge this from the source code in your repo and will do this soon.

[diyelectromusic]

Great!

I wasn't quite sure what to do about the backlight... It seemed to be a choice in the MT32-Pi repository, but has no equivalent in "4 bit mode" (I guess because it is a hardware link?). I've just "turned it on" here... Anyway, it is a start - probably not too hard to change if that turns out to be wrong! :)

[rsta2]

OK, let's do it this way. Your HD44780 I2C support is on the develop branch in the Circle repo now and will be part of the next release. Thanks again!

[diyelectromusic]

Great! Many thanks :)

[probonopd]

Thanks @diyelectromusic and @rsta2. MiniDexed is now supporting HD44780 I2C displays by using the develop branch of Circle. 👍

[diyelectromusic]

I've was having another look to see what the possibility of adding support for ssd1306 based OLED displays was too, based on the code already in MT32-Pi. It doesn't translate over in a particularly straightforward way as the handling of displays is very different in MT32-Pi compared to Circle itself....

But I have an example of the kind of thing I think could be possible here: https://github.com/diyelectromusic/circle/tree/ssd1306

Basically, I've suggested refactoring out much of the "character/terminal" handling from the hd44780 display code into its own base class, then that can be used for other "character devices" as required.

The ssd1306 probably has more in common with the st7789 code if I'm honest, but I'm interested in having something that could eventually be used in MiniDexed, so what I'd actually need is closer to what is in the hd44780 code without the graphical elements, hence going this way.

But my C++ is really quite rudimentary, so whilst this compiles and does seem to run on a hd44780 (GPIO), hd44780 (I2C) and ssd1306 (I2C) all sharing this same base character class, I really could do with someone who knows what they are doing taking a proper look!

I've simplified the ssd1306 handling compared to the MT32-Pi code - again it works, but I really am not sure it is keeping in the spirit of the original code (I am really fumbling in the dark when it comes to Templates!).

So in short, if this is of interest, do someone please take a look, but don't expect any grand things :) If any of it seems useful, again feel free to grab what works and ignore what doesn't (and if that includes it all - no worries! It is all still a useful learning exercise for me!).

Thanks,
Kevin

[diyelectromusic]

Yes of course. I was just continuing the API that was already there for the HD44780. It it already different to the graphical display, but I only needed text anyway, hence not worrying about it! :)

But yes, if someone wants to do it all properly and harmonize the whole lot that would be even better. The MT32-Pi approach could be used, but that would totally redefine your existing hd44780 interface... but as you say, that is perhaps a discussion for another time :)

[probonopd]

Indeed it would be nice if the SSD1306 support would come into Circle proper, as there are very small, inexpensive and nice OLED displays available with it which I think would be a great match for Raspberry Pi hats.

[rsta2]

There will be support for SSD1306-based displays in Circle, but I need time to harmonize this with the existing drivers, which is available not before the next Circle release.

[rsta2]

@diyelectromusic I merged your SSD1306 support without modification into the develop branch. Thanks for this contribution and sorry for the long delay. The previously announced harmonization work cannot be done currently by myself.

[diyelectromusic]

@diyelectromusic I merged your SSD1306 support without modification into the develop branch. Thanks for this contribution and sorry for the long delay. The previously announced harmonization work cannot be done currently by myself.

Great! Glad is was useful - that will be really useful for miniDexed I think... I'll need to see if I can build another version of it now including the new support!

The graphical stuff will be a little more complicated I think... that will probably need quite a lot more thought that this update...

Many thanks,
Kevin

[richard-broadhurst]

Great project and sorry if this isn't the best thread.
I was wondering if it is possible to bitbang a 15.7Khz arcade monitor display on the PI.
It should be on the older ones where the GPU ARM is accessible but I'm not sure about the more modern ones.
Would a better solution be to copy the display buffer to a PiPico and do it from there?

[substring]

Sorry to bump the topic, but I'm also pretty concerned with using a Pi + circle as a display adapter for arcade monitors (and generally CRT monitors). Would using the VGA666 to get native analog out and display frames sent through network at say approx 60FPS with the least possible lag in the video chain possible with Circle ? Like send video frames through network, bake the magic sauce within circle to display frames at the expected modeline (don't bother with the calculation for that, all the modelines charatristics would be sent by the app through network) ?

[rsta2]

Unfortunately I'm not familiar with the VGA666 and I cannot tell. After doing a quick read, I think, the VGA666 requires special software support, which is not available in Circle. You would have to implement and try this on your own.

[substring]

Ok, thank you for the quick reply. So if it's pure GPIO bitbanging, the pixel clock in most cases should be lower than 12MHz. Can we achieve real time precision with the circle timers to be sub micro second ?

[rsta2]

With the CTimer::nsDelay() method you can do delays of about 300ns. That's not enough. You would have to use your own delay loops and calibrate the number of loop runs in the init phase.

[substring]

Not being to be able to use a periodic timer with a 50ns precision will make it just painful to hold the expected pixel clock, so this sounds like a big no-no 😞
Thank you for the feedback

[ArnoldUK]

Not being to be able to use a periodic timer with a 50ns precision will make it just painful to hold the expected pixel clock, so this sounds like a big no-no 😞 Thank you for the feedback

I'm not sure what exactly it is that you are attempting to do but HDMI output is certainly possible so why not simply convert the signal to VGA or use a Pi PICO with interrupts and PIO. There are plenty of VGA output addons for the Pico that use bitbanging for the VGA signal in many formats.

[substring]

I'm looking for ways to "replace" a PC GFX card that don't have analog outputs anymore by sending frames from an emulator to a CRT monitor (TVs or arcade monitors). For HDMI : I saw nothing regarding setting the resolution nor the refresh rate. WHat you may miss here is that, in my case, we're not outputting at a static resolution/refresh rate. Any project that is stuck to 320x240@60Hz and can't move from it is of no help. Arcade games like R-Type (384x256@55Hz) or Mortal Kombat 1 (400x254@53.20Hz) have funky resoution/refresh rates and we must respect that. So the idea is to recreate the complete VGA signal, and not go through various adapters that may add video lag. I'm talking about control on a per line basis, and know on real time the raster position. Can't do that on digital outputs.

[ArnoldUK]

That's something you'd have to code yourself at those resolutions. For a start you could try the links below which I use for all sorts of emulators with custom VGA output modes:
PicoVGA - VGA/TV
Pimoroni Pico VGA
PIO Assembly VGA Driver

[substring]

I've already read about all these projects and found them just great, but not suitable in my case :

• I want to replace a GFX card, not emulate on a microcontroller. In other words, the "adapter" is fed with frames and generates the VGA signals. So it needs some inputs to get the frame
• need at least 16bits colors, so RGB 565

All in all, there are a number of constraints:

• free pixel clock
• no pwm analogue out (hell no), but 18 output pins (16 for RGB, 2 for H and V sync) + a resistor ladder like the VGA666 for "analogue conversion"
• and receive a frame (hopefully not compressed) and process it instantly. This means an approximate fill bandwidth of 320x240x60x16 ~= 75Mbits/s

[ArnoldUK]

Well I don't think a soft solution is going do this but you know more about it than me so can't really offer much more than that. Why do you need to replace the GFX card and what is it's purpose ?