Svenska ElektronikForumet

PICar är allt bra underbara, vi har fått ett problem med RBchange interrupt i samband med I2C.

Eftersom SCL är monterat på RB4 så innebär detta att den ingår i avkänningen på change av PORTB. vi har andra behov av att kunna känna av detta interrupt men att få ett varje gång klockan på i2c skiftar state ödelägger vårt system helt.

Snälla säg inte att vi ska byta ben eller sådant för vi har redan etsat ett 10 tal olika kort som inte går att bygga om.

Picarna som vi vet att detta berör är 16F88 men troligen är denna portkompatibel med åtskilliga andra.

Någon som råkat ut för detta och har ett snabt svar på vad vi ska göra för att rädda situationen?

Vääääääldigt tacksamma för svar

Enligt databladet för PIC16C63A/65A/73A/74B kan det inte plockas bort selektivt, men det fungerar enbart för ingånger, är pinnen en utgång avkännas den inte till detta.

Vad man kan göra är att acceptera att så är läget och plocka bort den i interrupt-rutinen, det borde inte vara något problem.

Alltså:
1: Ändring sker.
2: Interrupt utförs.
3: PORTB läsas, ger status samt rensar interrupten.
4: Den lästa port-data jämnföras med det förra, om PB4 är skillnaden avslutas interruptrutinen.

Edit av brist på tankeverksamhet: Därför ska man ha klart för sig vilka features man vill använda innan man definierar hårdvaran. Lusläs datablad.

Det som tog oss totalt på sängen var att det är en bugg i PICen vad gäller delade funktionaliteter på samma pinnar, för att möjliggöra utnyttjandet av RB interrupt i samband med I2c så MÅSTE egentlgien detta ben undantas från avkänningen av förändringar.
Detta är mao en klart oväntad feature som endast kan härledas genom att tkgranska den scematiska bilden av RB4s uppbyggnad.
Inget i texten signalerar att detta problem skulle upstå.

Din lösning på problemet hade kanske fungerat OM det va en 1khz signal vi tittade på och daton instruktionsfrekvens ligger runt 1GHz
men nu är det picar och I2c vi åratar om där har en instruktion 0,2 microsekunder i exekveringstid och ett interrupt tar upp minst 20 instruktioner per gång = 4 micro sekunder.
I2c går normalt med en sådär 100-400 Khz vi har gått ner till 50k ungefär men det innehär att klockan går hör 50 000ggr i sekunden och därmed låg 50000ggr i sekunden detta ger ett interrupt mellanrum på 10 micro sekunder... dvs kvar för normal körning är inte mycket alls. skulle sedan något behöva göras i interrupten så skulle vi direkt gå in iväggen.

Men det finns ingen som haft problemet och löst det eller?

Tja, så länge pinnen är definierat som input är det så det är.

Enda lösningar som finns:
* Använd pinnen som utgång.
* Byt pinne.
* Låt bli att använda PORTB interrupten.
* Sänka hastigheten på IIC'n så det kan sorteras bort i mjukvara.

Andra lösninger finns inte.

Jag har i övrigt för vana att alltid bygga en prototyp så jag kan testa hårdvaran innan jag slutgiltigen definiera hårdvaran, jag har testat er situation ett par gånger för mycket.....

Just det: det är ingen "bugg" att PORTB:4 har den funktion, det är faktisk designat så från början och framgår av databladet. Finns det någon "bugg" är det ni som är den.

Vad ska man säga, förstår du inte problemet och kan du inte inse det orimliga i att i2c skulle utlösa interrupt så vet jag inte varför du svarar alls.

men nu är det vardag så nu kan jag kontakta vår företagskontakt på memec istället.

vad gäller att bygga modeller i förväg så låter det sig göras i små enkla byggen men inte i vissa fall

Kanske problemet är att du inte förstår eller hur?

Du använder tydligen pinnen som input, då det är SCL kan jag förstå att du har en slav-IIC.

Då Microchip är nere för tillfället på grund av uppdatering kan jag inte kolla databladet för PIC16F88 och jag kan därför inte veta om det sitter en IIC-hårdvara på den pinne men det kan du ju svara på.

Men OM det sitter en hårdvara-IIC till den pinne tycker jag att det är klart fel om man inte kan "pilla bort" den pinne från interrupt-on-change!

Men har du vald en mjukvaru-IIC finns det ingen hårdvara att skylla på....

Dessutom kan man bygga ganska stora system som prototyp utan större problem, man kanske kan välja olika kapslinger som är mer medgörliga men har man inte stora frekvenskrav är det ingen problem.

Nog tycker jag att det är lite konstigt att man inte kan använda hårdvaru I2C som slave utan att PORTB interrupten ska bli aktivt....

Är interuptet på portb kritisk, det kanse går att polla istället med hjälp av timmer interupt....

Här är databladet ialla fall
http://ww1.microchip.com/downloads/en/D ... 30487b.pdf

en varning i databladet tycker jag vore på sin plats...

Icecap:
"av brist på tankeverksamhet"
"Kanske problemet är att du inte förstår eller hur?"

Killen behöver hjälp inte att bli idiotförklarad...

Självklart vet jag både vad jag håller på med och vad man ska förvänta sig av en hårdvaruimplementerad I2C anslutning.

Ingången ska vara input och datakomunikationen hanteras av SSP modulen, inkl automatisk adressavkodning för slaven.

Jag håller med Icecap att det ser inte ut att vara lösbart på något bra sätt. Jag skulle nog kalla det här för en miss i konstruktionen eftersom det omöjliggör en sådan här användning. Det är kanske inte bara I2C som får problem. Egentligen skulle man vilja kunna maska vilka bitar som skall gå till "interrupt on change"-funktionen på port B i ett maskregister. Eller iallafall att RB4 maskas bort när I2C är aktiverat på porten.

Däremot kan vi väl ha en lite mjukare ton i konversationen, snälla...

Lösningen som jag nu tillslut fått tagit till är att sätta en 12F629a som change interrupt å därefter, skrota den funktion som upptog RB0 där det enda andra externa interruptet sitter

Men det skulel va intressant å veta vad microchips motivering till konstruktionen är helt klart

erixon & vfr:

tummen skrev: Vad ska man säga, förstår du inte problemet och kan du inte inse det orimliga i att i2c skulle utlösa interrupt så vet jag inte varför du svarar alls.

Behöver jag säga mer?

OK, nu då man kommer åt databladet kan jag bara säga att Microchip har dummat sig mer än vanligt! Den pinne skulle DEFINITIV vara möjlig att maska ut. Jag kan dock tänka mig en möjlig lösning: interrupt-on-change kan väcka CPU'n från deep sleep....så det kan vara en möjlighet att strömsnåla och ändå hänga med. Men maskeringsbar skulle den funktion vara!

Beklageligt att vara tvungen att byta processor mitt i det hela.

Edit: syftningsfel.

Det kan finnas en förklaring på varför det är som det är. SSP-enheten sitter normalt på port C (28/40-pin PIC) och då får man inte dom här problemen. Det man sedan gjort är att införa mer och mer hårdvara i dom mindre PIC:arna, t.ex 18-pin. Dessa enheter hamnar då på andra portpinnar och konsekvenserna kan ibland bli lite "konstiga".

Observera att jag inte anser att detta är en ursäkt för konstruktionen, bara en tänkbar förklaring på hur det blivit så. Det är uppenbarligen missat att gå igenom konsekvenserna av att byta port på SSP-enheten, eller alternativt för dyrt/komplicerat att åtgärda det. Skit är det hursomhelst!

Det är vilket fall bra att ta upp dessa problem här så att andra kanske slipper "pröva" samma sak.

vfr skrev:Det kan finnas en förklaring på varför det är som det är. SSP-enheten sitter normalt på port C (28/40-pin PIC) och då får man inte dom här problemen. Det man sedan gjort är att införa mer och mer hårdvara i dom mindre PIC:arna, t.ex 18-pin. Dessa enheter hamnar då på andra portpinnar och konsekvenserna kan ibland bli lite "konstiga".

Notare att vissa PIC'ar (t.ex 16F688, 14-pin) inte har någon B-port alls, utan en A-port och en C-port...

Har varit i kontakt med microchips support avdelning och de har konstaterat att chipet är felbyggt. en ny erratta släpps om en vecka ungefär.

http://support.microchip.com
ticket: 1-23043

Som avslutning kan man väl oxo tillägga att ni inte ska va så snabba att försöka idiotförklara andra som skriver något här, inte speciellt listigt att ge sig på människor som ni inte vet vilka kunskaper de besitter.
Hur ska de okunniga våga fråga något när de ser hur andra blir behandlade här, helt utan anledning och utan att det fanns något som helst fog för påhoppet?

tummen skrev:Vad ska man säga, förstår du inte problemet och kan du inte inse det orimliga i att i2c skulle utlösa interrupt så vet jag inte varför du svarar alls.

Jepp: låt bli med det!