Activity for Joseph Realmuto
-
Joseph Realmuto posted a comment on discussion Open Discussion
That looks fine to me. Only thing I might add here is that GCB only supports 65K colors, even though the controller supports 262K colors.
-
Yes, please comment it out. The more portable the demo is the better. Minor correction to your comments in the demo: "It is a nice graphical TFT LCD, suitable for a lot of various projects." It's actually an OLED display, not an LCD.
-
Yes, please comment it out. The more portable the demo is the better.
-
No, the demo could use the internal oscillator.
-
Actually, the SetBrightness_SSD1351 sub didn't work because I set up a few things wrong. Here's the final revised glcd_ssd1351.h with the SetBrightness_SSD1351 sub working correctly.
-
I completed the testing and made my changes to glcd_ssd1351.h. I removed the SendMultipleCommand_SSD1351 and SendMultipleData_SSD1351 subs as there doesn't seem to really be any need for them. I also removed the SetBrightness_SSD1351 sub as it doesn't work, even though it should according to the data sheet. It was redundant anyway. The SetContrast_SSD1351 sub works just fine for the purposes of setting display brightness, as well as the relative brightness of the colors. On the rotation, I set it...
-
I completed the testing and made my changes to glcd_ssd1351.h. I removed the SendMultipleCommand_SSD1351 and SendMultipleData_SSD1351 subs as there doesn't seem to really be any need for them. I also removed the SetBrightness_SSD1351 sub as it doesn't work, even though it should according to the data sheet. It was redundant anyway. The SetContrast_SSD1351 sub works just fine for the purposes of setting display brightness, as well as the relative brightness of the colors. On the rotation, I set it...
-
I completed the testing and made my changes to glcd_ssd1351.h. I removed the SendMultipleCommand_SSD1351 and SendMultipleData_SSD1351 sub as there doesn't seem to really be any need for them. I also removed the SetBrightness_SSD1351 sub as it doesn't work, even though it should according to the data sheet. It was redundant anyway. The SetContrast_SSD1351 sub works just fine for the purposes of setting display brightness, as well as the relative brightness of the colors. On the rotation, I set it...
-
I completed the testing and made my changes to glcd_ssd1351.h. I removed the SendMultipleCommand_SSD1351 and SendMultipleData_SSD1351 sub as there doesn't seem to really be any need for them. I also removed the SetBrightness_SSD1351 sub as it doesn't work, even though it should according to the data sheet.It was redundant anyway. The SetContrast_SSD1351 sub works just fine for the purposes of setting display brightness, as well as the relative brightness of the colors. On the rotation, I set it up...
-
I completed the testing and made my changes to glcd_ssd1351.h. I removed the SendMultipleCommand_SSD1351 and SendMultipleData_SSD1351 sub as there doesn't seem to really be any need for them. I also removed the SetBrightness_SSD1351 sub as it doesn't work, even though it should according to the data sheet.It was redundant anyway. The SetContrast_SSD1351 sub works just fine for the purposes of setting display brightness, as well as the relative brightness of the colors. On the rotation, I set it up...
-
That works for me. I get a warning:16 from the compiler, but it makes the hex file just fine, and the display writes are at the same speed as when I manually put the SSP1ADD code in.
-
This is what you need to add to glcd.h: If GLCD_TYPE = GLCD_TYPE_SSD1351 Then #include <glcd_SSD1351.h> InitGLCD = InitGLCD_SSD1351 GLCDCLS = GLCDCLS_SSD1351 GLCDDrawChar = GLCDDrawChar_SSD1351 GLCDDrawString = GLCDDrawString_SSD1351 FilledBox = FilledBox_SSD1351 Pset = Pset_SSD1351 GLCDRotate = GLCDRotate_SSD1351 GLCDSetContrast = SetContrast_SSD1351 glcd_type_string = "SSD1351" GLCD_WIDTH = 128 GLCD_HEIGHT = 128 SSD1351_GLCD_HEIGHT = GLCDDeviceHeight SSD1351_GLCD_WIDTH = GLCDDeviceWidth End If...
-
This is what you need to add to glcd.h: If GLCD_TYPE = GLCD_TYPE_SSD1351 Then #include <glcd_SSD1351.h> InitGLCD = InitGLCD_SSD1351 GLCDCLS = GLCDCLS_SSD1351 GLCDDrawChar = GLCDDrawChar_SSD1351 GLCDDrawString = GLCDDrawString_SSD1351 FilledBox = FilledBox_SSD1351 Pset = Pset_SSD1351 GLCDRotate = GLCDRotate_SSD1351 GLCDSetContrast = SetContrast_SSD1351 glcd_type_string = "SSD1351" GLCD_WIDTH = 128 GLCD_HEIGHT = 128 SSD1351_GLCD_HEIGHT = GLCDDeviceHeight SSD1351_GLCD_WIDTH = GLCDDeviceWidth End If...
-
I made that change in the glcd_ssd1351.h (attached), uncommented the lines I mentioned, and all is well. :) Thanks! Interestingly, it's also possible to tweak the SPI speed further. SPI Master mode uses Fosc/16 instead of Fosc/4 like MasterFast. The K40 chips have an SPI master mode which uses SSP1ADD to tweak the SPI speed. You need to set SSPM(3:0] in SSP1CON1 to 1010. The chip then uses an SPI clock of Fosc/(4x(SSP1ADD+1). It was just a matter then of trying several SSP1ADD values to see what...
-
I made that change in the glcd_ssd1351.h (attached), uncommented the lines I mentioned, and all is well. :) Thanks! Interestingly, it's also possible to tweak the SPI speed further. SPI Master mode uses Fosc/16 instead of Fosc/4 like MasterFast. The K40 chips have an SPI master mode which uses SSP1ADD to tweak the SPI speed. You need to set SSPM(3:0] in SSP1CON1 to 1010. The chip then uses an SPI clock of Fosc/(4x(SSP1ADD+1). It was just a matter then of trying several SSP1ADD values to see what...
-
I made that change in the glcd_ssd1351.h (attached), uncommented the lines I mentioned, and all is well. :) Thanks! Interestingly, it's also possible to tweak the SPI speed further. SPI Master mode uses Fosc/16 instead of Fosc/4 like MasterFast. The K40 chips have an SPI master mode which uses SSP1ADD to tweak the SPI speed. You need to set [SSPM(3:0] in SSP1CON1 to 1010. The chip then uses an SPI clock of Fosc/(4x(SSP1ADD+1). It was just a matter then of trying several SSP1ADD values to see what...
-
I found a partial workaround. It looks like the SPI data rate to the display is too fast at 64 MHz for some reason. I tried starting the chip with #config FEXTOSC=HS, RSTOSC=EXTOSC, BOREN=OFF, CSWEN = ON, WDTE = OFF and writing to the display. That write was successful. I then put OSCCON1=0x20 to turn on the 4x PLL before trying another write to the display. That write failed. The problem seems to be with the initPPS. Here is what I've been using: 'Generated by PIC PPS Tool for Great Cow Basic 'PPS...
-
I found a partial workaround. It looks like the SPI data rate to the display is too fast at 64 MHz for some reason. I tried starting the chip with #config FEXTOSC=HS, RSTOSC=EXTOSC, BOREN=OFF, CSWEN = ON, WDTE = OFF and writing to the display. That write was successful. I then put OSCCON1=0x20 to turn on the 4x PLL before trying another write to the display. That write failed. The problem seems to be with the initPPS. Here is what I've been using: 'Generated by PIC PPS Tool for Great Cow Basic 'PPS...
-
I found a partial workaround. It looks like the SPI data rate to the display is too fast at 64 MHz for some reason. I tried starting the chip with #config FEXTOSC=HS, RSTOSC=EXTOSC, BOREN=OFF, CSWEN = ON, WDTE = OFF and writing to the display. That write was successful. I then put OSCCON1=0x20 to turn on the 4x PLL before trying another write to the display. That write failed. The problem seems to be with the initPPS. Here is what I've been using: 'Generated by PIC PPS Tool for Great Cow Basic 'PPS...
-
I found a partial workaround. It looks like the SPI data rate to the display is too fast at 64 MHz for some reason. I tried starting the chip with #config FEXTOSC=HS, RSTOSC=EXTOSC, BOREN=OFF, CSWEN = ON, WDTE = OFF and writing to the display. That write was successful. I then put OSCCON1=0x20 to turn on the 4x PLL before trying another write to the display. That write failed. The problem seems to be with the initPPS. Here is what I've been using: 'Generated by PIC PPS Tool for Great Cow Basic 'PPS...
-
I found a partial workaround. It looks like the SPI data rate to the display is too fast at 64 MHz for some reason. I tried starting the chip with #config FEXTOSC=HS, RSTOSC=EXTOSC, BOREN=OFF, CSWEN = ON, WDTE = OFF and writing to the display. That write was successful. I then put OSCCON1=0x20 to turn on the 4x PLL before trying another write to the display. That write failed. The problem seems to be with the initPPS. Here is what I've been using: 'Generated by PIC PPS Tool for Great Cow Basic 'PPS...
-
Attached.
-
My code. What I just wrote above is wrong anyway. What happens for some reason when I use #chip PIC18F27K40,32 the compiler ends up having the chip running on the 32 MHz internal oscillator, not the external crystal oscillator, despite the configuration telling it to use the crystal oscillator. That explains why the delay loops work as expected. The bottom line is I don't think I can make my project work at 64 MHz. I'll just have to accept that 40 MHz is all I can get. I attached the SSD1351 library....
-
I just made an interesting discovery. If I use the above program exactly as written it doesn't work. I tried changing CSWEN to ON. Still didn't work. However, if I change #chip PIC18F27K40,64 to #chip PIC18F27K40,32 then it works. I also tried #chip PIC18F27K40,48 but that doesn't work, either. Here's another interesting thing. Any delay loops should in theory run at half the speed since the program is assuming a clock speed of 32 MHz, when in reality the clock is 64 MHz. However, they don't. They...
-
That code with the chip and nothing but the crystal attached is working fine. The problem seems to be when the display attached. If I can sort it out with the simple test program I posted below (which just writes stuff to the display), all should be well.
-
I'm trying to run a test program which just sends stuff to the display, without any interrupts or use of the EEPROM. It doesn't work with the 16 MHz crystal and 4xPLL but works fine if I swap in a 10 MHz crystal. This is starting to look like some sort of weird interaction between the display and the chip. Here's the test program: ;Chip Settings #chip PIC18F27K40,64 #config FEXTOSC=HS, RSTOSC=EXTOSC_4PLL, BOREN=OFF, MCLR=ON, CSWEN = OFF #include <glcd.h> #include <glcd_large_number_fonts_SSD1351.h>...
-
Yes, there are interrupts running, and I'm still writing to the EEPROM. All this works fine with the 10 MHz crystal and 4xPLL. Also, everything works fine with the 16 MHz crystal without the 4xPLL.
-
The simple test program works, even with a 16 MHz crystal. PortA.0 pulses at a frequency of 50 Hz like it should. This is telling me there's definitely no issue with the crystal layout. I'm using 20 pf caps and a 330 ohm series resistor. It works with or without the series resistor. The problem is when I try your config with my project. At that point nothing works, or at least I'm not getting anything on the OLED display. Compiler version is 0.98.06 2019-06-12 (Windows 32 bit) with the new EEPROM...
-
The simple test program works, even with a 16 MHz crystal. PortA.0 pulses at a frequency of 50 Hz like it should. This is telling me there's definitely no issue with the crystal layout. I'm using 20 pf caps and a 330 ohm series resistor. It works with or without the series resistor. The problem is when I try your config with my project. At that point nothing works, or at least I'm not getting anything on the OLED display.
-
None of that works at all for me unless I have CSWEN = OFF. When I have it off, it works fine with the 10 MHz crystal but not at all with the 16 MHz one. I honestly think this is an undocumented hardware issue.
-
I tried so many different settings. Sometimes it hangs, other times it just runs slow.
-
Definitely not in the errata. I already checked.
-
Yes. Same problem with all three I tried.
-
This could be a chip problem, or a problem with settings but I'm curious if anyone else experienced it. A few weeks ago in the course of solving the EEPROM issue with the K40 I noticed that the K40 wouldn't run at 64 MHz on the internal oscillator. Further testing showed 32 MHz worked just fine but 48 MHz didn't work, either. However, for my project I was using the crystal oscillator, not the internal oscillator. I originally used a 4.194304 MHz crystal and the 4xPLL for a clock speed of 16.777216...
-
This could be a chip problem, or a problem with setting,s but I'm curious if anyone else experienced it. A few weeks ago in the course of solving the EEPROM issue with the K40 I noticed that the K40 wouldn't run at 64 MHz on the internal oscillator. Further testing showed 32 MHz worked just fine but 48 MHz didn't work, either. However, for my project I was using the crystal oscillator, not the internal oscillator. I originally used a 4.194304 MHz crystal and the 4xPLL for a clock speed of 16.777216...
-
Sent to your .anobium address.
-
Just tried the new eeprom.h. Same thing. It looks like I might have to abandon the K40 for this particular project.
-
I found this: http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F27_47K40%20Errata%20DS80000713D.pdf Look on page 4. That might be it.
-
a002
-
Question: How can I visually see if anything is working using that code? I tried running my test program with no PPS assignments and software SPI. Same result. It hangs after EPRead. Evidently PSS isn't causing the problem. I also tried running it with no config files, software SPI, and just the #chip PIC18F27K40 line. Same thing except it executes the first few commands in the second lamptest routine, but not the part where it writes characters. It looks like EPRead is changing something which keeps...
-
That seems to work, which is weird. I didn't put EPWrite in the example code because the problem occurred at the first instance of EPRead. It also occurred when I commented out anything using EPRead but kept stuff in using EPWrite. Both seem to cause the program to fail. It might be an issue with my chip configuration.
-
This is about as simple as I can get: ;Chip Settings #chip PIC18F27K40,4.194304 #config FEXTOSC=XT, RSTOSC=EXTOSC_4PLL, BOREN=OFF, MCLR=ON, CSWEN = ON #include <glcd.h> 'Generated by PIC PPS Tool for Great Cow Basic 'PPS Tool version: 0.0.5.15 'PinManager data: v1.65.1 ' 'Template comment at the start of the config file ' #startup InitPPS, 85 Sub InitPPS 'Module: MSSP1 RC5PPS = 0x0010 'SDO1 > RC5 RC4PPS = 0x0010 'SDA1 > RC4 SSP1DATPPS = 0x0014 'RC4 > SDA1 (bi-directional) RC3PPS = 0x000F 'SCL1 >...
-
This is about as simple as I can get: ;Chip Settings #chip PIC18F27K40,4.194304 #config FEXTOSC=XT, RSTOSC=EXTOSC_4PLL, BOREN=OFF, MCLR=ON, CSWEN = ON #include <glcd.h> 'Generated by PIC PPS Tool for Great Cow Basic 'PPS Tool version: 0.0.5.15 'PinManager data: v1.65.1 ' 'Template comment at the start of the config file ' #startup InitPPS, 85 Sub InitPPS 'Module: MSSP1 RC5PPS = 0x0010 'SDO1 > RC5 RC4PPS = 0x0010 'SDA1 > RC4 SSP1DATPPS = 0x0014 'RC4 > SDA1 (bi-directional) RC3PPS = 0x000F 'SCL1 >...
-
0.98.<<>> 2017-12-21 I also tried it with the latest release ( 0.98.06 2019-06-12 (Windows 32 bit) ). Same issues.
-
I haven't been around for a while but I recently started playing with PICs again. Anyway, I decided to substitute a PIC18F27K40 for a PIC18F2420 I was using for a project. I had a little difficulty with PPS but eventually got the program to work, at least up until the point where it reads from EEPROM. At that point, it just hangs and does nothing. If I comment out the lines using EPRead and EPWrite all is well. P.S. I recently modified the SSD1331 driver for faster character writes and also added...
-
It's sounding to me like a problem I had with some of these displays. Basically, I put a delay of 255 ms at the start of the initialization procedure to allow the power supplies time to stabilize. That fixed the problem. The delay would be right at the beginning of the InitGLCD_SSD1306 subroutine in SSD1306.h: Sub InitGLCD_SSD1306 'Colours //Set these first GLCDBackground = 0 GLCDForeground = 1 GLCDFontWidth = 6 GLCDfntDefault = 0 GLCDfntDefaultsize = 1 'need delay here to allow power supplies to...
-
It's sounding to me like a problem I had with some of these displays. Basically, I put a delay of 255 ms at the start of the initialization procedure to allow the power supplies time to stabilize. That fixed the problem. The delay would be right at the beginning of the InitGLCD_SSD1306 subroutine in SSD1306.h (shown in bold below): Sub InitGLCD_SSD1306 'Colours //Set these first GLCDBackground = 0 GLCDForeground = 1 GLCDFontWidth = 6 GLCDfntDefault = 0 GLCDfntDefaultsize = 1 [b]wait 255 ms[/b] #IFDEF...
-
It's sounding to me like a problem I had with some of these displays. Basically, I put a delay of 255 ms at the start of the initialization procedure to allow the power supplies time to stabilize. That fixed the problem. The delay would be right at the beginning of the InitGLCD_SSD1306 subroutine in SSD1306.h (shown in bold below): Sub InitGLCD_SSD1306 'Colours //Set these first GLCDBackground = 0 GLCDForeground = 1 GLCDFontWidth = 6 GLCDfntDefault = 0 GLCDfntDefaultsize = 1 ** wait 255 ms** #IFDEF...
-
@Stan-The initialization routine is practically the same for both the SSD1306 and SSD1306_32 other than buffer size and a few parameters which tell the chip the display is 128x32 instead of 128x64.
-
I've had also had the problem where the program doesn't restart if you turn the power off and then turn it back on shortly after. It will restart after it's been sitting a while. The reason is that the PIC draws very little power once the voltage drops low enough for the oscillator to stop. Therefore, the registers stay in whatever state they were in, and when you power it back up it often doesn't initialize because it hasn't really shut down completely. Solution is to short GND and Vcc after you...
-
I have SSD1306_32s working fine with a PIC18F2420. Might want to double check all your connections. On occasion I've had solder joints to resistors break and it caused me a lot of grief because I was checking for software issues instead of hardware issues.
-
Try this instead: DSint = 0 - DSint Negative numbers are represented in two's complement plus one format. For example, -1 is really 65535, -2 is 65534, and so forth. When you subtract from zero, you should end up with the correct positive number.
-
For the sign just do this instead: Select Case dig Case 1 IF sign = 1 THEN Set DISP_SEG_A on Set DISP_SEG_B on Set DISP_SEG_C on Set DISP_SEG_D on Set DISP_SEG_E on Set DISP_SEG_F on Set DISP_SEG_G off Set DISP_SEG_DOT on END IF Case 2 DisplayValue 2, Num3 Case 3 Displayvalue 3, Num2 Case Else dig = 1 End Select It looks like DSint returns a negative number if the temperature is below zero. That's why nothing displays. You need to convert it back to a positive number: DSint = DSint * -1
-
Just do this instead: Select Case dig Case 1 IF sign = 1 THEN Set DISP_SEG_A on Set DISP_SEG_B on Set DISP_SEG_C on Set DISP_SEG_D on Set DISP_SEG_E on Set DISP_SEG_F on Set DISP_SEG_G off Set DISP_SEG_DOT on END IF Case 2 DisplayValue 2, Num3 Case 3 Displayvalue 3, Num2 Case Else dig = 1 End Select
-
Just do this instead: Select Case dig Case 1 IF sign = 1 THEN Set DISP_SEG_A on Set DISP_SEG_B on Set DISP_SEG_C on Set DISP_SEG_D on Set DISP_SEG_E on Set DISP_SEG_F on Set DISP_SEG_G off END IF Case 2 DisplayValue 2, Num3 Case 3 Displayvalue 3, Num2 Case Else dig = 1 End Select
-
Just do this instead: Select Case dig Case 1 IF sign = 1 THEN Set DISP_SEG_G off END IF Case 2 DisplayValue 2, Num3 Case 3 Displayvalue 3, Num2 Case Else dig = 1 End Select
-
As Anobium mentioned, I ran some performance tests while we were developing these new drivers. It was important to be able to write the buffer in low GLCD mode as quickly as possible in order to have high screen refresh rates. My testing showed we could write the buffer to the screen in 5 to 6 ms. That means the entire screen can be updated in roughly 40 to 50 ms. Note this was with a baud rate of 400kHz. I've found some of these displays work OK even bringing the baud rate past 1 MHz. The primary...
-
As Anobium mentioned, I ran some performance tests while we were developing these new drivers. It was important to be able to write the buffer in low GLCD mode as quickly as possible in order to have high screen refresh rates. My testing showed we could write the buffer to the screen in 5 to 6 ms. That means the entire screen can be updated in roughly 40 to 50 ms. Note this was with a baud rate of 400kHz. I've found some of these displays work OK even bringing the baud rate past 1 MHz. The primary...
-
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...
-
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:
-
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: 'Hardware settings using I2C ' #define GLCD_TYPE GLCD_TYPE_SSD1306...
-
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: 'Hardware settings using I2C ' #define GLCD_TYPE GLCD_TYPE_SSD1306...
-
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: 'Hardware settings using I2C ' #define GLCD_TYPE GLCD_TYPE_SSD1306...
-
If you have time for this then I'll be happy to do some testing for the SSD1306 driver.
-
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
-
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...
-
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...
-
I made some progress. I determined that hardware I2C isn't working properly with the 18F2420 for some reason so 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...
-
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'm using a 4.194304MHz crystal, so the final clock value with the 4x PLL is 16.777216 MHz.
-
I'm using a 4.194304MHz crystal, so the final clock value with the 4x PLL is 16.777316 MHz.
-
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...
-
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...
-
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...
1