Har försökt fått sensorer att fungera med en PIC i tre dar nu, men det verkar vara något problem som jag inte får ordning på. Kanske någon av er har aning om vad som skulle kunna krångla.
Använder för närvarande en gammal 84A pic trots att många anser den uråldrig. Men även den borde väl kunna ha en I2C krets som slav. Jag vill bara få det hela att fungera och det borde väl den duga till. Till den har jag en extern 4.19MHz kristall och jobbar på en labbplatta. De sensorer jag försöker kommunicera med är bla en temperatur/termostatkrets (MAXIM DS1631).
Tycker mig dubbelkollat hur många gånger som helst att jag skickar signalerna i rätt ordning (så det anges i databladet). Dessutomsamt har jag har en resistor 10K mellan VDD +5V och SDA samt en mellan VDD +5V och SCL. Har testat att kolla SDA-porten ändras när jag gör om den mellanl input/output och den verkar gå hög när porten görs om till input (vilket var förväntat eftersom pull-up-resistorn tar över) och låg när porten görs om till output (förstår inte varför, vad styr detta? Är det ett förbestämt värde? Blir det alltid så eller kan det styras).
Det som är mysko är att jag inte verkar kunna få sensorn att skicka ut några signaler efter det att jag gett den kommandon. Får de inte ens att skicka ACK signlalerna rätt. Jag skickar iofs in kommandona rätt långsamt, men det bör väl fungera ändå?
Det här kanske är ett vanligt problem, men jag lyckas inte finna nån lösning här på forumet på det och heller inte vid googling. Nån som har koll på vad som brukar strula med sånt här, eller tips på vad jag kan försöka med för att lösa problemet.
(Har till och med testat att skicka kommandona genom att handgripligen byta mellan ettor och nollor i rätt ordning, men inte heller det fungerade, sensorerna talar inte med mig.)
Hjälp! Krånglande 2wire Bus interface till diverse sensore
Okej, så din PIC är master på I2C bussen och ds1631 slav. Verkar logiskt och bra. 
Det är helt okej att dra ner på takten för att se vad som händer, dock så brukar ju ett scope inte
ha några problem med att visa minst upp till 400KHz som du kan maxa med här.
Du måste sätta upp både SDA och SCL som utgångar till en början med, "idle" läget ska
vara "1". Nu har din master tagit över bussen och kontrollerar den.
Nästa steg är att för mastern tala om att nu ska det börja hända saker, aka start condition
som PaNiC talar om. Detta är när SDA går låg och därefter SCL går låg. Kan du se detta
på scopet? Sätt trig på nerflank av SCL, det kommer du ha nytta av framöver...
Efter detta skickar du addressen till den device du vill tala med. Här brukar det vara vanligt
att dribbla bort sig pga den ologiska definitionen av address...
I2C address är 7 bitar, tittar man i datablad på tex eeprom är basaddressen för dessa 0x50
(upp till 0x57). Men det är inte alls 0x50 man ska slänga ut på bussen utan 0x50 ska shiftas
1 steg vänster (0xA0) och på den plats som man lägger till, bit 0, sätter man 1 för read och 0 för write (eller om det var tvärtom)
Bitarna i addressen läggs ut samtidigt som du klockar med SCL. Mastern är hela tiden
ansvarig för klockan så efter att ha klockat ut de åtta bitarna (address+r/w) så måste du
göra en klockpuls till för att slaven ska skicka sin ACK bit. Under denna nionde bit så ska
ju också SDA göras om till input men det verkar du redan ha koll på.
Tycker inte heller att din PIC borde ha några problem med I2C, dock så är I2C inte så
himla simpelt som en del vill skriva ut innan man har koll på hur addressering mm sker.
Dessutom, för att kunna läsa på en fast address gör man först en skrivning med 1 byte
som blir offset, därefter gör man om address fasen och skiftar till läsning. Hur klumpigt
är inte det?
Lycka till med ditt I2C'ande!
Det är helt okej att dra ner på takten för att se vad som händer, dock så brukar ju ett scope inte
ha några problem med att visa minst upp till 400KHz som du kan maxa med här.
Du måste sätta upp både SDA och SCL som utgångar till en början med, "idle" läget ska
vara "1". Nu har din master tagit över bussen och kontrollerar den.
Nästa steg är att för mastern tala om att nu ska det börja hända saker, aka start condition
som PaNiC talar om. Detta är när SDA går låg och därefter SCL går låg. Kan du se detta
på scopet? Sätt trig på nerflank av SCL, det kommer du ha nytta av framöver...
Efter detta skickar du addressen till den device du vill tala med. Här brukar det vara vanligt
att dribbla bort sig pga den ologiska definitionen av address...
I2C address är 7 bitar, tittar man i datablad på tex eeprom är basaddressen för dessa 0x50
(upp till 0x57). Men det är inte alls 0x50 man ska slänga ut på bussen utan 0x50 ska shiftas
1 steg vänster (0xA0) och på den plats som man lägger till, bit 0, sätter man 1 för read och 0 för write (eller om det var tvärtom
)Bitarna i addressen läggs ut samtidigt som du klockar med SCL. Mastern är hela tiden
ansvarig för klockan så efter att ha klockat ut de åtta bitarna (address+r/w) så måste du
göra en klockpuls till för att slaven ska skicka sin ACK bit. Under denna nionde bit så ska
ju också SDA göras om till input men det verkar du redan ha koll på.
Tycker inte heller att din PIC borde ha några problem med I2C, dock så är I2C inte så
himla simpelt som en del vill skriva ut innan man har koll på hur addressering mm sker.
Dessutom, för att kunna läsa på en fast address gör man först en skrivning med 1 byte
som blir offset, därefter gör man om address fasen och skiftar till läsning. Hur klumpigt
är inte det?
Lycka till med ditt I2C'ande!
Tack för era försök att hjälpa till.
Det verkar dock inte vara något av de problem som ni nämner som det här rör sig om. Jag skickar in start-kommando, addresskommando, ACK etc så som i databladet. Däremot har jag inte kollat med timing, eller ifall pulserna är branta nog, det har jag bara antagit att de är. Och jag har lagt in en hel del delayer mellan varje värde, för att kunna följa hur output/input ändras i koden. Jag har dessutom skrivit ut värdena på en LCD display för att kunna se att det jag lägger på output hos uC är det jag önskar.
Funderade ett tag på ifall mina pullupresistorer inte passar till både uC och I2C-sensorn. Att 10k kanske är lagom för uC men att inte sensorn "orkar" dra ned den till noll.
När jag försöker ta emot bitarna från I2C slaven så har jag använt mig utav följande sätt.
efter clockpulsen har gått hög och sen låg, skifta ett "sparregister" vänster.
Sen om "input" (på uC) visar hög skrivs en etta på position
"sparregister,00" annars en nolla. Detta görs 8ggr och jag förväntar mig då att de åtta bitarna som I2C skall skicka är skickade. Kanske finns det bättre sätt att fixa mottagningen på men det borde iaf funka.
Hade tänkt att sitta resten av dagen med att få bukt på vad det är som krånglar med kretsarna. Vi får väl se hur det går.
Det verkar dock inte vara något av de problem som ni nämner som det här rör sig om. Jag skickar in start-kommando, addresskommando, ACK etc så som i databladet. Däremot har jag inte kollat med timing, eller ifall pulserna är branta nog, det har jag bara antagit att de är. Och jag har lagt in en hel del delayer mellan varje värde, för att kunna följa hur output/input ändras i koden. Jag har dessutom skrivit ut värdena på en LCD display för att kunna se att det jag lägger på output hos uC är det jag önskar.
Funderade ett tag på ifall mina pullupresistorer inte passar till både uC och I2C-sensorn. Att 10k kanske är lagom för uC men att inte sensorn "orkar" dra ned den till noll.
När jag försöker ta emot bitarna från I2C slaven så har jag använt mig utav följande sätt.
efter clockpulsen har gått hög och sen låg, skifta ett "sparregister" vänster.
Sen om "input" (på uC) visar hög skrivs en etta på position
"sparregister,00" annars en nolla. Detta görs 8ggr och jag förväntar mig då att de åtta bitarna som I2C skall skicka är skickade. Kanske finns det bättre sätt att fixa mottagningen på men det borde iaf funka.
Hade tänkt att sitta resten av dagen med att få bukt på vad det är som krånglar med kretsarna. Vi får väl se hur det går.
woflheat, ifall du har ett scope är det enklast att koppla upp detta.
titta på address fasen att du får ack, då betyder det att slaven är med i spelet.
Är den inte det är det inte så stor ide att fortsätta med läsning osv.
10k på 5v borde väl funka tycker jag, är inte så hw kunnig dock... har du scope kan du ju se hur pulserna ser ut
det får inte vara för sega stigningar (kan bli om pull up är fel) orka hålla ner borde dock inte vara några problem.
titta på address fasen att du får ack, då betyder det att slaven är med i spelet.
Är den inte det är det inte så stor ide att fortsätta med läsning osv.
10k på 5v borde väl funka tycker jag, är inte så hw kunnig dock... har du scope kan du ju se hur pulserna ser ut
det får inte vara för sega stigningar (kan bli om pull up är fel) orka hålla ner borde dock inte vara några problem.
Har meckat en del nu, men får fortfarande inte ut ett ACK från sensorn.
Eftersom uC släpper SDA (gör om den till input) och sedan skickar ut en klocksignal så borde ju datalinan gå hög (pga Pull-up) och då borde I2C kretsen ta vid och dra ned SDA till 0 och värdet jag bör läsa på input till uC bör vara en nolla, men så är inte fallet. Sitter och funderar på ifall det kan vara något som händer med I2C kretsen under initieringen av portarna, så att den börjar syssla med något på egen hand innan jag skicka in startsignalen, men det låter lite mysko att den skulle få för sig att göra så.
Skall testa att dra ned Pull-up resistorerna i värde och se vad som händer.
Oscilloskop skulle ju kunna vara bra, skall fundera på saken.
EDIT: Verkar som om det är ganska slumpartat ifall jag får ett ACK eller ej, varkar vara ca 20% av gångerna jag kör igenom programmet. Skall jobba vidare med mina tester. Hoppas jag kan få det att fungera redan ikväll.
EDIT2: Tror mig hittat en orsak till att jag inte kunnat läsa av ACK-signalerna, och när jag tänker på det så är det rätt självklart, men förbisett från min sida. Jag har tolkat det som att man skickar över klockpulsen vid ACK för att I2C skall byta TILL ACK-värdet, men man skall ju skicka klockpulsen när man läst av värdet redan. I2C-kretsen byter ju till att styra SDA vid nedgången av föregående klockpuls. Har dock inte fått ut nån vettig signal från sensorn, men jag jobbar på det.
Eftersom uC släpper SDA (gör om den till input) och sedan skickar ut en klocksignal så borde ju datalinan gå hög (pga Pull-up) och då borde I2C kretsen ta vid och dra ned SDA till 0 och värdet jag bör läsa på input till uC bör vara en nolla, men så är inte fallet. Sitter och funderar på ifall det kan vara något som händer med I2C kretsen under initieringen av portarna, så att den börjar syssla med något på egen hand innan jag skicka in startsignalen, men det låter lite mysko att den skulle få för sig att göra så.
Skall testa att dra ned Pull-up resistorerna i värde och se vad som händer.
Oscilloskop skulle ju kunna vara bra, skall fundera på saken.
EDIT: Verkar som om det är ganska slumpartat ifall jag får ett ACK eller ej, varkar vara ca 20% av gångerna jag kör igenom programmet. Skall jobba vidare med mina tester. Hoppas jag kan få det att fungera redan ikväll.
EDIT2: Tror mig hittat en orsak till att jag inte kunnat läsa av ACK-signalerna, och när jag tänker på det så är det rätt självklart, men förbisett från min sida. Jag har tolkat det som att man skickar över klockpulsen vid ACK för att I2C skall byta TILL ACK-värdet, men man skall ju skicka klockpulsen när man läst av värdet redan. I2C-kretsen byter ju till att styra SDA vid nedgången av föregående klockpuls. Har dock inte fått ut nån vettig signal från sensorn, men jag jobbar på det.
Nu verkar jag fått en sensor att fungera. Verkade vara felet med ACK-signalen som strulade. Dessutom hade jag mixtrat fel med in/out på SDA porten vid startsignalen, det kan ha varit de två sakerna som gjorde att det inte fungerade. Bytte ned mig från 10k resitorn till en 1,8k men testade precis att byta till en 10k igen och det fungerade ypperligt.
Dock har jag läst att det skall vara bättre att hålla nere resistansen på pull-up resistorn för att få säkrare/starkare övergångar. Om detta stämmer eller ej vet jag inte.
En sak till som gjorde att jag fick fel resultat var tydligen att mitt sätt att lagra informationen har något fel i sig, eftersom nu när jag fick det att fungera så skrev jag ut resultatet direkt på displayen istället för att lagra den och då visade den något helt annat.
EDIT: Hur brukar ni behandla inkommande data från I2C-sensorer etc?
Dock har jag läst att det skall vara bättre att hålla nere resistansen på pull-up resistorn för att få säkrare/starkare övergångar. Om detta stämmer eller ej vet jag inte.
En sak till som gjorde att jag fick fel resultat var tydligen att mitt sätt att lagra informationen har något fel i sig, eftersom nu när jag fick det att fungera så skrev jag ut resultatet direkt på displayen istället för att lagra den och då visade den något helt annat.
EDIT: Hur brukar ni behandla inkommande data från I2C-sensorer etc?
tja, jag kör ju mest linux jag
Här finns ypperligt stöd för allehanda i2c devices, eeprom, rtc etc etc.
Så det brukar räcka med att göra själva i2c kontroller driver'n så är det klappat
och klart. I de få fall man vill att cpu'n man kör linux på ska vara i2c slav så
får man strula lite för linux har ju inget i2c slav stöd tyvärr.
Här finns ypperligt stöd för allehanda i2c devices, eeprom, rtc etc etc.
Så det brukar räcka med att göra själva i2c kontroller driver'n så är det klappat
och klart. I de få fall man vill att cpu'n man kör linux på ska vara i2c slav så
får man strula lite för linux har ju inget i2c slav stöd tyvärr.
