 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 : ILI9341 on two Pi Pico
| Author | Message | ||||
| asknik2022 Regular Member  Joined: 26/03/2022 Location: United KingdomPosts: 92 |
Is it possible to switch between two Pico's onto one ILI9341 by changing CS pin etc. |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
I doubt it very much. You could put the display on one and link the two Picos using a COM port or SPI, passing over the data to display. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
Technically it is possible to hard wire one ILI9341 to 2 PicoMites, but they cannot run MMBasic at the same time. By pulling 1 of both RUN pins low, you select which pico is active.the other one is kept in reset, and performs a cold boot when started. This could be usefull if one pico runs mmbasic, the other one circuitpython or an othe program. Volhout Edited 2024-07-17 03:29 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
You have an SPI bus with two masters. That's very dodgy as you have two devices capable of providing SCLK. Yes, it's possible, but whether it's possible with a shared dumb slave is something else. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2075 |
done it the other way with no issues (two panels on a single 'mite) at all - very usable. Not done touch on them though, just display you might get some hints here h Edited 2024-07-17 05:47 by CaptainBoing |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
At best you need additional signals between the PicoMites to avoid bus collisions. You can't redefine MOSI and SCLK to be inputs to avoid loading the bus when it isn't being used so you would, at the very least, have to connect these signals to the bus via resistors. The CS to the display would have to be from OR signals from the PicoMites as they both need to be able to drive it. Each display would have to start display access by sending a request signal to the other asking for the bus. It would then have to wait for a ACK signal before lowering CS and taking over the display. At the end of the routine it would raise CS and remove the request signal. CS is handled by the display driver. How on earth you would get the display initialised in the first place I don't know, and how a PicoMite could talk to a display that it hasn't initialised I don't know either. :) Please don't attempt this. Life is too short to invite insanity. Just fit a second display. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 118 |
If I was forced to make this kludged architecture to work.... I wouldn't wait for the ACK-nowledge to come back. I would define the arbitration protocol such that the other side(s) only had a certain amount of time to NAK the request. That would be easily done by making sure nobody else was using the bus, and then asserting the signal that somebody was intending to use the bus. And probably a random back off time would make sense if there was a collision. But everybody here is in agreement.... This isn't the right way to go.... Edited 2024-07-17 14:40 by EDNEDN |
||||
| asknik2022 Regular Member Joined: 26/03/2022 Location: United KingdomPosts: 92 |
What about using 2x 74LS244 and have the outputs connected together or 2x MAX335 and Use SPI Interface to control which MAX335 is active |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
The problem isn't in switching the signals, it's in MMBasic. The SPI bus is just that, it's designed as a bus system. Unfortunately it's not an ideal one for multi-master use as it uses a single clock generator (the master). Slaves can never generate a clock. MMBasic can only be a master (don't ask me why but that's the case). You have an instant problem - two devices that can only be masters and one dumb slave. On boot MMBasic initialises the pins for the display then locks them. You can't change that behaviour so you can't change the pins. Additionally the Pico doesn't have tristate outputs so to prevent them from loading the bus you have to switch them to input mode. After boot MMBasic goes through an initialisation routine to set up the display. If it can't find it you get a "Display not configured" error as it's not getting a response - remember the Pico is generating a clock. If you attempt to use two Picos in any configuration only one can generate the clock and get the response. The other has to throw an error. I'm not sure if that's trappable, but even if it is the errored Pico may not be able to initialise the same display again as it's already been done. You may have to initialise the display every time a pico wants to start a write session to it. I really can't see this setup working, no matter what you do with external signal steering. The firmware just isn't designed to do it. If the display is only for simple stuff then I'd do it like this: Use a third Pico as the LCD driver. That has an I2C port exposed. You could also have a "Busy" line so that a Pico doesn't start to send while the LCD handler is doing something else. Each of the others is on the I2C bus and has no display. A simple descriptive "language", possibly using ANSI codes, would be used to send instructions to the LCD driver to update the screen. You could use simple macro commands to, say, draw a box of a certain size in a certain colour or to print text in a certain colour. The advantage of this approach is that it's "clean" and you can have the same set of library commands in both the Picos. Is there a special reason why two displays can't be used, I wonder? . Edited 2024-07-19 01:20 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| asknik2022 Regular Member Joined: 26/03/2022 Location: United KingdomPosts: 92 |
Hi Mick I have created a VU Meter (Left and Right Channels) using two SSD1309 2.42" SPI Displays (which unfortunately MMBasic does not support) so I am having to do it with Micropython (as I hate Arduino) I have got them working perfectly as you can see from a previous post. The problem is that when I add IR Receiver in order to control volume and sound sources(Cd,Tape etc) the IR stops working the moment the VU_Meter code is run and displayed. So my idea was to use another Pico to control the IR and its various other display screens (eg Volume control) and then have it switch over by remote command to the VU Meter display etc. I actually have a working MMBasic control amplifier using an ILI9341 + PGA2310 for audio volumec control but have not yet been able to to do a vu Meter in MMbasic yet (something else that I currently working on.) I am acutally thinking of using the SSD1309's in I2C mode if that is easier?? |
||||
| asknik2022 Regular Member Joined: 26/03/2022 Location: United KingdomPosts: 92 |
Also I have been looking at seeing if it would work using 2x 74LS244 Octal Buffers - 3 state output by connecting the outputs together and have each pico as input and having one of the pico's control both 244's |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
It sounds like your VU meter code is hammering the resources a bit. Can you handle the IR as interrupt driven? I suspect that one of them will have to take priority over the other as receiving a but stream over the IR will mean getting the timing right. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
