Jag behöver hjälp med en fråga jag tänkt på ett tag nu.
kan jag skriva call point() inne i sub point()?
jag har inte testat än ifall det skulle resultera i en infinity loop...
Hjälp med BASCOM-AVR
Re: Hjälp med BASCOM-AVR
Jag har aldrig använt BASCOM, men det verkar som du vill rekursera. Inget fel i det, men se till att du tänkt igenom funktionen ordentligt och att du har ett villkor som avslutar rekursionen. Annars kan det ge ganska konstiga resultat.
Och även om det skulle bli en oändlig loop av det är det väl inte hela världen? Bara skriva om koden och programmera om kretsen.
Och även om det skulle bli en oändlig loop av det är det väl inte hela världen? Bara skriva om koden och programmera om kretsen.
Re: Hjälp med BASCOM-AVR
Om det upprepas för många gånger så kommer väl ramminnet att fyllas av returadresser på stacken? dvs totalkrasch ganska snart? Funkar ju ofta när man har en dator med obegränsat (flera megabyte) ramminne, men inte nära man har några hundra bytes att leka med.
Re: Hjälp med BASCOM-AVR
> ...kommer väl ramminnet att fyllas av returadresser på stacken?
Är det där en gissning eller fakta?
Är det där en gissning eller fakta?
Re: Hjälp med BASCOM-AVR
Det verkar vara en väldigt bra gissning som med stor sannolikhet är fakta.
I princip måste alla rekursiva anrop fungera så, på ett ungefär.
En mycket intressantare (och den viktiga) frågan är vad
greyneon igentligen vill uppnå. Varför frågar greyneon om
rekursiva anrop över huvudtaget ?
I princip måste alla rekursiva anrop fungera så, på ett ungefär.
En mycket intressantare (och den viktiga) frågan är vad
greyneon igentligen vill uppnå. Varför frågar greyneon om
rekursiva anrop över huvudtaget ?
Re: Hjälp med BASCOM-AVR
Vid varje call läggs returaddressen på stacken. I en PIC16 har stacken åtta fasta nivåer. I en AVR används RAM för stacken. Vanligt är att stacken byggs från slutet av RAM. Jag vet inte om stackens storlek går att begränsa, men om den är obegränsad kommer den till slut växa in i utrymmen där variabler finns, och om det inte räcker för krasch så kommer antagligen stackpekaren nå 0 och slå runt (om det inte finns hårdvara som förhindrar det).
Re: Hjälp med BASCOM-AVR
Call-stacken på en PIC12 är en åtta nivåer djup och cirkulär buffer, vilket innebär att om man gör nio call:s så kommer returadressen på den första call:en att skrivas över. Gör man 16 calls blir stackens adresser överskrivna två gånger. RAM-minnet rörs inte alls, och det var därför jag undrade om det var fakta det handlade om.
Om det är fakta, att en AVR skriver över RAM-minnet bara för att man överskrider call-stacken, så tänker då iallafall jag aldrig ta i dem med tång ens.
Om det är fakta, att en AVR skriver över RAM-minnet bara för att man överskrider call-stacken, så tänker då iallafall jag aldrig ta i dem med tång ens.
Re: Hjälp med BASCOM-AVR
Äsch, bearing hann före 
Fast där fick jag till slut svar på min fråga.
Fast där fick jag till slut svar på min fråga.Re: Hjälp med BASCOM-AVR
> I en PIC16 har stacken åtta fasta nivåer....
Om inte kompilatorn implementerar en mjukvarustack.
Men det har ingen principiell betydelse för eventuella
stack problem vid rekursiva anrop. Grundfrågan är
fortfarande "Varför?". Vad är problemet som ska lösas ?
Om inte kompilatorn implementerar en mjukvarustack.
Men det har ingen principiell betydelse för eventuella
stack problem vid rekursiva anrop. Grundfrågan är
fortfarande "Varför?". Vad är problemet som ska lösas ?
Re: Hjälp med BASCOM-AVR
Nu så gällde ju frågan just AVR, men...
> Call-stacken på en PIC12 är en åtta nivåer djup,,,
Gäller nyare PIC12, äldre PIC12 är "base-line" och har inte 8 nivåer.
> ... och cirkulär buffer.
Nyare PIC's har både stack overflow och underflow traps.
Jag tror även att MPSIM larmar för stack-problem för dagens PICs.
> Call-stacken på en PIC12 är en åtta nivåer djup,,,
Gäller nyare PIC12, äldre PIC12 är "base-line" och har inte 8 nivåer.
> ... och cirkulär buffer.
Nyare PIC's har både stack overflow och underflow traps.
Jag tror även att MPSIM larmar för stack-problem för dagens PICs.
Re: Hjälp med BASCOM-AVR
>Om det är fakta, att en AVR skriver över RAM-minnet bara för att man överskrider call-stacken, så tänker då iallafall jag aldrig ta i dem med tång ens.
haha.... så fungerar ju de allra flesta processorer. Stacken ÄR ramminnet. Du väljer själv på vilken adress du ska ha den och hur mycket utrymme du vill ge den. Överskrider du det utrymmet finns det ingen kontroll (inte på de vanliga Attiny och ATmega i alla fall).
Men jag tror det kan vara värre än så (jag har inte testat): Ramminnet i en AVR delar adressutrymme med alla I/O och alla interna register. Så när du börjar komma ner i låga adresser börjar du skriva på alla IO-portarna med helt oanade konsekvenser. Processorn kan få riktigt tuppjuck med andra ord.
Rekursiva anrop för att skapa en loop anser jag är dålig programmering. Tyvärr är det väldigt vanligt och finns t.o.m. med i läroböcker om programmering. Men då får man vara jävligt säker på att loopen inte bara är ändlig, utan att den tar slut ganska snart. Dessutom , i vissa högnivåspråk skapar du ett gäng nya lokala variabler för varje anrop viket kan fylla ganska många megabyes ramminne mycket snabbt. Rekommenderas ej. Så jag undrar också - varför vill du göra ett rekursivt anrop?
haha.... så fungerar ju de allra flesta processorer. Stacken ÄR ramminnet. Du väljer själv på vilken adress du ska ha den och hur mycket utrymme du vill ge den. Överskrider du det utrymmet finns det ingen kontroll (inte på de vanliga Attiny och ATmega i alla fall).
Men jag tror det kan vara värre än så (jag har inte testat): Ramminnet i en AVR delar adressutrymme med alla I/O och alla interna register. Så när du börjar komma ner i låga adresser börjar du skriva på alla IO-portarna med helt oanade konsekvenser. Processorn kan få riktigt tuppjuck med andra ord.
Rekursiva anrop för att skapa en loop anser jag är dålig programmering. Tyvärr är det väldigt vanligt och finns t.o.m. med i läroböcker om programmering. Men då får man vara jävligt säker på att loopen inte bara är ändlig, utan att den tar slut ganska snart. Dessutom , i vissa högnivåspråk skapar du ett gäng nya lokala variabler för varje anrop viket kan fylla ganska många megabyes ramminne mycket snabbt. Rekommenderas ej. Så jag undrar också - varför vill du göra ett rekursivt anrop?
Re: Hjälp med BASCOM-AVR
Lösningar med rekursiva funktioner är snygga, när de används på rätt sätt. Alltså när samma problem egentligen inte skulle kunnat lösas på annat sätt, eller att alternativet skulle bli otymplig.
Jag minns bara ett tillfälle då jag använt en rekursiv funktion. Det var en textbaserad kalkylator som förstod parenteser. Funktionen som avkodade texten skickade innehållet i parenteser som argument till sig själv.
Jag minns bara ett tillfälle då jag använt en rekursiv funktion. Det var en textbaserad kalkylator som förstod parenteser. Funktionen som avkodade texten skickade innehållet i parenteser som argument till sig själv.
Re: Hjälp med BASCOM-AVR
> Lösningar med rekursiva funktioner är snygga, när de används på rätt sätt.
Helt rätt.
Jag gjorde så i en C-kod för att "nästla" upp svaret när man hämtar
listan med "kategorier" från Tradera. Det är en struct som i sig innehåller
samma struct i flera nivåer. Fungerar utmärkt. Liknar din text-parser...
Men på en mikrokontroller verkar det lite feltänkt...
Helt rätt.
Jag gjorde så i en C-kod för att "nästla" upp svaret när man hämtar
listan med "kategorier" från Tradera. Det är en struct som i sig innehåller
samma struct i flera nivåer. Fungerar utmärkt. Liknar din text-parser...
Men på en mikrokontroller verkar det lite feltänkt...
Re: Hjälp med BASCOM-AVR
tack för alla svar 
och att dom kom snabbt 
jag håller på med ett poäng system till några spel som jag gjort xD till en 20*4 display (lol?)
men jag löste det med variablar
och att dom kom snabbt jag håller på med ett poäng system till några spel som jag gjort xD till en 20*4 display (lol?)
men jag löste det med variablar
