Avr128da48, arduino and DOG128 #2683
Apostolaki-Eleni
started this conversation in
General
Replies: 2 comments
-
|
I believe if you use U8G2_ST7565_EA_DOGM128_F_4W_SW_SPI, you should be calling u8g2.clearBuffer and u8g2.sendBuffer instead of the nextPage loop. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
To me it sounds like that the WDT is active in the DxCore. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm experiencing an issue with the U8g2 library using Software SPI on an AVR128DA48 microcontroller (using the DxCore package in Arduino IDE) with an EA DOGM128-6 (ST7565 controller) LCD.
The display initializes correctly and shows text perfectly for the first refresh cycle (i.e., immediately after u8g2.begin() in setup() and during the first iteration of the do...while(u8g2.nextPage()) loop in loop()). However, after this initial display, the screen either goes blank or stops updating correctly on subsequent loop() iterations. The screen clears (indicating that at least the clear command is received), but no new drawing operations (like drawStr or drawFrame) are rendered.
What I've Already Verified/Tried:
Hardware Connections: All wiring (CLK, DATA, CS, DC, RESET, VCC, GND, PSB) has been thoroughly checked and is correct.
Crucial detail: The display works perfectly with another library (specifically, the GLCD library) using the exact same wiring. This confirms that the display itself is functional, the wiring is correct, and the power supply is stable.
U8g2 Constructor:
I'm using U8G2_ST7565_EA_DOGM128_F_4W_SW_SPI. This constructor allows for full-buffer display.
I've also tried U8G2_ST7565_EA_DOGM128_1_4W_SW_SPI and U8G2_ST7565_EA_DOGM128_2_4W_SW_SPI. With these, the display showed partial text, but still didn't update correctly on subsequent loops.
SPI Clock Speed (setBusClock()):
I've tried various setBusClock() values after u8g2.begin(), ranging from very slow (20kHz, 50kHz) to more common speeds (100kHz, 400kHz). None of these settings resolved the issue; the display still stops updating after the first cycle.
Reset Pin Handling:
I've tried both connecting the display's RESB pin to a microcontroller pin (PIN_PB3) and using U8X8_PIN_NO_RESET with the physical RESB pin either floating or tied to VCC (3.3V) via a 10kΩ resistor. No change in behavior.
U8g2 Library Version: Confirmed I'm using the latest version of the U8g2 library.
My Core Problem & Constraint:
The ability to rotate the display (U8G2_R1, U8G2_R2, etc.) is critical for my project. The GLCD library, while functional, doesn't easily support display rotation, which is why I need to use U8g2.
I cannot use Hardware SPI as the dedicated SPI pins on my AVR128DA48 are already occupied by other crucial components in my project.
Question:
Given that the display works perfectly with the GLCD library (suggesting the issue lies within U8g2's Software SPI implementation on this specific MCU), and I cannot use Hardware SPI, what could be causing this persistent update failure? Are there any known workarounds, specific configurations, or obscure settings for U8g2's Software SPI on AVR DA series microcontrollers that could resolve this timing or stability issue?
Beta Was this translation helpful? Give feedback.
All reactions