Op het forum van "element14" was er een gast die zei dat ie dat gedaan had. Hij had het getest en het werkte.
Ik heb hem toen verteld dat volgens de raspberry pi foundation de CPU van de pi na verloop van tijd kapot gaat. "reduced reliability and lifetime". En zowaar. Na enige tijd werkte het niet meer. Hij had het toch getest?
Dus... volgens mij valt alles op z'n plek: Het werkt, maar niet voor lang.
Signalen van de pi naar een atmega gaat gewoon goed. Pi stuurt 3.3V hetgeen minder is dan de 3.5V die gegarandeerd als 1 gezien wordt. Maar veel meer dan de 2.5V die over het algemeen het "kantelpunt" vormt.
Andersom raad ik aan een 1k weerstand in serie te zetten en een scottky diode naar de 3.3V (vanaf de pin van de pi).
Voor i2c wordt aangeraden een levelshifter te gebruiken. Kan je maken met twee fetjes. (of kopen. Bij mij?)
Anderzijds, voordat ik die levelshifters had werkte het ook gewoon. Precies om dezelfde reden: Hoog aansturen vanuit de atmega dat gebeurt niet, dus die weerstand heb je niet nodig. en de pullup naar 3.3V levert een voldoende hoge spanning op dat je atmega het als een "HOOG" leest.
Maar als je de atmega als i2c SLAVE gaat gebruiken dan is er een probleem. Er zit een hardware bug in de i2c module van de raspberry pi CPU.
Als de i2c bus op 100kHz moet draaien dan moet de clock 2x per 10 microseconde van waarde veranderen, iedere 5 microseconde dus. Als een slave nog even tijd nodig heeft om eea te regelen, dan kan ie de clock laag houden om te zeggen: effe kalmpies aan.
Dus wat er in de PI zit doet iets van:
maak clock hoog (open drain: de weerstand moet z'n werk doen.)
5 microseconde later: If clock inderdaad hoog dan verdergaan anders over 5 microseconde weer kijken.
<verdergaan>
Dat ziet er in de eerste instantie goed uit maar dat is het niet: Wat er gebeurt is dat de atmega "even wachten" doet, en toevallig na 4.9 microseconde zegt: ok, ik ben klaar je mag verder gaan. Het clock signaal gaat omhoog en op 5 microseconde kijkt de pi: Ja hoog! en gaat verder (clock weer laag). Dan kan je uitrekenen dat de clock pas 0.1 microseconde hoog is geweest.
Nu zeggen de specs dat ie 5 microseconden hoog moet zijn voordat je verder mag.... Nu is de atmega zo gemaakt dat ie vanaf ongeveer 100ns inderdaad ziet dat het signaal hoog is geweest (ondanks dat de puls dus 50x korter is dan de spec vereist... Da's nog eens marge houden!). Maar wordt het korter dan ziet ie de (zeer korte) clock puls dus niet meer. Dan heeft de pi 8 bits verstuurd en de atmega pas 7 bits ontvangen. En loopt de boel vast.
Ik heb deze bug gevonden in april 2012. Toen was de CPU een BCM2835. Ze hebben deze bug NIET gefixed voor de BCM2836. En ook NIET gefixed voor de BCM2837.
edit: Nu ik het schema makkelijker kan bekijken, snap ik ook beter wat die layout doet.
Je moet gebruik maken van de tools die je software je geeft. Mensen maken makkelijk fouten.
Dus als jij er aan went dat eagle zegt: "7 airwires" als je op "ratsnet" clickt, dan gaat het je een keer gebeuren dat je een draadje vergeet. Eentje die NIET elders al doorverbonden is.
1 van die "elders doorverbonden" is de 3.3V van de pi. Op mijn printjes ligt er gewoon een baantje op m'n print. Gewoon om eagle gerust te stellen. Daarnaast heb je een aantal baantjes tot op het pad gerouteerd maar net niet tot het "aansluit punt van het pad volgens eagle". Ook gewoon aansluiten. Het kost je steeds een paar seconde en op een dag scheelt het je 2 weken omdat je print WEL goed is.
Hetzelfde geldt voor de design rule violations. Je hebt een aantal vias gelegt op GND pads van de pi. Sluit die dan ook gewoon goed aan in je schema dat eagle niet klaagt. Jij went er nu aan dat eagle design rules altijd wat te zeiken heeft en op een keer heeft ie gelijk.
[Bericht gewijzigd door
rew
op 19 november 2017 11:18:13
(16%)