Hardware Design and Development

[TerryJC]

The electronic design of the Tiny-TV will follow the (rather poorly translated) instructions given in the Chinese manual. The Tiny-TV will consist of:

• A Raspberry Pi Zero W.
• A DC-DC Converter to provide 5 V for the Pi from the 12 V site supply. The display module will use 3.3 V from the Pi on Pin 17.
• The display arrives configured to use the SPI interface on the Pi and so will be wired In accordance with the supplied instructions. The attached diagram provides the pinouts.

[TerryJC]

Now that I have a Tiny-TV working, I have been looking into the possibility of getting one RPi to drive multiple Displays. Out of the box, the RPI has a single SPI Bus with two sets of pins dedicated to Chip Selection, etc. This implies that the limit would be two devices per Pi. After some sterling help from the Dorset Linux User Group I've been able to see some ways forward. Further research is probably needed, but I have identified two possible solutions; one with software and one with hardware. First, SPI is a multi-drop technology. The following diagram shows a typical arrangement:

SPI-Multi-Drop.png (12.42 KiB) Viewed 1259 times

As can be seen only the CS (SS in the diagram) is a unique line. However, the RPi arrangement for SPI Bus connections uses two each of each line including two sets of CS lines for each set, eg SPIO SCLCK, SPIO MOSI, SPIO MISO, SPIO CE0 and SPI0 CE1 plus the same five pins for SPI1. The Python driver Modules follow this. I'm not sure what is going on here and this originally made me think that there are two SPI Buses in the Pi. I will continue to pursue this.

Software Solution
In theory the OLED_Driver and it's associated Config.py could be rewritten to behave like the diagram, but it would be a major change to the module and would probably be confusing for future maintainers.

Hardware Solution
The second possibility is to multiplex the SPI Bus lines from the Pi. Several ways have been identified for this:

• Connect SCLCK, MOSI and MISO together as shown in the diagram.
• Connect the RPi SPIO CE0 and SPI0 CE1 pins to a multiplexer to switch the two CS lines to the correct device.
• Alternatively multiplex all five pins if that proves necessary.

or

• Use a dedicated expander chip for SPI, if a suitable device can be found.

The hardware solution has the distinct benefit that the software will be easy. The standard OLED_Driver will work as long as the code routes the chip select to the required device and holds it there until the required image has been uploaded.

Penri,

Do you have any thoughts on this?

[TerryJC]

• Use a dedicated expander chip for SPI, if a suitable device can be found.

Such as this maybe: https://docs.rs-online.com/33f6/0900766b8137eee7.pdf. Just over £1 each in packs of five from RS.

[Penri]

Terry

Excellent work.

For me I think the H/W solution is the way to go, should not be too difficult in simple combinational logic although a dedicated chip(s) would use less real estate.

As yet the planning on where the TinyTVs would go is in it’s early stages but I very much doubt it we’d put more than 3 in any one shop front with 2 probably being typical. Any dioramas with a TV would only need one per.

When I get back I’ll talk to Ian Yarrow, who’s been building the recent shop fronts about doing a couple of new ones for Holmans, deeper than the existing, so we can lay out a shop display. I also need to look at the other potential “homes” for the TinyTVs: Curry’s and Dacombe to see what they can accommodate as they are or if they need modification.

I’m also going to have to run 12V to Holmans as it isn’t currently connected plus there’s the issue of network connectivity for the RPi to work through.

From what I understand of the SPI bus SS is the “Slave Select” line and is active low, so the other three lines SCLK, MOSI and MISO could be paralleled up to to n slaves, up to the limit of the device drivers on the RPi, and SS driven either from the RPi GPIO pins or from a multiplexer. I am of course ignorant of how the associated library / driver works so don’t know what’s implementable.

Hwyl

Penri

[TerryJC]

Penri,

Yes. I assumed that SS was the equivalent of CS on the display and CE on the Pi. While you are away, I'm going to try to find out why the Pi claims to have only one SPI Bus, but provides two complete sets of control/data pins. It may be for ease of connection, but it seems a bit strange.

If we only want two Tiny-TVs per diorama then we won't need multiplexing, but I think it may be worth sussing the technique out anyway.

I believe that if we have multiplexed lines, then the software will be no problem.

[TerryJC]

While you are away, I'm going to try to find out why the Pi claims to have only one SPI Bus, but provides two complete sets of control/data pins. It may be for ease of connection, but it seems a bit strange.

I now understand the situation, which was caused in part by misleading representation of the functionality available in the diagram at https://pinout.xyz/pinout/spi. That site is extremely useful which is why I tend to take what it says at face-value.

In reality, there can be up to 6 discrete SPI Buses on a Raspberry Pi; two on the standard consumer boards and the other four on the Compute Module. By default none of the buses are active, but SPI0 can very easily be enabled by pressing a button in the utility raspi-config. Access to others is obtained by editing the file /boot/config.txt and adding overlays.

I have raised an issue about this on the Pinout.xyz GitHub page (https://github.com/Gadgetoid/Pinout.xyz/issues/372). The problem, as noted, isn't that Pinout.xyz is wrong; it is simply that it's misleading.

So for our purposes, there is a software solution. However I have noted that the Raspberry Pi Forums seem to have a lot of entries about people struggling to get these overlays working and I don't believe that the OLED_Driver supports this extra bus out of the box, so there would be work needed there anyway.

[TerryJC]

So for our purposes, there is a software solution. However I have noted that the Raspberry Pi Forums seem to have a lot of entries about people struggling to get these overlays working and I don't believe that the OLED_Driver supports this extra bus out of the box, so there would be work needed there anyway.

I raised the above question about the nature of the SPI Bus(es) on the Raspberry Pi Forum and since I posted the above things have got even more confusing, since some contributors are claiming that six buses are available on the Raspberry Pi 4 and not on the Compute Module, which is at odds with other documentation.

What has emerged from all this is that there are probably two SPI Buses available on a Pi Zero, SPI0 with two Chip Select outputs and SPI1 with three CSs. However, as stated earlier, the OLED_Driver only has support for one Bus and one Chip Select line. I then looked at the Python Module Luma.OLED, (which I suspect Waveshare used to form the basis of their driver). This too only has support for one Bus and one Chip Select line. This is hardly surprising really, because most applications of the 1.5" OLED Module (or any other similar display) are unlikely to want drive multiple devices. Ours is a bit of a corner case I think. I have to say that I'm drawn to the hardware solution the more I look at it.

I need to establish whether buffering will be needed on the main bus lines too or if the fanout of the Broadcom chip can cope with up to four or five devices connected. As I understand it, the spec on GPIO pins is up to 16 mA per pin, with a maximum of 50 mA on all pins, so it will depend on the input current of the SPI Bus chip on the display devices. My next task is to attempt a design and will look at the fanout issue during this exercise.

[TerryJC]

So I've been looking into the possibility of using a hardware demultiplexer to control the CS (CE on the Pi) lines to enable multiple screens when we want to render an image on them. I've been unable to establish what the SPI interface chip is; Waveshare provide a schematic which simply defines the display module as a yellow box called oled1 and then mention in passing that the display driver is an SSD1327, but that has a parallel bus, so there must be an SDI / I2C interface chip in there too, but that isn't mentioned.

Having said that, I think that the fanout of the Pi won't be a problem. Looking at the electrical specs of various SPI Bus chips, the input currents appear to be in the low uA, so we could probably drive a few hundred without fanout issues (lots of noise issues though ).

I stuck a scope on the CS pin in on the display and got the trace below when an image is rendered.

Tiny_TV_CS_Line_During_Render.JPG (206.01 KiB) Viewed 1240 times

So the line is active low. Also, the CS line seems to be toggled a lot during each render, which slightly scuppers my original idea of asserting the CS line just before the data for a render is sent and then deasserting it when the render is complete. I looked at a few chips and looked initially at the CD4028B, which is a BCD to Decimal Decoder. By writing a 4-bit input, then up to 10 outputs can be asserted high; one for each input address. The problem is that we would then need to invert the signal and I'm not sure how we could pass the signal through to the required device unchanged. I've been looking at digital switches, but these all seem to be analogue switches (at least in the DIP package), so I'm unsure of the way forward at the moment.

I expect that we could develop a suitable demultiplexer using discrete logic in DIP package format, but I'd like to exhaust all the other possibilities before I go there.

[TerryJC]

It's not as hard as I thought! I'm using a CD4081 Quad Dual-Input AND package to gate the CE01 signal to up to four Displays.

Circuit to follow.

[TerryJC]

Attached is the first draft of the Tiny-TV Chip Select Multiplexer Circuit Diagram:

Chip_Select_Multiplexer_Circuit_Diagram_V0.1.png (172.6 KiB) Viewed 1232 times

Penri,

I have some CD4081 chips on order, but don't want to spend too much time on designing the Veroboard until I have some idea how you want to interconnect the screens with this module. The main uncertainty for me is the connector type.