suggestion for multiple 0.96" OLED (Radio/Nav panel)

Status
Not open for further replies.
M

Mike554

Member
Hello Everyone,

I am looking for some advice on using multiple OLED's in a project (at least 8 x 0.96" displays).

Ultimately, the project will be a cessna style com/nav/adf/ap stack using a Teensy in Flight Sim 'mode' (what a combo by the way, X-Plane 11, Teensy plugin and Teensy - absolutely marvelous). I have prototyped Nav/Com using 7-Seg LEDs and it works fine but the displays are large and difficult to panel mount tightly so the final project is taking up too much space (I am not looking to replicate a cockpit - just abstract away from using mouse/mouse wheel in the sim). After that I would like to use the same type of displays (and experience gained) to make a 757 style autopilot MCU / Radio stack. Of course, Teensy based!

I managed to get a few cheap 0.96" OLEDs from Amazon that use I2C but all have the same address and no obvious way to 'chip select' (4 wire only Vcc Gnd, Sda Scl)
(https://www.amazon.co.uk/gp/product/B07BDFXFRK/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1). The form factor is perfect but reading through various library docs suggests using more than one of these will cause issues, if it is possible at all.

Could anyone suggest the best way to plan this project or suggest what OLED module to use (the 0.96" seem limited but they fit perfectly). Should I use SPI displays or some other protocol? Is this achievable with one Teensy or should I look to have a micro per display (maybe a nano or LC connected by serial/SPI/I2C to the controlling teensy?) or should I just wait until libraries catch up with using multiple OLEDs.

Sorry for asking such a mundane question. I always find my way through code eventually but find selecting hardware a nightmare ;) My coding ability is OKAY but bit bashing and the like is beyond me.

As a separate question, is it appropriate to submit a final project to this forum for review/suggestions/criticism. My prototype Nav Panel works but I'm sure it the code could be refactored and then it may be useful to others?

Love the Teensy, thanks for all the hard work making it so accessible to folk like me ;-)))

Mike
 
There are probably several ways to solve this problem:

1) You could get an i2c multiplexer. I haven't used it, but this one seems pretty simple. You can hook up to 8 devices to it, and then you write a byte the i2c address (usually 0x70, but it can be switched with solder jumpers) and it will switch which device gets the i2c traffic (note, while I'm in the USA, I'm using amazon.co.uk to give you a UK shipper):

2) In theory, you should be able to use multiple SPI devices. Some SPI devices have problems with multiple devices on the same SPI bus and may need either pull-up resistors on the CS pins or tri-state buffers. Note, some of the OLED drivers have special support for using the Teensy fast CS pins (2, 6, 9, 10, 15/A1, 20/A6, 21/A7, 22/A8, 23/A9). You might want to not use any of those pins since you will have multiple devices.

3) You could use the dig-ole displays. These displays have their own microprocessor, and have a library (IIRC, there was a simple modification you needed to enable compilation on Teensy). These displays have a library command to change the i2c address, which you would need to do once per device. I've only used a single display hooked up with a serial port, so I've not used the i2c route. There is a solder jumper you need to adjust to use with SPI, i2c, or serial port. Dig-ole also has color OLED, mono TFT, and color TFT displays in various sizes.

4) If the displays are all near each other, you could use a single larger display, and use some wood/cardboard to overlay parts so it looks like separate displays.

5) If you have a Teensy 3.6, you could use all 4 i2c ports, and then switch between the default and alternate ports to get 8 separate i2c devices. But there you would need to clone the library, and it seems like an awful amount of work compared to using an i2c multiplexer.

Note, for the common OLED i2c or spi 128x64 displays, you will need about a 1K of memory to hold each of the screen images (i.e. 8K for 8 displays). If you get color displays, you will need much more memory. The dig-ole displays have the buffer in the display, so you don't need to have a copy of the screen contents in your memory.

For 8 displays, you might need to think about how to power the displays and the Teensy (i.e. it might be too much if you hook all of the displays to the Teensy's 3.3v bus). You might need a separate 3.3v voltage regulator to feed the displays and use a common ground.
 
Hello Michael,

Thanks for the comprehensive (and quick) reply.

Answer 1) (I2C multiplexer solution) did not know these existed so thank you (and for the link to UK seller, most thoughtful of you). A quick read and 'intuition' lead me to believe this may be the solution.

Answer 2). I think this beyond my skill set. I prefer to let the clever people do the theory and then, at least, I know I don't understand it when things go south. My electronic ability is below average, improving very slowly despite lots of head banging on desk;-)

Answer 3). Dig-Oled. Okay, another few hours reading required as this sounds like a possible/probable solution. Thanks for the lead! Your answer has also told me I do not know enough about the different types of OLED/OLed modules so I'll hit google hard tonight!

Answer 4). Yes, the easiest approach for sure except the physical form factor, the housing will be about 1.5" high by about 14" wide and will be jammed with rotaries and switches. This is why the tiny 0.96" OLED appeal - easy to have the 'value' displayed physically next to the rotary knob. It's a shame they have not invented cuttable displays yet:rolleyes:

Answer 5). Agree, The multiplexer solution seems a 'proper' way to do things. Diddling with Libraries seems a bit hacky and less useful to others. My coding is okay but I can easily tie myself up in knots for days on end.

I have ordered the multiplexer, it should arrive Tuesday (again, thanks for the link!) so I have a positive first step, excellent!

Thanks, I will put in seperate power for the displays.

Regarding memory, I don't think having a buffer would help in this instance as the value is numeric only and read once per loop. the panel will read data from X-Plane via Pauls Plugin, it will update displays in hardware if they change in the sim and in the sim if changed in hardware. I'v sloppily prototyped (using LED 7 Segs) on a LC have plenty of memory left over but will add this to the watch list for sure (I could just buy a 3.6 but then all those spare IO would just have to be found jobs ). I think I am missing the point on buffers actually ... font must need memory etc (more reading tonight).

Thanks Michael, I'll post back and let you know how I get on.

Mike
 
Last edited:
In the normal 128x64 OLED devices, the microprocessor has to keep an entire image of the whole screen in memory. When you write text or draw lines, the routines update the in-memory array. When you issue the command to update the screen, it writes the whole image in memory (or possibly only updates the region that you modified in the last cycle). On small memory processors, this would be an issue, in that the ATtiny85 only had 512 bytes of memory, and the 328p used in the Arduino Uno had 2K (i.e. one display would take 1/2 of the memory). As long as you don't use a Teensy LC, the 8K for 8 separate displays might not be an issue (the 3.2 has 64K of SDRAM, while the 3.5/3.6 have 256K), but just in case you had the memory filled with other things, I thought I would mention it.

The dig-ole devices has a microprocessor in it, and a slightly higher protocol. Instead of just sending over the big image, instead you would send over the text or the commands to draw the lines. So, it should be faster to update each of the screens.
 
Good Morning Michael,

Okay, I understand the memory usage potential issue now. I have had my head in 7-Seg LED territory for a few day and just assumed the OLED would take a few bytes or an INT or String in similar fashion. So thanks for making me aware, I think I might change boards to a 3.2 or 3.5 - I'm on LC at the moment. Unfortunately, I am VERY guilty of project creep, so a bit more RAM won't hurt.

Hopefully, the multiplexer will arrive tomorrow so I can make a start with the displays I have and see if they pan out. It's a shame the dig-ole people don't make a 128*32 display. The 128*32 0.96" displays are just the perfect form factor for my project so a bit of head banging will be worth it in the long run ;-)

Thanks again for pointing me in the right direction!

Cheers
Mike
 
You'll be happier with the T3.x series. If you go with the 3.5/3.6 you'll have 3 dedicated hardware SPI busses and faster performance :)

Also you have 3 I2C busses on 3.5 and 4 on T3.6, T3.2 only has 2. If you put on multiple oleds (i2c?) that have same address, you can put them on a separate bus and not need a multiplexer (essentially things may run faster/efficient)

If you are feeling brave, you may also be able to use the ALTernate pins to switch the display pin busses when updating the oled. (feeling lucky? :) )

Glimpsing the pinout card on the T3.6 with 4 hardware I2C busses, you could essentially dive into .... wait.... I SEE 8 ! :)

pin 3,4 Wire2
pin 7,8 Wire
pin 18,19 Wire
pin 16,17 Wire
pin 37,38 Wire1
pin 33,34 Wire
pin 47,48 Wire
pin56,57 Wire3

Note, if you try to hurdle this, make sure you finish your I2C transfers then you can use Wire.setSDA/setSCL to change the hardware pins, to write to next display
All I2C busses do require a pullup, as the internal ones are insufficient for use.

Tony
 
Last edited:
Hello Tony,

Many thanks for the reply!

In fact, I have just ordered a 3.6 to play with ;-) Most of my projects are nano based and given the fact I am so impressed with the LC I think I'm going to make a conscious move to Teensy boards - it's about time I updated ;)

Many thanks for the suggestions about using 4 (or 8!!) I2C buses for this project. My plan is to stick with the multiplexer and LC, the reason being I just want to learn a bit more about using different hardware expanders (I have always shied away).

That said, I have a large future project that, up to now, has seemed too fiddly and complex. I can now see using multiple I2C buses AND expanders would give me the capability not only for sensors etc but to organise things logically (manage my own confusion!). So learning how to do multiplexers seems a good start as I have them arriving tomorrow I hope! Then I come back to these ALT pins!

Thanks for the Pullup tip - I would have missed that and assumed the internal pullup would be working while blaming everything else (Amateurs hey LOL).

Thanks for the reply Tony! Stay warm over there in Montreal (even colder than Scotland!)

Mike
 
Status
Not open for further replies.
Back
Top