Sitter och knappar in de flesta register som finns för PIC18F442.
RCON Equ 0x0FD0
RCREG Equ 0x0FAE
Osv...
Finns detta redan definierat?
Har ett minne av att jag sett det någonstans i Mplab IDE men minns inte var.
Finns registerdefinitioner färdiga för PIC?
Tror det är dags för mig att skaffa hatt eller något för att kunna äta upp den ibland 
Hittade den, minndes att den låg som en fil och det gjorde den nu med, jag hade missat den, vetekatten hur, måste vara blind på ögonen.
Hursomhelst.
De flesta felmeddelanden försvann men några är fortfarande kvar Error[113] Symbol not previously defined.
När jag däremot copy&pastar de trilskande definitionenerna till min egen definitionslista (provat två hittils) så försvinner de felmeddelandena.
Får ju intrycket att vissa definitioner inte fungerar i orginaldokumentet?
Kan det vara att PIC18F442.INC inte ska ligga under headerfiles?
Variables.inc fungerade utmärkt att ha där iaf.
Hittade den, minndes att den låg som en fil och det gjorde den nu med, jag hade missat den, vetekatten hur, måste vara blind på ögonen.
Hursomhelst.
De flesta felmeddelanden försvann men några är fortfarande kvar Error[113] Symbol not previously defined.
När jag däremot copy&pastar de trilskande definitionenerna till min egen definitionslista (provat två hittils) så försvinner de felmeddelandena.
Får ju intrycket att vissa definitioner inte fungerar i orginaldokumentet?
Kan det vara att PIC18F442.INC inte ska ligga under headerfiles?
Variables.inc fungerade utmärkt att ha där iaf.
Jag utgår från att du kör assembler.
INC filerna ska inkluderas med #include.
> Error[113] Symbol not previously defined.
Du *kan* få det om du inte har slagit av "case sensitivity" för MPASM
samt blandar upper och lower case. INC filen har bara det ena.
Enklast är att göra det till en vana att alltid stänga av
"case sensitivity" för MPASM...
INC filerna ska inkluderas med #include.
> Error[113] Symbol not previously defined.
Du *kan* få det om du inte har slagit av "case sensitivity" för MPASM
samt blandar upper och lower case. INC filen har bara det ena.
Enklast är att göra det till en vana att alltid stänga av
"case sensitivity" för MPASM...
Jag kanske borde köpa 2 hattar att äta paralellt, jag har ju inkluderat andra .inc filer borde ha listat ur det där men tydligen icke.
Tack för hjälpen sodjan, det uppskattas även om det säkert ter sig som enkla bekymmer jag har.
Nu ska jag bringa lite ordning i den röra jag har i vilka register som sätts var så man förhoppningsvis får lite bättre koll på hur registren står.
Har blivit för mycket spagettikod.
Tack för hjälpen sodjan, det uppskattas även om det säkert ter sig som enkla bekymmer jag har.
Nu ska jag bringa lite ordning i den röra jag har i vilka register som sätts var så man förhoppningsvis får lite bättre koll på hur registren står.
Har blivit för mycket spagettikod.
-
Schnegelwerfer
- Inlägg: 1863
- Blev medlem: 8 november 2004, 13:46:56
Fast nu är det ju så att assemblyprogrammering undviks i största möjliga utsträckning i arbetlsivet nuförtiden.nanopile skrev:Medhåll där, assembler ska det vara, då blir det bäst, man måste ju ändå tänka på hur assemblerkoden blir om man programmerar i något högnivåspråk.
Man kan göra snabb kod dessutom
Visst kan det vara värt att göra några små projekt i assembly för att få bättre förståelse, men sedan tycker jag att det är dags att gå över till C som totalt dominerar embedded-marknaden
Möjligt att det dominerar men det är inte lika roligt med C 
För min del är det så att jag tycker det känns skönt att veta att det är prestanda i koden och det känns som slöseri att göra 3 instruktioner med C istället för en i assembler.
Kan gå ned i kostnad för hårdvaran ibland också, kanske tom ofta?
Tvivlar dock inte för en sekund att C dominerar.
Eftersom det ger bättre förståelse, varför kör man då C?
Fler konsulttimmar?
För min del är det så att jag tycker det känns skönt att veta att det är prestanda i koden och det känns som slöseri att göra 3 instruktioner med C istället för en i assembler.
Kan gå ned i kostnad för hårdvaran ibland också, kanske tom ofta?
Tvivlar dock inte för en sekund att C dominerar.
Eftersom det ger bättre förståelse, varför kör man då C?
Fler konsulttimmar?
-
Schnegelwerfer
- Inlägg: 1863
- Blev medlem: 8 november 2004, 13:46:56
Vad menar du med 3 instruktioner i C och en i assembler? Har du granskat den kompilerade C-koden och kommit fram till det?
Jsg betvivlar att dina program blir mindre och effektivare i assembly, det är ganska svårt att skriva assemblykod som blir mer effektiv än kompilerad C-kod (om du inte har en usel kompilator).
EDIT: Med bättre förståelse menar jag på hobby/nybörjar/skol-nivå. Det finns dock en del gamla assemblerrävar ute i arbetslivet som misstror högnivåspråk och harvar vidare med assembler i större program eftersom de inte lärt sig något annat. Jag har tyvärr haft oturen att samarbeta med sådana...
Jsg betvivlar att dina program blir mindre och effektivare i assembly, det är ganska svårt att skriva assemblykod som blir mer effektiv än kompilerad C-kod (om du inte har en usel kompilator).
EDIT: Med bättre förståelse menar jag på hobby/nybörjar/skol-nivå. Det finns dock en del gamla assemblerrävar ute i arbetslivet som misstror högnivåspråk och harvar vidare med assembler i större program eftersom de inte lärt sig något annat. Jag har tyvärr haft oturen att samarbeta med sådana...
Har faktiskt inte kontrollerat hur C koden blir jämfört med assembler, trodde jag gissade riktigt lågt, förväntade mig att vissa saker skulle ta 20 ggr mer instruktioner.
Kan inte mycket C egentligen, har lite saker jag kan men inte jobbat så mycket med det, däremot vet jag att jag hade en kompilator för x86 kod som gjorde ena riktiga härvor av enkla kommandon.
Skulle iofs vilja kunna skriva nya kommandon efter ; som i C.
Storleken på assemblykoden hmm, man utgår ju från assembly, inte något högnivåspråk, man är ju inte ute efter att göra kompilatorns jobb för hand.
Skulle jag upptäcka att det blir bättre prestanda av C så skulle jag blanda de bra bitarna ur båda språken.
Minns någon som sade att C++ började andvändas av många för att det var komplext och drog ut på projektens tid och man kunde redovisa att man varit mer effektiv genom att vissa upp mer kod och att det krävde fler deltagare.
Fick sådana vibbar när du skrev att man får bättre förståelse av assembler men ändå föredrog C
Jag är tyvärr inte särskilt bra på att läsa mellan raderna så jag tror intuitivt på att det som sagts eller skrivits är exakt och korrekt och det ger mig problem varje dag men verkar inte lära mig det särskilt snabbt, en av mina brister
, lär mig dessbättre andra saker bra
Kan inte mycket C egentligen, har lite saker jag kan men inte jobbat så mycket med det, däremot vet jag att jag hade en kompilator för x86 kod som gjorde ena riktiga härvor av enkla kommandon.
Skulle iofs vilja kunna skriva nya kommandon efter ; som i C.
Storleken på assemblykoden hmm, man utgår ju från assembly, inte något högnivåspråk, man är ju inte ute efter att göra kompilatorns jobb för hand.
Skulle jag upptäcka att det blir bättre prestanda av C så skulle jag blanda de bra bitarna ur båda språken.
Minns någon som sade att C++ började andvändas av många för att det var komplext och drog ut på projektens tid och man kunde redovisa att man varit mer effektiv genom att vissa upp mer kod och att det krävde fler deltagare.
Fick sådana vibbar när du skrev att man får bättre förståelse av assembler men ändå föredrog C
Jag är tyvärr inte särskilt bra på att läsa mellan raderna så jag tror intuitivt på att det som sagts eller skrivits är exakt och korrekt och det ger mig problem varje dag men verkar inte lära mig det särskilt snabbt, en av mina brister
, lär mig dessbättre andra saker bra 
