Don,
I've moved some code that runs quite happily on a 328n, 328l and zx24a to a zx40n and I am seeing intermittant problems with text positioning on the lcd display.
every few seconds or so an item of text will be missing a letter or incorrectly positioned.
I am driving the lcd in 8 bit mode using:-
port c for d0-d7 on the lcd
d7 =ena
d5=r/s
d6=r/w
it is of course possible there is a wiring issue but i did test the lcd display on the 328 last night and it seemed ok
are there any differences that might be causing an issue, or should i look for a more basic problem ?
thanks
Timing differences from zx328n to zx40n ?
Re: Timing differences from zx328n to zx40n ?
The execution speed of a ZX-328n and ZX-40n should be nearly the same so I wouldn't suspect a timing issue.FFMan wrote:are there any differences that might be causing an issue, or should i look for a more basic problem ?
If you would post the code for the send-a-byte-to-the-LCD routine for the ZX-328n and ZX-40n along with the pertinent definitions perhaps someone could spot an issue.
- Don Kinzer
the code comes direct from one of the examples off your site. The only mod was to use a table to locate the pin as on the 328 i couldn't use a complete port and aliasing that was originally done.
I see there is a comment in the borrow code regards additional delays, I shall have a play with a small delay as indicated and see if it helps.
If anyone has made this transition and found the solution that would be good.
The code for 328 and zx40 is the same code:-
I see there is a comment in the borrow code regards additional delays, I shall have a play with a small delay as indicated and see if it helps.
If anyone has made this transition and found the solution that would be good.
The code for 328 and zx40 is the same code:-
Code: Select all
Private Sub LCD_Out (byval C as Byte)
'debug.print "Pins"
dim i as byte
locktask
' send a single byte to the LCD in text mode
call PutPin (LCD_Enable, zxOutputLow) ' set enable low
for i=0 to 7
call PutPin(LCD_Pin(i),GetBit(C,i))
next i
' Debug.Print chr(C)
call PutPin (LCD_RS, zxOutputHigh) ' RS = Data
call PutPin (LCD_RW, zxOutputLow) ' R/W = write mode
call PutPin(LCD_Enable,zxOutputHigh)
call delay (0.002)
call PutPin(LCD_Enable,zxOutputLow)
'call PulseOut (LCD_Enable, 2, 1) ' E = enable 2 micro-seconds long
' note: per docs 37 micro seconds are required for a write operation.
' testing reveals no additional delay is needed for the target device.
'call delay (0.001) ' delay 2/1000 seconds
unlocktask
End Sub
You should note that the Delay() call defeats the purpose of the LockTask() in that it forces the task to be unlocked. The subroutine Pause() does not have that side effect nor does the PulseOut() call that was used in the original code.FFMan wrote:I shall have a play with a small delay as indicated and see if it helps.
- Don Kinzer
as usual don, right on the money - changed the delay statements to pause and all came good. interaction with another task must have been causing intermittant timing issues. Not sure why this was only apparent on the zx40 and not on the 328 but there is an answer somewhere i'm sure.
all fixed now and running quicker as once the timing was fully under control i was able to tighten the timing a bit.
thanks
all fixed now and running quicker as once the timing was fully under control i was able to tighten the timing a bit.
thanks
It is difficult to guess what the issue might be. I checked several datasheets for HD44780 devices - they all indicated a minimum E pulse width of 450nS and no maximum pulse width.FFMan wrote:interaction with another task must have been causing intermittant timing issues.
By the way, the pulse generated by PutPin() in zxOutputPulse mode should meet the minimum E pulse width; it should be about 540nS wide (8 CPU cycles).
Code: Select all
Call PutPin(LCD_Enable, zxOutputPulse)
- Don Kinzer