PIC, ändra port från analog till digital utan att ha källkod

[JohnGalt]

Jag har ett kort med en PIC16F74, vars kod är flyttad från en äldre PIC där PORT A enbart var digital.
Eftersom PORT A default analog, fungerar det inte som tidigare och jag vill ändra porten till digital ( ADCON1=0x07 ).
Jag har dock inte tillgång till rätt version av källkoden.

Min fråga är: Finns det något sätt att ändra porten utan att ha källkoden?

Min tanke var att i assembler el direkt i hex-filen göra ett uthopp direkt när programmet startar (till ledig plats i programminnet), sätta ADCON1=0x07 och sedan hoppa tillbaka till efter uthoppet (och även flytta de instruktioner vars plats jag lånar för uthoppet till uthoppsrutinen).
Hoppas det framgår hur jag menar.

Är detta en framkomlig väg? Finns det andra (enklare) metoder?

[sodjan]

Det är en väg som tekniskt sett fungerar, om man inte har
några andra möjliga vägar. Inget konstigt egentligen, så
gjorde man ofta för 30 år sedan även i stora system. Dock
så ställer det ju lite krav på att man vet vad man gör och
att man kan arkitekturen man jobbar med. Men det fungerar...

Du har alltså tillgång till HEX filen?
Eller kan du läsa ut den från processorn?
Ligger även CONFIG i HEX filen?

[LHelge]

Det borde väl finnas verktyg för att disassemblera hex-filen.

I så fall borde det räcka att lägga till en rad som skriver till ADCON1 och sedan assemblera den igen.

[jesse]

Det ska säkert fungera bra, jag har själv gjort liknande saker. Det är en fördel om man har en disassember, så att man kan se koden.

[bearing]

Jag har ett gammalt program som heter "IC-prog" som kan disassembla filer. Har legat orört i massor med år på min hårddisk, men jag använde det faktiskt nyligen då jag disassemblade en "hex-fil" som hörde till en Alltrax motorstyrning (PIC-processor). Filen innehöll en lookup-tabell (retlw), som jag kunde ändra och assemblera igen (med MPLAB), och sedan skicka in i processorn, och allt fungerade som tänkt.

http://www.ic-prog.com/index1.htm

[jesse]

Jag skulle nog undvika att assemblera om koden. Bättre att hitta plats där man kan göra ett call, och sedan ändra direkt i hex-koden. Tror det kan vara stor risk för fel annars, eftersom en disassembler ofta gör fel (tolkar data som instruktioner t.ex).

[vfr]

Håller med om att det inte ska vara några problem. Men man bör nog ha bra koll på arkitekturen och tungan i rätt mun. Dissasemblera och jobba direkt mot hexdata när du gör modifieringarna.

[bearing]

Jag skulle nog undvika att assemblera om koden. Bättre att hitta plats där man kan göra ett call, och sedan ändra direkt i hex-koden. Tror det kan vara stor risk för fel annars, eftersom en disassembler ofta gör fel (tolkar data som instruktioner t.ex).

Finns bara instruktioner FLASH i en PIC av den här typen. (Man sparar data i FLASH m.h.a. retlw-instruktioner)

[sodjan]

Och egentligen har just det ingen större betydelse, bara det blir
samma "data" efter assembleringen. Det är samma "sorts" bitar i
instruktioner och data... Men kanske att det finns andra
fallgropar, och det är ju bara ett par instruktioner som ska
flyttas/läggas till.

> Jag har dock inte tillgång till rätt version av källkoden.

Har du tillgång till *någon* version av källkoden och i så fall,
hur mycket skiljer den sig från originalet? Den kan ju kanske
i alla fall vara till hjälp för att bedömma en disassemblering...

[JohnGalt]

Tack alla för era synpunkter och råd , då gör jag ett försök.

Jag kan ju läsa ut filen och disassemblera den i MPLAB, så jag behöver inte jobba direkt i hex-filen. Men jag kan ju inte gärna lägga in extra rader?, då blir ju alla hopp i koden fel, de går ju till absoluta adresser.

Ja, jag har *någon* version av källkoden , så det kan ju absolut vara ett stöd. Det bör vara stora likheter. Bra råd.

Gjorde så här i AXE-växlar en gång i tiden (säkert fler här som jobbat med det?), men vill minnas att det fanns en massa "NOP" överallt, så det var lätt att hitta plats för uthopp. Här finns inga sådana tomrum, så instruktionerna på de adresser jag lånar får jag också lägga i uthoppsrutinen.

[sodjan]

Nej, du ska inte "flytta" koden mer än det som behövs för att lägga in en CALL någonstans.
Annars ställer du , som du också säger, till det med alla andra CALL och GOTO...

Du går först förstå vad den gör "i början" så att säga. Eventuellt hade källkoden en "init"
subrutin, du kan ju leta efter en "MOVWF TRISA" eller liknande och en CALL i början.
När du har hittat vad som sannolikt är original-init rutinen, så kan du t.ex byta ut 2-3
instruktioner till en CALL (och eventuellt laddning av PAGE bitarna beroende
på var du lägger det nya). De delar som du plockar bort får också ingå i den nya
koddelen som sedan avslutas med en RETURN. En klassisk patch av binär...

[bearing]

Visste inte att MPLAB innehöll en disassembler. En bra disassembler byter ut adresserna i hoppen till labels, så då behöver du inte vara rädd för att lägga in instruktioner som förskjuter programmet. IC-prog gör detta. "; Generated by WinDis84, (c) Nigel Goodwin 1998.", står det i filen som IC-prog genererar.

EDIT: i vissa program (som t.ex. innehåller långa retlw-tabeller) kanske tabellen måste läggas på en fast adress som är en multipel av 256 eller liknande, för att programmet ska fungera som det ska.

[sodjan]

Jag har för mig att den i MPLAB enbart avkodar varje instruktion.

[JohnGalt]

Stämmer bra att den i MPLAB enbart avkodar instruktion för instruktion. Då ska jag kolla upp IC-prog också, går det att göra så borde det bli enklare.
Tack igen, då har jag lite att bita i.