Archiv verlassen und diese Seite im Standarddesign anzeigen : Arduino Mega/Due: i2c Master port multiplexen
hallo,
ich müsste den i2c Masterport auf dem Arduino Mega(5V) und Due (3.3V) multiplexen auf mindestens 8 einzelne i2c Ports (einer der Hauptgründe ist, dass die angeschlossenen i2c Geräte alle dieselbe i2c Device Adresse haben).
Wie mache ich das am geschicktesten mit welchem Zusatzchip?
Die Arduinos schaffen ja locker 400kbps per i2c, aber die Geschwindigkeit an den gemuxten Ports ist nicht so entscheidend, da reichen jeweils ~10kHz dicke.
Hallo,
ich kann nur zum ARM-Teil der Frage antworten. Bei Controllern wie auf dem Due gibt es normalerweise mehrere I2C-Busse, also nicht sowas wie einen Masterport. Der Due hat zwei I2C-Ports (SDA, SCL und SDA1, SCL1), es gibt aber außerhalb der Arduino-Welt Boards mit mehr Bussen.
Der hier hat z.B. drei I2C und vier SPI:
http://www.watterott.com/de/NUCLEO-F401RE
die könnte man über SPI verbinden, ein Board als Master die anderen als Slaves. Für den Preis eines Due hätte man dann zwölf I2C.
Will man das alles auf einer Platine, gibt es SPI-Lösungen wie den CP-2120. Da braucht man einen pro zusätzlichen I2C-Bus. Das geht auch nur am Due (oder anderen ARM-Boards), weil 3,3 Logik.
http://www.silabs.com/products/interface/spitoi2c/Pages/default.aspx
man kann theoretisch sowohl den Mega- als auch die beiden Due-I2c ports frei als Master oder Slaves konfigurieren per wire.begin() (mit oder ohne dev address Parameter: wenn mit addr-Byte, dann wird er slave, ansonsten master ).
Ich will auch nur 1 von den i2c ports verwenden, aber den eben multiplexen, um identische Slaves anschließen zu können (alle haben z.B. dev addr 0x02).
SPI ist keine Option, es soll der Hardware-i2c Port gemuxt werden ( - oder habe ich was falsch verstanden?)
Praktisch ist das ganze gedacht wie z.B. bei PCF8591 ADC/Analog-Muxern , nur dass eben nicht verschiedene Analog-Geräte sondern eben weitere i2c Geräte am selben Port gemuxt werden sollen).
Mit Logikgatter-ICs wird das ziemlich aufwendig. Ich kenne kein Multiplexer-IC mit Open-Collector- oder Open-Drain-Ausgang. Und SDA ist auch noch ein bidirektionaler Pin, Eingang und Open-Drain-Output gleichzeitig.
Hallo!
kleine Beitragergänzung #4 vom Mxt:
Jeden Ausgang könnte man mit einer Diode OC ("open collector") bzw. OD ("open drain") machen, dass nur an GND "zieht". ;)
ja, das bidirektional stimmt, ich muss ja bytes schreiben und lesen können.
Geschwindigkeit ist kein Thema, der Mega-i2c kann locker 400kHz und an jedem Endgerät reichen locker 10kHz aus.
Ich muss sie nur alle einzeln pollen können.
Die i2c slaves sind ganz normale i2c-Chips, das könnten z.B. durchaus PCFs oder MAXs oder MPUs etc. sein.
Das mit OC oder OD verstehe ich nicht.
wie man das macht, weiß ich nicht, man müsste mir dann eben die entsprechenden Sketch-Befehle noch dazu sagen damit wire.write/read richtig funktioniert und ich die einzelnen Slaves korrekt individuell pollen kann.
und 2 x 74HC4016 um die Signalleitungen durch zu schalten
Geht das vom Widerstand her ?
ach ja, es sollten schon erprobte oder bekanntermaßen funktionierende Lösungen sein, auf die ich mich 100%ig verlassen kann... 8-)
nein, ich bin absolut Elektronik-unbeleckt, ich brauche einen fertigen i2c-Multiplexer, der mit Arduinos zusammen funktioniert :)
ich verstehe übrigens auch nicht viel von der Verschaltung oder Programmierung, es müsste also auch gut erklärt sein :)
(einzelne i2c Geräte kann ich natürlich schon auslesen wie z.B. einen MCU6050, und hier oder da einen Widerstand oder einen Kondensator vor den einen oder anderen Pin zu setzen - nach Anleitung - ist ntl auch kein Problem)
- - - Aktualisiert - - -
ps,
da ich über die einzelnen Chips und die passende Elektronik keinen Überblick habe, nützten mir ntl auch die 10 Seiten Google-Treffer-Liste nichts - ich brauche da schon eine konkrete Angabe ;)
ich brauche da schon eine konkrete Angabe
Dann nimm halt den hier, der dürfte für dich passen:
http://www.watterott.com/de/Relay-shield-V20
:cool:
moment - das ist doch ein Relais-Shield - was soll ich damit tun?
Deine I2C-Leitungen umschalten.
Wenn es was fertiges sein soll, dürfte das, neben der Lösung mit mehreren Controllerboards, die einzige Lösung sein.
ich glaube, wir reden aneinander vorbei -
ich brauche einen i2c-Multiplexer, keine Relais.
Ich will wie gesagt 8 oder mehr i2c chips mit identischer dev-Adresse (oder 2x 4 etc.) am selben i2c Bus ansprechen.
Ich will auch nicht mehrere Arduino- Controllerboards o.ä. - nur einen Multiplexer.
ich glaube, wir reden aneinander vorbei -
Nein, du willst was fertiges. Also must du nehmen was es gibt.
aber das Relais Shield ist doch nichts fertiges? wie soll ich damit 8 oder mehr i2c slaves ansprechen?
ich dachte an einen Mux-Chip, ähnlich wie die PCF8591 oder PCF8574 oder meinetwegen den MAX127, aber eben für i2c-Endgeräte, nicht Analog-Endgeräte.
Es war ja auch etwas ironisch gemeint. Das Umschalten wäre zu langsam. Aber funktionieren würde es. Wird in der Messtechnik sogar mit sehr vielen Relais gemacht:
http://sine.ni.com/nips/cds/view/p/lang/de/nid/210705
Aber Mux-Chips hast du ja schon gefunden. Also kauf dir z.B. welche hiervon und mach dir eine Platine
http://www.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=1650&uiTemplateId=NODE_STRY_PGE_T
hallo,
wenn man da zum tca9548a Seite 3 anguckt
http://www.ti.com/lit/ds/symlink/tca9548a.pdf
finde ich einige unverständliche Beschreibungen z.B. über initiate und high to low transition -
das ist nichts was ich mit wire umzusetzen wüsste. Wie programmiere ich das in Sketch?
- - - Aktualisiert - - -
Soll das in diese Richtung gehen? Ich habe nur dieses Bastelprojekt gefunden, aber vielleicht gibt es das fertig: http://dangerousprototypes.com/2012/10/11/i2c-multiplexer-shield/
jetzt gerade erst deinen Post entdeckt!
Genau!
Sowas in der Art! Guck ich mal genauer... (ja, scheint Marke Eigenbau zu sein - mal gucken ob es Programmierinfos gibt)
kennt jemand eine günstige Bezugsquelle in Deutschland für diesen
TI PCA9548A 8 channel I2C switch
Chip?
Am besten ntl mit Steckboard-kombatiblen Pins.
Bei Mouser kostet er 1,70, es gibt ihn von TI und NXP. Dort habe ich allerdings noch nie privat bestellt, soll aber gehen. Ich glaube der Mindestbestellwert ist sehr hoch.
Am besten ntl mit Steckboard-kombatiblen Pins.
Ich glaube den gibt es nur als SMD.
http://www.mouser.de/Search/Refine.aspx?Keyword=PCA9548A
[Edit]
Es gibt ein Evaluation-Board von TI dazu, ist aber teuer. Muss man wohl auch direkt bei TI in USA bestellen.
http://www.ti.com/tool/tca9548aevm
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):
// 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);
}
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:
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?
@ Mxt
Noch mal kurz über einfach mit Diode (D) gebastelten OC/OD Ausgang am µC:
Ach ja richtig. Danke.
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
This function works very accurately in the range 3 microseconds and up. We cannot assure that delayMicroseconds will perform precisely for smaller delay-times.
Auch beim Due ?
ich bekam inzwischen einen ernüchternden Hinweis von Andy Shaw, einem Programmier-Profi, der auch das komplette Java-Betriebssystem samt VM für Lego NXT und EV3 entwickelt:
I'm not surprised as I mentioned above the Lego i2c code (on both the NXT and EV3) adds extra wait states and an extra restart specifically for the Ultrasonic sensor. I doubt if any hardware i2c master will talk with it.
(...)
You can't add the extra wait states or the restart if using hardware i2c. See the following (or simply google Arduino Lego Ultrasonic) http://blog.tkjelectronics.dk/2011/10/nxt-shield-ver2/
das ganze ist mir aber denn doch im Moment ein wenig zu hoch, und es bedeutet wohl das Aus für den Hardware-Muxer.
Also bleibt dann trotz alledem nur noch das bitbang übrig.
Doch, die Lego-Sensoren kann man mit einem Hardware I2C auslesen, da bin ich vorhin drüber gestolpert, als ich nach Code für Bitbanging gesucht habe.
Siehe letzten Eintrag hier
http://developer.mbed.org/forum/mbed/topic/804/
Bitbanging würde von der Logik her so funktionieren
https://github.com/todbot/SoftI2CMaster
Problem: Der Code ist für den Uno. Um schnell genug zu sein, werden da direkt Register des Controllers manipulliert. Das würde bei einem Cortex-M3 wie beim Due ganz anders gehen. Weiß nichtmal, ob das 1:1 auf einem Mega geht, das sollten andere hier aber wissen. Deshalb mein Hinweis oben auf FastIO beim mbed, das hat man Zugriffszeiten auf IOs im zweistelligen Nanosekunden-Bereich und deshalb dieses Problem nicht.
der erste Link scheint aber doch nicht "richtiges" i2c zu sein, denn da steht doch
I2C i2c(p9, p10);
also ist es doch wohl nur eine Software-Emulation, oder?
I2c auf dem mega hat ja eigene Pins, und auf dem Uno sind es Pins A3 und A4 oder schlagmichtot.
Immerhin - ich bräuchte die 8 i2c Peipherals ja nicht nur für 1 Lego US-Sensor mit seinen besonderen Macken, sondern auch für frei wählbare gleiche, ähnliche oder andere Sensoren, sowohl lego als auch 3rdParty als auch Standard-i2c.
Das scheint dann aber äußerst schwierig zu sein.
Mit den github-Sachen kanst du mich jagen - ein derartiges Un-Ordner-Chaos, da blicke ich nicht durch. Da bräuchte ich
1 Ordner zum Kopieren in den Arduino-lib-Ordner
1 Ordner mit Tutorials in .ino und pdf-Form.
der erste Link scheint aber doch nicht "richtiges" i2c zu sein, denn da steht doch
I2C i2c(p9, p10);
also ist es doch wohl nur eine Software-Emulation, oder?
Nein, es ist ein "Hardware Abstraction Layer", das ist ja der Sinn von mbed.
Das Beispiel bezieht sich auf dieses IC
http://developer.mbed.org/platforms/mbed-LPC1768/
da siehst du in dem Bild: p9 und p10 können IO-Pins sein, ein UART oder ein I2C.
Mit
I2C Wire(p9, p10);
erstellt man ein Objekt, das den I2C-Bus kapselt, wie das Wire-Objekt in Arduino, was ja auch eine C++ Klasse ist (als vordefinierte globale Variable).
Das ist auch der Trick an dem Code für den Lego Sensor
{
I2C i2c(p9, p10); // Ab hier sind die Pins ein I2C-Bus
// ... hier wird was mit I2C gemacht
} // jetzt sind die Pins wieder unbenutzt
{
DigitalInOut scl(p10); // Jetzt ist p10 ein IO-Pin
scl = 0; // er wird als Ausgang auf Low gesetzt
scl.input(); // jetzt wird er ein Eingang
scl.mode(PullUp); // und der Pull-Up Widerstand eingeschaltet
// ...
} // Jetzt ist p10 wieder unbenutzt
{
I2C i2c(p9, p10); // Jetzt ist wieder ein I2C-Bus auf den Pins
// ...
}
Da hast du jetzt in der Tat ein schönes Beispiel gefunden, wo man zeigen kann, was mit mbed geht und nicht mit Arduino ...
ach so, das ist gar nicht für den Arduno Due?
Auf dem Due müsste man die harte Tour wählen. Prozessorhandbuch lesen und die Register entsprechend belegen. Standard-Arduino wird da nicht weiterhelfen.
An diese Stelle kommt man bei Due sehr schnell. Das ist nicht wie bei den 8-Bit Arduinos. Es gibt wenige Anwender, wenig Software, wenig Libraries und wenig Doku. Wer sich ernstaft damit beschäftigt, wechselt schnell zu was anderem.
Aber vielleicht gibt es bald auch für fest auf Atmel fixierte einen Weg. Seit Anfang Oktober ist Atmel Mitglied bei mbed:
https://atmelcorporation.wordpress.com/2014/10/01/atmel-teams-with-arm-on-iot-development-platform/
Auf dem Due müsste man die harte Tour wählen. Prozessorhandbuch lesen und die Register entsprechend belegen. Standard-Arduino wird da nicht weiterhelfen.
achduschei...
nee. das ist nichts für mich.
update:
ich habe nochmal was zu bitbang i2c gefunden - jemand der sich genau mit meinem derzeitigen Problem beschäftigt hat, nämlich den besagten NXT Ultraschallsensor zu bitbangen:
http://blog.tkjelectronics.dk/2011/10/nxt-shield-ver2/
das klappt jetzt mit dem Code dort! :D
jetzt kann ich doch einen Hardware i2c-Mux/switch verwenden und brauch also jetzt einen, der Steckboard-kompatibel ist :roll:
Gehe ich recht in der Annahme, dass du gar keinen Due hast ?
Im Code von dem Link steht
* Software: AVR-GCC 3.4.3 / avr-libc 1.2.3
* Target: any AVR device with hardware TWI
Der macht da das gleiche, wie der von mir gefundene mbed-Code, nämlich das Einfügen der zusätzlichen Signale auf dem SCL. Für die eigentliche Übertragung nimmt er aber das Hardware I2C, kein Bitbang.
Nur macht er das halt auch, wie der andere Code von Sourceforge, durch Beschreiben der AVR-Register.
Da auf dem Due aber kein AVR sondern ein SAM3 steckt, ist das nicht verwendbar.
hi,
Den Due habe ich tatsächlich noch nicht, der ist noch mit der Post hierher unterwegs, ich habe den Code bisher erst auf einem Mega getestet.
Wär ja wirklich doof, wenn der Code nicht auf dem Due läuft :(
Hallo,
den Code kannst du ganz einfach testen. Einfach in der Arduino Software ein Projekt für den Due anlegen und überprüfen lassen. Ich gehe mal davon aus, da kommen sehr viele Compilerfehler.
Und ganz wichtig, wenn dein Due da ist:
Keine Schaltung mit 5V Logik von einem AVR-Projekt einfach an den Due anschliessen. Der Due geht bei 5V Signalen kaputt ! In den "Absolute Maximum Ratings" im Datenblatt steht, kein Pin darf mehr als 4V gegen GND bekommen ! Auch der I2C-Bus vom Lego-Sensor wird einen Pegelwandler brauchen, wenn da 5V drauf sind.
Das ist bei den anderen von mir erwähnten ARM-Board anders, die sind 5V-Tolerant.
Um Eingänge vor 5V Signalen zu schützen, besorg dir 74HC4050 ICs. Wenn man die mit den 3,3V vom Due-Board versorgt, vertragen die über 12 V am Eingang. Um 3,3 V Ausgangssignale auf 5V Pegel zu heben, nimm 74HCT... Schaltkreise (das T ist wichtig, das steht für TTL-Kompatibel).
hallo,
danke für die netten Ratschläge! :)
Mit dem Pegelwandler-Problem hatte ich schon gerechnet und mir sicherheitshalber zum Due auch gleich diese Teile bestellt:
http://www.ebay.de/itm/131196183140?ssPageName=STRK:MEWNX:IT
Ich hoffe, ich bin da als Anfänger nicht auf die falsche Fährte gekommen... :-/
Der TI Muxer/Switch jedenfalls kommt ja mit allen möglichen Pegeln zurecht.
http://www.bitwizard.nl/shop/i2c-splitter-PCA9548A
Die Lego-Sensoren haben allerdings auf dem i2c/TWI gar keine eigene Spannung sondern nur die des Masters - un da arbeiten sie ohne Probleme mit 3.3 V (wie auch der Lego EV3).
Sie haben aber ein Zusatzkabel zur extra-Spannungsversorgung, wenn sie mehr Leistung brauchen (je nachdem, 5V oder 9V), aber das kriegen sie extern.
Wie meine H-Brücken allerdings für den Due angepasst werden müssen, da habe ich noch keinen Plan...
http://www.ebay.de/itm/191187840120?ssPageName=STRK:MEWNX:IT
hallo,
Mit dem Pegelwandler-Problem hatte ich schon gerechnet und mir sicherheitshalber zum Due auch gleich diese Teile bestellt:
http://www.ebay.de/itm/131196183140?ssPageName=STRK:MEWNX:IT
Sieht ok aus. Gäbe es für den Preis sogar aus Deutschland
http://www.watterott.com/de/Level-Shifter
Kann man z.B. für I2C auch auf Steckplatine bauen, siehe hier unter "Using 4 transistors"
http://playground.arduino.cc/Main/I2CBi-directionalLevelShifter
Geht mit allen Transistoren dieser Bauart, also BC547 - BC550 und BC237 - BC239 als A,B,C.
Der TI Muxer/Switch jedenfalls kommt ja mit allen möglichen Pegeln zurecht.
Ja.
Wie meine H-Brücken allerdings für den Due angepasst werden müssen, da habe ich noch keinen Plan...
Das sollte mit einem beliebigen 74HCT... gehen. Wenn man da was invertierendes hat, einfach zwei Gatter hintereinanderschalten, z.B. beim 74HCT04.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.