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

Add support for SSD1306-based OLED I²C displays (monochrome, up to 128x64 pixel) #245

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
2 participants
@kainhofer
Copy link
Contributor

kainhofer commented Dec 29, 2017

  • Class DisplaySSD1306(node_manager, dev, i2caddress) added
  • One string child (display caption, by default written in double font size)
  • Customizable (also remotely via SensorConfiguration): Font size, caption font size, rotation (0/180 degree), contrast, inverted display
  • Customziable (NOT through SensorConfiguration): Display caption text (Request does not support strings) => one has to hard-code the optional display caption in the sketch...
  • By default, all names and values of ALL sensors+children of the node manager are displayed.
  • To show different text on the display, one has to sub-class DisplaySSD1306 and re-implement _display(const char*captionstr = 0)
  • Added virtual function printOn(Print& p) to the Child class and its subclasses, since this was the only clean way to display the child's value to the display (or more generally to any Print-derived class, like Serial, SoftwareSerial, this OLED display, etc.)
  • Base library is the very light-weight SSD1306Ascii library, which does NOT use a display buffer and is meant only for text. (Other SSD1306 libraries use a display buffer, which requires at least 1024 bytes of SRAM, which is not available with NodeManager on lower-end arduinos).
    o) Drawback is that one has to make sure that each line is written to the very end. So instead of
    _oled->println(F("Text"));
    one needs to use
    _oled->print(F("Text"));
    _oled->clearToEOL();
    _oled->println();
    Otherwise letters on screen are NOT erased in that line.
Add support for SSD1306-based OLED I²C displays (monochrome, up to 12…
…8x64 pixel)

- Class DisplaySSD1306(node_manager, dev, i2caddress) is added
- One child (display caption, by default written in double font size)
- Customizable (also remotely via SensorConfiguration): Font size, caption font size, rotation (0/180 degree), contrast, inverted display
- Customziable (NOT through SensorConfiguration): Display caption text (Request does not support strings) => one has to hard-code the optional display caption in the sketch...
- By default, all names and values of ALL sensors+children of the node manager are displayed.
- To show different text on the display, one has to sub-class DisplaySSD1306 and re-implement _display(const char*captionstr = 0)
- Added virtual function printOn(Print& p) to the Child class and its subclasses, since this was the only clean way to display the child's value to the display (or more generally to any Print-derived class, like Serial, SoftwareSerial, this OLED display, etc.)
- Base library is the very light-weight SSD1306Ascii library, which does NOT use a display buffer and is meant only for text. (Other SSD1306 libraries use a display buffer, which requires at least 1024 bytes of SRAM, which is not available with NodeManager on lower-end arduinos).
    o) Drawback is that one has to make sure that each line is written to the very end. So instead of
          _oled->println(F("Text"));
       one needs to use
           _oled->print(F("Text"));
           _oled->clearToEOL();
           _oled->println();
       Otherwise letters on screen are NOT erased in that line.
@user2684

This comment has been minimized.

Copy link
Contributor

user2684 commented Dec 31, 2017

Great PR, something like this was in the queue since a while (#95). My plan was to kind of add hook functions to let each sensor displaying its own text but this approach is way better. In the future we can even think of associating for each sensor/sensor type a unit so it will be displayed together with the measurement.

What about making const DevType* dev and uint8_t i2caddress with default values? In this way a new user could create the instance in a simpler way.

You are saying that Request does not support strings and this is true but only since #229 to save some storage since never used so far. I have no problem in taking it back if needed.

Btw, I probably merged your PRs in the wrong order causing some conflicts, let me know if you need any help in fixing them. Thanks again!

@user2684

This comment has been minimized.

Copy link
Contributor

user2684 commented Dec 31, 2017

Or better, just wait for #251 to be completed before fixing the conflicts to avoid doing the job twice. Thanks!

@user2684 user2684 referenced this pull request Jan 1, 2018

Merged

Architecture review (2) #251

@user2684

This comment has been minimized.

Copy link
Contributor

user2684 commented Jan 1, 2018

Hi, I tried to save you some time by merging manually this PR into #251 (de5040f). I've added setter methods for _dev and _i2caddress and assigning those variables a default value so removing them from the constructor. Have a look if everything is in order, thanks!

I also checked the old implementation of Request::getValueString() but taking it back into the code is a bit more complex than I thought: Request was storing the value as a char* and now as a float so I am a bit afraid every new string received from the remote API would have an impact on the memory but if you could find a good way to handle those situations, feel free to get it back! Thanks again!
Closing this PR, feel free to reopen/submit a new one if something would not work as expected after those changes. Thanks

@user2684 user2684 closed this Jan 1, 2018

@user2684

This comment has been minimized.

Copy link
Contributor

user2684 commented Feb 11, 2018

Fixes #281

@user2684

This comment has been minimized.

Copy link
Contributor

user2684 commented Feb 24, 2018

This PR went through a few changes through #286. A new Display class has been added and this class has been re-adapted into the new architecture. No major changes for the class itself of course

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.