teensey 3.2 n OLED screen

Status
Not open for further replies.

Opelnut

Member
Is it possibly to connect the oled screen to the Teensey wireless? What would be needed?
I know I would need a battery source for the teensey and another one for the oled. what I can quite figure out is what transceiver would work good for this. Range is aprox 10 meters


this is the oled I would like to use. right now it recieves its SPI data by wires and I would like it wireless with the least number of parts and code


Thanks
Adafruit Junkie for the moment
 
Google for Teensyview. That's an OLED with a breakout board which can directly be stacked on the Teensy with common power supply. A simple to use library comes with it.

BUT... FORGET ABOUT 10m!!! SPI is a short distance data bus (as is I2C). These aren't designed for such a long wiring which represents too much capacitive, resistive and inductive losses. If you'd really have to span that distance, you'd need 2 Teensys, linked by Ethernet. One as the sender, and another as receiver and display driver.
 
There is no direct wireless protocol for SPI. You'll have to transmit data over a different protocol (wired or wireless) and have a second Teensy as a receiver/decoder and display driver.
 
You have one Teensy as a sender where code decides what to display on the OLED, for example the text "Welcome" at screen position 20,0 with the help of the OLED library. This would be rendered to a frame buffer in memory which is a mirror in pixels of what the display should show. If the distance were short (a few cm), you could use the OLED library to write the frame buffer out to the OLED via SPI to refresh and update the screen. That's how things work normally.

For longer distances, you'll have to break that up and send the frame buffer content over Ethernet (Serial is too slow) instead of SPI to a second Teensy which would receive that data block, create a copy of the frame buffer from it, and finally send it over SPI (since this is the only protocol the OLED understands) to the display.

So instead of the classic Teensy -> frame buffer -> SPI -> OLED, you'd do Teensy -> frame buffer -> Ethernet -> 2nd Teensy -> frame buffer -> SPI -> OLED.

Please don't expect to find ready to use libraries for that relatively rare use case, you'll have to break off the OLED SPI library and add code from an Ethernet library. It sounds challenging, but it's for sure a great learning experience!
 
The RFM12 with a data rate of 128kbps (or 256kbps) is ways too slow. To get a fluid screen refresh, you need a data rate of at least 1Mbps. Modern SPI display drivers support data rates up to 6Mbps. And Ethernet can do that, even over the air. Ever heard about Wifi?

SPI itself is, as I said, a transfer protocol for short wires (inside PCB). It has no checksum, no error correction, to re-transmit request in case of corrupted data. Thus, it is not suitable (as is) for wireless transmission. You'll have definitively to pack the data and make it ride onto a different protocol. These are telecommunication basics which EE students learn in the first year...
 
Opelnut,

Depending on your application, you could possibly use one Teensy to send the raw data via RF to a second Teensy that actually generates the display images which is wired to the SPI display. This would greatly reduce the bandwidth requirement of your RF link.

A very well supported radio module is the Nordic nRF24.
A pair of bluetooth modules would also work, and opens other possibilities like using your cellphone as a display device.
 
Last edited:
To me, it is hard to give a complete answer as not knowing your actual needs...

As mentioned there are several options for nRF modules. I know that Sparkfun/Adafruit... sell several different ones. There are often specific libraries for each type as well as libraries like Radiohead (which teensyduino installs), that can handle several different types.

As mentioned you could use bluetooth modules or XBees or...

As for speed of these interfaces? Hard to know how well any of them will work for you. If you are thinking that you wish to encode the actual SPI or I2C communications like it was going direct to the display and send that... Maybe none of these will work fast enough. On the other hand you are setup that the remote Teensy controls the I2C/SPI of the display and simply listens for some specific data from the host, like a new string to display or a new value for some field, that may change at some reasonable rate, than it would not be hard to simply setup some protocol between the two and send the data...
 
I want a wirleess Video display for a teensy that will will be displaying a picture with some occasional Video (moving picture) the Distance is between 5 to 10 feet. was hoping there was no encoding/decoding of SPI on my part. Not good at software so was hoping there was a hardware Solution. will google bluetooth/ xbees and continue my search.
 
You'll need a receiver that supports SPI Master mode to talk to the display controller. Possibly an ESP8266 or an ESP32 can do that but there will definitely be some software development involved to do this.

For a truly direct wireless SPI link to a display module which receives information only, you will may only need to send the MOSI and SCLK signals from the Teensy.

There may be some clever way to not need to send the SCLK signal by synchronizing the SCLK signal with a remote oscillator but it would need to be very precise.

Please let us know if you find a solution as this is an interesting problem.
 
Use wires: SPI can travel 10 feet if done carefully

You can get 10 ft with wires. We have done this with the small ILI9341 touchscreen and a custom board. Our Teensy is on a control board which is in an awkward place in a metal box and we needed to plug a display in and have a cable of at least a few feet.

We slow the SPI down to the data sheet rate for the ILI9341 which is something like 10 MHz for SPI clock. I can't remember exactly but we have test code for this on Github.

This is not easy to achieve! We used a 10x2 .050 spaced ribbon cable, with alternating gounds, and series impedance matching resistors... the cable impedance is about 100 ohms. We used 74HC125 drivers. There is a local 3.3V regulator on the remote touchscreen board, fed by 5V from the controller board. I have tested with 10 feet of cable. It works well with decent signal quality and timing margins. We more commonly use 3 feet of cable in other applications and have hundreds of hours of flawless operation with that length.

This took careful PC board layout, etc. It's not a trivial design. It took us two board turns to get it right. The first attempt had a 16C cable and there was too much signal crosstalk. We used the 3.2" resistive touch displays from BuyDisplay.

You asked for wireless: a lot more work just to get 10 feet. Wires were hard enough for us.
 
You asked for wireless: a lot more work just to get 10 feet. Wires were hard enough for us.

Again Design needs to be wireless but thanks for the info that does provide some info about why the long WIRED connection was a problem and why we want a WIRELESS SOLUTION... I think WiFi will provide part of the answer 2.4 or 5.8. should have acceptable bandwidth for our application
 
Status
Not open for further replies.
Back
Top