Bra idé med lysdioder. Så enkelt det bara går.
Jag plockar fram ett rutat papper och sätter igång.
HD44780-kompatibel display: Kommer inte över till CGRAM...
-
JimmyAndersson
- Inlägg: 26470
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Jodå, det vet jag. Men det är alltid bra med påminnelser och extra koll i koden.
Bra idé med lysdioder. Så enkelt det bara går.
Jag plockar fram ett rutat papper och sätter igång.
Bra idé med lysdioder. Så enkelt det bara går.
Jag plockar fram ett rutat papper och sätter igång.
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Enl. det datablad jag har på min hemsida ska det skickas: (räknar bara nibble, High = höga nibble, Low = låga nibbel, Värde = bara det värde, inget dubbelt!)
*Vänta 15ms eller mer efter power-on* I detta läge ska Enable vara inaktiv!
0x3 (kan vara 0x2)
*Skaka Enable* (alltså '0' -> '1' -> '0')
*Vänta 4,1ms eller (gärna) mer*
0x3 (kan vara 0x2)
*Skaka Enable*
*Vänta 100µs eller (gärna) mer*
0x3 (kan vara 0x2)
*Skaka Enable*
(Helt OK att vänta lite men behövs inte så värst)
0x2
*Skaka Enable*
(Nu ska displayen vara i 4-bit läge, dubbelskrivning gäller numera!)
0x2 (High 0x28) // Set double lines on display (0x20 for single line)
*Skaka Enable*
0x8 (Low 0x28)
*Skaka Enable*
0x0 (High 0x0C) // Activate Display, no cursor, no blink @ cursor position
*Skaka Enable*
0xC (Low 0x0C)
*Skaka Enable*
0x0 (High 0x01) // Clear screen
*Skaka Enable*
0x1 (Low 0x01)
*Skaka Enable*
*Vänta minst 1,7ms = tiden för Clear Screen)
0x0 (High 0x02) // Cursor home
*Skaka Enable*
0x2 (Low 0x02)
*Skaka Enable*
Då så, nu ska man kunde skriva till skiten.
Sedan måste du ha en sekvens av typen:
1: Ställ R/S rätt (om den ska ändras, hoppa över annars).
2: Ställ Data (High) rätt.
3: Höja Enable.
4: Sänka Enable.
5: Ställ Data (Low) rätt.
6: Höja Enable.
7: Sänka Enable.
Klar. Så en skrivning av ett enda tecken ska lägga beslag på minst 6 uppdateringar av portexpandern!
*Vänta 15ms eller mer efter power-on* I detta läge ska Enable vara inaktiv!
0x3 (kan vara 0x2)
*Skaka Enable* (alltså '0' -> '1' -> '0')
*Vänta 4,1ms eller (gärna) mer*
0x3 (kan vara 0x2)
*Skaka Enable*
*Vänta 100µs eller (gärna) mer*
0x3 (kan vara 0x2)
*Skaka Enable*
(Helt OK att vänta lite men behövs inte så värst)
0x2
*Skaka Enable*
(Nu ska displayen vara i 4-bit läge, dubbelskrivning gäller numera!)
0x2 (High 0x28) // Set double lines on display (0x20 for single line)
*Skaka Enable*
0x8 (Low 0x28)
*Skaka Enable*
0x0 (High 0x0C) // Activate Display, no cursor, no blink @ cursor position
*Skaka Enable*
0xC (Low 0x0C)
*Skaka Enable*
0x0 (High 0x01) // Clear screen
*Skaka Enable*
0x1 (Low 0x01)
*Skaka Enable*
*Vänta minst 1,7ms = tiden för Clear Screen)
0x0 (High 0x02) // Cursor home
*Skaka Enable*
0x2 (Low 0x02)
*Skaka Enable*
Då så, nu ska man kunde skriva till skiten.
Sedan måste du ha en sekvens av typen:
1: Ställ R/S rätt (om den ska ändras, hoppa över annars).
2: Ställ Data (High) rätt.
3: Höja Enable.
4: Sänka Enable.
5: Ställ Data (Low) rätt.
6: Höja Enable.
7: Sänka Enable.
Klar. Så en skrivning av ett enda tecken ska lägga beslag på minst 6 uppdateringar av portexpandern!
-
JimmyAndersson
- Inlägg: 26470
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Ja du Icecap.. Du är inte dum du. Men det visste du redan. 
Jag har testat ditt tips med lysdioder.
Din kod har jag därför inte hunnit testa än, men den var väldigt snyggt strukturerad och utmärkt förklarad.
Tack för att du tog dig tiden att fixa det.
Jag ska testa den också.
Nedan använde jag Martas initiering, som jag haft med i de senaste testerna i tråden.
Jag har hittat en grej under sändningen av initierings-datan som är väldigt fel.
Titta från början och fram till strecken (----------):
Inte konstigt om initieringen hamnar fel då.
Förmodligen ligger den kvar i 8-bit läge.
Ganska skön upptäckt.
Jag har gjort om testet ett par gånger och det är precis samma sak
- om jag bryter matningspänningen mellan försöken.
Men! Om jag *inte* bryter matningspänningen, utan bara gör om testet
så skickar portexpandern ut rätt hela vägen.
Jag har även gjort om testet och haft LCD'n bortkopplad under tiden, men det är samma sak ändå.
Det här är lite småkryptiskt, för jag gör såhär:
Startar labaggregatet.
Väntar 6-7 sekunder innan jag är redo med block och programstart.
Startar programmet som sätter upp några konstanter.
Väntar 2-3 sekunder innan jag tryckt "the any-key".
Programmet tar kontakt med portexpandern via I2C. (En rad).
Väntar 2-3 sekunder innan jag tryckt "the any-key".
Programmet sätter upp några register för portexpandern.
Väntar 2-3 sekunder innan jag tryckt "the any-key".
och så kör den i gång med det jag visat i kodrutan.
Mellan varje rad i kodrutan ovan finns en "Press the any-key",
så det tar ett par sekunder innan jag antecknat och tryckt.
Så felet beror ju varken på att matningspänningen inte hunnit stabiliseras
eller att det går för fort under anrop/setup av portexpandern.
Lite skumt.
Jag har testat ditt tips med lysdioder.
Din kod har jag därför inte hunnit testa än, men den var väldigt snyggt strukturerad och utmärkt förklarad.
Tack för att du tog dig tiden att fixa det.
Jag ska testa den också.
Nedan använde jag Martas initiering, som jag haft med i de senaste testerna i tråden.
Jag har hittat en grej under sändningen av initierings-datan som är väldigt fel.
Titta från början och fram till strecken (----------):
Kod: Markera allt
Vid Power On visar lysdioderna 00000001(bit 7 - bit 0. Dvs RS = 1.)
När jag initierat portexpandern så visar lysdioderna 00000000.
Skickar Får
00000000 00000000 (Sätter RS=0)
Börjar initiering
00110000 00000000
00110110 00000000
00110000 00000000
#
00110000 00000000
00110110 00000000
00110000 00000000
#
00110000 00000000
00110110 00000000
00110000 00000000
#
00100000 00000000
00100110 00000000
00100000 00000000
#
00100000 00000000
00100110 00000000
00100000 00000000
# -------------
10000000 00000000
10000110 10000110
10000000 10000000
#
00010000 00010000
00010110 00010110
00010000 00010000
#
01000000 01000000
01000110 01000110
01000000 01000000
#
00000000 00000000
00000110 00000110
00000000 00000000
#
11100000 11100000
11100110 11100110
11100000 11100000
#
00000000 00000000
00000110 00000110
00000000 00000000
#
01100000 01100000
01100110 01100110
01100000 01100000
#
00000000 00000000
00000110 00000110
00000000 00000000
#
00100000 00100000
00100110 00100110
00100000 00100000
#
00000000 00000000
00000110 00000110
00000000 00000000
#
00010000 00010000
00010110 00010110
00010000 00010000
#KlarInte konstigt om initieringen hamnar fel då.
Förmodligen ligger den kvar i 8-bit läge.
Ganska skön upptäckt.
Jag har gjort om testet ett par gånger och det är precis samma sak
- om jag bryter matningspänningen mellan försöken.
Men! Om jag *inte* bryter matningspänningen, utan bara gör om testet
så skickar portexpandern ut rätt hela vägen.
Jag har även gjort om testet och haft LCD'n bortkopplad under tiden, men det är samma sak ändå.
Det här är lite småkryptiskt, för jag gör såhär:
Startar labaggregatet.
Väntar 6-7 sekunder innan jag är redo med block och programstart.
Startar programmet som sätter upp några konstanter.
Väntar 2-3 sekunder innan jag tryckt "the any-key".
Programmet tar kontakt med portexpandern via I2C. (En rad).
Väntar 2-3 sekunder innan jag tryckt "the any-key".
Programmet sätter upp några register för portexpandern.
Väntar 2-3 sekunder innan jag tryckt "the any-key".
och så kör den i gång med det jag visat i kodrutan.
Mellan varje rad i kodrutan ovan finns en "Press the any-key",
så det tar ett par sekunder innan jag antecknat och tryckt.
Så felet beror ju varken på att matningspänningen inte hunnit stabiliseras
eller att det går för fort under anrop/setup av portexpandern.
Lite skumt.
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Har du ställd in alla systemregister rätt i portexpandern?
-
JimmyAndersson
- Inlägg: 26470
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Jag har kollat igenom det flera gånger, men vi kan ta en titt i offentlighetens ljus.
Databladet till MCP23017: http://ww1.microchip.com/downloads/en/D ... 21952b.pdf
Och så min kod:
Jag är lite osäker på om jag valt rätt under "1.3.1 BYTE MODE AND SEQUENTIAL MODE" (Sida 5 i databladet.)
Jag använder ju en Raspberry Pi's I2C-port till portexpandern,
så jag antar att det är Raspberryn som någonstans ska vara inställd för att matcha portexpandern.
Men jag vet inte var man hittar infon om hur Raspberryn är inställd
och därför vet jag inte riktigt hur jag ska sätta de register som punkt 1.3.1 behandlar.
Nu begär jag inte att någon ska kolla igenom det och förklara, men jag skulle förstås bli glad.
edit:
Som ni ser så har jag inte ställt in interrupts och sådant,
men som jag förstått det så påverkar detta input, inte output.
Ok, jag vet vad som anses om icke satta register, så jag fixar dem också för säkerhet skull.
edit 2:
Nu har jag gjort läxan, så här är alla register i portexpanderns datablad med:
Det jag lade till nu var alltså:
Som ni ser så lade jag till GPIO.
Jag använder register OLATA för att skicka ut data från portexpandern.
OLATA har alltid funnits med i min setup av portexpandern.
edit:
Senaste testet var att köra med GPIOA istället för OLATA,
men då fick jag inte ut något alls från portexpandern.
Undrar om det är jag som är ovanligt dum aftonen till ära eller om det är kretsen som är trasig.
Synd att jag bara köpte en sådan krets. Annars hade det gått fort att verifiera det sistnämnda också.
edit 2:
Jag hittade en intressant sak: En bugg kring clock-stretching av I2C-bussen i Raspberry Pi.
http://www.advamation.com/knowhow/raspb ... c-bug.html
Men frågan är isåfall varför min DS2482 (I2C-1wire-bridge) fungerar felfritt
när inte portexpandern (MCP23017) gör det...
Lite samlade trådar som jag hittat när jag letat efter info om problemet:
http://www.raspberrypi.org/phpBB3/viewt ... 0&p=302378
http://www.microchip.com/forums/m628744.aspx
http://www.raspberrypi.org/phpBB3/viewt ... 44&t=13771
Quick2Wire ska tydligen vara en kompatibel variant av I2C som kan fungera bättre,
men det finns inte längre på deras sajt vad jag kan se:
http://quick2wire.com/
Här är förresten de SMbus/I2C-kommandon som Python stödjer:
http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc
Jag kör med write_byte_data(addr,cmd,val)
SMbus-protokollet:
http://git.kernel.org/cgit/linux/kernel ... s-protocol
Nu är det ju inte helt säkert att mitt problem bero på detta,
eftersom kommunikationen kommer igång efter ett tag.
Men det var intressant läsning.
Jag tänkte testa write_i2c_block_data(addr,cmd,vals)
istället för write_byte_data(addr,cmd,val).
Men icke...
Den här raden:
bus.write_i2c_block_data(DEVICE, OLATA, 0) # RS
ger:
"Traceback (most recent call last):
File "LCD-test2c.py", line 110, in <module>
bus.write_i2c_block_data(DEVICE, OLATA, 0) # RS
TypeError: Third argument must be a list of at least one, but not more than 32 integers"
Jag har provat 0x00 istället, men nej.
Det finns inget tal någonstans som är större än 255 (0xFF). Inte ens i närheten.
DEVICE = 0x22
OLATA = 0x0A
Jag börjar bli lite småputt på det här projektet...
Lärde mig Python på en eftermiddag, byggde upp allt på en annan.
Gjorde trevliga Python-klasser och bibliotek och kunde initiera efter en kväll.
Men det har man förstås inget för. För naturligtvis blir det tvärstopp på något så oväntat
som att data bara bestämmer sig för att sluta dyka upp på andra sidan kretsen.
Portexpandern har ju en A och B port.
Jag ska kolla om B är lika B som A.
edit igen:
Port B ignorerar mig totalt.
Gjorde precis likadant som innan, men bytte OLATA mot OLATB.
Båda de registren är konfigurerade likadant, men då förstås mot olika portar.
Nä men om man skulle beställa lite nya kretsar kanske.......
Electrokit brukar ta någon vecka på sig. Elfa verkar inte leverera till dagen efter längre.
Får se vad jag hittar för leverantör.
Databladet till MCP23017: http://ww1.microchip.com/downloads/en/D ... 21952b.pdf
Och så min kod:
Kod: Markera allt
# Definiera adresser
DEVICE = 0x22 # Adressen till min krets på I2C-bussen.
# A
IODIRA = 0x00 # Register for pin direction. In or Out
OLATA = 0x0A # Register for outputs (When IOCON.BANK=1)
GPIOA = 0x09 # Register for inputs (When IOCON.BANK=1)
GPPUA = 0x06
# B
IODIRB = 0x10
OLATB = 0x1A
GPIOB = 0x19
GPPUB = 0x16
#
IOCON = 0x04
# - - - - - -
bus = smbus.SMBus(1) # I2C-bussen och vilken kanal.
#Bank 1. No mirror in INT. Sequential operation enabled. (IOCON: Sid 18 i databladet.)
bus.write_byte_data(DEVICE, IOCON, 0b10000000)
# Pull-up disabled for inputs
bus.write_byte_data(DEVICE, GPPUA, 0x00)
bus.write_byte_data(DEVICE, GPPUB, 0x00)
# Set all GPA and GPB pins as outputs by setting
# all bits of IODIRA and IODIRB register to 0
bus.write_byte_data(DEVICE,IODIRA, 0x00)
bus.write_byte_data(DEVICE,IODIRB, 0x00)
# Set output all 7 output bits to 0 on GPA and GPB
bus.write_byte_data(DEVICE,OLATA, 0x00)
bus.write_byte_data(DEVICE,OLATB, 0x00)Jag är lite osäker på om jag valt rätt under "1.3.1 BYTE MODE AND SEQUENTIAL MODE" (Sida 5 i databladet.)
Jag använder ju en Raspberry Pi's I2C-port till portexpandern,
så jag antar att det är Raspberryn som någonstans ska vara inställd för att matcha portexpandern.
Men jag vet inte var man hittar infon om hur Raspberryn är inställd
och därför vet jag inte riktigt hur jag ska sätta de register som punkt 1.3.1 behandlar.
Nu begär jag inte att någon ska kolla igenom det och förklara, men jag skulle förstås bli glad.
edit:
Som ni ser så har jag inte ställt in interrupts och sådant,
men som jag förstått det så påverkar detta input, inte output.
Ok, jag vet vad som anses om icke satta register, så jag fixar dem också för säkerhet skull.
edit 2:
Nu har jag gjort läxan, så här är alla register i portexpanderns datablad med:
Kod: Markera allt
# Definiera adresser
DEVICE = 0x22 # Adressen till min krets på I2C-bussen
# A
IODIRA = 0x00 # Register for pin direction. In or Out
OLATA = 0x0A # Register for outputs (When IOCON.BANK=1)
GPIOA = 0x09 # Register for inputs (When IOCON.BANK=1)
IPOLA = 0x01 # Register for input polarity
GPINTENA = 0x02 # Interrupt on change. Enable/Disable.
DEFVALA = 0x03 # Default value for interrupt-on-change.
INTCONA = 0x04 # Intterupt on change. Control.
# B
IODIRB = 0x10
OLATB = 0x1A
GPIOB = 0x19
IPOLB = 0x11
GPINTENB = 0x12
DEFVALB = 0x13
INTCONB = 0x14
#
IOCON = 0x04
GPPUA = 0x06
GPPUB = 0x16
# - - - - - -
bus = smbus.SMBus(1) # I2C-bussen och vilken kanal.
#Bank 1. No mirror in INT. Sequential operation enabled.
bus.write_byte_data(DEVICE, IOCON, 0b10000000)
#Interrupt on change. Disable GPIO input for interrupt-on-change
bus.write_byte_data(DEVICE, GPINTENA, 0b00000000)
bus.write_byte_data(DEVICE, GPINTENB, 0b00000000)
#Default value for interrupt-on-change-pins.
bus.write_byte_data(DEVICE, DEFVALA, 0b00000000)
bus.write_byte_data(DEVICE, DEFVALB, 0b00000000)
#Pin value is compared against the previous pin value.
bus.write_byte_data(DEVICE, INTCONA, 0b00000000)
bus.write_byte_data(DEVICE, INTCONB, 0b00000000)
#Input polarity. Input will reflect the same logic state.
bus.write_byte_data(DEVICE, IPOLA, 0b00000000)
bus.write_byte_data(DEVICE, IPOLB, 0b00000000)
# Pull-up disabled for inputs
bus.write_byte_data(DEVICE, GPPUA, 0b00000000)
bus.write_byte_data(DEVICE, GPPUB, 0b00000000)
# Set all GPA and GPB pins as outputs by setting
# all bits of IODIRA and IODIRB register to 0
bus.write_byte_data(DEVICE,IODIRA, 0x00)
bus.write_byte_data(DEVICE,IODIRB, 0x00)
#GPIO port. All to 0.
bus.write_byte_data(DEVICE, GPIOA, 0x00)
bus.write_byte_data(DEVICE, GPIOB, 0x00)
# Set output all 7 output bits to 0 on GPA and GPB
bus.write_byte_data(DEVICE,OLATA, 0x00)
bus.write_byte_data(DEVICE,OLATB, 0x00)
# - - - - - -Det jag lade till nu var alltså:
Kod: Markera allt
IPOLA = 01h
IPOLB = 11h
GPINTENA = 02h
GPINTENB = 12h
DEFVALA = 03h
DEFVALB = 13h
INTCONA = 04h
INTCONB = 14h
#Input polarity. Input will reflect the same logic state.
IPOL = 0b00000000
#Interrupt on change. Disable GPIO input for interrupt-on-change
GPINTEN = 0b00000000
#Default value for interrupt-on-change-pins.
DEFVAL = 0b00000000
#Pin value is compared against the previous pin value.
INTCON = 0b00000000
#GPIO pull-upp resistor. Disabled
GPPU = 0b00000000
#GPIO port. Alla 0.
GPIO = 0b00000000Jag använder register OLATA för att skicka ut data från portexpandern.
OLATA har alltid funnits med i min setup av portexpandern.
edit:
Senaste testet var att köra med GPIOA istället för OLATA,
men då fick jag inte ut något alls från portexpandern.
Undrar om det är jag som är ovanligt dum aftonen till ära eller om det är kretsen som är trasig.
Synd att jag bara köpte en sådan krets. Annars hade det gått fort att verifiera det sistnämnda också.
edit 2:
Jag hittade en intressant sak: En bugg kring clock-stretching av I2C-bussen i Raspberry Pi.
http://www.advamation.com/knowhow/raspb ... c-bug.html
Men frågan är isåfall varför min DS2482 (I2C-1wire-bridge) fungerar felfritt
när inte portexpandern (MCP23017) gör det...
Lite samlade trådar som jag hittat när jag letat efter info om problemet:
http://www.raspberrypi.org/phpBB3/viewt ... 0&p=302378
http://www.microchip.com/forums/m628744.aspx
http://www.raspberrypi.org/phpBB3/viewt ... 44&t=13771
Quick2Wire ska tydligen vara en kompatibel variant av I2C som kan fungera bättre,
men det finns inte längre på deras sajt vad jag kan se:
http://quick2wire.com/
Här är förresten de SMbus/I2C-kommandon som Python stödjer:
http://wiki.erazor-zone.de/wiki:linux:python:smbus:doc
Jag kör med write_byte_data(addr,cmd,val)
SMbus-protokollet:
http://git.kernel.org/cgit/linux/kernel ... s-protocol
Nu är det ju inte helt säkert att mitt problem bero på detta,
eftersom kommunikationen kommer igång efter ett tag.
Men det var intressant läsning.
Jag tänkte testa write_i2c_block_data(addr,cmd,vals)
istället för write_byte_data(addr,cmd,val).
Men icke...
Den här raden:
bus.write_i2c_block_data(DEVICE, OLATA, 0) # RS
ger:
"Traceback (most recent call last):
File "LCD-test2c.py", line 110, in <module>
bus.write_i2c_block_data(DEVICE, OLATA, 0) # RS
TypeError: Third argument must be a list of at least one, but not more than 32 integers"
Jag har provat 0x00 istället, men nej.
Det finns inget tal någonstans som är större än 255 (0xFF). Inte ens i närheten.
DEVICE = 0x22
OLATA = 0x0A
Jag börjar bli lite småputt på det här projektet...
Lärde mig Python på en eftermiddag, byggde upp allt på en annan.
Gjorde trevliga Python-klasser och bibliotek och kunde initiera efter en kväll.
Men det har man förstås inget för. För naturligtvis blir det tvärstopp på något så oväntat
som att data bara bestämmer sig för att sluta dyka upp på andra sidan kretsen.
Portexpandern har ju en A och B port.
Jag ska kolla om B är lika B som A.
edit igen:
Port B ignorerar mig totalt.
Gjorde precis likadant som innan, men bytte OLATA mot OLATB.
Båda de registren är konfigurerade likadant, men då förstås mot olika portar.
Nä men om man skulle beställa lite nya kretsar kanske.......
Electrokit brukar ta någon vecka på sig. Elfa verkar inte leverera till dagen efter längre.
Får se vad jag hittar för leverantör.
-
JimmyAndersson
- Inlägg: 26470
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Äventyren fortsätter.
Jag har fuskat lite.
Efter att jag ställt in portexpandern så skickar jag lite skräpdata:
(Python är ju lite "kul" så range(1,11) betyder att den kör 1 - 10.)
Det här får ju portexpanderns utgångar att vakna.
(Den missade ju 17 bytes tidigare, men jag kör ett par extra.)
Efter detta är det inga problem att initiera displayen korrekt och skriva lite tecken.
Ett eget tecken då?
Nej, det blir precis samma sak som innan jag gjorde tråden för snart en vecka sedan. Suck.
Alla lysdioder visar precis exakt 100% rätt.
Här är koden för CGRAM-grejerna:
Resultatet:
Så fort den börjar skicka data för själva tecknet så hoppar markören ner på rad 2
och börjar stega framåt kolumn för kolumn.
Kan någon kolla så att jag sätter GRAM-adressen rätt? Dvs rad 8 - 28.
Jag har aldrig fått det bekräftat i tråden.
Jag såg att jag missat att svara på lite från Icecap:
[om testet med lysdioder]
"Detta sätt är långsamt, tråkigt - och ger ett stensäkert bild av vad som händer! Den tid det tar att göra såhär är definitivt kortare än det (som jag uppfattar det) hattande och antagande som du har gjort tidigare."
Du får ju uppfatta det som du vill naturligtvis,
men jag följt ALLA tips som ni har gett mig.
Att de sedan kommer i den ordning att jag först kollar mjukvara för att nästa gång kolla display
och sedan portexpander, för att i nästa gång handla om mjukvara och och portexpander igen..
ja det kan ju faktiskt inte jag rå för:
Jag tar allt i tur och ordning som ni skriver för att ni tydligt ska kunna se att jag inte ignorerar något tips.
Och jag gör mitt bästa.
Naturligtvis är det svårt att förklara i ord, så jag är tacksam att jag fick ett par av dig,
så härmed kallar vi min kämparglöd för "hattande och antagande".
Jag kunde inte bry mig mindre om det.
För jag har en display som jag ska få igång.
Du får gärna hjälpa till om du har tid.
Ja, förutsatt att inte mitt hattande och antagande är för jobbigt för dig.
Jag har fuskat lite.
Efter att jag ställt in portexpandern så skickar jag lite skräpdata:
Kod: Markera allt
for junk in range(1,11):
bus.write_byte_data(DEVICE, OLATA, 0b10000000)
sleep(0.01)
bus.write_byte_data(DEVICE, OLATA, 0b01000000)
sleep(0.01)
bus.write_byte_data(DEVICE, OLATA, 0b00000000)Det här får ju portexpanderns utgångar att vakna.
(Den missade ju 17 bytes tidigare, men jag kör ett par extra.)
Efter detta är det inga problem att initiera displayen korrekt och skriva lite tecken.
Ett eget tecken då?
Nej, det blir precis samma sak som innan jag gjorde tråden för snart en vecka sedan. Suck.
Alla lysdioder visar precis exakt 100% rätt.
Här är koden för CGRAM-grejerna:
Kod: Markera allt
print("Now, how about a character of our own?")
#
#
print("First, RS should be set to 0.")
raw_input("\n\nPress the any-key to set RS = 0.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000000) # RS
print("RS = 0")
print("Then, the CGRAM-adress.")
raw_input("\n\nPress the any-key to set the CGRAM.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01000000) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01000110) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01000000) # E off
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000000) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000110) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000000) # E off
raw_input("\n\nDone! Press the any-key.\n\n")
print("Now, RS should be set to 1.")
raw_input("\n\nPress the any-key to set RS = 1.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # RS
raw_input("\n\nPress the any-key to send character-data.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00010001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00010111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00010001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00110001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00110111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00110001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b01110001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01110111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01110001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b11110001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b11110111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b11110001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b01110001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01110111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b01110001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00110001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00110111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00110001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00010001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00010111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00010001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # DB
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000111) # E on
raw_input("\n\nPress the any-key.\n\n")
bus.write_byte_data(DEVICE, OLATA, 0b00000001) # E off
raw_input("\n\nPress the any-key.\n\n")
#Resultatet:
Så fort den börjar skicka data för själva tecknet så hoppar markören ner på rad 2
och börjar stega framåt kolumn för kolumn.
Kan någon kolla så att jag sätter GRAM-adressen rätt? Dvs rad 8 - 28.
Jag har aldrig fått det bekräftat i tråden.
Jag såg att jag missat att svara på lite från Icecap:
[om testet med lysdioder]
"Detta sätt är långsamt, tråkigt - och ger ett stensäkert bild av vad som händer! Den tid det tar att göra såhär är definitivt kortare än det (som jag uppfattar det) hattande och antagande som du har gjort tidigare."
Du får ju uppfatta det som du vill naturligtvis,
men jag följt ALLA tips som ni har gett mig.
Att de sedan kommer i den ordning att jag först kollar mjukvara för att nästa gång kolla display
och sedan portexpander, för att i nästa gång handla om mjukvara och och portexpander igen..
ja det kan ju faktiskt inte jag rå för:
Jag tar allt i tur och ordning som ni skriver för att ni tydligt ska kunna se att jag inte ignorerar något tips.
Och jag gör mitt bästa.
Naturligtvis är det svårt att förklara i ord, så jag är tacksam att jag fick ett par av dig,
så härmed kallar vi min kämparglöd för "hattande och antagande".
Jag kunde inte bry mig mindre om det.
För jag har en display som jag ska få igång.
Du får gärna hjälpa till om du har tid.
Ja, förutsatt att inte mitt hattande och antagande är för jobbigt för dig.
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Kod: Markera allt
const unsigned char LCD_INIT[7] = {0x38,0x38,0x38,0x38,0x0C,0x01,0x06}; /* 16x2 */
const unsigned char LCD_Chars[64] = {
0x00,0x00,0x1C,0x04,0x1C,0x10,0x1C,0x00, /* 00h/08h Subscript '2' */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 01h/09h */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 02h/0Ah */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 03h/0Bh */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 04h/0Ch */
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 05h/0Dh */
0x0C,0x12,0x12,0x0C,0x00,0x00,0x00,0x00, /* 06h/0Eh */
0xFF,0x00,0x00,0x00,0x00,0x00,0xFF,0x00};/* 07h/0Fh */
volatile unsigned char x;
LCD_NPower = 0; /* Turn on power to LCD */
LCD_Control &= ~LCD_Cont_Bit; /* Inactivate the bits */
LCD_Data = 0x00; /* Set to 0x00 */
LCD_Delay_40ms();
for(x = 0;x < sizeof(LCD_INIT);x++)
{ /* First initialize the LCD mode */
LCD_Data = LCD_INIT[x];
LCD_Delay_Setup();
LCD_Shake_Enable();
LCD_Delay_1530us();
}
LCD_Data = 0x40; /* Load own char's command */
LCD_Delay_Setup();
LCD_Shake_Enable();
LCD_RS = 1;
LCD_Delay_60us();
for(x = 0;x < sizeof(LCD_Chars);x++)
{
LCD_Data = LCD_Chars[x];
LCD_Delay_Setup();
LCD_Shake_Enable();
LCD_Delay_60us();
}
LCD_RS = 0;
LCD_Delay_60us();
}
Re: HD44780-kompatibel display: Kommer inte över till CGRAM.
Eftersom Du inte kunde få portexpanderns PORTB att fungera så är det något med kommunikationen till denna som inte fungerar. Lös detta innan Du fortsätter att rota i sekvenserna som skickas till displayen. Antingen det nu är procedurfel eller trasig hårdvara. Du nämnde att alla pinnarna behövdes, så detta måste hur som helst lösas. Alldeles bortsett från de stora potentiella problem det innebär att något är trasigt eller feluppfattat så det saknas kontroll över vad som händer.
Tyvärr har jag ingen sådan här portexpander liggande, det hade varit intressant att prova vad som händer genom att skicka data från en PIC skrivet i assembler helt utan obekanta faktorer inblandade. Du har kanske själv denna möjlighet att testa med någon enklare anordning att skicka data från? Utan scriptspråk och annat klabb, direkt mot hårdvaran.
Detta är långsökt, men Microchip har haft problem tidigare med firmwarebug i en annan MCP???? i början då denna kom ut, men som sedan rättades till. Är det ett tidigt tillverkningsdatum på den krets Du har så kan det knappast uteslutas helt att den inneåller en bug.
Angående "1.3.1 BYTE MODE AND SEQUENTIAL MODE" så skall Du stänga av detta så som Du avänder kretsen. Det är en funktion som inkrementerar registeradressen mellan varje skrivning så kretsen kan initieras snabbare med att endast skicka databytes iställt för hela adressen till varje register.
När hel adress skickas varje gång så borde det inte ha betydelse, men bäst att stänga av alla finesser som inte används...
Tyvärr har jag ingen sådan här portexpander liggande, det hade varit intressant att prova vad som händer genom att skicka data från en PIC skrivet i assembler helt utan obekanta faktorer inblandade. Du har kanske själv denna möjlighet att testa med någon enklare anordning att skicka data från? Utan scriptspråk och annat klabb, direkt mot hårdvaran.
Detta är långsökt, men Microchip har haft problem tidigare med firmwarebug i en annan MCP???? i början då denna kom ut, men som sedan rättades till. Är det ett tidigt tillverkningsdatum på den krets Du har så kan det knappast uteslutas helt att den inneåller en bug.
Angående "1.3.1 BYTE MODE AND SEQUENTIAL MODE" så skall Du stänga av detta så som Du avänder kretsen. Det är en funktion som inkrementerar registeradressen mellan varje skrivning så kretsen kan initieras snabbare med att endast skicka databytes iställt för hela adressen till varje register.
När hel adress skickas varje gång så borde det inte ha betydelse, men bäst att stänga av alla finesser som inte används...
