Druckbare Version
Hallo Zusammen,
ich suche derzeit eine alternative zum Raspberry PI, da dieser ja bekannterweise ein Problem mit dem I2C Bus hat,
welche in meinem Robby zu mehreren Subsystem verwendet wird.
Hat jemand den Beagle Bone im Einsatz ?
Wenn ich den Schaltplan richtig deute hat dieser auch mehrere i2C Bus System am rennen,
zwar mit 1.8Volt, aber das läßt sich wandeln auf 5V.
Gruss R.
Was soll denn der Raspberry PI, für ein I2C Problem haben? Hast du ein Link/Quelle die das belegt?
Hallo Frank,
der Raspberry PI (BCM2835) unterstützt kein "Clock Streching", was ein Problem bei der Verwendung von Atmega I2c Slaves darstellt,
wenn diese noch etwas anderes machen, als nur den I2C Bus zu bedienen.
Info hier:
http://www.advamation.com/knowhow/ra...i-i2c-bug.html
http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=13771
http://elinux.org/BCM2835_datasheet_...ock_stretching
und jede Menge mehr, wenn man google fragt
https://www.google.com/search?q=rasp...fe_rd=cr&gbv=1
Ich habe bis jetzt einen BigBanging Treiber für I2C gesucht, konnte diesen aber nicht finden.
Daher die Suche nach einer Alternative. Der "Beaglebone Black Rev C" /(Element14) scheint hier nicht schlecht zu sein,
da er scheintbar dieses Problem nicht hat.
Hast Du andere Erfahrungen gemacht ?
Viele Grüße
R.
Ich habe mit Raspberry noch nicht viel gemacht, daher die Frage!
Ach das berühmte "Clock Streching", das unterstützen auch viele andere AVR C-Libarys immer noch nicht. Ist I2C im Raspberry per Hardware realisiert oder eine reine Software-Lösung? Bei einer Softwarlösung sollte Treiber doch leicht um Clockstretching erweitert werden, viel mehr als eine Warteschleife muss da nicht rein! Oder mein schreibt schnell eigene C-Implementation, sollte auch nicht so schwer sein.
Hallo Frank,
die Sache ist wohl via Hardware realisiert und der verwendete Chip (BCM2835) unterstützt diese Funktion nicht sauber.
Nach meinen Wissen ist derzeit auch kein Treiber in Planung, welcher über "BigBanging" (Stichwort im Internet) die Steuerung des I2C Bus
per Software realisiert, da ja Standard I2C-Bausteine korrekt arbeiten.
Auch laufen einige Slaves, welche ich auf PIC Basis und in ASM geschrieben habe, ohne Probleme.
Bei meiner Motorsteuerung sieht das schon anders aus, die muss nebenbei noch einiges selber machen.
Hier geht mir bei jeder zweiten Übertragung ein Bit "flöten".
Da ich bis jetzt noch keinen Linuxtreiber geschrieben habe, und hierfür auch weder die Lust noch die Zeit habe,
verfolge ich lieber die Variante, einen Board zu nehmen, wo es arbeitet. Auch aus dem Grunde, weil der Frustfaktor
hier geringer ist. Zwar muss ich jetzt wieder die Hardware anpassen (Interface Board neu machen), dafür sehe ich
dann in der Realisierung keine Problem (bis jetzt jedenfalls).
Viele Grüße
R.
Man kann unter Linux GPIO Pins nutzen um dadurch aus ihnen I2C zu machen. Das war zur Laufzeit über das /sys Filesystem. Das muss auch unter dem Raspi gehen. Hier ein Link ins RPi Forum.
http://www.raspberrypi.org/forums/vi...p?f=44&t=76468
http://haifux.org/hebrew/lectures/25..._userspace.pdf
http://lwn.net/Articles/280187/
https://www.kernel.org/doc/Documenta.../dev-interface
https://www.kernel.org/doc/Documenta...iating-devices
Insbesonders "instantiating-devices" wird für dich interesant sein. Punkt:
Zitat:
Method 4: Instantiate from user-space
-------------------------------------
Und das Modul wird sein: "i2c-gpio".
Unter Linux kannst du mit GPIO's fast alles machen. ;)
Hallo,
ich will mein Programm so schreiben, das ich ohne große Probleme meine Hardware wechseln kann.
Da mein Program derzeit schon multi-thread arbeitet, will ich mir das auch nicht noch antun.
Ich hatte vorher eine CPU von Taskit (tu ich mir nicht nochmals an, lief gut, aber schlechter support, da hier nur Industiekunden gefragt sind.)
am Start und jetzt hatte ich es mit dem Raspberry PI versucht, weil ich da noch einen in Reserve von meiner Gebäudesteuerung hatte (FHEM.DE).
Nur scheinen mir die Probleme mit dem I2C Bus zu detailreiche und will ich will irgendwann mal zum Schluss kommen.
Der BeagleBone ist gestellt. Auch steht hier noch ein Cubietruck 3 rum, den ich auch noch konfiguieren (ipfire) muss.
Langeweile habe ich nicht (Beruflich wie privat), daher lasse ich anderen den Vortritt.
Gruss R.
Nun, um die Frage zu beantworten eine mögliche alternative wäre das Cubieboard oder Cubietruck je nachdem, wenn noch mehr Leistung sein soll ist das UDOO Projekt sehr interessant. Ein Hammer board (leider ohne Community) wäre der E9 mini PC.
Hi,
danke für die Info. Den Cubietruck 3 habe ich auch Zuhause, aber für andere Sachen
und nicht für meinen Robby. Hier wäre die Stromversorgung ein Problem.
Das Teil ist nicht nur in der Rechenleistung ein Kracher.
Wahrscheinlich muss ich hier mein derzeitiges Netzteil auch noch verbessern,
das mache ich aber erst, wenn die anderen Probleme (i2C Bus) gelöst sind.
Gruss R.
Sorry, dass ich nun mal ne Frage stelle, aber ihr scheint in diesem Thema ja gut daheim zu sein.Zitat:
... eine mögliche alternative wäre das Cubieboard oder Cubietruck .... Ein Hammer board ... wäre der E9 mini PC.
Für meinen Archie hatte ich ursprünglich an nen MiniPC als Zentralrechner gedacht. RasPi war wohl definitiv zu klein (und ich ein absoluter Linux-Nobody). Da hatte ich an manchen ITX gedacht, bin aber später nach manchen Überlegungen "erstmal" mit der aktuellen, verteilten AVR-8Bit-Lösung zufrieden, zumal aufwändigere Aufgaben wie Bilderkennung sowieso noch nicht kann.
Nun lese ich hier Cubiexx und E9 - und frage mich, wieso hir und bei ähnlichen Threads nie der Revo von Asus auftaucht. Ich hatte nämlich zwischendurch überlegt einen geschenkten Revo R 3610 zu verwenden. Der läuft mit 12V (getestet bis knapp über 10), frisst dabei knapp 2A und hat für mich (lacht nicht) als langjährigen Windowsnutzer eher den Anschein, dass ich das hinbekommen hätte. Klar, GPIO gibts da nicht und von zeitkritisch kann keine Rede mehr sein - aber wäre das eine mögliche Alternative? Was meint ihr dazu?
Danke schon mal jetzt für eure Kommentare.