Virrigt problem med PIC-kod.

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
pheer
EF Sponsor
Inlägg: 1283
Blev medlem: 16 januari 2005, 18:05:21

Inlägg av pheer »

Anropar du proceduren med den raden eller menar du egentligen
sub procedure lcd_variabel2(dim value_c, rs_bit_c, var1_c, var2_c as byte)?

Om du anropar den så är jag inne på samma spår som Kaggen. Anropa
såhär istället: lcd_variabel2(value, rs_bit, var1, var2). Gärna med
variablenamn som inte heter som funktionsparametrarna.

Och man får väl anta att du anropar med rätt värde på rs!
Nu kommer vi till problemet: När jag har med raden
lcd_variabel2(dim value_c, rs_bit_c, var1_c, var2_c as byte)
så blir den översta raden på displayen full med svarta rutor. Den undre
raden är tom. Om jag plockar bort kod-raden ovan så fungerar hela
programmet (som bl.a visar en meny på displayen.)
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

Skrev lite fel där. Det ska vara "Om jag däremot tar bort raden lcd_variabel2(value_c, rs_bit_c, var1_c, var2_c)...", dvs ingen 'dim' där. I resten av tråden står det rätt.

Det är alltså så att jag anropar proceduren med:
lcd_variabel2(value_c, rs_bit_c, var1_c, var2_c)

Så jag gör precis som ni skrivit.
För att utesluta att namnen påminner om andra namn så testade jag att byta ut namnen lite.

Anropar proceduren med:

lcd_bah(tjo, 3, %1000, %0010)



och själva proceduren ser ut såhär:

Kod: Markera allt

sub procedure lcd_bah(dim value_c, rs_bit_c, var1_c, var2_c as byte)

lcd_skriv(59, 3, %1000, %0111)

end sub

Men då verkar det som att programmet fastnar. Först ser man bara "U V" och efter 34sek så gör det vad det ska.

Efter att ha resetat några gånger så verkar det fungera, bortsett från att det fastnar sådär i början.

Hur kan det bli så när jag lägger till "anrops-raden"?? Den ska inte ens kunna köras så länge man inte trycker på encoderns knapp. Om det är något interrupt som slår till så borde det ju bli samma sak om jag plockar bort raden.


edit: Testade att kompilera om samma kod. Displayen fylls på båda rader med svarta rutor. Startar om labbagget och då visas slumpmässiga tecken som blinkar och flyttar på sig. Det blir mest action när man trycker på någon av de "vanliga" knapparna. När jag tryckte på encoderns knapp så töms displayen ..och är fortfarande tom när jag skrivit detta.
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Inlägg av sodjan »

WDT ?
Stack overflow ?
Finns det LST eller MAP filer som man kan kolla att allt ser "OK" ut ?
Kaggen
Inlägg: 432
Blev medlem: 29 januari 2005, 03:06:02

Inlägg av Kaggen »

Tycker problemet låter komplicerat, det kan bero på många faktorer inklusive sådant vi inte "ser" här på forumet. Allt från koppling till kod.

Jag tror du måste börja strippa ner koden. Jag skulle gjort en kopia på ditt projekt (koden alltså) och sedan börjat radera eller kommentera bort det mesta så att programmet inte gör annat än slänger ut något på LCDn utan interrupt/tryckavkänning och sådant.

Om detta funkar har du antagligen problem med koden. Om minimal kod inte heller funkar, kan det vara kopplingen som det är nå knas med. Antar att du använder avkopplingskondingar och räknar med kontaktstuds på tryckknappar och liknande? Du har mätt att matningsspänning (LCD och PIC) och eventuellt andra spänningar stämmer?

Jag hade mycket konstiga problem en gång när jag labbade och upptäckte att det berodde på att jag ställt ner strömmen på mitt lab-aggregat, vilket innebar att vid vissa tillfällen när mitt "bygge" drog mer ström än labbagget levererade fick skiten spel. Tog ett tag innan jag kom på det felet :P

Kolla speciellt sådant du är helt säker på att du gjort riktigt. :)
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

WDT är disabled.

Har inte fått något felmeddelande om Stack overflow.

Läste även att:
"mikroBasic limits the number of non-recursive nested calls to 31 calls for PIC18 family. If the allowed number of nested calls is exceeded, compiler will report stack overflow error."

Jag är bara uppe i 5st.


Tyvärr finns det inga LST eller MAP-filer. Det finns bara lite statistik för procedurerna som visar storlekar de har och vilka adresser de ligger på.
Har även kikat igenom den genererade asm-koden. Lite rörig, som vanligt i MikroBasic, men ser inget uppenbart konstigt ut.
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

Kaggen: Det räcker med att jag plockar bort raden lcd_variabel2(value_c, rs_bit_c, var1_c, var2_c) så fungerar allt. Har även börjat om totalt från början en gång.

Labbagget kan ge 4A och så mycket drar inte en 18F1320, en display (visserligen med backlight) och 6st knappar.

Jag har kondingar av rekommenderade storlekar på knappingången (som är en analog ingång) och även direkt över matningspinnarna till PIC-kretsen. Det sitter även en 1000µF över matningen till labbplattan, knappt 2cm ifrån PIC-kretsen.

Elektronik kan visserligen ge märkliga resultat och man ska aldrig ta något för givet, men labbplattan är likadant kopplad oavsett om jag har den berömda raden med i koden eller inte, så om det var något sådant problem så skulle jag med ganska stor sannorlikhet ha märkt det även om jag inte hade detta procedur-anrop i koden.


edit: Missade några frågor. Jepp, jag har "designat bort" kontaktstudsar och har mätt så jag får rätt spänning.


edit 2: Testade att disabla alla interruptmöjligheter. Scrollningen av texten stannar halvvägs och det visas ett ü på nedersta raden. Samma sak varje gång jag resetar. Jag tycker att det verkar som att displayen visar lite olika resultat varje gång jag ändrar någon liten detalj i koden, även om jag bara döper om en variabel.

Programmerade om koden igen. Displayen visar likadant.
Kompilerar om samma kod igen och programmerar om. Displayen visar likadant.
pheer
EF Sponsor
Inlägg: 1283
Blev medlem: 16 januari 2005, 18:05:21

Inlägg av pheer »

En annan grej. Borde det inte vara: (jag har för mig att index börjar på 1 i basic, i vb är det så iaf)

Kod: Markera allt

for tecken = 1 to antal 
Om index börjar på 0 ska det vara:

Kod: Markera allt

for tecken = 0 to antal-1 
Kaggen
Inlägg: 432
Blev medlem: 29 januari 2005, 03:06:02

Inlägg av Kaggen »

JimmyAndersson: Du menar alltså att om du tar bort den enda raden (anropet till lcd_variabel2) funkar allt klockrent?

Det finns inga speciella definitioner för delat minne eller minnesbanker i BASICen? Jag menar ifall vissa variabler rent fysiskt använder samma minne som t.ex. union deklarationen i C? Jag antar att BASICen borde hålla reda på minnesbanker (typ banksel i assembler)åt dig, så inte vissa variabler pekar på en position och du befinner dig i fel minnesbank.

Det är inget som behöver typkonverteras när du anropar funktioner? T.ex att value_c är definierad som en byte fast fuktionen lcd_variable2 förväntar sig ett 16-bitars ord eller en sträng eller ett signerat heltal eller något sådant?

I ett inlägg ovan skrev du följande rad:

lcd_skriv(59, 3, %1000, %0111)

Hur ser BASICen skillnaden mellan att du skriver 59 med siffror och "H"? I C är allt som står mellan dubbla citat (som "H") en noll terminerad sträng medans 59 kan vara en signerad byte och t.ex 'H' (observera enkelcitat) är ett tecken/osignerad byte. Med andra ord är det en vital skillnad mellan "H" och 'H' eller 59 i C, vet ej hur det är i din BASIC.
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

Pheer:
Tyvärr inte. Basic klarar att börja for-loopar med 0. Dessutom har jag plockat bort den for-loopen men det vill ändå inte.

Vad kan det beror på att jag får (iallafall rent visuellt) random-tecken på displayen när jag ändrar smågrejjer i koden?

Som sagt, när jag stängt av interrupten så såg det ut som i min andra edit i förra inlägget. Testade då att lägga till test = 0 i slutet av koden och kompilerade. Då var alla tecken utbytta mot U och v och *. Enablade interrupten igen och då såg det bättre ut, så jag plockade bort test = 0 (som inte används till något alls, den var däremot dimensionerad som byte) och då visades bara hälften av bokstäverna i displayen.
Användarvisningsbild
Jine
Inlägg: 1795
Blev medlem: 21 juli 2004, 20:25:56
Skype: Jim.Nelin
Ort: Trångsund, Stockholm
Kontakt:

Inlägg av Jine »

Måste man inte RENSA displayen mellan gångerna man skickar informationen?
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

Kaggen:
"Du menar alltså att om du tar bort den enda raden (anropet till lcd_variabel2) funkar allt klockrent?"

Jepp. :)


"Det finns inga speciella definitioner för delat minne eller minnesbanker i BASICen?"

Tyvärr vet jag inte det. Men fenomenet påminner om någon form av problem med minnet.


"Jag antar att BASICen borde hålla reda på minnesbanker (typ banksel i assembler)åt dig, så inte vissa variabler pekar på en position och du befinner dig i fel minnesbank."

Jo, det tror jag. Tycker annars att jag borde stött på problemet tidigare. När jag gjorde kod för en klocka använde jag till väldigt stor del samma kod på exakt samma PIC. (Har inte ens rört labbplattan sedan dess.) Enda skillnaden nu är att jag delat upp det lite snyggare i olika procedurer istället för att ha vissa delar "löst" i main-loopen.



"Hur ser BASICen skillnaden mellan att du skriver 59 med siffror och "H"?"

I en procedur kan man skriva antingen t.ex lcd_skriv(65) eller lcd_skriv("A"). Resultatet blir det samma. (A = 65 i ascii-tabellen.) Även om själv proceduren dimensionerar för en byte så blir det rätt.

Om jag däremot vill att lcd_skriv("A") ska vara en sträng, så får jag dimensionera det i proceduren. Dvs:

sub procedure lcd_skriv(dim bokstav as string[1])
...
end sub
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

Jine: Nja, det beror på. Så länge inte markören hamnar "utanför" displayen är det bara att fylla på med tecken. I min kod så berättar jag på vilken rad och kolumn som jag vill att tecknen ska hamna. Då behöver man inte heller rensa. Det går utmärkt att skriva över tidigare tecken som visas.
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Inlägg av sodjan »

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.

> 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).

Glapp (du kanske stöter till LCD'en samtidigt som du ändrar i koden :-) ).

Prova att slöa ner *allt*.
Användarvisningsbild
JimmyAndersson
Inlägg: 26586
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Inlägg av JimmyAndersson »

Ska testa det lite mer i morgon.

Trots att jag börjat med asm så vore det intressant om man lyckades lösa detta. Det går ju inte att låta en utmaning gå obemärkt förbi... :)


"Glapp (du kanske stöter till LCD'en samtidigt som du ändrar i koden)"

Man vet aldrig. :D
Nja, den står ganska tryggt en bit upp på bordet. :)
Användarvisningsbild
oJsan
EF Sponsor
Inlägg: 1541
Blev medlem: 11 november 2005, 21:36:51
Ort: Umeå
Kontakt:

Inlägg av oJsan »

sodjan skrev:...
Prova att slöa ner *allt*.
Ett enkelt sätt (utan att behöva ändra på en massa ställen i koden) är att byta oscillator eller att stoppa in en binär räknare mellan oscillator och PIC. (såvida du inte använder den interna).
Jag har använt LCD-displayer i projekt några gånger och det ständigt återkommande problemet är "timing"...
JimmyAndersson skrev:Har inte fått något felmeddelande om Stack overflow.
Sånt sker under körning och är inget som kompilatorn/länkaren kan förutspå. Dumma programhopp kan göra att antalet "push" blir fler än antalet "pop" och således blir det fullt.

Föresten, grattis till valet av asm. Jag hoppas att det löser problemet! :)
Skriv svar