 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Two displays on one micromite.
| Author | Message | ||||
MustardMan Senior Member  Joined: 30/08/2019 Location: AustraliaPosts: 175 |
Hairbrane idea... I have an Explore 100 set up as a controller, connected to a 7 inch SSD1963 (parallel interface) display, and use it for displaying critical parameters and implementing a touch screen. I have an idea to connect an auxillary, smaller, display (such as an ILI display with SPI interface) to display logs and other non-critical but still pertinent information. I would like to be able to use the MMbasic built in graphics and text commands because they simplify tedious low-level screen stuff enormously. How do I (in fact: can I) set up an additional display without having to write a complete set of drivers/routines for the "non-active" display? For example, if I switch between them with something like... "OPTION LCDPANEL SSD1963_7A ..." ' Main display do some graphics & text "OPTION LCDPANEL DISABLE" ' Turn off main display in prep for sub-display "OPTION LCDPANEL ILI9341..." ' Sub-display do the alternate display graphics & text "OPTION LCDPANEL DISABLE" etc. ...the 'active' panel is reset each time I switch from one to another. Is there a way I can switch panels without resetting/restarting/reinitialising them each time? My (not preferred) alternate is to run a separate micromite (eg: the LCD backpack) and put a serial link between them (I am using 3 of the 4 UART channels on the E100 already). Extra software, extra debugging, serial links to contend with... I might be better writing some specific "dual display" drivers... Cheers, edit: PS, 'option lcdpanel disable' also resets the touch functionality, resulting in a gap in responsiveness, and adding the requirement of having to set touch up again each time. Edited 2021-06-18 20:12 by MustardMan |
||||
| Volhout Guru  Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
Hi Mustardman, I don't think it is that easy. The ILI display will also have different mm.hres and mm.vres. You are looking at a very complex piece of code on your part (the basic stuff) and a complex piece of code on Geoff's part. (dynamic switching screens, or full dual screen support). I guess your option to use a MX170 backpack is easiest to implement. Another option could be is to write the text to a 1602 LCD. That could work independent of the SSD1963 since the commands are completely different, as is the hardware interface.  PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
With the LCD display you also have the option of using the i2c version and only using 2 pins. The driver can quite happily live in the library on a Micromite and, although it doesn't share the same commands as a graphics display, is straightforward to use. If you can't find a i2c version then there are very cheap adapter pcbs on ebay. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
I did this with ILI9341s on a micromite Mk2. http://www.fruitoftheshed.com/MMBasic.Multiple-LCD-panel-displays.ashx I programmatically manipulate the CS pins for each display right before any LCD operations - it works well, you don't have to do the two chips to select thing... there is no practical limit to the number of displays you can have in this manner. You do lose the CS pin associated with the OPTION LCDPANEL vid thoughts... 1. never tried with two different types of panel. Driving another display manually (i.e. you setting all the registers up etc) should work, but a lot of hassle. 2. touch is likely to be tricky if you are using interrupts but manipulating T_CS and polling might be ok Edited 2021-06-18 22:22 by CaptainBoing |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
That's good, but I don't think it would work with dissimilar displays no matter whether they are SPI or parallel because of the different resolutions. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
@CaptainBoing I did read the thread you had on TBS some time back about running two identical displays with interest. They only need to be electrically identical, so I could have different physical sizes. The only modules (800x480) I've seen on ebay are 7", 5" and 4.3" with the latter having an unknown pinout. The screen initialisation code (in MMbasic) resets the display when called. I wonder if I could have a CSUB version that does everything but - ie: sets resolution etc for MMbasic to interface with, but does nothing to the screen itself, leaving whatever pixels are on it entirely alone. It would likely work with different screen types too: Startup code initialises both screens using "OPTION LCDPANEL ..." Loop code switches with CSUBs 'Use_SSD' and 'Use_ILI' Like many are saying, that is starting to get complicated. A backpack hanging off a serial port (which could be something other than a UART) sounds like the go, and wiring a serial port & power is far easier than duplicating a parallel port. Good point about the character LCD modules, although I am looking for something with a bit better display ability (probably half a dozen text lines). And colour is definitely nice: green for normal messages, red for bad messages. Cheers! As an aside, I had a play with the LCDPANEL initialisation code about 12 months back, and commented out the 'clear' segment for fun & interest. The displays initialised and displayed VRAM "noise". Looked just like the no-channel noise on old-school television sets - cool, interesting, but ultimately useless... although I had a thought of being able to get random numbers from it... then thought, nah. There are much simpler ways. |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
It might be easier to just bite the bullet and get the same display for everything - in the name of not making a whip for your back. However, now the creative juices are flowing... If you only want one display for logging etc, had you considered using a VGA monitor? There are several very cheap text to VGA modules; one on Geoff's site or a batsocks tinyTV(?) and then a tiddly VGA monitor like this one MatherP did a while back? If you use something like a MMX as the controller (like I have for my "workshop assistant - very under-used controller in my opinion), you could even dispense with the VGA converter. I made up a couple of those little monitors for workshop use - something you can just plug in to check an output. You could connect one of these to the console and then have as many LCD panels as you like, flipping between their CS pins easily... with some mux you could have hundreds without any issue (ignoring any loading issues on the SPI bus etc... for brevity)... using something like 74HC154 gives you sixteen CS pins from just four output bits - that could even make use of the otherwise sterilized CS pin from the OPTION *very* easily. what is your application? p.s. you idea on gaining TRNG from that noise is not a bad one - if it is truly random, it would likely be a form of "shot noise" (if it is genuinely derived from the electric charge on individual memory cells in a indeterminate state - some testing would be required to look for bias) and if already exists as black and white dots, the conversion to binary is done for you... hmmm... interesting concept. Random has been a pet interest of mine for decades. . Edited 2021-06-19 18:24 by CaptainBoing |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
@CaptainBoing I am using a 7" 800x480 SSD1963 in portrait mode with the top 2/3 for displaying system running parameters and the bottom 1/3 for touch screen controls. My concept (and I am wondering if is worth the effort) is running a second smaller screen in landscape (maybe 4.5" or thereabouts : 5" is too big) to mostly display errors, but also to display abbreviated logs. I am logging by minute to SD card, and outputting status/log messages to the 'console' every second. However, it is an embedded system and having a monitor (like a VGA monitor) of any sort hanging off it would be a very untidy look (and in the application, get covered in dust and grease and dirt). Having a second display embedded into the panel (which is not big) would look nice - but as I say, it may not be of that much use... I use the 'console' UART with a laptop for immediate diagnostics, and can remove or access the SD card to get information on events that happen while I'm not watching. TRNG: Yes, memory "noise" is true random when started 'cold' (ie: turned on after being off for an acceptable period). Some memory has bias towards 1 or 0, but some memory is truly random. An XOR swipe though a reasonable segment of memory will give a TRN, and useful to seed a PRNG. Reading the LSB from multiple AD conversions is a better way, and does not require a cold start. But that only works if you have an ADC... |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003 |
If you write your own CSUB driver that combines the SSD1963 driver and the SPI driver for the other LCDPANEL into a single driver that is aware of a switching bit that tells it which one to talk to, you might make it work. The LCDPANEL drivers only have the initialisation code, you do both at start up, and the two routines that replace DrawRectangle and DrawBitMap, all the graphics/text commands call one of these. You write these for each display and call the correct set depending on the flag ,that indicates which one you want to talk to. The CSUB would take up some program space so depends what you have left. A character in the OPTIONS could be used to indicate which display is in use. This can be written on the MMBasic side and read on the CSUB side.From CFunctios.h char pins[4]; // general use storage for CFunctions that need to record the pins for a parallel port. Latest F4 Latest H7 FotS |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
