Sida 1 av 2
PIC IO ?
Postat: 24 oktober 2006, 18:25:45
av persika
Har tänkt att använda en pinne på en 12F629 som öppen-kollektor utgång/ingång.
Tanken är att pinnen ska vara högohmig då den är ingång och när den är hög som utgång, alltså ska den låg när den är lågohmig.
Jag vet inte riktigt vad som händer när man ställer om i TRISIO-registret från ingång till utgång, kommer pinnen att ge ut den nivå den hade när den var ingång, precis innan TRSIO ändrades ?
se exempel här:
12F629
; OC-pinne ställs in för normaltillstånd som ingång
bsf status, RP0 ; bank 1
bsf TRISIO, OC-pinne
bcf status, RP0 ; bank 0
;
;
;
;signal skickas ut på OC-pinne, dvs den görs låg
; ställ om till utgång
bsf status, RP0 ; bank 1
bcf TRISIO, OC-pinne
bcf status, RP0 ; bank 0
; Här är det okänt om OC-pinne är 1 eller 0, bara känt att den är
lågohmig, eller.. ?
bcf GPIO, OC-pinne ; OC-pinne görs låg
Postat: 24 oktober 2006, 18:46:32
av sodjan
När pinnen är ingång, är den högohmig.
När pinnen är utgång styrs den av motsvarande bit i GPIO registret.
Du ska alltså ha en pullup på pinnen (eller "linjen" den är kopplad till,
normalt gör man så här för att bygga en "bus" med flera processorer...).
> kommer pinnen att ge ut den nivå den hade när den var ingång, precis innan TRSIO ändrades ?
Den kommer att ha värdet som motsvarande bit i GPIO har.
Detta värde kanske inte är det som du tror, p.g.a av operationer
mot GPIO som du gjorde medan pinnen var ingång. Om du t.ex gör
en bcf/bsf mot en *annan* pinne, så kommer hela GPIO att läsas
(inkl OC-pinnen), den andra pinnen sätts enligt bcf/bsf parametern och
resultatet skrivs tillbaka til GPIO. Alltså har din OC-pinnen nu samma
värde som ingången just nu istället för det du tror.
Ovanstående kallas "read-modify-write" (eller bara RMW) fenomenet.
Bäst är att se till att GPIO-biten är korrekt direkt innan pinnen sätts till utgång.
Postat: 24 oktober 2006, 21:19:43
av persika
>När pinnen är ingång, är den högohmig.
>När pinnen är utgång styrs den av motsvarande bit i GPIO registret.
Jag är helt med på det.
>Du ska alltså ha en pullup på pinnen (eller "linjen" den är kopplad till,
>normalt gör man så här för att bygga en "bus" med flera processorer...).
Det är så jag tänkt.
Om jag förstått rätt:
Så alltså under tiden OC-pinnen är en ingång, så nollställer man motsvarande bit i GPIO.
Då skulle egentligen OC-pinnen nollställas, om den hade varit en utgång, det görs så att säga i luften.
Så när man sen gör om OC-pinnen till en utgång så har den rätt nivå direkt.
Om ett avbrott (interrupt) kommer mitt i ovanstående, kan det bli fel då ?
Postat: 24 oktober 2006, 21:39:34
av vfr
Inte av bara ett avbrott vilket som helst! Däremot om avbrottskoden är och pillar på den pinnen, eller ev. rmw på andra portpinnar så skulle det kunna bli det. Men isåfall är det helt upp till koden du har skrivit.
Postat: 24 oktober 2006, 21:46:52
av sodjan
> Då skulle egentligen OC-pinnen nollställas, om den hade varit en utgång, det görs så att säga i luften.
Tja, i "luften" vet jag inte, det görs i GPIO registret.
Det är bara det att om pinnen än ingång, så finns det så att säga
igen koppling mellan GPIO och själva pinnen...
Om du tittar på schemat för GP0/GP1 i databladet, så ser du att det
finns en D-vippa där dete står "WR PORT" (jag tycker att det borde ha stått
"WR GPIO" men i alla fall). Den D-vippan är en en av bitarna i GPIO registret.
Sedan går utgången från den D-vippan till I/O pin via en buffert (den
trekantiga lilla saken).
Sen finns det en D-vippa till vid "WR-TRISIO". Notera att en av utgångarna
från *den* vippan (som alltså utgör en bit av TRISIO) styr den lilla
bufferten och kan sätta den i högimp läge.
Notera att "RD PORT" läser pinnen *efter* bufferten, så om pinnen är
en ingång så läses nivån på pinnen, inte på GPIO vippan. Det är därför
det kan bli problem när man gör bcf/bsf på *andra* pinnar, eftersom
alltid hela GPIO läses och skrivs tillbaka (och alltså sätter GPIP
vippan = aktuell nivå på pinnen...).
Postat: 24 oktober 2006, 21:49:12
av bengt-re
*ler* Detta är ett problem som kan ge en små gråa hår innan man fattade vad man gjorde för fel... Men med denna vetskap så är det inte skumt, utan bara en egenhet man får räkna med...
Postat: 24 oktober 2006, 21:51:11
av sodjan
It's all in the data sheet...

Postat: 24 oktober 2006, 21:57:02
av bengt-re
Yupp... men ibland glömmer och missar man saker som man faktist har läst... Fyller ju 35 nu, så senilitetet börjar så sakterliga slå in....
Postat: 24 oktober 2006, 22:19:54
av sodjan
Senilitet vid 35 !?
Tja, jag kan inte minnas någon senilitet 1994...
Eller det är kanske det jag gör...

Postat: 24 oktober 2006, 22:21:38
av bengt-re
Beöver en större hårddisk kanske bara... Eller en större defragmentering....
Postat: 24 oktober 2006, 22:44:51
av vfr
Kan undra hur många reservblock hjärnans hårddisk har att allokera av när dom urspungliga börjar bli dåliga. Kan man kolla det med S.M.A.R.T?
Postat: 24 oktober 2006, 22:51:10
av bengt-re
Man är ju alltid så smart..... så tveksamt....

Postat: 25 oktober 2006, 06:25:01
av persika
Har kollat schemat, på sid 22
Ser vippan vid WR-PORT
Är det så att den ställs i skrivdelen? av cykeln läs-ändra-skriv
GPIO är inte det ett register som ligger i nåt slags minne "inuti" själva processorn?
Postat: 25 oktober 2006, 07:03:50
av Pjoms
sodjan skrev:> Notera att "RD PORT" läser pinnen *efter* bufferten, så om pinnen är
en ingång så läses nivån på pinnen, inte på GPIO vippan. Det är därför
det kan bli problem när man gör bcf/bsf på *andra* pinnar, eftersom
alltid hela GPIO läses och skrivs tillbaka (och alltså sätter GPIP
vippan = aktuell nivå på pinnen...).
Rent spontant känns detta förfarande en smula märkligt, lite som att "be om problem"... Antar att det finns en tanke bakom, som jag dock inte ser.
Postat: 25 oktober 2006, 09:27:36
av vfr
Vid läsning av porten så måste man läsa från ingången om man bara har ett läsregister annars får du inte in indata med porten som ingång. Lösningen är ett extra register där du kan läsa ut latchens data vilket är infört i PIC18-arkitekturen. Detta är inget speciellt udda utan väldigt vanligt på mikrokontrollers I/O-pinnar.