I haven't had time to test this yet. -Mike
On Monday, September 7, 2020 at 4:14:34 AM UTC-4, Rob CJ wrote: > > Hi Mike, > > Thanks for the clarification. Just to be sure that I understand this > correctly. You mentioned that the module pulls-up the level to 3.3. Volt. > Since I am also using the module at 5 Volt, does that mean that I should > not use any pull-up resistors to 5 Volt but leave it open and rely on the > module to pull the levels up to 3.3. Volt? > > I can imagine that pulling the IIC pins up to 5 Volt may destroy the > SSD1306. > > BTW. I did not yet receive an e-mail that a new bee-package was created. > If you want an update of the SSD1306 library, let me know. > > Kind regards, > > Rob > > ------------------------------ > *Van:* 'Mike' via jallib <[email protected] <javascript:>> > *Verzonden:* zondag 6 september 2020 22:08 > *Aan:* jallib <[email protected] <javascript:>> > *Onderwerp:* Re: [jallib] Re: JAL Library for SSD1306 graphic display > module. > > Hi Rob, > > Here's some more information, if that helps, regarding the I2C/SMbus > levels. The datasheet for the PIC12F1840 (Section 30.4, param D041) > indicates that VIH for I2C levels is 0.7VDD, which is 3.5V if VDD is 5V. > And VIH for SMbus levels is 2.1V for the VDD voltage range of 2.7V to > 5.5V. Herein must lie the problem. While the SSD1306 OLED displays are 5V > tolerant, they run at 3.3V. I hooked up my oscilloscope to check and, yes, > the bus is idling at 3.3V (pulled-up by the OLED). > > So SMbus levels are correct for these displays, at least the two SSD1306 > displays that I tested. The times that I used I2C levels and it worked was > just luck...If the VDD happened to be low, like 4.8V (which I know my > PICKit2 is) then 4.8 x 0.7 = 3.36V. That, plus a little forgiveness by the > PIC would account for it. But, of course, not advisable...a.k.a. "skating > on thin ice". > > Regards, > Mike > > On Sunday, September 6, 2020 at 5:21:20 AM UTC-4, Rob CJ wrote: > > Hi Rob, Mike, > > I fixed the SSD1306 library with the following changes: > > 1) When the device is initialized, the display is turned on AFTER the > screen is cleared. > 2) You can select a display using 128 x 32 instead of the default of 128 x > 64 by setting: const SSD1306_Y_32_PIXELS = TRUE > 3) About the SMB levels, if the main program defines: const bit _i2c_level > = FALSE then it will use the SMB levels, if nothing is defined it or the > variable is set to TRUE uses the IIC levels. > > I updated this version and the updated sample files to GitHub so it should > be in the next bee package. > > I do not have a 128 x 32 display but when I select that, the resolution is > half so I assume it works OK. > > Kind regards, > > Rob > > > ------------------------------ > *Van:* [email protected] <[email protected]> namens Rob > Hamerling <[email protected]> > *Verzonden:* zondag 6 september 2020 10:36 > *Aan:* [email protected] <[email protected]> > *Onderwerp:* Re: [jallib] Re: JAL Library for SSD1306 graphic display > module. > > > Hi Rob, > > On 06/09/2020 10:01, Rob CJ wrote: > > > I could set it FALSE by default in the SSD1306 library. I could also > remove the include of the IIC library at all from the SSD1306 library so > that it has to be included by the main program and the user can set it > there. I tried to make life simpler by including the required IIC or SPI > libraries in the SSD1306 library. > > I am not sure what the best practice is, suggestions are welcome. > > With I2C you can have the choices: > - idle state of CLK signal high or low > - data capture on first or second clock transition (either can be > falling or rising) > It depends on the implementation of the slave which combination is > appropriate. > So I would think that the choices should be made in the SSDD1306 library. > > However, the datasheet of the SSD1306 (fig 8-6) shows that data capture is > on the rising CLK signal, but it seems not to care about the CLK idle > state. When CLK-idle is low then data capture is on the first CLK > transition, when CLK-idle is high then it is on the second transition. So > it is somewhat difficult to decide which are the right choices! > > Regards, Rob. > > > > -- > *Rob H*amerling, Vianen, NL > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/d557b65f-61ee-9fd2-7da6-6ae1d0ab69ef%40gmail.com > > <https://groups.google.com/d/msgid/jallib/d557b65f-61ee-9fd2-7da6-6ae1d0ab69ef%40gmail.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/1efccce8-00a6-420d-ae47-9f06e676f154o%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/1efccce8-00a6-420d-ae47-9f06e676f154o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/b0b7dcb6-42e9-44cf-ad42-f5b22e9c75c8o%40googlegroups.com.
