Timing differences from zx328n to zx40n ?

Discussion of issues related specifically to writing code for native mode devices. This includes ZBasic code as well as assembly language code and C code, both inline and standalone.
Post Reply
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Timing differences from zx328n to zx40n ?

Post by FFMan »

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
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Re: Timing differences from zx328n to zx40n ?

Post by dkinzer »

FFMan wrote:are there any differences that might be causing an issue, or should i look for a more basic problem ?
The execution speed of a ZX-328n and ZX-40n should be nearly the same so I wouldn't suspect a timing issue.

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
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Post by FFMan »

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:-

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
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

FFMan wrote:I shall have a play with a small delay as indicated and see if it helps.
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.
- Don Kinzer
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Post by FFMan »

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
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

FFMan wrote:interaction with another task must have been causing intermittant timing issues.
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.

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)
Also, you may have noticed that I edited your post, adding "code" tags around the source code. This makes it much easier to read. When you post, you can select a block of text and click on the Code button located above the message edit box. Doing so adds the words "code" and "/code" enclosed in square brackets. You can type them in directly, too.
- Don Kinzer
Post Reply