PIC Disassembler?
PIC Disassembler?
Finns det någon ENKEL disassembler för PIC, både 16 och 18, som man kan ladda ned någonstans? Den skall bara användas för att validera en hemmaskriven assembler så det behövs inte några fina finurliga fantastiska finesser för att hjälpa till med att försöka återskapa labels och sådant.
Min egen assembler
Det är min egen assembler som skall användas istället för mpasm.jag tycker inte om syntaxen i den och lägger istället till PIC till den assembler jag redan har skrivit för 65C02 och 8088. För att kontrollera att det inte har kommit en bit på tvären någonstans så måste funktionen kontrolleras med en disassembler genom att assemblera och sedan disassemblera och jämföra ett nonsensprogram som använder alla instruktioner och addresseringssätt.
Den är fortfarande lite kvar, närmare bestämt kodningen, men det går snabbt bara jag får ledig tid. Hela infrastrukturen finns där ju redan och det är en enekl CPU med få adresseringssätt.
Alla opkoder är tre tecken, precis som till 6502, och adresseringen skrivs som t.ex ADD A,MEM för att addera till ackumulatorn ADD MEM,A så adderar den ackumulatornn till minnet. Det är så jag är van att skriva ochtänka, hela köret med destinationsbit gör mig vimmelkantig. Alla ALU-operationer utom SUB/SBC är kommutativa så därför går det att tänka på vanligt sätt. Unära operationer med resultatill ackumulatorn skrivs som t.ex. INC A=COUNT.
Den stödjer PIC 10/12/16 som ju är samma instruktionsset, samt PIC18.
Blir det lungt under julen så kommer den att vara färdig under mellandagarna tror jag. Nu skall det bakas kakor och annat gott inför helgen, så det blir lite mindre tid att knappa på datorn. Sådant här knappar jag helst på dagtid, på kvällen är jag trött och risken att få en bit på tvären blir mycket större.
Alla opkoder är tre tecken, precis som till 6502, och adresseringen skrivs som t.ex ADD A,MEM för att addera till ackumulatorn ADD MEM,A så adderar den ackumulatornn till minnet. Det är så jag är van att skriva ochtänka, hela köret med destinationsbit gör mig vimmelkantig. Alla ALU-operationer utom SUB/SBC är kommutativa så därför går det att tänka på vanligt sätt. Unära operationer med resultatill ackumulatorn skrivs som t.ex. INC A=COUNT.
Den stödjer PIC 10/12/16 som ju är samma instruktionsset, samt PIC18.
Blir det lungt under julen så kommer den att vara färdig under mellandagarna tror jag. Nu skall det bakas kakor och annat gott inför helgen, så det blir lite mindre tid att knappa på datorn. Sådant här knappar jag helst på dagtid, på kvällen är jag trött och risken att få en bit på tvären blir mycket större.
OK, du har alltså skapat en tänkt CPU med en egen instruktions
uppsättning som du sen "mappar" över till den riktiga processorn.
Det är ju inte bara att mappa instruktioner till varandra.
Man kanske inte alls bör skriva koden till en PIC så som
ditt språk förespråkar.
Skapar du maskinkod direkt eller PIC assembler ?
Hur gör du med "relocatable code" ? (D.v.s användning av MPLINK ?)
> Den stödjer PIC 10/12/16 som ju är samma instruktionsset,
Fel.
PIC10 och *vissa* PIC12 och 16 är 12-bitars processorer.
Nyare PIC12 och de flesta PIC16 är 14-bitars processorer.
Det finns vissa ganska avgörande skillnader.
Hur tar du hand om skillnaderna i arkitektur mellan olika
modeller ? Kommer du att skriva egna definitions- och
include filer ? Eller hur håller du reda på adresser till t.ex
SFR'er mellan olika processorer ?
uppsättning som du sen "mappar" över till den riktiga processorn.
Det är ju inte bara att mappa instruktioner till varandra.
Man kanske inte alls bör skriva koden till en PIC så som
ditt språk förespråkar.
Skapar du maskinkod direkt eller PIC assembler ?
Hur gör du med "relocatable code" ? (D.v.s användning av MPLINK ?)
> Den stödjer PIC 10/12/16 som ju är samma instruktionsset,
Fel.
PIC10 och *vissa* PIC12 och 16 är 12-bitars processorer.
Nyare PIC12 och de flesta PIC16 är 14-bitars processorer.
Det finns vissa ganska avgörande skillnader.
Hur tar du hand om skillnaderna i arkitektur mellan olika
modeller ? Kommer du att skriva egna definitions- och
include filer ? Eller hur håller du reda på adresser till t.ex
SFR'er mellan olika processorer ?
Den skapar maskinkod direkt, precis som den gör till 65(c)02 och 8088/86/V20/V30. Jag gillar enkelhet, så ut med rel-filer och linkers. Skall koden flyttas är det bara att .OR till en ny startadress och assemblera om. Den är enormt snabb så det finns ingen anledning att krångla med halvfärdiga mellanformat.
Det är 14-bit på det enkla instruktionssetet som jag har preparerat tabeller för, samt 18Fxx8. Kanske 12-bit kommer med, men frågan är om det kommer att bli använt. 14-bit versionerna lär täcka alla mina behov..
Registerdefinitionerna får skrivas som filer där det definieras labels för dem. Här går det att adresser bits också så att en viss bit kan erhålla en egen label.
Vad vill disassembler till mplab ha för input? Det kanske är en stökig bitstream typ rel-fil e.dyl?
Det är 14-bit på det enkla instruktionssetet som jag har preparerat tabeller för, samt 18Fxx8. Kanske 12-bit kommer med, men frågan är om det kommer att bli använt. 14-bit versionerna lär täcka alla mina behov..
Registerdefinitionerna får skrivas som filer där det definieras labels för dem. Här går det att adresser bits också så att en viss bit kan erhålla en egen label.
Vad vill disassembler till mplab ha för input? Det kanske är en stökig bitstream typ rel-fil e.dyl?
Senast redigerad av Marta 19 december 2005, 00:47:57, redigerad totalt 1 gång.
De har en 8-bit ALU, men instruktionsordet är 12 bitar på vissa avde enkl modellerna eftersom adresseringen av minnet inte kräver mera. Då slösar de inte dyrt flash-minne som bara skall vara tomt.. Det är sådant Du aldrig ser om Du änvänder färdigautvecklingsverktyg och bara jobbar på en grundläggande nivå.
En annan sak är att 6502 och 80xx är van Neuman arkitekturer, mendan PIC
är har en Harward arkitektur, vilket gör det hela lite mer "intressant". Men det
har du antagligen redan koll på...
danai > Nej det är 8bits processorer allihop.
Vilka då ? PIC processoerna ?
> Vad vill disassembler till mplab ha för input?
En HEX fil.
Välj rätt device.
Välj file->import
Välj view -> program mem.
är har en Harward arkitektur, vilket gör det hela lite mer "intressant". Men det
har du antagligen redan koll på...
danai > Nej det är 8bits processorer allihop.
Vilka då ? PIC processoerna ?
> Vad vill disassembler till mplab ha för input?
En HEX fil.
Välj rätt device.
Välj file->import
Välj view -> program mem.
> men instruktionsordet är 12 bitar på vissa av de enkl modellerna eftersom adresseringen av minnet inte kräver mera.
Nja...
Nu är det ju så att de 12 (eller 14) bitarna inte räcker till i alla fall,
därav uppdelningen av RAM minnet i banks och programminnet
i pages. På PIC18 är det en hel del bättre med 16 bitar...
Nja...
Nu är det ju så att de 12 (eller 14) bitarna inte räcker till i alla fall,
därav uppdelningen av RAM minnet i banks och programminnet
i pages. På PIC18 är det en hel del bättre med 16 bitar...
PIC18 har banks den också, upp till 16 stycken. Jag har inte tittat så noga på 12-bitarna, men det ser precis som väntat lätt ut att göra tabeller fördessaockså. I många fall är instruktionen bara shiftad två steg åt höger. Jag tycker det hadevarit bättr då att ha 14-bit ock skippa bankerna på de som har lite RAM.
Arkitekturen på PIC18 är lite av en mix, det är ingen ren harward utan det fuskas lite på de absolutadresserade hoppen och någon till.
Hur som helst, det är svaga processorer med torftiga instruktionset som lämnar mycket övrigt att önska. Bl.a. bristen på en vettig stack och indexregister. Lösningen att komplettera instruktionssetet med en otrolig massa SFR's är inte helt lyckad. Tänk om det hade funnits en liknande kretsmed 65C02 som kärna. Det hade varit fint. Tyvärr är alla mikrocontrollers från WDC maskprogrammerade och f*n vet om de kommer att göra någon mer. De rör på sig liteivarje fall, bla. har de en 6551 på gång, men den har några bitar på tvären i första upplagan.
Arkitekturen på PIC18 är lite av en mix, det är ingen ren harward utan det fuskas lite på de absolutadresserade hoppen och någon till.
Hur som helst, det är svaga processorer med torftiga instruktionset som lämnar mycket övrigt att önska. Bl.a. bristen på en vettig stack och indexregister. Lösningen att komplettera instruktionssetet med en otrolig massa SFR's är inte helt lyckad. Tänk om det hade funnits en liknande kretsmed 65C02 som kärna. Det hade varit fint. Tyvärr är alla mikrocontrollers från WDC maskprogrammerade och f*n vet om de kommer att göra någon mer. De rör på sig liteivarje fall, bla. har de en 6551 på gång, men den har några bitar på tvären i första upplagan.
Visst räknas PIC till "åttabitarna" generellt sätt.
Och dataminnesmässigt är nästan alla PIC 8-bitars, men det
var ju inte det tråden gäller, så du var lite "out of context"
i just detta fall.
> Det är så man burkar beskriva bitbredden på en processor.
> Iafa gör jag det.
Visst, gör du det.
Men är det inte mycket enklare och tydligare om man
gör som alla andra som talar om PIC processorer. Alltså
som 12, 14 respektive 16 bitars. Risken är ju stor att
det verkar som om man inte vet vad man talar om,
och det vill ju ingen...
> PIC18 har banks den också, upp till 16 stycken.
Jo, men det "stör" mycket mindre.
Jo, men det finns sätt att adressera hela RAM utan bankswitching, antingen via MOVFF eller via index registren. Nyare PIC18 har även en "extended
mode" med ytterligare adresserings möjligheter (främst avsedda för
kompilatorer, inte för assemblerprogrammering direkt).
Förresten, hur väljer dit verktyg att mappa din MOV instruktion
till antingen MOVF/MOVWF eller MOVFF ?
När det gäller 12-bitarna så tänkte jag på sådana "egenheter" som
att man inte kan göra CALL till hela programminnet...
Och dataminnesmässigt är nästan alla PIC 8-bitars, men det
var ju inte det tråden gäller, så du var lite "out of context"
i just detta fall.
> Det är så man burkar beskriva bitbredden på en processor.
> Iafa gör jag det.
Visst, gör du det.
Men är det inte mycket enklare och tydligare om man
gör som alla andra som talar om PIC processorer. Alltså
som 12, 14 respektive 16 bitars. Risken är ju stor att
det verkar som om man inte vet vad man talar om,
och det vill ju ingen...
> PIC18 har banks den också, upp till 16 stycken.
Jo, men det "stör" mycket mindre.
Jo, men det finns sätt att adressera hela RAM utan bankswitching, antingen via MOVFF eller via index registren. Nyare PIC18 har även en "extended
mode" med ytterligare adresserings möjligheter (främst avsedda för
kompilatorer, inte för assemblerprogrammering direkt).
Förresten, hur väljer dit verktyg att mappa din MOV instruktion
till antingen MOVF/MOVWF eller MOVFF ?
När det gäller 12-bitarna så tänkte jag på sådana "egenheter" som
att man inte kan göra CALL till hela programminnet...
Marta> Kan du inte göra tvärtom istället? Alltså assemblera med din assembler och sedan assemblera med MPLab för att slutligen jämföra outputen från dem båda. Detta skall ju ge samma hexfil som resultat. Borde väl vara enklare än att disassemblera det.
Sedan håller jag inte riktigt med om att relokering och sådant är onödigt. Iallafall i dom program jag skriver så är det en absolut nödvändighet för att det skall bli hanterbart. Men räcker det för dig så är det ju alldeles utmärkt! Lycka till!
Sedan håller jag inte riktigt med om att relokering och sådant är onödigt. Iallafall i dom program jag skriver så är det en absolut nödvändighet för att det skall bli hanterbart. Men räcker det för dig så är det ju alldeles utmärkt! Lycka till!
