DIY Tiny OLED I2C full graphics controller
Posted by enif
|
Re: DIY Tiny OLED I2C full graphics controller June 14, 2015 01:41PM |
No idea of sainsmart..Quote
Yellobello
no datasheet for the sainsmart display
I've a couple of 7pin SPIs namedQuote
Yellobello
The connectors are called CS,RST,DC,SCLK,SDIN,GND and 3,3V..
GND, VCC, D0, D1, RST, DC, CS
plus some datasheets...
Due to them CS isn't used with 4wire SPI, CS should be connected to GND.
D0 is (S)CLK, it must be connected LCD4 / EXP1-Pin5 (RRD schematic)
D1 is (S)DTA / DI / SID, it must be connected to LCDE / Exp1-Pin3 (RRD schematic)
DC should be connected to LCDRS !! / Exp1-Pin4 (RRD schematic)
RST is Reset and should be connected to VCC due to RRD schematic.
I'm using that wiring together with ATMega8A projects only, mostly for displaying 3 large digits.
Not for Marlin/Repetier for I would need glasses + loupe + microscope..
All my OLEDs are running from SSD1306 / SH1106 and need different commands/inits compared to ST79.. ones.
But U8GLIB should handle it, SSD1306 SPI is listed.
Have a look at at the fast version, its runnin' fine on my pro micros.
|
Re: DIY Tiny OLED I2C full graphics controller June 16, 2015 09:15AM |
Yesterday evening I had some tries with my OLEDs. at the moment, I2C is the best option, indeed.
My first problem was an actual marlin copy, it didn't compile.
It seems that it has not much to do with Marlin from spring 2014
((, my old I3 rework configuration.h sucks.
So I checked emotion tech / reprap France for a new version and found i3_rework 1.5.
This version is quite different to all other, too. But it compiles fine.
I2C is runnin' out of the box, only two declarations in configuration.h and dogm_lcd-implementation are needed.
With ISP I wasn't lucky, the Mega2560's "Standard" SPI Signals are not catched by RAMPS, they must be routed to other pins used by RAMPS.
For there exists a Reprap-Special-Version for the ST7920 named "ultralcd_st7920_u8glib_rrd.h" I guess we need a special version
for SSD1306-SPI-reprap too.
Edited 1 time(s). Last edit at 06/16/2015 09:16AM by bianchifan.
My first problem was an actual marlin copy, it didn't compile.
It seems that it has not much to do with Marlin from spring 2014
((, my old I3 rework configuration.h sucks.So I checked emotion tech / reprap France for a new version and found i3_rework 1.5.
This version is quite different to all other, too. But it compiles fine.
I2C is runnin' out of the box, only two declarations in configuration.h and dogm_lcd-implementation are needed.
With ISP I wasn't lucky, the Mega2560's "Standard" SPI Signals are not catched by RAMPS, they must be routed to other pins used by RAMPS.
For there exists a Reprap-Special-Version for the ST7920 named "ultralcd_st7920_u8glib_rrd.h" I guess we need a special version
for SSD1306-SPI-reprap too.
Edited 1 time(s). Last edit at 06/16/2015 09:16AM by bianchifan.
|
Re: DIY Tiny OLED I2C full graphics controller July 04, 2015 06:10AM |
Quote
n.glasson
It looks like the fix for the rotary encoder isn't quite 100% yet. I still find it works the wrong way in some places. For example when I am printing I can turn the speed up by twisting the knob upwards (at the front) when I am on the info screen, but when I select speed from the tune menu the knob needs to be twisted down to increase the speed...
Yes, you are right indeed! As I use my TinyOled just for checking the temperatures and adjusting the feed rate, I did not notice the problem with the value editing..
So here is a new attempt. It's again just a patch for ultralcd.cpp, but this time you need to add the line "#define SIDE_ENCODER" to your Configuration.h to activate these changes.
If SIDE_ENCODER is defined, it will reverse the direction of rotation of the encoder in general (which should affect all the encoder operations) and then explicitly revert (back) the menu rotation, because that should be left as it is in the front encoder (i.e. left -> down, right -> up).
--- ultralcd.cpp.ori103 2015-05-08 18:47:27.000000000 +0200
+++ ultralcd.cpp 2015-07-04 11:18:42.000000000 +0200
@@ -127,10 +127,18 @@
/**
* START_MENU generates the init code for a menu function
*/
+
+ // reverse menu direction for encoders mounted on the side
+ #ifdef SIDE_ENCODER
+ #define MENU_DIR -1
+ #else
+ #define MENU_DIR 1
+ #endif
+
#define START_MENU() do { \
encoderRateMultiplierEnabled = false; \
- if (encoderPosition > 0x8000) encoderPosition = 0; \
- uint8_t encoderLine = encoderPosition / ENCODER_STEPS_PER_MENU_ITEM; \
+ if (MENU_DIR*encoderPosition < 0) encoderPosition = 0; \
+ uint8_t encoderLine = MENU_DIR*encoderPosition / ENCODER_STEPS_PER_MENU_ITEM; \
if (encoderLine < currentMenuViewOffset) currentMenuViewOffset = encoderLine; \
uint8_t _lineNr = currentMenuViewOffset, _menuItemNr; \
bool wasClicked = LCD_CLICKED, itemSelected; \
@@ -204,7 +212,7 @@
#define MENU_MULTIPLIER_ITEM_EDIT_CALLBACK(type, label, args...) MENU_ITEM(setting_edit_callback_ ## type, label, PSTR(label), ## args)
#endif //!ENCODER_RATE_MULTIPLIER
#define END_MENU() \
- if (encoderLine >= _menuItemNr) { encoderPosition = _menuItemNr * ENCODER_STEPS_PER_MENU_ITEM - 1; encoderLine = encoderPosition / ENCODER_STEPS_PER_MENU_ITEM; }\
+ if (encoderLine >= _menuItemNr) { encoderPosition = MENU_DIR*(_menuItemNr * ENCODER_STEPS_PER_MENU_ITEM - 1); encoderLine = _menuItemNr-1; }\
if (encoderLine >= currentMenuViewOffset + LCD_HEIGHT) { currentMenuViewOffset = encoderLine - LCD_HEIGHT + 1; lcdDrawUpdate = 1; _lineNr = currentMenuViewOffset - 1; _drawLineNr = -1; } \
} } while(0)
@@ -220,7 +228,7 @@
uint8_t currentMenuViewOffset; /* scroll offset in the current menu */
millis_t next_button_update_ms;
uint8_t lastEncoderBits;
- uint32_t encoderPosition;
+ int32_t encoderPosition;
#if (SDCARDDETECT > 0)
bool lcd_oldcardstatus;
#endif
@@ -1510,8 +1518,13 @@
//manage encoder rotation
uint8_t enc=0;
- if (buttons & EN_A) enc |= B01;
- if (buttons & EN_
enc |= B10;
+ #ifndef SIDE_ENCODER
+ if (buttons & EN_A ) enc |= B01;
+ if (buttons & EN_B ) enc |= B10;
+ #else // for side encoders reverse rotation direction
+ if (buttons & EN_B ) enc |= B01;
+ if (buttons & EN_A ) enc |= B10;
+ #endif
if (enc != lastEncoderBits) {
switch(enc) {
case encrot0:
I have done some quick tests on my systems here, and so far it seems to work. But as I only use the very basic stuff here, more testing is certainly needed.
PS: Note that I changed the type of encoderPosition from uint32_t to int32_t. This seems to be the more natural type for this variable, and there are many int() casts that could be removed as well, in case someone someday decides to integrate this patch to a Marlin source tree. However, if someone sees a problem with this type change, or knows a good reason why encoderPosition needs to be unsigned, please let me know.
|
Re: DIY Tiny OLED I2C full graphics controller September 01, 2015 01:15PM |
Connector Borad for TinyoLED
www.hkmakers.hk
Edited 4 time(s). Last edit at 09/01/2015 01:24PM by fredchan.
www.hkmakers.hk
Edited 4 time(s). Last edit at 09/01/2015 01:24PM by fredchan.
|
Re: DIY Tiny OLED I2C full graphics controller September 24, 2015 11:58AM |
Firstly: Very nice work manQuote
enif
This describes a little DIY project I did for building a I2C based tiny full graphic controller using the SSD1306 128x64 OLED display.
This OLED display comes in two sizes, 0.96" and 1.3", and can be ordered on eBay for a few dollars. So far I only have the 0.96" version, but I have now ordered the 1.3" version. Fortunately, the SSD1306 interface is already supported in U8GLIB, so no programming is needed, just some configuation changes. Since the OLED display uses the I2C, only 4 wires (VCC, GND, SCL, SDA) are needed for the display itself. Add to that the 3 signals for the rotary encoder plus one signal for an (optional!) piezo buzzer, to a total need for only 8 wires. I found this especially useful for the Sanguinololu, where not so many additional pins are available.
Other advantages of the OLED display are that is really bright, does not need any fiddling with the contrast, only draws a total current of about 8mA and, last but not least, works with either 5V or 3.3V supply and signals - the latter being particularly interesting for ARM based controller boards.
For building the controller you need the following:
- an SSD1306 I2C 128x64 OLED display (available as 0.96" or 1.3" versions)
- a rotary encoder with integrated click switch
- a piezo buzzer (optional, just for audible feedback of click)
- a piece of prototype PCB board (about 1.5"x2.5" is enough)
- some wires and pin headers
Here first the schematic how I wired the components and connected them to either RAMPS or Sanguinololu..
The modifications to Marlin are only minimal changes in the files Configuration.h, Conditionals.h, dogm_lcd_implementation.h, pins_SANGUINOLOLU_11.h and pins_RAMPS_13.h. The attached patch file contains all the changes needed to the current version 1.0.3 of Marlin.
For those wanting printing from an SD-card (I don't), it is easy to add one of these cheap SPI based micro-SD modules that can be ordered on eBay for less than 2$, since the standards SPI pins used for the SD-cards are left untouched by the OLED display. Here pictures of my test using the tiny OLED controller together with an micro-SDcard module, on both RAMPS and Sanguinololu:
I know, buying a ready made 2004 or full graphic LCD controller is so cheap today, that you won't save any money by building things yourself. But that was not my aim for this project, rather my goal was (other than the fact that I really like tinkering) to have something really small, need only a minimum of cabling, draws only little current and is also working on 3.3V...
Anyone got it to Work with the new Marlin firmware, where the "Conditionals.h" file no longer exists?
I got it to Work successfully with previous versions of Marlin, but I can't seem to get it to work with the new layout.. anyone had any luck at this?
Sorry, only registered users may post in this forum.