Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] initial SSD1306 OLED display driver #8336

Closed
wants to merge 1 commit into from
Closed

[WIP] initial SSD1306 OLED display driver #8336

wants to merge 1 commit into from

Conversation

dagar
Copy link
Member

@dagar dagar commented Nov 22, 2017

Not functional yet.

#6231

@dagar dagar added this to the Release v1.8.0 milestone Nov 22, 2017
@dagar dagar mentioned this pull request Nov 22, 2017
@dagar dagar force-pushed the pr-ssd1306 branch 3 times, most recently from d30ff01 to 1a487de Compare November 22, 2017 07:41
@LorenzMeier
Copy link
Member

Cool!

@tubeme
Copy link

tubeme commented Nov 27, 2017

Waiting... I prepared 2.4 inch one for tests...

@dagar
Copy link
Member Author

dagar commented Nov 27, 2017

Which screen size is everyone interested in? The driver either needs to be geared towards a particular model, or the dimensions need to be parameterized.

@tubeme
Copy link

tubeme commented Nov 27, 2017

The size does not matter in 1306 because all of them are 128x64. Mine just shows bigger letters and graphs then let say 0.96". For me 0.96" is unreadable because since 2 years I wear glasses for reading :) without them the 0.96' looks like noise haha.

@edsellar
Copy link

I have both sizes in front of me and while the 2.4" is definitely bigger, I'm trying to think of where the larger one could be put on my multi or plane without being in the way. Can have almost 2 of the smaller screens. Looking at this to make sure things are kosher preflight etc is likely the intended use and the ~1" screen I can squeeze into a lot of places. I would think more people would want to not take up too much real-estate. Just my 2¢ but in the case that the driver is independent of screen size then that is good, I still think 1" is more "manageable" but I understand the small text concern.

@tubeme
Copy link

tubeme commented Nov 29, 2017

@edsellar My point was that the size does NOT concern the driver work, because all of these displays are the same resolution 128x64 dots. There are 0.96", 1.3" and 2.4" for now and all of them show exactly the same graphics and text, just with a different physical size. If you put a 2.4" on a larger plane (3+ meters wingspan) there is plenty of space to fit them somewhere. I agree with the small planes and MCs you could use 0.96"

@edsellar
Copy link

edsellar commented Dec 8, 2017

@tubeme that’s great then! If driver work is completely agnostic of true board size due to same resolution then given we aren’t using these for their beauty capabilities, it’s win win. I’m looking forward to it and will def put the smaller in multi and larger anywhere I can fit.

@ryanjAA
Copy link
Contributor

ryanjAA commented Jan 7, 2018

Just built and tried. I2c conflict. 0x78 says connected when not. Will need to change solder pad to 7A on physical board or locate conflict and reassess.

@ryanjAA
Copy link
Contributor

ryanjAA commented Jan 26, 2018

Changed address to 0x7A on both physical unit and driver and rebuilt. No text/non-operational.

@ryanjAA
Copy link
Contributor

ryanjAA commented Mar 29, 2018

Needs added library for pixel to character. Currently init is functional and will drawn line (thanks to @dagar).

@dagar
Copy link
Member Author

dagar commented Mar 30, 2018

Rebased on master.

@dagar dagar removed this from the Release v1.8.0 milestone May 4, 2018
@stale
Copy link

stale bot commented Jan 20, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale
Copy link

stale bot commented Feb 4, 2019

Closing as stale.

@stale stale bot closed this Feb 4, 2019
@mijarck
Copy link

mijarck commented Aug 16, 2019

No support for this in visible future?

@dagar
Copy link
Member Author

dagar commented Aug 16, 2019

@mijarck the basic driver works for drawing pixels and lines to the screen. It still needs a small library for handling characters (fonts, etc).

@mijarck
Copy link

mijarck commented Aug 16, 2019

Ok, good to know. Was just interested to know about the support on PX4 if could get battery and pre-arm state easily visible, but there’s other ways to solve the issue too.

@ryanjAA
Copy link
Contributor

ryanjAA commented Aug 16, 2019

I’ve been wanting this for years. I think it’s a great idea to isolate yourself from needing a computer and have more info than the led or red button can provide.

Sat info
Armed status errors
Etc would be helpful for people.

This is the cleanest solution I can see since reliance on a remote control is diminishing greatly.

@julianoes
Copy link
Contributor

@dagar you should get your stuff in 😄

@stale
Copy link

stale bot commented Nov 17, 2019

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@stale stale bot added the stale label Nov 17, 2019
@dagar dagar closed this May 6, 2020
@bys1123
Copy link
Contributor

bys1123 commented Nov 5, 2020

Any new update?

@LorenzMeier LorenzMeier deleted the pr-ssd1306 branch January 18, 2021 14:31
@Phillweston
Copy link

Any new update?

@ryanjAA
Copy link
Contributor

ryanjAA commented Mar 30, 2021

Actually @AlexKlimaj did a driver for it but it needs backend or expansion done if you want it to work similar to how Ardupilot has it subscribing to data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants