Skapar en projekt fil i Mplab och bifogar både en *.lkr och en sorce fil *.asm För PIC16f84 krets. Efter detta kompilerar jag utan att ändra i *.asm filen. Konstigt nog ger dett a mig ett fel som blir detta.
Clean: Deleting intermediary and output files.
Clean: Done.
Executing: "C:\Program\Microchip\MPASM Suite\MPAsmWin.exe" /q /p16F84A "f84atmpo.asm" /l"f84atmpo.lst" /e"f84atmpo.err" /o"f84atmpo.o"
Message[301] C:\PROGRAM\MICROCHIP\MPASM SUITE\P16F84.INC 37 : MESSAGE: (Processor-header file mismatch. Verify selected processor.)
Executing: "C:\Program\Microchip\MPASM Suite\MPLink.exe" "C:\Program\Microchip\MPASM Suite\LKR\16f84a.lkr" "C:\Program\Microchip\MPASM Suite\Template\Object\f84atmpo.o" /o"Test.cof" /M"Test.map"
MPLINK 3.94, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - section 'INT_VECTOR' can not fit the absolute section. Section 'INT_VECTOR' start=0x00000004, length=0x00000010
Errors : 1
Ska ju inte bli fel när man skapar project tycker jag.speciellt när jag inte har ändrat i någon fil.
Pic16f84A, problem att skapa projectfil.
> och bifogar både en *.lkr och en sorce fil *.asm
En "*" säger ju allt om vilka filer du använder...
Det blir ju jätte lätt att försöka göra om samma sak.
Men, i princip säger det du får att Microchip inte är ofelbara.
Det finns helt enkelt några små "fel" i deras LKR filer, och de
kanske inte lägger så mycket krut på filerna för en "utdöd" processor.
En "*" säger ju allt om vilka filer du använder...
Det blir ju jätte lätt att försöka göra om samma sak.
Men, i princip säger det du får att Microchip inte är ofelbara.
Det finns helt enkelt några små "fel" i deras LKR filer, och de
kanske inte lägger så mycket krut på filerna för en "utdöd" processor.
Sorry, det var inte detta meddelande jag ville skicka i vä
Jag var för sleten i går när jag skickade i väg detta meddelande. sorry. Felmeddelande jag ville att ni skulle få del av var detta. detta får jag efter jag hat byggt ett project till pic16f84a kretsen.
Error - section '.org_1' can not fit the absolute section. Section '.org_1' start=0x00000004, length=0x00000010
vad kan detta bero på.
Error - section '.org_1' can not fit the absolute section. Section '.org_1' start=0x00000004, length=0x00000010
vad kan detta bero på.
Det är ju samma felmeddelande som i första inlägget, så
det gjorde väll ingen skillnad !?
Och orsaken fick du i mitt förra inlägg, Microchip's exempelfiler
och LKR filer stämmer inte riktigt överens.
Du får antingen "skruva" lite med definitionerna av sektionerns i LKR
fileren, eller ändra i ASM filen så att det enbart ligger en GOTO på
h'0004' och sedan ett nytt CODE segment.
Notera att "vectors" segementet i LKR filen slutar på h'0004' :så det får bara plats en instruktion där...
Ett annat sätt är att ändra följande i LKR filen :
till :
det gjorde väll ingen skillnad !?
Och orsaken fick du i mitt förra inlägg, Microchip's exempelfiler
och LKR filer stämmer inte riktigt överens.
Du får antingen "skruva" lite med definitionerna av sektionerns i LKR
fileren, eller ändra i ASM filen så att det enbart ligger en GOTO på
h'0004' och sedan ett nytt CODE segment.
Notera att "vectors" segementet i LKR filen slutar på h'0004' :
Kod: Markera allt
CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTEDEtt annat sätt är att ändra följande i LKR filen :
Kod: Markera allt
CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
CODEPAGE NAME=page START=0x5 END=0x3FF
...
SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
SECTION NAME=PROG ROM=page // ROM code spaceKod: Markera allt
//CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
CODEPAGE NAME=page START=0x0 END=0x3FF
...
//SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
SECTION NAME=PROG ROM=page // ROM code spacenu måste du ha skrivit fel sodjan
När jag ändrar på lkr filen enligt din förändring i lkr filen så får jag felmedelandet memory page 'overlaps memory vectors'
min andra fråga, så jag har fattat dig rätt så får jag inte andvända mer än en goto operator i interrupt vector H'0004'=H'4', eller. För denna adress andvänds väll för interrupt på pic 16f84a kretsen. eller?. om jag ska göra det så måste jad code segementera koden. Har jag fattat rätt.
Min tredje fråga behöver jag en *.LKR fil för att programmera ett program till vilken processor som helt. Vad händer om jag skiter i denna fil.
Min sista fråga är vart jag läser mer info om *.lkr filer.
Ps: Frågar bara för att lära mig för att kunna få lika mycket erfarenhet som du sojan och dom andra där ute på forumet. Allt är inte självklart när man är grön på pic processorer. Men man lär sig med tiden.
min andra fråga, så jag har fattat dig rätt så får jag inte andvända mer än en goto operator i interrupt vector H'0004'=H'4', eller. För denna adress andvänds väll för interrupt på pic 16f84a kretsen. eller?. om jag ska göra det så måste jad code segementera koden. Har jag fattat rätt.
Min tredje fråga behöver jag en *.LKR fil för att programmera ett program till vilken processor som helt. Vad händer om jag skiter i denna fil.
Min sista fråga är vart jag läser mer info om *.lkr filer.
Ps: Frågar bara för att lära mig för att kunna få lika mycket erfarenhet som du sojan och dom andra där ute på forumet. Allt är inte självklart när man är grön på pic processorer. Men man lär sig med tiden.
> När jag ändrar på lkr filen enligt din förändring i lkr filen så får jag felmedelandet
> memory page 'overlaps memory vectors'
Jag har ingen kristallkula. Svårt att säga när du inte visar vad du har gjort.
LKR filen är så liten så kopiera gärna in den med code-taggarna...
Jag kan hålla med om att det är lite synd att Microchip har strulat till
det lite med de LKR filer som är med MPLAB som standard...
> så får jag inte andvända mer än en goto operator i interrupt vector H'0004'
Nja, jo, med den LKR fil som levereras med MPLAB i original, ja. Som du ser
så är address h'0004' den sista adressen i segmentet "vectors". Alltså kan
kod inte "dra över" den gränsen, och med andra ord så får det bara
"plats" en instruktion där, sedan måste det komma ett nytt CODE segment.
(Rent teoretiskt skulle men inte behöva en GOTO i h'0004' med nyvarande
LKR fil. Hur det går till får var och en fundera på, det är inte så intressant
och det är inte en speciellt "snygg" lösning...)
Med mitt andra förslag (som skulle göra hela flashminnet till ett enda stort
segment, men jag kan ha missat något) så ska det inte vara något problem.
Det finns lite olika "skolor" här. En del vill ha ett segment som *börjar* på
h'0004' för att slippa att hårdkoda adressen till interrupt-vektorn i källkoden.
Det gör att det blir lite mindre att ändra om man flyttar kod från PIC16
till PIC18 (där vektorn ligger på en annan adress, och alltsp MPLINK
tar han om den skillnaden autometiskt...)
Personligen tycker jag inte att det är så stor affär med att ange två
adresser (reset- och interrupt-vektorna) i källkoden.
> behöver jag en *.LKR fil.... ?
http://www.jescab.se/Info_MPLAB.html
http://www.jescab.se/Rellocmode.html
(Notera att jag av misstag har skrivit LNK istället för LKR på den första av sidorna...)
Normalt vill man inte köra utan. Möjligtsvis om man har någon gammal
källkod som är skriven i "absolute mode" och man bara vill bygga om den.
Annars är det "relocatable mode" som gäller i dag. Det är inte
> Min sista fråga är vart jag läser mer info om *.lkr filer.
Dokumentationen brukar vara första stället (RTFM heter det visst på engelska... ) :
"MPASM/MPLINK User's Guide" : http://ww1.microchip.com/downloads/en/D ... 33014J.pdf
Men den borde du redan ha laddad ner, den ligger ju på samma sida
som där du laddade ner MPLAB...
> memory page 'overlaps memory vectors'
Jag har ingen kristallkula. Svårt att säga när du inte visar vad du har gjort.
LKR filen är så liten så kopiera gärna in den med code-taggarna...
Jag kan hålla med om att det är lite synd att Microchip har strulat till
det lite med de LKR filer som är med MPLAB som standard...
> så får jag inte andvända mer än en goto operator i interrupt vector H'0004'
Nja, jo, med den LKR fil som levereras med MPLAB i original, ja. Som du ser
så är address h'0004' den sista adressen i segmentet "vectors". Alltså kan
kod inte "dra över" den gränsen, och med andra ord så får det bara
"plats" en instruktion där, sedan måste det komma ett nytt CODE segment.
(Rent teoretiskt skulle men inte behöva en GOTO i h'0004' med nyvarande
LKR fil. Hur det går till får var och en fundera på, det är inte så intressant
och det är inte en speciellt "snygg" lösning...)
Med mitt andra förslag (som skulle göra hela flashminnet till ett enda stort
segment, men jag kan ha missat något) så ska det inte vara något problem.
Det finns lite olika "skolor" här. En del vill ha ett segment som *börjar* på
h'0004' för att slippa att hårdkoda adressen till interrupt-vektorn i källkoden.
Det gör att det blir lite mindre att ändra om man flyttar kod från PIC16
till PIC18 (där vektorn ligger på en annan adress, och alltsp MPLINK
tar han om den skillnaden autometiskt...)
Personligen tycker jag inte att det är så stor affär med att ange två
adresser (reset- och interrupt-vektorna) i källkoden.
> behöver jag en *.LKR fil.... ?
http://www.jescab.se/Info_MPLAB.html
http://www.jescab.se/Rellocmode.html
(Notera att jag av misstag har skrivit LNK istället för LKR på den första av sidorna...)
Normalt vill man inte köra utan. Möjligtsvis om man har någon gammal
källkod som är skriven i "absolute mode" och man bara vill bygga om den.
Annars är det "relocatable mode" som gäller i dag. Det är inte
> Min sista fråga är vart jag läser mer info om *.lkr filer.
Dokumentationen brukar vara första stället (RTFM heter det visst på engelska...
) :"MPASM/MPLINK User's Guide" : http://ww1.microchip.com/downloads/en/D ... 33014J.pdf
Men den borde du redan ha laddad ner, den ligger ju på samma sida
som där du laddade ner MPLAB...
CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
--------------------------------------------------------------------------------
så det får bara plats en instruktion där...
Ett annat sätt är att ändra följande i LKR filen :
code:
--------------------------------------------------------------------------------
CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
CODEPAGE NAME=page START=0x5 <= (1) END=0x3FF
...
SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
SECTION NAME=PROG ROM=page // ROM code space
--------------------------------------------------------------------------------
till :
code:
--------------------------------------------------------------------------------
//CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
CODEPAGE NAME=page START=0x0<= (2) END=0x3FF
...
//SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
SECTION NAME=PROG ROM=page // ROM code space
--------------------------------------------------------------------------------
Jag bytte värdet på page vectorn från 0x5 till 0x0. se punkt 1 och 2.
då fick jag felemdelande ovanstående.
Ok jag förstår inte så mycket av åvanstånde .Tar ock läser om detta nu tänkte jag i pdf filen du hänvisade till.
Hur var det du menade att jag skulle byta värden i *.lkr filen. Sorry för min oförståelse men det är första gången jag ser en *.lkr fil. Om jag kunde ändra på Lkr filen så att min kod blir opåverkad skulle vara drömläget.
--------------------------------------------------------------------------------
så det får bara plats en instruktion där...
Ett annat sätt är att ändra följande i LKR filen :
code:
--------------------------------------------------------------------------------
CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
CODEPAGE NAME=page START=0x5 <= (1) END=0x3FF
...
SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
SECTION NAME=PROG ROM=page // ROM code space
--------------------------------------------------------------------------------
till :
code:
--------------------------------------------------------------------------------
//CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
CODEPAGE NAME=page START=0x0<= (2) END=0x3FF
...
//SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
SECTION NAME=PROG ROM=page // ROM code space
--------------------------------------------------------------------------------
Jag bytte värdet på page vectorn från 0x5 till 0x0. se punkt 1 och 2.
då fick jag felemdelande ovanstående.
Ok jag förstår inte så mycket av åvanstånde .Tar ock läser om detta nu tänkte jag i pdf filen du hänvisade till.
Hur var det du menade att jag skulle byta värden i *.lkr filen. Sorry för min oförståelse men det är första gången jag ser en *.lkr fil. Om jag kunde ändra på Lkr filen så att min kod blir opåverkad skulle vara drömläget.
> CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
> så det får bara plats en instruktion där...
Nja, 0-4 är ju = 5 instruktioner.
*MEN* den första instruktionen i *** interruptrutinen *** ska ju ligga i just 0x4...
> Jag bytte värdet på page vectorn från 0x5 till 0x0. se punkt 1 och 2.
Japp, jag har just byggt samma ASM fil (med MPLAB 7.30) och har
kört med en LKR som ser ut så här :
Alltså med samma ändringar som jag föreslog. Den byggs utan fel.
Om du jämför med original LKR'en så ser du att två rader
är bortplockade och att "0x5" är ändrat till "0x0", det är allt.
> så det får bara plats en instruktion där...
Nja, 0-4 är ju = 5 instruktioner.
*MEN* den första instruktionen i *** interruptrutinen *** ska ju ligga i just 0x4...
> Jag bytte värdet på page vectorn från 0x5 till 0x0. se punkt 1 och 2.
Japp, jag har just byggt samma ASM fil (med MPLAB 7.30) och har
kört med en LKR som ser ut så här :
Kod: Markera allt
// Sample linker command file for 16F84A
// $Id: 16f84a.lkr,v 1.4 2002/01/29 22:10:01 sealep Exp $
LIBPATH .
CODEPAGE NAME=page START=0x0 END=0x3FF
CODEPAGE NAME=.idlocs START=0x2000 END=0x2003 PROTECTED
CODEPAGE NAME=.config START=0x2007 END=0x2007 PROTECTED
CODEPAGE NAME=eedata START=0x2100 END=0x213F PROTECTED
DATABANK NAME=sfr0 START=0x0 END=0xB PROTECTED
DATABANK NAME=sfr1 START=0x80 END=0x8B PROTECTED
DATABANK NAME=gprs START=0xC END=0x4F
SECTION NAME=PROG ROM=page // ROM code space
SECTION NAME=IDLOCS ROM=.idlocs // ID locations
SECTION NAME=CONFIG ROM=.config // Configuration bits location
SECTION NAME=DEEPROM ROM=eedata // Data EEPROM
Om du jämför med original LKR'en så ser du att två rader
är bortplockade och att "0x5" är ändrat till "0x0", det är allt.
ok,sodjan
Nu kanske mitt program kommer att fungera. Tror det kan vara något med detta att göra. fast borde inte gått igenom. Har converterat två project *.asm filer från pic18f452 till PIC16f84A krets. Bägge dessa program fungerar precis som tänkt i kompilatorn men inte i verkligheten på pic16f84 a när jag kör dom med fysika objekt som knappar och lysdioer.en enkel prototyp. Men denna prototypen fungerar klockrent med pic 18f452 kretsen med samma programvara fast okonverterad(det vad denna krets som jag byggde programvarorna till att börja med). Sedan vill jag ha stöd för denna mjukvara till pic16f84a kretsen med. Då började jag ändra tex WREG=W, option_REG i stället för pic 18f452 kretsen register vad det än heter nu.
Fattar inte vad felet är. Tänkte det kanske har något med ovanstående diskutionen. vem vet, den som lever får se. Kollade för enkelheten skull att bränna över blinkande led programmet från programmerarens hemsida wisp programmeraren bara för att testa om piv 16f84a kretsen fungerade och var rätt kopplad.det gjorde den. Sludigt fel. Förhoppningsvis så är det detta fel med ej rätt konfigruerade *.LKR. men borde ju inte gå igenom compilatorn. borde få samma problem som disk ovanstående. Klistade ju bara in koden från pic18f452 och konverterade den lite och sedan kompilerade och körde .Fick inga fel .simulerade och fungerade utmärkt.
Men inte när jag kör den i verkligheten . Svara inte på något. Fundera på kanske också om kretsen resistor jag kopplar mot jord eller Vss beroende om den ska vara Push down eller push Upp.Så kanske den är lite mera känslig för lägre resistor värde än pic18f452 kretsen.jag andvänder jämnt nu 330 ohm i stället frö 1 k ohm. Har nu beställt en pic 18f542 krets till om jag inte löser problemet och 10 st 1 k ohm resistorer. Det är nämerligen så att jag andvänder en kod(Polling avläsning,timer0) för att styra servot med den är tänkt att sitta i pic 16f84a kretsen sedan logikmjukvaran att sitta i pic 18f452 kretsen. Sedan koppla i hopp dessa kretsar med varandra. Med hjälp av detta så har jag byggt en liten mojäng. Vill inte tala om vad.hemligt.Tack vare test att ta patent på ideen att börja med. Så nu håller jag på att bygga upp en inovation.
Fattar inte vad felet är. Tänkte det kanske har något med ovanstående diskutionen. vem vet, den som lever får se. Kollade för enkelheten skull att bränna över blinkande led programmet från programmerarens hemsida wisp programmeraren bara för att testa om piv 16f84a kretsen fungerade och var rätt kopplad.det gjorde den. Sludigt fel. Förhoppningsvis så är det detta fel med ej rätt konfigruerade *.LKR. men borde ju inte gå igenom compilatorn. borde få samma problem som disk ovanstående. Klistade ju bara in koden från pic18f452 och konverterade den lite och sedan kompilerade och körde .Fick inga fel .simulerade och fungerade utmärkt.
Men inte när jag kör den i verkligheten . Svara inte på något. Fundera på kanske också om kretsen resistor jag kopplar mot jord eller Vss beroende om den ska vara Push down eller push Upp.Så kanske den är lite mera känslig för lägre resistor värde än pic18f452 kretsen.jag andvänder jämnt nu 330 ohm i stället frö 1 k ohm. Har nu beställt en pic 18f542 krets till om jag inte löser problemet och 10 st 1 k ohm resistorer. Det är nämerligen så att jag andvänder en kod(Polling avläsning,timer0) för att styra servot med den är tänkt att sitta i pic 16f84a kretsen sedan logikmjukvaran att sitta i pic 18f452 kretsen. Sedan koppla i hopp dessa kretsar med varandra. Med hjälp av detta så har jag byggt en liten mojäng. Vill inte tala om vad.hemligt.Tack vare test att ta patent på ideen att börja med. Så nu håller jag på att bygga upp en inovation.
glömde en sak
Måste tacka framför allt dig sodjan och icecap för att ni har ståt ut med mig på forumet och förhoppningsvis vill ha kvar mig. Vill fråga för mycket. Beror på att jag är för intresserad för att lära mig mer om pic processorer. ett intressant ämne att ha som hobby på sidan om jobbet. Tack så mycket för all hjälp. Jag är nog inte den enda som vill tacka er heller. Jag delar nog mina känslor med masa andra med på forumet.
Notera att ett byte från 18Fxxxx till en 16F84A är ett *mycket*
stort steg **tillbaka**.
Det är mycket osannolikt att en applikation (om den inte är
väldigt enkel) för en 18F skulle fungera på en F84A.
Det kan fungera, men då måste du i princip kolla rad-för-rad för
och jämför med F84A för att se att det är korrekt.
> Då började jag ändra tex WREG=W
Notera att 18F har W "mappat" som ett SFR (WREG), det har inte F84A.
Så t.ex en MOVFF med WREG som en parameter måste skrivas om helt.
Det är också stora skillnader i konfig m.m.
> Så nu håller jag på att bygga upp en inovation.
Då ska du *absolut inte* använda F84A !! Den är dyr, dålig och stendöd.
Vill du ha 18-pinnar så är t.ex 628A, 648A eller 88A bättre (bereoende
på vad du behöver i kretsen).
stort steg **tillbaka**.
Det är mycket osannolikt att en applikation (om den inte är
väldigt enkel) för en 18F skulle fungera på en F84A.
Det kan fungera, men då måste du i princip kolla rad-för-rad för
och jämför med F84A för att se att det är korrekt.
> Då började jag ändra tex WREG=W
Notera att 18F har W "mappat" som ett SFR (WREG), det har inte F84A.
Så t.ex en MOVFF med WREG som en parameter måste skrivas om helt.
Det är också stora skillnader i konfig m.m.
> Så nu håller jag på att bygga upp en inovation.
Då ska du *absolut inte* använda F84A !! Den är dyr, dålig och stendöd.
Vill du ha 18-pinnar så är t.ex 628A, 648A eller 88A bättre (bereoende
på vad du behöver i kretsen).
Håller helt med sodjan (även här). PIC16F(/C)84(A) är så död att den till o med luktar illa 
DESIGNA INGET NYTT MED DEN!!!!!
ANVÄND DEN ENBART OM DET ÄR "LIVSVIKTIGT"!!!!
På Microchips hemsida kan man jämföra "designpriser":
16F84A: $2.71 (1Kword prog, 64 byte EEPROM, 68 byte RAM, 13 I/O, 0 AD, 1 timer)
16F88: $1.93 (4Kword prog, 256 byte EEPROM, 368 byte RAM, 16 I/O, 7 AD, 3 timer, int. osc., AUSART mm)
Fattar du galoppen?
'F84A kostar 41,5% mer, har 25% av programmeringsminnet, 25% EEPROM, 18,5% RAM minne jämförd med 'F88.
På '88'an har man dessutom även en bra intern 8MHz oscillator, AD-ingånger, 3 timers (2 st 8-bitars, 1 st 16 bitars), AUSART (serieport med godis) osv osv.
Om du alltså designer något nytt med en 'F84A skjuter du dig själv i foten, det blir dyrare, besvärligare och inte lika enkelt uppgraderbart.
Dock tycker jag att man kan testa saker med en 'F84A om man bara ska kolla en grej och har den liggande men nydesign? NEJ!!!!!!
DESIGNA INGET NYTT MED DEN!!!!!
ANVÄND DEN ENBART OM DET ÄR "LIVSVIKTIGT"!!!!
På Microchips hemsida kan man jämföra "designpriser":
16F84A: $2.71 (1Kword prog, 64 byte EEPROM, 68 byte RAM, 13 I/O, 0 AD, 1 timer)
16F88: $1.93 (4Kword prog, 256 byte EEPROM, 368 byte RAM, 16 I/O, 7 AD, 3 timer, int. osc., AUSART mm)
Fattar du galoppen?
'F84A kostar 41,5% mer, har 25% av programmeringsminnet, 25% EEPROM, 18,5% RAM minne jämförd med 'F88.
På '88'an har man dessutom även en bra intern 8MHz oscillator, AD-ingånger, 3 timers (2 st 8-bitars, 1 st 16 bitars), AUSART (serieport med godis) osv osv.
Om du alltså designer något nytt med en 'F84A skjuter du dig själv i foten, det blir dyrare, besvärligare och inte lika enkelt uppgraderbart.
Dock tycker jag att man kan testa saker med en 'F84A om man bara ska kolla en grej och har den liggande men nydesign? NEJ!!!!!!
ok, sodjan
men inse hur klassiker kretsen är.status stämpeln är fin. Jag håller på med pic 16f84A krets. Satt på alla priratkort till viacess och dmac. Är bara så kultförklarad krets.
