You don't want filtering caps on communications lines, you want the high-low-high transitions as crisp as possible. If anything, you may adjust the SLRCONx settings.
You don't want filtering caps on communications lines, you want the high-low-high transitions as crisp as possible. If anything, you may adjust the SLRCONx settings.
LOL I'm not adding filtering caps to data lines. I'm adding them to power lines![]()
Looking at the library code, if the clock is set for > 16MHz (or 24MHz in some cases) it uses a longer internal delay before asserting some of the control pins.
Try this - lie to the compiler and tell it you're running faster than you really are:
DEFINE OSC 32 'set oscillator speed
Don't change your OSCCON setting... leave it so you're still actually running at 16MHz.
Yes I already tried that and it works just fine, but it messes up with all other timing settings in my code, which is about 16K.
Is there any way to adjust the library settings?
Not that I see, at least not without re-writing the lib asm code.
It looks like your display just isn't compatible with the timing of LCDOUT.
Your method of changing the osc freq before/after using the LCD is probably the easiest "fix" that comes to mind.
Yes, quite possible, since this is not usual 1602 LCD module - it has 3 character sets (JP, Western europe, Cyrilic), switchable just like in WS0010. It also ignores LCDOUT $FE,$0 statement. But I will try with other 1602 modules and write the results.
Try to increase delays with defines
' Set command delay time in us
DEFINE LCD_COMMANDUS 1500
' Set data delay time in us
DEFINE LCD_DATAUS 44
Last edited by pedja089; - 19th November 2022 at 11:28.
Bookmarks