I've been using GCBasic for the last 8 years. Thus far it's been able to do everything I wanted. I recently purchased several I2C OLED displays on eBay which use the SSD1306 controller. I'm using a PIC18F2420 for testing purposes. I slightly modified one of the demo programs. I know the 18F2420 doesn't have enough RAM, so I reduced the buffer size to 400 bytes. I had read elsewhere that this will at least allow some lines on the display to work. Unfortunately, nothing works. I'm getting a sine wave on the crystal but all the other outputs are inactive. I even put some test LEDs which should light up if the main program is running but they don't. The I2C lines remain high all the time. Basically, it looks like the PIC isn't running the program at all (or it's locking up beforehand). I even tried it using the internal oscillator instead of the crystal. Same result. The microcontroller works fine when I load other programs.
Any insight would be appreciated. The program compiled with no errors. Here is the full program:
GCB needs to know what the final Mhz value of the clock is including the PLL. So for say a 10Mhz ext osc it would be #config 18f2420, 10 or #config 18f2420, 40 with the 4x PLL. Values over 10Mhz with the PLL enabled seem to be operating outside the 18f2420 parameters. This is the case with the more vintage 18f's, while the 18fxxk20 and 18fxxk22 devices can go up to 16Mhz with the PLL for a 64Mhz clock.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For what it's worth I not only tried it with the internal oscillator, but I also tried software I2C, and both slave addresses (0x78 and 0x7A). Same results each time. The I2C lines remained high and it looked like the PIC was either locked up or just not initializing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made some progress. I determined that hardware I2C isn't working properly with the 18F2420 for some reason so I tried software I2C (I forgot to set the ports as inputs last time I tried software I2C). This time instead of limiting the buffer in the SSD1306.h file I changed the chip number to PIC18F2520 which has 1536 bytes of RAM. Surprising, the resulting hex file worked mostly OK when loaded into an 18F2420. It looks like some dots are missing but at least the display is doing something. In the long run I plan to use a chip with enough RAM. I just wanted to see if I can get the display working.
Trying to make the OLED work by hacking the buffer array, or limitiing the pixels will not work. The buffer will simply overrun trashing other variables. Just need some RAM. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well Yes. I am aware of this approach. We have all the fonts, we could do this.
It is simply time. The adapation would include revising GLCD.h, the OLED specific driver and potentially the drawing primitives.
I think it is doable. I think for the Great Cow BASIC driver this is relatively easy. I do not have a OLED with me... so, I cannot test until Mid August.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed these lines in glcd_ssd1306.h
Dim SSD1306_BufferAlias(512)
in glcdcls change to
For SSD1306_BufferLocationCalc = 1 to 512
for SSD1306_BufferLocationCalc = 0 to 31 step 8
and this worked if any use to Joseph.
GLCDCLS
GLCDDrawString (0,0,"Test")
line (0,8,32,16,1)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That works but it limits you to half the display. I've been playing around and I found a few things which sort of work. I can have a 128 byte buffer and divide the display into 8 pages. When you write to a new page you clear the buffer. This only seems to work with text, and only if the text y positions are 255, 7, 15, 23, 31, 39, 47, and 55. This works fine for a mostly static display (i.e. only one line of text is changing). Here's the code:
A second approach if you have more than one line of text which changes regularly is to saved the 128 byte buffer. In this code I can save the last three buffers. This lets me have up to three lines of text which change frequently. This approach uses 512 bytes for buffering so it might not be suitable for a low-RAM chip. I'm still looking for a more universal approach but at least I'm making some progress. Here's the code for this version:
I will create a very low memory driver for the SSD1306 in August 2017. Use of the approach / code will require the use of Great Cow BASIC compiler of v0.98.00 or greater, so, I will update this posting when I have completed testing.
The driver should include a set of full capabilities that we have today - including full screen circles and full font support. It will be 8 pages using a 128byte buffer. I think this is easy doable.
Anobium
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How to do circles and lines. I suppose I'd keep track of the plot x,y. Draw in 1 buffer then at a point on the screen use buffer2 for write/map next row of 128 bytes because the bytes on display remain.
Would 256 bytes ram minimum for 2 buffers work?
My first thoughts was get a chip with more memory but I can see it would be useful if lower memory chips could be used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I managed to get a low RAM text only driver working with Anobium's help. It works well, updates changing fields much faster than my prior attempts, and doesn't force me to start the text only on certain lines. The complied demo only uses 136 bytes! Here's a picture of it in action:
Excellent Joseph. I've scratched my head as for graphics and first thought it would need two 128 byte buffers.Then when I thought more my head hurt. Since you can't read the screen, I can't see how to do it. Mid point circle algo plot point jumps around the screen when drawing a circle and I just can't "see/imagine" a method to do it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I went through the same thought exercise myself. Can't really see a way to do it. About the only possibility I see for low RAM chips is to define a graphics window whose size is based upon how much RAM you have available. For example, you might define a window maybe 64 pixels wide and 32 pixels high. This would need a buffer of 64 * 32 / 8, or 256 bytes. You could put this window anywhere you want on the display. Anything you draw outside the window would be rejected. You would still be able to use the remainder of the display for text. Of course, this would require a major rewrite of the graphics routines. The bottom line though is it looks like you can use low RAM chips if all you want is text. If you want graphics, at best you can only use a portion of the display, and that's assuming the graphics routines were heavily modified.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been using GCBasic for the last 8 years. Thus far it's been able to do everything I wanted. I recently purchased several I2C OLED displays on eBay which use the SSD1306 controller. I'm using a PIC18F2420 for testing purposes. I slightly modified one of the demo programs. I know the 18F2420 doesn't have enough RAM, so I reduced the buffer size to 400 bytes. I had read elsewhere that this will at least allow some lines on the display to work. Unfortunately, nothing works. I'm getting a sine wave on the crystal but all the other outputs are inactive. I even put some test LEDs which should light up if the main program is running but they don't. The I2C lines remain high all the time. Basically, it looks like the PIC isn't running the program at all (or it's locking up beforehand). I even tried it using the internal oscillator instead of the crystal. Same result. The microcontroller works fine when I load other programs.
Any insight would be appreciated. The program compiled with no errors. Here is the full program:
Last edit: Joseph Realmuto 2017-07-22
GCB needs to know what the final Mhz value of the clock is including the PLL. So for say a 10Mhz ext osc it would be #config 18f2420, 10 or #config 18f2420, 40 with the 4x PLL. Values over 10Mhz with the PLL enabled seem to be operating outside the 18f2420 parameters. This is the case with the more vintage 18f's, while the 18fxxk20 and 18fxxk22 devices can go up to 16Mhz with the PLL for a 64Mhz clock.
I'm using a 4.194304MHz crystal, so the final clock value with the 4x PLL is 16.777216 MHz.
Last edit: Joseph Realmuto 2017-07-22
OK then, thought it might be a timing problem. I do not have the I2C model of the SSD1306, so can't test the reduced ram example.
For what it's worth I not only tried it with the internal oscillator, but I also tried software I2C, and both slave addresses (0x78 and 0x7A). Same results each time. The I2C lines remained high and it looked like the PIC was either locked up or just not initializing.
I made some progress. I determined that hardware I2C isn't working properly with the 18F2420 for some reason so I tried software I2C (I forgot to set the ports as inputs last time I tried software I2C). This time instead of limiting the buffer in the SSD1306.h file I changed the chip number to PIC18F2520 which has 1536 bytes of RAM. Surprising, the resulting hex file worked mostly OK when loaded into an 18F2420. It looks like some dots are missing but at least the display is doing something. In the long run I plan to use a chip with enough RAM. I just wanted to see if I can get the display working.
Here's the program which worked (more or less):
Last edit: Joseph Realmuto 2017-07-23
Trying to make the OLED work by hacking the buffer array, or limitiing the pixels will not work. The buffer will simply overrun trashing other variables. Just need some RAM. :-)
Yes, I know that. Any chance of writing a GC Basic driver for low RAM chips? Someone did that here in C: https://www.ccsinfo.com/forum/viewtopic.php?t=54453
Well Yes. I am aware of this approach. We have all the fonts, we could do this.
It is simply time. The adapation would include revising GLCD.h, the OLED specific driver and potentially the drawing primitives.
I think it is doable. I think for the Great Cow BASIC driver this is relatively easy. I do not have a OLED with me... so, I cannot test until Mid August.
If you have time for this then I'll be happy to do some testing for the SSD1306 driver.
I have sent you a Personal Message. :-)
Idea. try
#define GLCD_TYPE_SSD1306_32This will limit memory usage to 512 bytes and the display to 128 * 32. There may be other side effects - I cannot test.
I changed these lines in glcd_ssd1306.h
Dim SSD1306_BufferAlias(512)
in glcdcls change to
For SSD1306_BufferLocationCalc = 1 to 512
for SSD1306_BufferLocationCalc = 0 to 31 step 8
and this worked if any use to Joseph.
Use of the approach / code requires the use of Great Cow BASIC compiler of v0.98.00 or greater.
That works but it limits you to half the display. I've been playing around and I found a few things which sort of work. I can have a 128 byte buffer and divide the display into 8 pages. When you write to a new page you clear the buffer. This only seems to work with text, and only if the text y positions are 255, 7, 15, 23, 31, 39, 47, and 55. This works fine for a mostly static display (i.e. only one line of text is changing). Here's the code:
Last edit: Joseph Realmuto 2017-07-25
A second approach if you have more than one line of text which changes regularly is to saved the 128 byte buffer. In this code I can save the last three buffers. This lets me have up to three lines of text which change frequently. This approach uses 512 bytes for buffering so it might not be suitable for a low-RAM chip. I'm still looking for a more universal approach but at least I'm making some progress. Here's the code for this version:
Use of the approach / code requires the use of Great Cow BASIC compiler of v0.98.00 or greater.
I will create a very low memory driver for the SSD1306 in August 2017. Use of the approach / code will require the use of Great Cow BASIC compiler of v0.98.00 or greater, so, I will update this posting when I have completed testing.
The driver should include a set of full capabilities that we have today - including full screen circles and full font support. It will be 8 pages using a 128byte buffer. I think this is easy doable.
Anobium
How to do circles and lines. I suppose I'd keep track of the plot x,y. Draw in 1 buffer then at a point on the screen use buffer2 for write/map next row of 128 bytes because the bytes on display remain.
Would 256 bytes ram minimum for 2 buffers work?
My first thoughts was get a chip with more memory but I can see it would be useful if lower memory chips could be used.
@Stan. We are working on a solution. We can make this work as this is a good additional to the capabiliites.
I managed to get a low RAM text only driver working with Anobium's help. It works well, updates changing fields much faster than my prior attempts, and doesn't force me to start the text only on certain lines. The complied demo only uses 136 bytes! Here's a picture of it in action:
Excellent Joseph. I've scratched my head as for graphics and first thought it would need two 128 byte buffers.Then when I thought more my head hurt. Since you can't read the screen, I can't see how to do it. Mid point circle algo plot point jumps around the screen when drawing a circle and I just can't "see/imagine" a method to do it.
I went through the same thought exercise myself. Can't really see a way to do it. About the only possibility I see for low RAM chips is to define a graphics window whose size is based upon how much RAM you have available. For example, you might define a window maybe 64 pixels wide and 32 pixels high. This would need a buffer of 64 * 32 / 8, or 256 bytes. You could put this window anywhere you want on the display. Anything you draw outside the window would be rejected. You would still be able to use the remainder of the display for text. Of course, this would require a major rewrite of the graphics routines. The bottom line though is it looks like you can use low RAM chips if all you want is text. If you want graphics, at best you can only use a portion of the display, and that's assuming the graphics routines were heavily modified.