There's something I don't understand

[FFMan]

Further to my earlier post, i was looking for a way to drive my LCD in 8 bit mode, using pins that do not necessarily all come from one port. (I expect in due course I will switch to 4 bit mode but so I can get on with other elements of the project I decided to try a quick and dirty fix)

The code I had from the sample on the website, used an alias technique to assign the data to the pins. So I figure if the pins might be anyhow numbered why not just have a table and do this :-

if LCD_Alias=true then
LCD_Data = C else
for i=0 to 7
call PutPin(LCD_Pin(i),GetBit(C,i))
next i

so this code should in theory cope with either scenario depending on the setting of a variable.

If I define my pins like this:-

LCD_Pin(0)=A.0
LCD_Pin(1)=A.1
LCD_Pin(2)=A.2
LCD_Pin(3)=A.3
LCD_Pin(4)=A.4
LCD_Pin(5)=A.5
LCD_Pin(6)=A.6
LCD_Pin(7)=A.7


it seems to work, however if I use pin number instead of A.n etc i get a different result, the top line of the lcd is quite unreadable with nothing on line 2.
also, demonstrating that there is something i don't understand, if i use the working method to define the pins, then i swap 2 wires on the ZX24, and swap the corresponding pin designations i still get slightly garbled output on the lCD, when i was hoping if i swap 2 wires, and swap and the table entries in LCD_Pin the resuilt would still work.

i though aliasing was just a shorthand for referencing variables but there seems to be more going on than that would suggest.


thanks

[dkinzer]

[FFMan]

yep and i realised just a few mins ago what was wrong - i had the pin designations running back to front, i though a0 was pin 13 when its pin 20, so the lcd was getting all sorts of nonsense.

and now when i swap the pins and the corresponding table entries about it works, so this means i can move the code to the 328n and use what ever pins i like

thanks don
(coding after a long day doing other stuff can lead to errors for me !)

[dkinzer]

[FFMan]

thanks for the suggestions. In fact I had already made use of the compiler directives as it seemed sensible and the compiler throws up warnings about statements always being true etc

I shall move LCD_Pin to progmem, its only a few bytes but its the principal of efficiency that I like.

I like the bit shift technique, would SHL be even more efficient that a divide ?

Using the corrected code I got it working using various pins on the 328n

thanks

[dkinzer]