Först hoppas jag att du får ordning på projektet i ASM.
Därnäst kan jag faktisk inte låta bli: VAD VAR DET JAG SA??!!!?!?! BASIC suger!!!!!!!!!
Sådär, nu är det ute ur systemet.
Det svåraste i programmering är att få överskådlighet, olika språk har olika uppbyggnad som hjälper/stjälper med denna överskådlighet och BASIC är inte ett speciellt bra språk för överskådlighet.
Men den största faktor är programmören, inte språket! Att bryta ner ett program i moduler kan vara totalt likgiltigt om dessa moduler är dåligt valda. Ett exempel är att du kallar en lcd_delay och det är i DEN som Strobe aktiveras!
Som jag ser det ska den rutin som skriver ut en byte göra HELA utskrivningen, en delay ska vara just enbart delay osv. vara sig du kör assembler/BASIC/C eller annat.
Virrigt problem med PIC-kod.
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
"Därnäst kan jag faktisk inte låta bli: VAD VAR DET JAG SA??!!!?!?! BASIC suger!!!!!!!!! "
Jo, man kanske inte bör göra såhär stora program i Basic. Det blir bara komplicerat. Däremot tror jag (åminstone än så länge) att Basic är praktiskt för mindre grejjer. Tester, LED/fläkt-styrning mm, som jag skrev i en annan tråd. Det kanske kommer visa sig att jag har fel, men då blir man en erfarenhet rikare.
Håller med om att det inte är så logiskt att ändra E i en procedur som heter lcd_delay. Namnet kanske kan diskuteras, men att E-skakningen finns med i samma rutin som delayet tycker jag är en bra idé. Utan E så skulle proceduren vara onödig. Jag kunde då lika gärna ha lagt delayen direkt i den övriga lcd-koden och då hade det blivit såhär:
LATA = %00000011
delay_us(500)
E = 1
delay_us(500)
E = 0
LATA = %00000011
delay_us(500)
E = 1
osv...
Jämför man med hur jag kört nu så blir det lite bättre:
LATA = %00000011
lcd_vanta
LATA = %00000011
lcd_vanta
osv...
Sedan om proceduren heter lcd_vanta, lcd_wait eller lcd_wait_and_shake_e gör inte proceduren till ett dåligt val. Så länge man håller sig till en standard (egen eller befintlig) och har koll på vad som är vad så är man på rätt väg.
Att jag försöker använda med "svenska" namn på procedurer och variabler beror på två orsaker:
1) Ännu lättare att hålla isär vad som är "mina grejjer" och vad som är "programmeringspråkets".
2) I princip obefintlig chans att man använder ord som är reserverade för programmeringspråket.
Då och då får man plocka bort å ä ö, men vem är inte van vid det med tanke på URL'er och mailadresser...
Jo, man kanske inte bör göra såhär stora program i Basic. Det blir bara komplicerat. Däremot tror jag (åminstone än så länge) att Basic är praktiskt för mindre grejjer. Tester, LED/fläkt-styrning mm, som jag skrev i en annan tråd. Det kanske kommer visa sig att jag har fel, men då blir man en erfarenhet rikare.
Håller med om att det inte är så logiskt att ändra E i en procedur som heter lcd_delay. Namnet kanske kan diskuteras, men att E-skakningen finns med i samma rutin som delayet tycker jag är en bra idé. Utan E så skulle proceduren vara onödig. Jag kunde då lika gärna ha lagt delayen direkt i den övriga lcd-koden och då hade det blivit såhär:
LATA = %00000011
delay_us(500)
E = 1
delay_us(500)
E = 0
LATA = %00000011
delay_us(500)
E = 1
osv...
Jämför man med hur jag kört nu så blir det lite bättre:
LATA = %00000011
lcd_vanta
LATA = %00000011
lcd_vanta
osv...
Sedan om proceduren heter lcd_vanta, lcd_wait eller lcd_wait_and_shake_e gör inte proceduren till ett dåligt val. Så länge man håller sig till en standard (egen eller befintlig) och har koll på vad som är vad så är man på rätt väg.
Att jag försöker använda med "svenska" namn på procedurer och variabler beror på två orsaker:
1) Ännu lättare att hålla isär vad som är "mina grejjer" och vad som är "programmeringspråkets".
2) I princip obefintlig chans att man använder ord som är reserverade för programmeringspråket.
Då och då får man plocka bort å ä ö, men vem är inte van vid det med tanke på URL'er och mailadresser...
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Funderade lite på det sodjan skrev:
"Jag är inte riktigt säker här, men notera att en HD44780 kontroller
tar lite olika tid på sig för att göra olika saker. Jag vet dock inte om
"flytta cursor" hör till de som tar "extra" tid."
Sant. "Flytta cursor" tar 39µs. Min delay är på 500µs, så jag har god marginal.
Men när jag plockar bort problemraden så flyttas markören flera gånger. Kan även hålla inne knapparna och få massa interrupt. Ändå fungerar allt och LCDn hinner flytta markören. Så då vågar jag nog påstå att själva LCD-skrivningsdelarna inte har något med problemet att göra.
"> Vad kan det beror på att jag får (iallafall rent visuellt) random-tecken
> på displayen när jag ändrar smågrejjer i koden?
Timing problem i koden eller R-M-W fenomen (du fipplar ju med CE, RS
o.s.v med bit-operationer, antar jag). "
När jag fipplar med dem så använder jag LAT, så då borde jag inte få R-M-W-problem. Timing-problem... mja, möjligen, men nog borde 39st "skriv ut bokstav" följt av "flytta markör" ha större potential att ge timingproblem än ett anrop till en procedur som enbart skriver ut ett "A" ?
Den proceduren ska dessutom bara köras när jag fått ett interrupt på ADC'n och den har gett ett värde som ligger mellan 169-179. Men proceduren verkar köras utan att man gör något annat än att ge PIC'en spänning, för om jag plockar bort raden som kör proceduren så fungerar allt felfritt.
"Jag är inte riktigt säker här, men notera att en HD44780 kontroller
tar lite olika tid på sig för att göra olika saker. Jag vet dock inte om
"flytta cursor" hör till de som tar "extra" tid."
Sant. "Flytta cursor" tar 39µs. Min delay är på 500µs, så jag har god marginal.
Men när jag plockar bort problemraden så flyttas markören flera gånger. Kan även hålla inne knapparna och få massa interrupt. Ändå fungerar allt och LCDn hinner flytta markören. Så då vågar jag nog påstå att själva LCD-skrivningsdelarna inte har något med problemet att göra.
"> Vad kan det beror på att jag får (iallafall rent visuellt) random-tecken
> på displayen när jag ändrar smågrejjer i koden?
Timing problem i koden eller R-M-W fenomen (du fipplar ju med CE, RS
o.s.v med bit-operationer, antar jag). "
När jag fipplar med dem så använder jag LAT, så då borde jag inte få R-M-W-problem. Timing-problem... mja, möjligen, men nog borde 39st "skriv ut bokstav" följt av "flytta markör" ha större potential att ge timingproblem än ett anrop till en procedur som enbart skriver ut ett "A" ?
Den proceduren ska dessutom bara köras när jag fått ett interrupt på ADC'n och den har gett ett värde som ligger mellan 169-179. Men proceduren verkar köras utan att man gör något annat än att ge PIC'en spänning, för om jag plockar bort raden som kör proceduren så fungerar allt felfritt.
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
-
Jim_the_one
- Inlägg: 1669
- Blev medlem: 8 december 2004, 00:03:49
- Ort: Falköping
Jimmy: "Jo, man kanske inte bör göra såhär stora program i Basic. Det blir bara komplicerat. Däremot tror jag (åtminstone än så länge) att Basic är praktiskt för mindre grejer."
Att ett högre nivå språk än ASM kan vara snabbare när man väl har fattat hur processorn fungerar kan definitivt vara sant, har man inte timingskänsliga funktioner men att BASIC är bättre till detta än C.... tillåt mig ett rått skratt.
Men om du någon gång kommer in i C-världen lär du upptäcka skillnaden.
Men vilket språk man än väljer kommer det knappast att bli bättre än programmören: väljer man flyttal där heltal hade varit lika bra osv kommer det såklart att påverka funktion och hastighet.
Att ett högre nivå språk än ASM kan vara snabbare när man väl har fattat hur processorn fungerar kan definitivt vara sant, har man inte timingskänsliga funktioner men att BASIC är bättre till detta än C.... tillåt mig ett rått skratt.
Men om du någon gång kommer in i C-världen lär du upptäcka skillnaden.
Men vilket språk man än väljer kommer det knappast att bli bättre än programmören: väljer man flyttal där heltal hade varit lika bra osv kommer det såklart att påverka funktion och hastighet.
