Druckbare Version
danke, aber beim ersten Link wird man ja geradezu erschlagen - da weiß ich ja gar nicht wo ich hingucken soll vor lauter Daten- und Typensalat. So ein Durcheinander hab ich nich nicht gesehen.
Beim 2. Link - da hast du Recht, 79 USD, dann plus shipping (üblicherweise 30-80 USD aus Amiland) plus Zoll plus MWst - das ist ja ein Vermögen.
SMD kann ich aber auch nicht brauchen, weil die hier keiner löten kann, ich komme höchstens mit Steckbrettformat zurecht.
Die einzelnen Typen unterscheiden sich u.a. in der Art der SMD-Gehäuse und einigen, für diese Anwendung wohl unerheblichen, elektrischen Eigenschaften.
Meine Empfehlung aus der ersten Antwort ist als Stecklösung umsetzbar. Einfach alle Geräte an einen eigenen I2C-Bus hängen, dann gibt es keine Adresskonflikte.
Allein bei mbed.org finde ich drei Boards, mit je 3 I2C: Das ST Nucleo F401, das F411 und das Freescale FRDM-K64F. Zumindest mit den ST wäre man deutllich billiger als mit Arduino Mega oder Due. Man kann die Boards ja einfach mit ein paar M3-Distanzbolzen aufeinandersetzen, zu einem kleinen Turm.
Wenn man etwas die Arduino Scheuklappen ablegt, sollte die mbed Online IDE kein großes Problem darstellen. Ein I2C-Objekt unterscheidet sich nicht wirklich von einem Wire-Objekt in Arduino:
http://developer.mbed.org/handbook/I2C
Wenn es unbedingt Arduino sein muss, könnte man auch vier Due zusammenstecken. Jeder hat mit Wire und Wire1 zwei unabhängige I2C-Busse. Man könnte einen Due als Chef nehmen und die drei anderen über je einen UART des Chefs anbinden. Zwei I2C-Clients bedient der Chef selber, für die anderen schickt er per Serial... eine Anfrage an die Helfer.
Ist jetzt nicht die platzsparendste Lösung. Aber in den vorhergehenden Posts stand, es sollten wechselnde Geräte an I2C-Bus angeschlossen werden. Eventuell handelt es sich ja um eine Art Testaufbau oder Prüfstand ? Dann würde etwas verteilte Lösung mit mehreren Boards schon Sinn ergeben.
danke, aber das Projekt-Design lässt nichts anderes zu und ich habe nur 1 Hardware-i2c-Port frei - alle anderen Pins sind im Prinzip komplett besetzt.
(Warum Arduino die ports nun TWI und nicht i2c nennt, erschließt sich mir nicht, ist aber auch wurscht.)
Das ganze Projekt basiert aber auf einem einzigen Arduino Due, das lässt sich aus Performance-, Größen- und Programmiergründen (Sketch) auch nicht ändern.
Der 2. i2c-Port des Due ist auch schon für was anderes reserviert (er wird als i2c SLAVE benötigt).
Bleibt also nur der i2c-Muxer für meine 8 teilw sehr speziellen i2c-Endgeräte.
Sind noch IO-Bits frei, um Analogschalter-ICs anzusteuern ?
Wenn ich mit die Widerstandswerte vom PCA9548A anschaue, wäre folgender Ersatz möglich:
Für jeden der 8 I2C-Busse einen 74HC4066. Je zwei Analogschalter parallel, um den Widerstand zu senken. D.h. man hat dann noch zwei Schalter pro IC, womit man den SCA und SCL zu einem Slave verbinden und trennen kann. Man schaltet über IOs vom Controller nur den Client frei, mit dem man gerade sprechen will.
Wenn keine 8 Ausgänge mehr frei sind, aber mindestens 3: Einen 74HC595 nehmen, um die Schalter anzusteuern. Das geht mit ShiftOut auf dem Arduino, dazu gibt es Beispiele.
D.h. man hätte im Worst Case 9 ICs auf der Steckplatine. Geht das auch mit den 110 Ohm eines einzelnen Schalters und hat man 8 Ausgänge am Due frei, wären es minimal 4 Stück.
Der 74HC4066 hat bei Conrad die Nummer 1047751-62, der 74HC595 die 1074759-62.
analog-pins A0-A7 einschl sind in Benutzung, darüber hinaus sind sie noch frei.
Alles was mit eigener Hardware-Entwicklung und -Programmierung zu tun hat, ist aber zu kompliziert, der TI Chip erledigt das ja alles intern, vom Port-Switching bis hin zum Level-Shifting.
Übrigens wird mir für ein paar sehr spezielle Sensoren, die nur mit 9.6k laufen, von vielen Seiten bitbang empfohlen - das wäre eine gute Alternative.
Ich bräuchte nur dafür eine fertige lib, die folgendes über entsprechende API Funktionen problemlos portieren kann (für 1 von den 8 Sensoren, Rest entsprechend):
Code:// US sensor reading test
#include <Wire.h>
#define devaddr_US 0x02
byte US_readbytes[4];
void setup()
{
Wire.begin(); // join i2c bus
Serial.begin(9600); // start serial for output
}
void loop() {
byte bbuf, i;
Wire.beginTransmission(devaddr_US);
Wire.write(0x41); // send the ping command to write reg
Wire.write(0x01); // single shot mode
Wire.endTransmission();
delay(50); // give sensor time to do the ping
Wire.beginTransmission(devaddr_US);
Wire.write(0x42); // select read register
Wire.endTransmission();
Serial.println(" echo 0 1 2 3");
Wire.requestFrom(devaddr_US, 4); // request 4 bytes from slave device
while (Wire.available()) { // slave may send less than requested
bbuf= Wire.read(); // receive a byte
US_readbytes[i++] = bbuf; // store the byte
Serial.print(bbuf); // print the byte
Serial.print(" ");
}
Serial.println();
delay(50);
}
Zitat:
ceterum censeo: dass man hier nicht standardmäßig Code-Tags im Editor hat, finde ich reichlich doof, ehrlich gesagt.
Mir ist nicht ganz klar, wie ein I2C-Bitbang in Hardware geschaltet werden soll.
Da wären wir wieder beim Thema Open-Collector von oben. Dazu vielleicht erstmal diese Wikipedia Seite:
http://de.wikipedia.org/wiki/Open-Collector-Ausgang
Kurze Zusammenfassung: Ein normaler digital-IO hat zwei Transistoren, von denen immer nur einer durchgeschaltet ist. Entweder wird die Versorgungsspannung auf den Ausgang geführt, oder Masse. Der Ausgang ist entweder Low oder High.
Bei den I2C-Ausgängen ist das anders. Dort kommt die Versorgungsspannung über den Pull-Up-Widerstand auf die Leitung. Sagt keiner was, ist die High. Alle Ausgänge haben nur einen Transistor der gegen GND schaltet. Deswegen ist es auch egal, wenn mehrere gleichzeitig schalten.
Bei normalen Ausgängen hat man dagegen einen Kurzschluss, wenn einer High und einer Low ausgibt.
Und wie gesagt, bei I2C sind die SDA-Pins bei Master und Client jeweils ein Eingang und parallel dazu ein Open-Collector-Ausgang.
nein - das mit bitbang war eine andere Idee, mit "normalen" pins. Ich hätte ja noch ein paar ganz wenige normale pins frei (die nicht an timern oder IRQs hängen) und auch noch ein paar analoge.
Wäre doof, wenn ich einen timer IRQ pin opfern müsste, aber wenn, dann timer 2 IRQ.
Die Frage ist ntl, ob man mit 2-3 digitalen und 4-5 analogen Pins ein bitbang-i2c für 8 unabhängige Peripherals hinkriegt.
Ansonsten kommt für Hardware-i2c nur ein fertiger, funktionierender i2c Mux/Switch in Frage samt fertiger Arduino-Lib, wie der obige.
@ Mxt
Noch mal kurz über einfach mit z.B. Schottky-Diode (D) gebastelten OC/OD Ausgang am µC:Code:VCC=5V
+
|
.-------------.
| | |
| ||-+ |
| ||-> |
| -||-+ |
| | | Output D
| µC +---------o-S<-o-> I²C
| | |
| ||-+ |
| ||<- |
| -||-+ |
| | |
'-------------'
|
===
GND
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
danke für das Schaltbild. Ich verstehe es zwar einerseits nicht, aber wenn - was macht man dann damit?
Ach ja richtig. Danke.Zitat:
Zitat von PICture
Ok, das mit der Diode sollte auch an einem Due gehen, da könnte man auch mit 5V arbeiten.
Wieviele Pins würde man brauchen ? 8 mal SCL, zu jedem Slave einer. Ein gemeinsamer für SDA zu allen. Und zwei Eingangspins. Damit komme ich auf elf. Soviele hat er wohl nicht frei. Könnte man die SCLs noch irgendwie multiplexen ? Der Trick mit der Diode würde ja auch an einem Logik-IC gehen ...
Die Programmierung auf einem Due würde wahrscheinlich an die Grenzen der Arduino Software gehen. Für 32-Bit Entwicklung finde ich die nicht so berauschend. Müsste erstmal nach den Gegenstücken zu FastIO und wait_us() vom mbed suchen ...
[Edit]
Ah, Mikrosekunden warten haben sie ja doch, aber
Auch beim Due ?Zitat:
This function works very accurately in the range 3 microseconds and up. We cannot assure that delayMicroseconds will perform precisely for smaller delay-times.