Hallo zusammen ich habe jetzt folgendes Problem und komme nicht weiter. Ich habe 3 Sensoren an einem Uno hängen. Dieser sendet dann über I2C die Daten weiter. Der Master hat für jeden Sensor eine I2C Adressen die ich nicht ändern kann. Heißt also der Master erwartet 3 Antworten von 3 I2C Adressen. Wie kann man das an einfachsten lösen nur grob den Weg erklärt.
Ein Switch-Case mit den verschiedenen Ausgabe-Adressen? Und je nach angesprochener Slave-Adresse dann unterschiedliche Daten zur Verfügung stellen.
>für jeden Sensor eine I2C Adresse ist das immer dieselbe, sodaß ein Adresskonflikt auftritt? Lässt sich der Sensor nicht umkonfigurieren? Für solche Fälle gibt es I2C-Erweiterungschips. z.B: https://www.ti.com/product/TCA9548A
:
Bearbeitet durch User
Mit dem Register TWAMR kann man Bits in der Slaveadresse maskieren. Somit kannst Du einstellen, daß der AVR auf mehrere Adressen antworten kann. "The TWAMR can be loaded with a 7-bit Slave Address mask. Each of the bits in TWAMR can mask (disable) the corresponding address bits in the TWI Address Register (TWAR). If the mask bit is set to one then the address match logic ignores the compare between the incoming address bit and the corresponding bit in TWAR."
Nein den Master kann ich nicht ändern. Die Sensoren haben beim Master immer die selbe Adresse. Z.B. RPM = 0x01 Temp= 0x02 Ampere = 0x0A Der Master startet und fragt alle Adressen 2x hintereinander ab und wartet auf Antwort sollte sich der Slave nicht melden wird der Sensor auch nicht mehr angesprochen. Ich werde es mal mit switch/case probieren immer ein Case pro Adresse
Ich glaube da besteht ein Missverständnis, wie der I²C Bus funktioniert. I²C Sensoren können nichts aktiv Senden, sondern sie werden vom Master abgefragt. Wenn dein master dafür 3 feste Adressen vorgegeben hat, dann musst die drei Sensoren auf eben diese Adressen einstellen - that's it. Basti schrieb: > Ich werde es mal mit switch/case probieren Daraus leite ich ab, dass der master wohl doch nicht fest vorgegeben ist, sondern du ihn programmieren kannst. Auf jeden Fall läuft es darauf hinaus, dass die drei im Master konfigurierten Adressen mit den tatsächlichen Slaves überein stimmen müssen.
"RPM Temp Ampere" scheinen mir sekundäre Adressen zu sein, der Master muss immer noch die feste Sensor-Hauptadresse vorausschicken.
Guckt mal das sind die Adressen es ist ein Spektrum Empfänger und diesen kann ich nicht ändern.
1 | //////////////////////////////////////////////////////////////////
|
2 | //
|
3 | // Assigned I2C Addresses and Device Types
|
4 | //
|
5 | //////////////////////////////////////////////////////////////////
|
6 | #define TELE_DEVICE_NODATA (0x00) // No data in packet
|
7 | #define TELE_DEVICE_VOLTAGE (0x01) // High-Voltage sensor (INTERNAL)
|
8 | #define TELE_DEVICE_TEMPERATURE (0x02) // Temperature Sensor (INTERNAL)
|
9 | #define TELE_DEVICE_RSV_03 (0x03) // Reserved
|
10 | #define TELE_DEVICE_RSV_04 (0x04) // Reserved
|
11 | #define TELE_DEVICE_RSV_05 (0x05) // Reserved
|
12 | #define TELE_DEVICE_RSV_06 (0x06) // Reserved
|
13 | #define TELE_DEVICE_RSV_07 (0x07) // Reserved
|
14 | #define TELE_DEVICE_RSV_08 (0x08) // Reserved
|
15 | #define TELE_DEVICE_RSV_09 (0x09) // Reserved
|
16 | #define TELE_DEVICE_PBOX (0x0A) // PowerBox
|
17 | #define TELE_DEVICE_LAPTIMER (0x0B) // Lap Timer
|
18 | #define TELE_DEVICE_TEXTGEN (0x0C) // Text Generator
|
19 | #define TELE_DEVICE_AIRSPEED (0x11) // Air Speed
|
20 | #define TELE_DEVICE_ALTITUDE (0x12) // Altitude
|
21 | #define TELE_DEVICE_GMETER (0x14) // GForce
|
22 | #define TELE_DEVICE_JETCAT (0x15) // JetCat interface
|
23 | #define TELE_DEVICE_GPS_LOC (0x16) // GPS Location Data
|
24 | #define TELE_DEVICE_GPS_STATS (0x17) // GPS Status
|
25 | #define TELE_DEVICE_RX_MAH (0x18) // Receiver Pack Capacity (Dual)
|
26 | #define TELE_DEVICE_JETCAT_2 (0x19) // JetCat interface, msg 2
|
27 | #define TELE_DEVICE_GYRO (0x1A) // 3-axis gyro
|
28 | #define TELE_DEVICE_ATTMAG (0x1B) // Attitude and Magnetic Compass
|
29 | #define TELE_DEVICE_AS3X_LEGACYGAIN (0x1F) // Active AS3X Gains for legacy mode
|
30 | #define TELE_DEVICE_ESC (0x20) // ESC
|
31 | #define TELE_DEVICE_FUEL (0x22) // Fuel Flow Meter
|
32 | #define TELE_DEVICE_ALPHA6 (0x24) // Alpha6 Stabilizer
|
33 | // DO NOT USE (0x30) // Reserved for internal use
|
34 | // DO NOT USE (0x32) // Reserved for internal use
|
35 | #define TELE_DEVICE_MAH (0x34) // Battery Gauge (mAh) (Dual)
|
36 | #define TELE_DEVICE_DIGITAL_AIR (0x36) // Digital Inputs & Tank Pressure
|
37 | #define TELE_DEVICE_STRAIN (0x38) // Thrust/Strain Gauge
|
38 | #define TELE_DEVICE_LIPOMON (0x3A) // 6S Cell Monitor (LiPo taps)
|
39 | #define TELE_DEVICE_LIPOMON_14 (0x3F) // 14S Cell Monitor (LiPo taps)
|
40 | #define TELE_DEVICE_VARIO_S (0x40) // Vario
|
41 | #define TELE_DEVICE_RSV_43 (0x43) // Reserved
|
42 | #define TELE_DEVICE_USER_16SU (0x50) // User-Def, STRU_TELE_USER_16SU
|
43 | #define TELE_DEVICE_USER_16SU32U (0x52) // User-Def, STRU_TELE_USER_16SU32U
|
44 | #define TELE_DEVICE_USER_16SU32S (0x54) // User-Def, STRU_TELE_USER_16SU32S
|
45 | #define TELE_DEVICE_USER_16U32SU (0x56) // User-Def, STRU_TELE_USER_16U32SU
|
46 | #define TELE_DEVICE_RSV_60 (0x60) // Reserved
|
47 | #define TELE_DEVICE_RSV_68 (0x68) // Reserved
|
48 | #define TELE_DEVICE_RSV_69 (0x69) // Reserved
|
49 | #define TELE_DEVICE_RSV_6A (0x6A) // Reserved
|
50 | #define TELE_DEVICE_RSV_6B (0x6B) // Reserved
|
51 | #define TELE_DEVICE_RSV_6C (0x6C) // Reserved
|
52 | #define TELE_DEVICE_RSV_6D (0x6D) // Reserved
|
53 | #define TELE_DEVICE_RSV_6E (0x6E) // Reserved
|
54 | #define TELE_DEVICE_RSV_6F (0x6F) // Reserved
|
55 | #define TELE_DEVICE_RSV_70 (0x70) // Reserved
|
56 | #define TELE_DEVICE_RTC (0x7C) // Pseudo-device giving timestamp
|
57 | #define TELE_DEVICE_FRAMEDATA (0x7D) // Transmitter frame data
|
58 | #define TELE_DEVICE_RPM (0x7E) // RPM sensor
|
59 | #define TELE_DEVICE_QOS (0x7F) // RxV + flight log data
|
60 | #define TELE_DEVICE_MAX (0x7F) // Last address available
|
61 | #define TELE_DEVICE_SHORTRANGE (0x80) // Data is from a TM1100
|
:
Bearbeitet durch Moderator
Stefan ⛄ F. schrieb: > Wenn dein master dafür 3 feste Adressen vorgegeben hat, dann > musst die drei Sensoren auf eben diese Adressen einstellen - that's it. Ich schätze, daß letztendlich drei Unos mit jeweils einem Sensor die für den TO passenden Lösung wäre. Oliver
Ich kann also nur den Slave anpassen wenn ich jetzt jeden Sensor einzeln bauen also jeder hätte einen UNO dann wüßte ich wie es geht aber das macht ja keinen sinn 3 Uno zu verwenden
Stefan ⛄ F. schrieb: > Daraus leite ich ab, dass der master wohl doch nicht fest vorgegeben > ist, sondern du ihn programmieren kannst. Das genaue Gegenteil ist der Fall Stefan ⛄ F. schrieb: > Wenn dein master dafür 3 feste Adressen vorgegeben hat, dann > musst die drei Sensoren auf eben diese Adressen einstellen - that's it. Klar schöne einfache Welt.... Problem nicht verstanden, aber that's it sagen. Tipp: Es gibt in dem Spiel zwei Master und 4 Slaves wovon einer der Slaves auf 3 Adressen antworten soll. peda hats verstanden! Peter D. schrieb: > Mit dem Register TWAMR kann man Bits in der Slaveadresse maskieren. > Somit kannst Du einstellen, daß der AVR auf mehrere Adressen antworten > kann. Nur geht das eben mit der Arduino Wire Lib nicht, ohne größere Umbauten. Denn sie hat immer nur 1 Slave Adresse.
>Spektrum Empfänger achso, das ist ein Firmenname, es geht um Modellflug https://www.spektrumrc.com/Air/Receivers.aspx https://www.spektrumrc.com/ProdInfo/Files/SPM_Telemetry_Developers_Specs.pdf Seite 6 Hardware level protocol
:
Bearbeitet durch User
Muss ja kein UNO sein, ein kleiner ATTiny würde pro Sensor ja auch reichen. Aber ein I²C Filter ist ja auch kein Hexenwerk, man kann sich nur eben nicht ins fertig gemachte Bett legen, sondern muss ein wenig programmieren.
EAF schrieb: > Problem nicht verstanden, aber that's it sagen. Was meist an einer unklaren Beschreibung liegt. Auch hier, nach dem ersten Post wusste ich auch nicht was du willst. EAF schrieb: > Es gibt in dem Spiel zwei Master und 4 Slaves wovon einer der Slaves auf > 3 Adressen antworten soll. Wieder so eine verschwurbelte Scheibe Salami. Fakt scheint: dein Master fragt alle möglichen Slave Adressen ab und du möchtest dass dein Uno als Slave auf 3 unterschiedliche antwortet. Das sollte im Prinzip so wie Peter vorgeschlagen hat lösbar sein: Peter D. schrieb: > "The TWAMR can be loaded with a 7-bit Slave Address mask. Each of the > bits in TWAMR can mask (disable) the corresponding address bits in the > TWI Address Register (TWAR). If the mask bit is set to one then the > address match logic ignores the compare between the incoming address bit > and the corresponding bit in TWAR." Du setzt also die Maske so dass alle 3 Adressen (und wahrscheinlich noch andere) damit enthalten sind und prüfst dann im Code ob tatsächlich eine der 3 Adressen angefragt wird. Nur dann antwortest du. Das wird wahrscheinlich nicht mit der Standard Arduino I2C Schnittstelle gehen, dann musst du deinen eigenen "Sketch" schreiben. Siehe dazu: https://www.mikrocontroller.net/articles/AVR_TWI#Slave_Receiver_Mode
Udo S. schrieb: > Was meist an einer unklaren Beschreibung liegt. Auch hier, nach dem > ersten Post wusste ich auch nicht was du willst. Ich bin nicht der TO! Habe aber sofort verstanden, was er will. Udo S. schrieb: > Wieder so eine verschwurbelte Scheibe Salami. > > Fakt scheint: dein Master fragt alle möglichen Slave Adressen ab und du > möchtest dass dein Uno als Slave auf 3 unterschiedliche antwortet. Ich bin nicht der TO! Habe aber sofort verstanden, was er will. Zudem haben wir jetzt mindestens 3 Threads in mindestens 2 Foren zum gleichen Problem. Alle vom gleichen Menschen mit unterschiedlichen Namen.
und wen interessiert das? Ich kann in so vielen Foren nach Hilfe fragen wie ich möchte und brauche ganz bestimmt nicht von Dir eine Erlaubnis
Basti schrieb: > und wen interessiert das? Ich kann in so vielen Foren nach Hilfe fragen > wie ich möchte und brauche ganz bestimmt nicht von Dir eine Erlaubnis Mich interessiert es. Aber "ich" scheine dir nicht wichtig genug zu sein. Ich stimme dir zu: Man kann sich auch ohne jede Erlaubnis daneben benehmen.
Man könnte auch ganz einfach Google befragen: "Arduino as slave with multiple i2c addresses" https://stackoverflow.com/questions/34691478/arduino-as-slave-with-multiple-i2c-addresses Da gibt es sogar nen Link zum Code: https://github.com/alexisgaziello/TwoWireSimulator
Basti schrieb: > und wen interessiert das? Ich kann in so vielen Foren nach Hilfe fragen > wie ich möchte und brauche ganz bestimmt nicht von Dir eine Erlaubnis Spätestens nach dem dritten Thread solltest du dich allerdings fragen, warum du auf deine verschrobene Problemdarstellung keine dir passende Antwort bekommst. Vielleicht machst du mal eine Skizze, wer alles Master ist, wer alles Slave ist und welche Adresse(n) welcher Slave hat.
So allmählich sollte es aber klar sein. Der I2C-Master hat das von mir oben verlinkte "Hardware-Protocol": https://www.spektrumrc.com/ProdInfo/Files/SPM_Telemetry_Developers_Specs.pdf Der Uno liest drei eigene Sensoren aus (SPI oder ähnliches) und schickt sie als I2C-Slave an den Master, wenn der ihn abfragt. Laut Hardware-Protocol gibt es "user defined" slaves und andere. Als was die Sensoren am Uno gelten wurde noch nicht gesagt. Peter hat einen Forumsbeitrag verlinkt, in dem beschrieben ist, wie man die Adressen so maskiert, dass der Arduino auf mehrere Adressen reagieren kann. Mir wäre sonst nur noch "bit-banging" eingefallen, ein Flanken-Interrupt auf die Datenübernahmeflanke des I2C-Takts. Im Hardware-Protocol sind 100 kHz und 400 kHz I2C-Takt genannt. Für 400 kHz hätte das Interrupt-Programm nur 40 Takte von 16 MHz zur Verfügung, das ist schon recht sportlich. Für das Hauptprogramm sollten auch noch ein paar Prozent Rechenzeit übrigbleiben.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > So allmählich sollte es aber klar sein Ich habe den Knackpunkt so verstanden: Dein Arduino UNO soll ein I²C Slave sein, der auf drei Slave-Adressen reagiert. Die 3 Adressen sind vom Master fest vorgegeben. Ziel der Aktion ist, drei vorher einzelne Geräte (Sensoren) durch einen einzigen Mikrocontroller zu ersetzen. Ist das soweit richtig?
Ich programmiere ja auch seit 15 Jahren I2C auf unterschiedlichen Architekturen. Aber was der TE jetzt beabsichtigt, und wo sein Problem ist, das habe ich nicht verstanden. Warum sind die Original-Fragen immer so kurz und kryptisch, dass kein Erfahrener versteht, worum es geht. Ein paar Worte mehr, oder eine Zeichnung würden schon helfen. Insbesondere wenn wohl Master und Slave verwechselt werden.
>Die 3 Adressen sind vom Master fest vorgegeben.
Welche das sind hat Basti noch nicht verraten. In seiner großen Liste
(die auch im "Protocol" auftauchen) stehen z.B. vier #define
TELE_DEVICE_USER... (0x50) bis (0x58), falls er user-defined Typen
nehmen will.
PittyJ schrieb: > Aber was der TE jetzt beabsichtigt, und wo sein Problem ist, das habe > ich nicht verstanden. Eigentlich ist das doch völlig klar beschrieben. (Selbst) Stefan hats verstanden. Stefan ⛄ F. schrieb: > Dein Arduino UNO soll ein I²C > Slave sein, der auf drei Slave-Adressen reagiert. Die 3 Adressen sind > vom Master fest vorgegeben. Die Lösungen dazu stehen auch schon alle hier im Thread. Oliver
Christoph db1uq K. schrieb: > Der Uno liest drei eigene Sensoren aus (SPI oder ähnliches) und schickt > sie als I2C-Slave an den Master, wenn der ihn abfragt. Warum diese vermischte Funktionsbeschreibung. Bei I2C ist der Master der Herrscher über die Datenübertragung und legt mit seinem Clock fest, wann ein Bit über den Bus geht. Der Slave schickt gar nichts, sondern der Master holt die Daten Bit für Bit ab. Zum Abfragen und Daten schicken/senden bräuchte man halbwegs eigenständige Transceiver.
Ja bitteschön, der untertänige Sklave stellt auf Aufforderung seines Herrn die gewünschten Daten zur Verfügung. Den Takt dazu legt der Master fest. Wenn er unbedingt 400 kHz fordert muss sich der Sklave fügen. Das ist das eigentliche Problem, wenn der Arduino nicht schnell genug ist funktioniert es eben nicht. Wenn er nicht schnell genug der Aufforderung des Meisters folgt wird er rausgeworfen.
:
Bearbeitet durch User
Beitrag #6903947 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.