 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 : Question - Can the MM output to multiple touch screens?
Page 1 of 2   |
|||||
| Author | Message | ||||
| AussieWombat Newbie  Joined: 04/05/2018 Location: AustraliaPosts: 21 |
Hi All, I was thinking about a project, where it would be nice to have output to multiple(3) touch screens. Ideally I would like to run the 3 screens, with 1 having the use of touch. The selection would happen on the main touch screen, and the output would happen on the 2 other screens(duplicates). Or Will I have to use 3 MM's? With connection between master(1) and slaves(2) Regards AussieWombat |
||||
| PeterB Guru  Joined: 05/02/2015 Location: AustraliaPosts: 655 |
G'Day AW Grogster has designed a board to run 2, 7in touch screens as dumb displays. I know it works because I had to connect up 2 displays to convince him. I have no idea how you would get on with 3 displays. The problem will be when you try to use the touch function. MMBASIC will enable touch on all connected screens so, short of using a hack-saw,I think there will be problems. But I have been wrong in the past so good luck  Peter EDIT. I imagine you could just not connect the touch lines. That would be better than using a hack-saw. Of course it will work, trust me  Peter Edited 2020-03-07 15:03 by PeterB |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Mornijg AW. Multiple screens is quite do-able. I played with this a while back and found the number of screens was practically limitless if you manually (via program) control the chip select for each. I have a tiddly vids showing this here and here If this is the sort of thing you are after, I can grub out the code and post it. As pointed out above, there are complexities with touch and certainly any interrupts would need consideration. I think you might be able to support a single screen for touch fairly easily. hth h |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 655 |
G'Day CB et al I think you are using a micro on each display hence the problem with interrupts. I used one E64 with 2 displays but they were dumb displays. I'm good at dumb  However if only 1 screen has it's touch connected it should / might work. Peter |
||||
| Warpspeed Guru Joined: 09/08/2007 Location: AustraliaPosts: 4406 |
Pretty crude, but if all else fails, how about a sheet of clear acrylic over the displays to disable the touch function mechanically ? Cheers, Tony. |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 655 |
Grogster wanted back to back dumb screens and that was no problem however, if I remember correctly, there is a limit on how long the ribbon cable can be. About 150mm comes to mind. Peter |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 621 |
On a different system, I am using a slave screen which uses an arduino as a screenscraper. The arduino runs as a spi slave and does the lcd updates etc. I guess that could be an option for the MM, using the second spi port and various select pins (?). The benefit is that the commands tend to be only small strings instead of the pixel updates and you can tweak the display, fonts etc a lot by bending the arduino program...here I am using a proportional font, it is a bit sad that what I once thought "futuristic" is now "retro"    PROGRAM introlcd CHARACTER*17 txts(6) C SPBSTT - start SPI port B SPBSTT C pause for lcd start CALL delay() txts(1) = 'LINE ONE' txts(2) = 'LINE TWO' txts(3) = 'LINE THREE' txts(4) = 'LINE FOUR' txts(5) = 'LINE FIVE' txts(6) = 'LINE SIX' CALL dispflds ( txts ) END SUBROUTINE dispflds ( txts ) INTEGER*2 cr, ht, eot CHARACTER*17 msg, hh INTEGER*4 nth cr = 13 ht = 9 eot = 4 nth = 1 DO WHILE ( nth < 7 ) msg = txts(nth) SPBXWD msg, hh CALL sendit ( cr ) CALL sendit ( ht ) nth = nth + 1 END DO CALL sendit ( eot ) RETURN END SUBROUTINE sendit ( outbyte ) INTEGER*2 temp SPBXWD outbyte, temp RETURN END SUBROUTINE delay ( ) INTEGER*4 n n = 0 DO WHILE ( n < 4000) n = n + 1 END DO RETURN END \ Edited 2020-03-11 13:54 by zeitfest |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Yes, all I wanted was two displays on the one MM chip, but touch was not used, just the display. None of the touch pins were connected, only the parallel bus for the LCD data as it was 2x 7" displays. Never tried two SPI ones in parallel. Never tried getting the touch to work. One would think that in theory, you could connect both displays together, but I bet that would be a case where theory and practice do not agree.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 655 |
G'Day Grogster I know you designed a board to drive 2 displays but never heard if it worked. Can I assume that it did? I would think that the touch pins could be used on one display but 2 would be a bit iffy. I also suspect that AW wants the displays too far apart but don't really know. Peter {just for you) |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
nope. Single '170 driving two displays. You can see both displays are connected in common (except CS, natch) in this still from the vid. Could drive many more (of the same type) - limited only by free pins. I programatically handle the CS pin just before I do any screen access.  I don't (never have yet) use the touch interrupt, I prefer to poll for changes but it could be handled on one screen OK, just have to activate the CS for the "touch display". Using something based on a priority encoder it should be possible to determine which of the screens you touched if you wanted it on all of them and switch the correct CS in... with caveats (and some extra circuitry)... with a bit more time it might be possible to come up with a total MM solution, but I just yanked this out of the air. It's not something I have ever needed so no proven method, just guessing. Edited 2020-03-12 02:48 by CaptainBoing |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 655 |
Good morning CB Very clever. You can wipe that smug look off your face NOW! It will take me some time to fully understand it but well done. Peter |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 621 |
Do the displays both show the same content ? I had the impression, MM will not maintain two different concurrent display states for updates etc |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 655 |
G'Day Z CB is probably tucked up in bed and not able to respond. If you look at his vids from his first post you will see what it does. I wish I was that clever, and for a pom too.  Peter |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
an as-yet un-diseased pom... mate they are dropping like flies in and around my town  ... I try not to be smug - we all began as something else and I am only too aware of walking among masters here and of my Socratean status - "True wisdom comes to each of us when we realize how little we understand [...]" Always happy to share what I learn/do.So with the displays, all pins with the exception of CS are common and controlled by the MM. I lose one pin when configuring the display in MMBasic as it asks for a CS - it gets it but it isn't connected and I can't use it for anything else. Then with all other display access, I programatically take whichever CS pin I want, active right before. In the video, you can see two display resets - this happens by my program resetting the display, selecting the other CS and doing it again - this is how I figure (haven't tested) that you could do this on a dozen displays or more if you have the pins and can keep track of what's what in your code. At first I was thinking about some multiplexer to control the CS but really, unless you are pushed for speed, it is easy enough to do it directly with code rather than components and sacrifice the one pin - you have to select the display you want anyway. I did a little write-up about it here and you can see in the code around line 7 where I select each CS in turn and initialise the panel, then inside the DO/LOOP, I use a FOR/NEXT loop to select each CS in turn and do some random scribbling... I think this is probably the code you see running (with tweaks) in the second vid where it demonstrate independent control/content. You are probably thinking about inputs at this stage and you'd be right - I never played with that as the application was after display only (and it mean slightly cheaper LCD panels with no touch chip). I think it would be easy using a single display for touch because then when you get an interrupt, you know which display you need to service... if more, my idea around priority encoder would still give you the interrupt but then you'd have to read 3 bits from the '148 to determine which of the (8 in this case) displays generated the interrupt. Too busy to check atm but it would make for an interesting afternoon in the shed. all the best hth h Edited 2020-03-12 17:56 by CaptainBoing |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Both displays can have independent content. I think with the cheaper little panels, MMBasic uses a "fire and forget" approach and the only "state" maintained is just concerned with the interface. Don't know if that is an accurate assessment but looking at how this does actually work I am drawn to think the internals are fairly simple. The thought crossed my mind when I was playing with this first and was half expecting the Gui Reset Lcdpanel command to complain after the initial one, but it was fine - and it is key to the whole thing - you can't send stuff to a screen you haven't initialised so I was half expecting the second panel to not respond or be filled with junk, but it is fine. It continually blows me away just what a tiddly MM can be pushed to accomplish.The ILI9134 is not the fastest of panels but simple animations/screen gadgets and informational updates are fine. Never tried this on a different panel. Edited 2020-03-12 18:06 by CaptainBoing |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
ignore... Edited 2020-03-12 18:09 by CaptainBoing |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Hiya. I did do a board to drive two LCD's, but it DIDN'T work, and nothing I did would make it. It would run one or the other, but as soon as both were connected, nothing happened. I abandoned that PCB at that point. It is quite possible I made some kind of error with my layout, or maybe the screens simply did not like the old 40-wire IDE hard-drive cables I was using. I probably should dig out that board again, and crimp up some custom leads, as I have a feeling that some IDE hard-drive leads had certain pins connected within the plugs for grounds or something. Peter - can you remember if when you tested, you used IDE hard-drive leads to couple the two displays together, or did you crimp up your own ribbon cables? Thanks for the smilies. Smoke makes things work. When the smoke gets out, it stops! |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 655 |
Sorry your board didn't work but there must be a reason. I think I made my own cable using cable and connectors from Aztronics or Jaycar and a 4in Dawn vice. I have been looking back over my posts and I think I sent photos via email because I could not get them attached to a post. 150mm was good but not a lot longer. Why are you using cables? I thought your displays would plug directly into your board. I have yet to work through what CB has done. I am getting slower and slower. Good luck Peter |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Yeah, perhaps my cables were either wrong(designed for IDE hard-drives), or they might have indeed been too long. No, the board had two 40-pin box-headers on it, and I was trying to use two cables - one for each display, with the main PCB joining them together. Perhaps I was simply pushing allowable lengths too far there. The new version that DOES work has a master and slave arrangement. One PCB is the master and drives one display, and a 2nd board is a slave and takes simple commands from the master to draw the same thing on the 2nd display. Both are then individually driven from their own MM+ chips. But I digress.....sorry. Not meaning to hijack the thread.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
it's not like it hurts much Some really interesting stuff comes out of ramblings. I have to defend you anyway as I am guilty as charged  |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
