2
\$\begingroup\$

I have an LCD display which is powered from a pretty powerful micro, with GPU and all sorts of stuff. However, it turns out that it will take it over 5 seconds to boot the core. From a user experience perspective 5 seconds to see any boot up image/animation on screen after turn on is unacceptable.

So i was thinking of including a separate very cheap micro which can hold the master line for the first couple of seconds and provide the boot up image. It would then hand over the SPI bus to the main micro.

This of course is not the only use case of the smaller micro. I would also use it for all the backlight control. The larger micro might go into a sleep state and i would like for the smaller micro to still keep the display on. (So basically the main micro will simply tell the small micro what brightness to keep things on and a default brightness in case the main micro sleeps).

Is there any way i could hold the small micro as master for first 5 seconds and then let go to the main micro for the rest of the time (and as a bonus, hand it back to the small micro when the main micro goes into sleep)?

Thanks!

\$\endgroup\$
2
  • \$\begingroup\$ Just to be clear: SPI is the communication method between the two micros, as well as with LCD, right? Do you have any spare IOs on the small micro and main micro that can be used to signal between them? \$\endgroup\$
    – Annie
    Commented Dec 18, 2018 at 0:04
  • \$\begingroup\$ Well, i will have SPI between the LCD and the main micro and the LCD and the small micro. The comms between the small micro and the main micro will most likely be something like UART or I2C. Would this complicate things at all? \$\endgroup\$
    – Hasman404
    Commented Dec 18, 2018 at 9:06

4 Answers 4

Reset to default
1
\$\begingroup\$

The main problem here is probably not to pick a suitable MUX - most analog switches will probably work. But rather how to sync "GPU" and "MCU". Because MCU should be speaking most of the time, except when GPU takes over, then it should be quiet.

The GPU can't just cut the SPI wires when it pleases, because then it will corrupt an on-going SPI transfer. This can have very bad side effects if the MCU is interrupted when writing commands to the display.

You can solve this by having the two devices listen to each others /SS lines and use that as a means of "arbitration".

GPU:

  • When /SS line out from MCU is pulled low, remain quiet during the on-going transmission.
  • When /SS from MCU goes high, grab the bus by starting a SPI transfer and thereby pulling /SS from GPU low.

MCU:

  • Before starting a SPI transmission, check /SS line from GPU.
  • If /SS line from GPU is high, we may send.
  • If /SS line from GPU is low, go passive/sleep for a certain amount of time, before checking again.

MUX:

  • Wire it so that the two different /SS lines are used as channel select, determining the source of MOSI and CLK. (MISO shouldn't be needed for most displays.) Either by finding a suitable switch or by inverting the signal of one of the masters through BJTs or similar.
  • You can perhaps make the MCU /SS recessive by connecting it through a 10k pull resistor, so that the GPU /SS can override it without having two outputs competing. I suppose there are lots of ways to solve this.
\$\endgroup\$
5
  • \$\begingroup\$ I went through this earlier and i've been told no changes can be made to the board with the GPU. This board uses level conversion buffers and so the SS line coming from here to the LCD board is one directional. So the GPU would have no way to see if the MCU has pulled the line low or high. So i will have to use your last statement with the HLP overriding the MCU. \$\endgroup\$
    – Hasman404
    Commented Dec 20, 2018 at 9:33
  • \$\begingroup\$ @HassanNasir You don't need to change the GPU board, only the GPU firmware. The MUX, level converters, polarity switchers etc can be placed on a board in between GPU board and LCD board. Though if the GPU can't listen to /SS, then I don't see how you can make this work well. You'll get display disturbances whenever the GPU interrupts the MCU. \$\endgroup\$
    – Lundin
    Commented Dec 20, 2018 at 9:48
  • \$\begingroup\$ Instead of listening to the /SS line (which it can't because of level conversion buffers), it could use the i2c interface with the small micro to check with it before sending anything out? \$\endgroup\$
    – Hasman404
    Commented Dec 21, 2018 at 8:11
  • \$\begingroup\$ @HassanNasir Simply use a bidirectional level converter? 74HCT245 or similar. \$\endgroup\$
    – Lundin
    Commented Dec 21, 2018 at 8:25
  • \$\begingroup\$ The level converter is on the PCB with the main micro which can't be changed. The change to a bidirectional converter would add cost which would make it even harder to make such changes. \$\endgroup\$
    – Hasman404
    Commented Dec 21, 2018 at 10:48
1
\$\begingroup\$

It would probably be simplest to pick a "small micro" that has two SPI interfaces. Use one as a master to drive the display, and the other as a slave attached to the "large micro".

Then, your small micro's firmware can arbitrate between passing the large micro's transactions through to the display and sending its own commands.

Note that sending data to the display this way is straightforward. But if the large micro needs to read anything back from the display, a little more thought is required.

\$\endgroup\$
3
  • \$\begingroup\$ Is this possible? The main micro will be using its GPU to send several animations to the LCD at a high frame rate. I appreciate the smaller micro isn't doing any processing at this point but can it still act as a medium to send through the SPI commands ? I assume it should work as long as there is enough bandwidth on the SPI bus? \$\endgroup\$
    – Hasman404
    Commented Dec 18, 2018 at 9:04
  • \$\begingroup\$ Maybe not. To be honest, before I started considering hardware solutions, I'd be taking a close look at the boot sequence of the large micro, so see whether some code couldn't be inserted at an early point to initialize the display and put up your splash image. What kind of processor is it anyway? I've never heard of a GPU that outputs to SPI before. \$\endgroup\$
    – Dave Tweed
    Commented Dec 18, 2018 at 12:54
  • \$\begingroup\$ I considered this too when I wrote my answer. It is the easiest solution but will have a latency of 1 SPI frame at best. SPI to LCD is often fairly quick too, so you might have to "DMA through" the data. If that kind of delay is acceptable, then this is the easiest solution. \$\endgroup\$
    – Lundin
    Commented Dec 20, 2018 at 10:06
0
\$\begingroup\$

The straight forward way to implement what you want is to insert some circuitry between the processors and the display. This circuitry can take two forms:

  1. Use a four bit wide multiplexer chip that can MUX the four SPI control lines (SPI_CS, SPI_CLK, MISO, MOSI) for each of the two masters to the display interface. The selection control for the MUX would come from your low cost MCU.
  2. Use two separate 4-bit wide tristate buffers to select one master interface or the other to the SPI interface on the display. Normally the same part would be used for both masters and so it would take two control lines from the low cost MCU to control the tri-state of the two buffers (or another added inverter gate). Alternatively with careful part selection you may find two tristate buffer chips, one with an active high enable and the other with an active low enable which can then just be connected together and controlled from one pin of the low cost MCU.

This scheme does require you to use care when you actually switch the display from one master to the other. You would want to avoid switching while there is an active SPI transaction in progress on the interface. Some devices could get confused when this happens. Other SPI devices would recover simply by driving the SPI_CS signal to the inactive level for a period of time.

\$\endgroup\$
0
\$\begingroup\$

Quad SPDT analog switch would do also such as http://www.ti.com/lit/ds/symlink/ts3a5018.pdf That one is a 3.3V level, there are 5V level switches as well.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.