Svenska ElektronikForumet

Skulle testa MicroC då ASM kan vara ganska jobbigt och tidsförödande ibland, men jag får ingenting till att fungera.

Just nu har jag otroligt simpel och egentligen meningslös kod: Men det fungerar inte, inga pinnar blir 0

Konfigurationen ser ut som följande: Importerar HEX-filen med PicKit2-programmet, och använder min PicKit2'a till att programmera, och programmet säger att programmeringen lyckas och HEX'en ser ut som följande: Alltså skrivs i alla fall någonting till PIC'en, men det fungerar ändå inte.

Vad har jag gjort fel?

Nu vet jag inte hur MikroC hanterar detta, men "vad händer sedan". Dvs efter att ditt program exekverats försvinner PICen ut i tomma intet?

Edit: Ditt program är ju så kort att du kan disassemblera det för hand för att se vad det gör

Testade sätta dit I slutet av koden, detta borde skapa en oändlig loop som gör att den inte "försvinner", ingen skillnad dock

Skall inte behövas, sista 280c är en GOTO. Det blir nog bara att sätta sig ned och disassemblera

Sådär verkar det vara, PIC'en verkar inte initieras någonstans?
Borde inte MicroC göra det automagiskt när man sätter de parametrarna jag har bild på i mitt första inlägg?

Samt MicroC verkar ta fel på adresserna till ANSEL och ANSELH Men det borde inte göra någon större skillnad då de ändå bara fylls med 0'or..

Ser ut som fler problem.

0x4 är ju interupt vector adressen.

Jag begriper inte varför koden hamnat i din ISR eller varför den hoppar ur den med GOTO.
Begriper heller inte ditt påstående om ANSEL. Det är ju ADRESH den blankar och inte ANSELH, vilket ändå inte stämmer i och för sig.

Kort sagt det enda jag begriper är att det ser helt galet ut.

Kan det inte vara så att det saknas includes/defines ?

Det jag menade med ANSEL och ANSELH är att jag skriver ANSEL och ANSELH i C-koden, men den kompilerade koden styr till ADCON0 och ADRESH

Och jag är helt ny med detta, bara kört ASM innan, så om det är någon include eller define som saknas har jag inte en aning om

Klas-Kenny skrev:Testade sätta dit

Kod: Markera allt

void infinite() {
     infinite();
}

I slutet av koden, detta borde skapa en oändlig loop som gör att den inte "försvinner", ingen skillnad dock

Nu vet jag inte hur functionsanrop hanteras på en uC, men den koden skulle inte fungera på en vanlig dator. Vill du ha en evighetsloop så fungerar betydligt bättre.

Eller enbart "while (true) {}". Behövs ingen extra funktion.

Det där andra såg rekursivt ut och det borde bli stack-problem ganska
snabbt och sedan kan i princip vad som helst hända.

> Det jag menade med ANSEL och ANSELH är att jag skriver ANSEL och ANSELH i
> C-koden, men den kompilerade koden styr till ADCON0 och ADRESH

Nej, det gör den inte, det bara ser ut så.

Det är exakt samma kod för "CLRF ADCON0" som för "CLRF ANSELH" och
det som skrev ut koden kan ju inte veta vilket det ska vara, eller hur ?
D.v.s om man enbart har tillgång till maskinkoden så går det inte att veta.

På samma sätt så spelar det igentligen ingen roll när man skriver assembler
om man skriver "CLRF ADCON0" bara "CLRF ANSELH" bara man gör
"BANKSEL ANSELH" före så går det alltid till rätt register...

Sen, när det gäller den ursprungliga frågan, *VET* du att koden körs alls ?

En annan sak...

> 0x4 är ju interupt vector adressen.

Ja, det stämmer, men det är inget annan än just exakt det, en adressvektor !

> Jag begriper inte varför koden hamnat i din ISR...

Notera att *processorn* inte har en susning om vad en "ISR" är !

Det är enbart en logisk uppdelning av koden som den som skriver
källkoden gör. Processorn har aldrig någon möjlighet att "veta" eller
"se" att den vid ett visst tillfälle befinner sig i en del av koden som
den som skrev koden råkade kalla för sin "ISR".

Det är inte heller något speciellt med kod som ligger vid adress 0004, det
är bara en adress i programminnet som alla andra. Det finns inget som helst
sätt att från koden se hur man kom dit. Det kan lika gärna vara via ett
"riktigt" interrupt som en GOTO h'0004'. Enda skillnaden är att GIE kommer
att vara avslagen efter ett interrupt, men det går ju att göra på andra sätt
också och är inget signifikativt.

Så, om det inte finns någon "ISR" i C-koden så finns det ingen ISR någon
annanstans heller. Och det är helt OK för C-kompilatorn att lägga sin
kod var den vill !

I C brukar det finnas något speciellt sätt att ange att en viss funktion är
den ISR man vill använda. Detta är till största delen till för att tvinga in
just den koden i adress h'0004'. Samt att det normalt även läggs med lite
extrakod (context saving/restoring) och att RETFIE används istället för
RETURN för att avsluta hela funktionen. För övrigt är det inget speciellt.

void main() {
TRISC = 0;
ANSELH = 0;
ANSEL = 0
PORTC = 0;
}

Det finns ju inget semikolon på Anselraden så den koden kan ju aldrig gå genom kompilatorn? Ser allt ok ut när du klickar Build?
Har du testat nått av de exempel som finns i programkatalogen?

Sodjan: Aha, det är så det fungerar! Förvirrande att alla minnesplatser har olika adresser ifall man kollar databladet.
Inte en aning om koden körs eller ej, då det inte händer någonting med PIC'ens utgångar, men jag ser ingen anledning till att koden inte skulle köras då programmeringen lyckas, samt har testat med en likadan PIC.

PHermansson:
Helt säker på att semikolonet är i koden (Har inte tillgång till den för tillfället), det måste ha försvunnit i kopieringen eller liknande.
Har testat med "LED-blink" som finns som exempel, inte ett liv där heller, min tanke är om min konfiguration av MircoC/PIC'en är fel någonstans eller liknande

Jag vet inte vad du programmerar med, men en del program har en
knapp eller likande för att "släppa" processorn till "run" läge. Annars
hålla den i reset av programvaran/programmeraren.

> Förvirrande att alla minnesplatser har olika adresser ifall man kollar databladet.

Ja, det har de i och för sig, men två av adressbitarna kommer från de två
bitarna i STATUS registret och resten kommer från själva instruktionen. Så
man kan inte enbart genom att titta på instruktionen avgöra vilken bank
intruktionen kommer att jobba mot.

Programmerar med en PicKit2, och har aldrig haft problem med detta tidigare när jag skrivit ASM, utan enbart nu med MicroC.

Förstod nu att de är så det ligger till, men som sagt, man blir förvirrad när de skriver olika adresser i databladet om man inte vet säkert hur det är