SSD1306 I2C with Pic16f1937!

[jgu1]

Hi!

I can not compile this tiny program to the Pic. Get the error not enough space for the SSD1306.

What am I do wrong please

Br Jorgen

[chipfryer27]

Hi Jorgen

My 1306 is one of the small versions, half the size of yours (64 x 32) and this compiles OK. However using your chart with my display, the Memory Summary shows:-

Memory Summary:
Program space used 94Ah ( 2378) of 2000h words ( 29.0%)
Data space used 194h ( 404) of 200h bytes ( 78.9%)

Guessing if you need to use a 128 x 64 display you will need a chip with more Data space.

Regards
PS
I usually use it on an ESP32

[jgu1]

Thank you Chipfreyer!

Ok with the space, I though when this display work fine with an Arduino Nano it also could work with this " powerfull old boy" Pic 16F1937.

I would exchange the LCD display to the SSD1306 in an other project I have. I try to find a (64 x 32) display, and yes, ESP32 handle everything

Thanks jorgen.

[chipfryer27]

Hi Jorgen

My mistake, I'm using a 128 x 32 display and If you look in the usual markets for a "0.96 inch OLED" you should get quite a few options for them. I've found them to be quite useful.

Regards

[BenR]

Hello,

The 512 Bytes of RAM on the 16F1937 is the limiting factor here, the display needs a RAM buffer to be able to work correctly and (128x64)/8 = 1024 Bytes of RAM at a minimum.

The PIC16F18877 is pin compatible and has 4KB of RAM available so could be an option.

You can drive the display without a RAM buffer but the functionality gets very limited without corruption on the display.

[mnfisher]

It might be possible to use a character mapped approach.

See https://flowcode.co.uk/forums/viewtopic ... ter+mapped

Martin

[jgu1]

Martin, Ben and Chipfreyer!

Thank you all I think I will use Ben´s suggest, easy´st for me

Br Jorgen

[mnfisher]

For 'fun' I made a minimal character mapped display for the ssd1306. It is not designed to be fast - but for those times when you want to get some data out of a MCU with minimal resources - it might be just the job.

It is 'stripped back' - so it only allows strings to be printed - and although it 'offers' a choice of 'y' it only prints to 4 rows (in the case of a 32 pixel display) (So y = 0..7 will print to first row, 8..15 2nd row etc) It would save a few instructions to just have y = 0..3? (or 0..7 for a 64 pixel display)

As it stands - the character set itself is 768 bytes. I think that restricting this to upper case characters only would be a useful saving too (whilst still allowing numbers etc) By limiting it to ascii characters 32..90 would save a lot of flash. (And for the really small MCUs maybe XYZ could go too - who uses them anyway?)

Jorgen - please could you test with your PIC? If I cam find one I'll try an ATTiny13.

With my display it 'chokes at 400kHz on the i2c - it could be sped up a little by sending all 8 bytes of a character as a single transaction but it would entail a 9 byte buffer - or poking 0's into the lookup table before each character.

ssd1306_min.fcfx

(32.43 KiB) Downloaded 265 times

Martin

[jgu1]

Hi Martin!

Wow But honest I dont understand your program. So far I use the Arduino.

I am not home at the moment, but at the end of the week I perform a test on a Pic device, you hear.

Thank´s

Jorgen

[BenR]

Great work there Martin,

It would be nice if we could somehow force the mono GLCD components to be in a simple mode where only text is available to forgo the need for a buffer unless you actually want it. I'll add it to my list of things to ponder over

Could be there are seperate components but this seems a bit overkill.