I2C och PIC

[squiz3r]

Okej, Då får det nog bli en 16F628A som slav. Interrupten jag har kommer jag hålla väldigt korta, de ska bara läsa av en IO-pinne och ändra en variabel därefter, så det är bara några instruktioner.

Om jag då vill att mastern ska efterfråga lite data från slaven, och slaven sedan ska skicka de variablerna, då ska jag bara göra såhär:

1* Evig loop, vänta på "S"
2* Läs adress, Om adress = X eller 0, och R/W = R, skicka ett ACK, annars gå tillbaks till 1.
3* Skicka Databyte 1, vänta på ett ACK, om det inte kommer nästa klockcykel, gå tillbaks till punkt 1.
4* Skicka databyte 2, gör som ovan....
...
...
* Gå tillbaks till punkt 1.

Ser det rätt ut? Det finns väll egentligen ingen anledning för slaven att kolla efter en stopp-bit? Om den inte får något ACK eller om den har skickat all sin data kan den väll lika gärna gå tillbaks till punkt 1??

Men sen funderade jag på om min PIC håller reda på flera saker, och jag inte vill att den ska skicka alla, hur ska man då göra? Såhär eller:
Data från master: S - Adress, W (Vänta på ACK) - Data(tex, SKICKA ENDAST BYTE 231) (Vänta på ACK) - P
Data från slav: S - Adress, R (Vänta på ACK) - DataByte231 (Skicka ACK), P
Alltså så att först skickar mastern info till slaven om vilken byte den vill ha, sen skickar mstern ett R så att slaven kan skicka den byten som mastern bad om tidigare? Eller brukar man alltid ha så att slavarna skickar ALL data dem har?! (Ända tills mastern skickar ett NACK)

Det börjar klarna upp lite nu i alla fall... Sen ska man bara hitta något bra sätt att få in datan vid rätt tillfälle på klocksignalen..

[sodjan]

Bara några små generella kommentarer...

> I2C är segt/snabbt.

Tja, allt är rellativt. SPI t.ex körs ju betydligt snabbare, i alla fall
upp till 5 MHz, men jag tror att det finns 10 Mhz EEPROM, jag har
inte kollat så noga.

> hårdvaru eller programvarulösning ?

Visst går det att implementera en I2C master eller slav i programvara.
Mitt intryck är dock att det är lite enklare att skriva en SPI lösning,
bl.a p.g.a av att SPI har separata data-linjer i varje riktning. I2C har
lite mer "hyss" för sig med clock-stretshing o.s.v.

> Okej, Då får det nog bli en 16F628A som slav.

Samtidigt så skrev bl.a vfr att "Enligt min erfarenhet så är egentligen
slaven svårare att göra själv utan hjälp-hårdvara". Så där verkar du
inte ha tagit till dig rådgivningen...

Slutligen så ser det ut som att du ska bygga något där du själv
fixar både master och alla (?) slavar. D.v.s ingen färdig I2C-krets ?
I så fall kan du ju även sno ihop ett enklare/eget protokoll för bara
din egen applikation...

[squiz3r]

Sodjan: Vist hade det varit enklare att göra ett eget protokoll för dem två, men jag vill ju lära mig I2C! Jepp, Jag tänker göra både mastern och slaven, men sen när jag ändå har ett I2C nät på den så kommer jag säkert hitta en massa annat kul att koppla in .

"Så där verkar du inte ha tagit till dig rådgivningen..."
Jodå, men jag fick göra en övervägning. Som master kommer jag ha en kraftfull PIC (eftersom den ska göra en MASSA annat också) så den kommer ha inbyggt stöd för I2C. Så då är det bara slaven som är problemet, och då tar jag hellre en mindre PIC och gör mjukvaru I2C trotts att det är svårare. Om jag nu lyckas med det, då kommer jag ju ha ordentlig koll på hur I2C fungerar sen! Så jag ser det mera som en lärorik sak än vad som är lättast..

Jag såg någonstans ett EEPROM för SPI som gick i 20MHz! Sen läste jag någon stans att man med I2C kunde köra upp till 3,8Mhz eller något sånt tror jag det var, i alla fall var det ett antal MHz!

[vfr]

Det som jag kommer ihåg som det stora problemet med just slaven, var att den skall låsa klockan låg tills den är "färdig". Jag antog då att det måste göras tämligen omedelbart när klockan går låg, d.v.s hårdvarumässigt som en vippa. Men vid närmare eftertanke så kanske det finns (borde finnas) vissa minimitider som den ligger låg i vilket fall. Och att man då skulle ha tillräckligt med tid för att reagera programmässigt, iallafall på avbrott. Isåfall är det säkert inga större problem.

Det är några år sedan jag sysslade med I2C, så minnet är lite rostigt...

[squiz3r]

Om man kör 400 Kbit/s, då betyder det att klockfrekvensen går i 400khz?? I så fall så är ju klocksignalen låg 1,25µS!? (Jag utgår ifrån att klocksignalen har 50% dutycycle?)

Om jag kör en PIC på interna klockan, 4MHz, då är Tosc = 1MHz, vilket betyder att jag hinner göra drygt 1 instruktion på den tiden... Om jag kör på en 20MHz kristall, då hinner jag drygt 6 instruktioner på den tiden? Det känns som om det kommer bli väldigt stressigt...

Om jag har räknat rätt tar det ~172 µS att skicka 6 bytes? (Alltså från startbiten till stoppbiten) Eftersom mina interrupt kommer var 1,8onde mS så stänger jag av GIE när jag håller på att skicka/ta emot I2C data.. Då slipper jag det bekymret i alla fall!

Det som verkar bli svårast med detta är att trycka ihop timingen, för jag vill inte köra långsammare än 400Kbit/s... Man borde nog inte behöva ha interrupt för att hitta startbiten, inte om jag bara ligger i en evig loop och letar efter den? Problemet är ju om jag först får ett interrupt från mina andra sysslor, och jag är kvar i det interruptet när det kommer en startbit på I2C'n... Då kommer jag ju missa den ... Detta börjar bli komplicerat nu

[TomasL]

Om du använder en hårdvarustödd slav, dvs en PIC med MSSP, så får du ett INT när den detekterar en startkondition samt när bufferten är full. Detta gör att du inte behöver polla hela tiden.

[sodjan]

> ...Detta börjar bli komplicerat nu

He, du kanske skulle ha lyssnat bättre lite tidigare i tråden.
Att det blir lite stressigt att hantera 400 kb/s i bara programvara
är ju ganska uppenbart...

En annan sak är att jag inte vet om det har framgått vad det är
du ska göra. I2C handlar ju alltid om korta avstånd i alla fall (inom
samma kretskort eller kanske mellan moder/dotterkort) så varför inte
bara göra allt i huvudprocessorn istället ? Då slipper du ju I2C helt...

Nu var ju målet även att du ville lära sig I2C, men det kanske
är enklare med t.ex ett I2C EEPROM och en PIC med MSSP.

[squiz3r]

Självklart har ni helt rätt! Jag tar istället en 16F887 även om den är lite klumpig, den har både MSSP och ett antal "general pupuse I/O pins" med Schmitt Trigger på. Så den blir fin fin till detta..

Jo, du har nog rätt att jag kanske skulle börja med att leka master (på en med MSSP) till en färdigbyggd slav... Jag har två olika EEPROM från microchip, och jag tror även jag har en RTC som är I2C baserad. Så jag får väll börja med att leka med det..

Det jag ska använda det till är på en robot, en utvecklingsplattform, där jag tänkte ha en processor (18F4620) som sköter sensorer och andra leksaker, eventuellt PWMningen av motorerna också, sen har jag X antal rotations encodrar på hjulen, och eftersom dessa kommer ge interruppt lite då och då tänkte jag dedikera en processor för att ta tiden mellan alla interrupt på dem. Sen ska huvudprocessorn kunna be om dessa tider (=hastigheter) så ska den skicka dem så jag har lite att leka med.

Hur långt avstånd kan man normalt köra en I2C buss? Inom ett kretskort verkar ju inte vara några problem, men säg att man har några dm kabel emellan?

[sodjan]

dm är sannolikt OK.
Det finns nog specat någonstans...

[TomasL]

Beror naturligtvis antalet enheter, bussimpedans hastighet mm, men nån km eller så lär inte vara nått problem.

[squiz3r]

TomasL: Menar du verkligen Km, inte dm??

Edit: Mina RTCer var inte I2C, det var SPI .. Får bli att "leka" med ett 32k EEPROM istället.

[TomasL]

Jupp km dvs 1000 m ( snarare 1800 m)
Från Philips application note AN452

AN444 showed that shielded audio cable could be used to
communicate up to 1000 feet at a 100Kbps data rate. What if the
user wants to go farther? The answer is that you can, but you have
to do it at a slower data rate. In this Application Note tests were run
up to a distance of 6,000 feet, and the effect on the data rate was
noted. The results are shown in Figure 1. The tests were run with
the I2C hardware on the 87C751. Since there is not a great deal of
flexibility in the timing from Timer I, the only way to reduce the data
rate is to reduce the crystal frequency or use software “bit banging”.
This Application Note used the on-board I2C with the reduced
crystal frequency technique. The results are shown in Figure 2.

Så visst går det om man vill.
Det finns dessutom speciella I2C extenderkretsar för att köra ännu längre avstånd.
Dock finns det betydligt smartare sätt att kommunicera på dessa avstånd. Bl.a. RS485 mfl.

[squiz3r]

Intressant! Laddade ner app-noten och läste lite, dem fick gå ner till 3-4kbit/sek för att klara en "mile"! Men coolt i alla fall.

Här är app-noten ifall nån annan vill läsa: .PDF