Sida 2 av 2
Postat: 23 juni 2008, 00:00:30
av Skede
Sådär då va midsommar firandet färdigt. Hoppas ni haft en bra helg och lika avslappnande som jag haft =)
Innan veckans slut så hoppas jag att vi kommit en bra bit på vägen med vårat lilla projekt.
Gjorde ett liknande projekt i skolan, dock inte othello men med ett bräde på 8*8 rutor. Vi klurade ett bra tag på hur knapparna skulle lösas, men hittade sen denna:
http://se.farnell.com/1441593/electrica ... -18r-200fh
Vilket var oväntat billig och väldigt enkel att använda mha AD-omvandling på processorn.
Låter intressant. Den skall jag ta och kolla upp lite. Har du kvar något exempel på hur du använde dig utav den?
Vi har ju ingen direkt budget vi behöver tänka på bara det inte blir allt för dyrt. Jag anser ju att pengarna vi investerar i detta får vi tillbaka i kunskap. Vilket är ovärdeligt

.
Sitter nu med C och försöker klura ut hur programmet skall fungera.
För att lösa själva spelbordet. skall man använda sig av en 2D array med 8x8 fält eller vad är enklast?
Och kan man använda sig av funktioner i PIC programmering?
Som sagt så är AI'n i spelet inte av vikt i nuläget utan vi vill i första hand bara få spelet att fungera och så att man inte kan lägga ut "brickor" på fel plats m.m.
Tack igen för alla svar och hoppas inte ni tycker vi är allt för tröga inom detta område

som sagt man måste ju börja någonstanns.
Postat: 23 juni 2008, 00:12:02
av sodjan
> Och kan man använda sig av funktioner i PIC programmering?
Lite oklart vad du menar. En PIC vet inte vad en "funktion" är.
Om det däremot är vanliga funktioner så som man definierar dom i C, så
förstår jag inte heller frågan, varför skulle man inte kunna det ?
Postat: 23 juni 2008, 00:32:20
av Skede
Hehe. Jo det va funktioner i själva c koden jag menade. Tänkte om det är för avancerat för picen, men nu i efterhand så är det ju ganska så självklart att det går å använda sig av det

Postat: 23 juni 2008, 00:36:23
av sodjan
He, själva processorn har inte en aning om att du använder C.
Du kan skriva ditt program precis med vilka verktyg du vill,
processorn bryr sig inte ett smack...

Postat: 23 juni 2008, 08:16:35
av Earendil
En (ganska viktig) detalj när det gäller PIC och C-programmering är att de enklare PIC:arna (10F, 12F och 16F) inte har något smidigt stöd för datastackar. Detta gör att lokala variabler i C-funktioner blir svårhanterade. Jag har inte sett någon C-kompilator som hanterar detta för dessa modeller. Fast man borde iofs kunna använda INDF- och FSR-registrena för att implementera en datastack, på bekostnad av prestanda och kodstorlek förstås...

Progress
Postat: 28 juni 2008, 15:10:09
av murrayhack
Tjenare! Va ett tag sedan vi skrev något men nu har vi köpt oss en labbplatta, en pic och en 15v adapter till vår programmerare. Så nu är vår inlärningen i full gång!
Hittills har vi bara testat lite olika program för LEDs men vi sitter i denna stund mitt uppe i att testa "input".. dvs vi vill få en knapptryckning att göra något å det går framåt.
Lite video på vår första räknare har ni här:
http://www.youtube.com/watch?v=u43m8Nwzqx0
Finns några bilder me. Är du intresserad så finns dom
här.
Glömde säga att vi inte hade någon vettig strömkälla till vår labbplatta. Detta löste vi dock genom att kortsluta ett ATX aggregat med en strömbrytare när vi behöver ström på labplattan! Finns en bild på detta under länken åvan!
Postat: 28 juni 2008, 15:18:02
av Icecap
Jag ser att ni inte har strömbegränsarmotstånd till er 7-segment, det är inte speciellt bra om PIC'en ska hålla en längre tid.
Och sedan svara ni nog att "PIC'en kan inte ge ut mer än 25mA vilket 7-segmenten klarar" och till det svarar jag att det inte är 7-segmenten som tar stryk, det är PIC'en som blir onödigt varm pga. att strömbegränsningen värmer upp chippen.
Det är inget problem nu... men om ett par veckor kan det mycket väl vara det.
Postat: 28 juni 2008, 19:24:52
av Skede
Tack för informationen

Och jag håller med dig om att man helt klart bör använda motstånd i det fallet. Dock så va vi så sugna på testa programmet så vi orkate inte
Nu har jag stött på ett litet problem.. eller vad man ska kalla det.
Jag har en knapp och ett gäng leds.
Programmet har 3 olika funktioner som blinkar med dioderna i olika mönster.
När knappen trycks in så byter den funktion.
Detta funkar bra men dock så vill jag kunna byta funktion under tiden funktionen körs.. så att inte hela funktionen behöver bli klar innan jag kan trycka på knappen.
Går detta lösa på något sätt?
Postat: 28 juni 2008, 20:32:57
av BEEP
Friskt kopplat, hälften brunnet

Postat: 28 juni 2008, 22:08:44
av Icecap
Skede: självklart, det är bara att programmera rätt, sedan är det inget problem.
Jag brukar lösa detta vid att ha en timerinterrupt som läser knapparna, samtidig finns det en timer som styr hastigheten på funktionerna.
Sedan kör mainloopen hela tiden igenom, är timern noll utförs nästa funktion och timern sätts till nästa tid. Ganska enkelt när man har det gjort.
Själva sekvenseringen kan även utföras i timer-ISR'n, vilket som är bäst beror på vad som ska utföras.
Svaret är alltså: sluta göra kassa program, börja programmera rätt.
Kod: Markera allt
Timer-ISR:
if(Time_Counter) Time_Counter--;
if(Getkey)
{
Time_Counter = 0;
if(++Function >= 3) Function = 0;
}
Mainloop:
if(Time_Counter < 1)
{
switch(Function)
{
case 0:
switch(Sequence)
{
case 0:
break;
case 2:
break;
}
break;
case 1:
switch(Sequence)
{
case 0:
break;
case 2:
break;
}
break;
case 2:
switch(Sequence)
{
case 0:
break;
case 2:
break;
}
break;
}
}
Postat: 29 juni 2008, 01:42:57
av sodjan
> Detta funkar bra men dock så vill jag kunna byta funktion under tiden funktionen körs..
> så att inte hela funktionen behöver bli klar innan jag kan trycka på knappen.
Antingen gör "funktionen" snabbare/kortare.
Eller kolla knappen samtidigt so funktionen körs.
Finns väl inget annat sätt.
Jag vet inte riktigt vad funktionen gör, men det normala är att
göra hela applikationen händelsestyrd och att all timing sker via
timers. D.v.s att applikationen aldrig är "fast" i någon speciell rutin
någon längre tid. Vad som är en "lång tid" bestämms av hur snabbt
du behöver reagera på något annat (än det du gör just nu).
Postat: 29 juni 2008, 08:38:12
av Icecap
I vissa (mycket enkla) funktioner kan ett programflöde som set ut som:
mainloop:
* Slå på A
* Vänta 3 sek
* Slå på B
* Vänta 2 sek
* Slå av A
* Slå av B
* goto mainloop
vara acceptabelt men det är sällan!
Min regel är att ett programsteg aldrig får stå still och vänta på något! Är det så att en viss tid ska gå startar jag en timer och när det programsteg inte har timet klart testar jag helt enkelt timern och hoppar över programsteget om inte den är klar.
Alltså ville ovanstående se ut som följer:
Kod: Markera allt
mainloop:
* är Timern = 0? annars ta nästa punkt
- är Sekvensen = 0? annars kolla nästa sekvens
- Slå på A
- Set timer = 3 sek
- Sekvens = Sekvens + 1
- är Sekvensen = 1? annars kolla nästa sekvens
- Slå på B
- Set timer = 2 sek
- Sekvens = Sekvens + 1
- är Sekvensen = 2? annars set sekvens = 0!
- Slå av A
- Slå av B
- Sekvens = 0
* goto mainloop
I en timer-ISR finns det då en timer-nerräkning.
På detta vis kan man välja dels att byta sekvens direkt, programflödet här ovan var bara en sekvens, man kan lägga till fler och sedan ha en variabel som väljer vilken sekvens som ska utföras, om man samtidig med byte av sekvens nollar timern får man omedelbar respons.
Så det är en fråga om att gå bort från det mycket enkla men knappt så funktionella sätt att programmera på till att göra det en aning mer komplicerat men ändå mer ändamålsenligt och, i slutändan, enklare programmering.
Postat: 29 juni 2008, 17:40:28
av Skede
Tack så mycket för hjälpen

Nu börjar man nästan förstå sig på PIC'ens värld lite. Det blir bara roligare å roligare att sitta å leka både med komponenter å kod å man lär sig lite nytt hela tiden.
Här är en liten filmsnutt med dagens framgång.
http://www.youtube.com/watch?v=kuCoOlgW9sQ
Det är lite glapp i knappen om nån undrar varför jag trycker två gånger

.
LED displayen visar vilket "program/funktion" jag kör.
Slut för idag!
Postat: 29 juni 2008, 18:06:05
av Icecap
Nu är det inte bara PIC som dessa programmeringssätt gäller, det är generellt.
Och visst är det skoj att programmera in en funktion och se den fungera!
Jag har ett projekt där jag styr mekanik, det är skitkul att se hur den rent fysisk reagerar när jag ändrar i programmet.
Det finns en självkalibreringsfunktion, när jag klickar knappen på min PC kör skridskorslipen (som det råkar vara) en kalibreringskörning där den räknar hur "lång" den är i antal pulser från motorn, kör ett antal gånger, ser om skillnaden är så låg att det är OK och sedan sparar värdet.
Detta betyder att man kan ta "valfri" växellåda i drivningen och montera den, sedan kör man en kalibrering och det är klart.
Anledningen till att man ska veta antal pulser mellan start o stopp är att den ska kunna köra t.ex. mellan 30% och 70% ett antal gånger.