Hallo zusammen,
ich bin auf der Suche nach einem RaspberryPi-ähnlichem
Einplatinencomputer, der 2 I2C-Schnittstellen hat.
Hintergrund: ich möchte mich damit zwischen zwei Geräte hängen die mit
i2c kommunizieren, diese sollen nichts davon mitbekommen (und können
auch nicht verändert werden). Das hiesst, dass der Computer beiden
Geräten die jeweilige Gegenstelle vorgaukelt.
Das RaspberryPi hat nur einen i2c
cubieboard hat wohl mehrere, aber nur einen einzelnen auf den
GPIO-Steckerleisten geführt
kennt ihr grad einen, der sowas könnte?
Danke
I2C schrieb:>> Das RaspberryPi hat nur einen i2c> cubieboard hat wohl mehrere, aber nur einen einzelnen auf den> GPIO-Steckerleisten geführt>
Nein, der Raspberry Pi hat zwei davon,
Neben dem 'P1' GPIO - Steckverbinder ist noch 'P5'.
Auf dem ist der zweite I2C.
Den Steckverbinder solltest du aber von unten einlöten, sonst wird es zu
eng, die Stecker drauf zu bekommen.
I2C schrieb:> Das hiesst, dass der Computer beiden> Geräten die jeweilige Gegenstelle vorgaukelt.
Muss das sein? Es genügt doch, wenn du auf den Leitungen mithörst.
Gruss Reinhard
Reinhard Kern schrieb:> Muss das sein? Es genügt doch, wenn du auf den Leitungen mithörst.
Es reicht,wenn klar ist, was der Slave gesendet hat und was der Master.
Wenn die Richtung mitprotokolliert werden soll wirds etwas
komplizierter.
Es geht darum, in einem älteren Auto, welches einen CD-Wechsler hat (der
notabene keinem Standard entspricht zu dem entsprechende Geräte gibt)
einen HD-Player zu installieren, ohne den CD-wechsler ausser Betrieb zu
nehmen.
Lustigerweise entspricht das Protokoll dem I2C. Mithören habe ich mit
einem AVR geschafft.
Deshalb möchte ich mich quasi in die Mitte hängen. Mit der Taste
"shuffle" würde ich dann die Quelle umschalten (von CD-wechsler zu
externem Eingang (das das Autoradio nicht hat) oder eben Harddisk) und
das entsrechende Audiosignal umschalten. Nur mithören würde auch gehen,
aber dann zeigt das Autoradio weiterhin das was vom CD-Wechsler ankommt
an und zusätzlich spielt der CD-Wechsler dann Shuffle wenn ich die
Quelle umschalte...
Deshalb möchte ich mich direkt dazwischen hängen und ggf. die Daten die
angezeigt werden selbst senden.
Zum Bitbanging: hätte ich mit einem AVR auch so gemacht. Nun könnt ihr
mir nochmals helfen: da das Ding (ob Raspberry oder was auch immer) ein
komplettes OS drauf hat, frage ich mich ob das noch funktioniert?! Wie
echtzeitfähig sind die Dinger? Wie gesagt, wenn ich die Kommunikation
mit einem AVR machen würde, hätte ich meine Bedenken. Kann da jemand
auskunft geben ob das problemlos möglich ist?
Ich würde das ganze tatsächlich mit einem AVR oder PIC mit zwei
I2C-Schnittstellen realisieren.
1.: Wenn Du den Zündschlüssel umdrehst, willst Du, dass das ganze sofort
funktioniert. Ein RaspPi wird aber erstmal eine halbe oder ganze Minute
lang booten, bis er bereit ist. Für mich wäre das ein KO-Kriterium.
2.: Das Auto ist eine sehr unfreundliche Umgebung. Beim Anlassen kannst
Du Spitzen von bis zu 40V auf der 12V-Versorgung haben. In einer
Automotive-Umgebung kommt es darauf an, wirksame Schutzschaltungen gegen
Störungen von außen einzubauen, um die Zuverlässigkeit sicherzustellen
und die eigene Schaltung vor Beschädigungen zu schützen. Ein PIC ist
hier ganz einfach robuster als ein hochintegrierter ARM, und
leistungsmäßig sollte er völlig ausreichen.
3.: Linux ist kein Echtzeitsystem. Jedenfalls kein wirklich gutes. Ein
FreeRTOS oder so wäre die bessere Wahl hier.
Ein PIC18F25K22 hat 4 in Hardware realisierte I2C-Schnittstellen und
kann mit 5V betrieben werden. Wenn Du mehr Leistung haben möchtest und
3.3V Betriebs- und Signalspannung ok sind, dann wäre zB ein
PIC32MX150F128B was für Dich. Das ist ein 32 Bit 50 MHz PIC mit 2
I2C-Ports und 128k Flash und 32k RAM und kostet bei Reíchelt 3.50€.
Bei den AVRs kenne ich keinen mit zwei I2C-Hardwareeinheiten, daher
würde meine Wahl in diesem Falle auf PIC fallen.
fchk
Zu deinen Bedenken:
1. ich würde das so machen, dass das System so arbeitet wie bisher, bis
der OS läuft (Radio mit CD wechsler direkt verbunden). Sobald der PC
läuft schaltet er sich dazwischen. Wenn ich einen kompletten PC im Auto
habe, muss der immer erst booten. Wobei das Booten optimiert werden kann
(bzw. über Hibernate o.ä.)
2. Das krieg ich hin. So wild ist das auch wieder nicht. Das Problem
habe ich mit jeder Elektronik die im Auto ist.
3. Da habe ich keine Erfahrungen. Deshalb meine Frage weiter oben dazu.
Bitbanging wird deshalb wohl ausfallen, aber ein i2c müsste doch schon
gehen? Da es sich ohne hin nur um die Steuerdaten handelt, kommt es
nicht auf jede Millisekunde an...
I2C schrieb:> 1. ich würde das so machen, dass das System so arbeitet wie bisher, bis> der OS läuft (Radio mit CD wechsler direkt verbunden). Sobald der PC> läuft schaltet er sich dazwischen. Wenn ich einen kompletten PC im Auto> habe, muss der immer erst booten. Wobei das Booten optimiert werden kann> (bzw. über Hibernate o.ä.)
Kann man so machen, aber das wäre dann nochmal etwas, was die
Komplexität erhöht. Ein PIC ist sofort da, einfach zu beschalten, hat
kein Filesystem, was beschädigt werden kann, und ist aus, wenn er aus
sein soll. So macht das auch die Zubehörindustrie, und so machen es auch
die Hersteller selber. Wobei die dann natürlich AEC100
Automotive-qualifizierte Teile verbaut, die von -40 bis +85 oder bis
+125°C funktionieren, die Boards mit Schutzlack versiegeln, etc etc.
Das ist der Weg, den man in diesem Fall geht.
fchk
Frank K. schrieb:> Ein PIC ist sofort da, einfach zu beschalten, hat> kein Filesystem, was beschädigt werden kann, und ist aus, wenn er aus> sein soll. So macht das auch die Zubehörindustrie, und so machen es auch> die Hersteller selber.
[ ] Du hast Ahnung von dieser Industrie.
Max
