I2C Porterweiterung am ASURO

Hi nun wurde das Layout auf AsuroWiki geändert. Ich hatte mir noch die alte Layoutzeichnung ausgedruckt. Aber laut Schaltplan war es ja eindeutig mit den Adressleitungen.

Huch, habe gerade bei einem nochmaligen hinsehen gesehen, das der R7 in Layoutbild mit R1 bezeichnet ist. (Schönheitsfehler) :-)

Aber nun zu meinem Problem oder eher nur Unwissenheit.
Ich habe mir, weil ich den Hals ja nicht vollgenug kriegen kann, eine Platine geätzt, wo ich gleich 2 Porterweiterungen nebeneinander drauf habe. Man weis ja nie was man noch für Ideen bekommt und alles dranhängen will.

Aber was ist denn mit den drei Widerständen R1,R2,R3 als Abschluß für die Datenleitungen (SDA, SCL). Wenn ich nun zwei Porterweiterungen nutze, sollte ich die Abschlußwiderstände auf jede Porterweiterung setzen oder kann ich die komplett weglassen?

Was bewirken diese Widerstände überhaupt?

Schon mal einen Dank an alle Spezialisten.

Hi,

Zitat:

---

das der R7 in Layoutbild mit R1 bezeichnet ist. (Schönheitsfehler)

---

Richtig. Das muß ich mal bei Gelegenheit korrigieren.

Zitat:

---

Aber was ist denn mit den drei Widerständen R1,R2,R3 als Abschluß für die Datenleitungen (SDA, SCL). Wenn ich nun zwei Porterweiterungen nutze, sollte ich die Abschlußwiderstände auf jede Porterweiterung setzen oder kann ich die komplett weglassen?
Was bewirken diese Widerstände überhaupt?

---

R1 und R2 sind die PullUp Widerstände für den I2C Bus und müssen einmal vorhanden sein. R3 ist für die optionale Interrupt Leitung und nicht notwendig, wenn man kein Interrupt benutzen will. Dabei fällt mir gleich der nächste Fehler auf, diesmal im Schaltbild zur I2C -Erweiterung. Die Widerstände hängen direkt an SCL und SDA gegen VCC und nicht über Jumper, wie im Schaltbild zu sehen.

Guck mal im Schaltbild zur LCD Erweiterung, dort wird dieselbe Schaltung stark vereinfacht verwendet.

Bei 2 Porterweiterungen müssen die AdressPins unterschiedlich belegt sein. Entweder über Jumer oder Lötbrücken.

So jetzt stehe ich vor der nächsten Frage.
Ich habe mir das Datenblatt vom 8574 angesehen,
kann aber die Adressen nicht finden.
Die Adresse
#define Dev8574 0x40
aus dem Beispiel scheint ja die erste zu sein, wenn alles auf Masse ( Also 0 0 0 ).
Woher weis ich nun, was ich bei
#define Dev8574
angeben muß z.B für 0 0 1.

Habe ich etwas im Datenblatt übersehen?

Hi,

im Datenblatt S.9 steht die Antwort A0..A2 sind die 3 niederwertigsten Adressen. Demnach wäre

Code:

---

#define Dev8574 0x41      // A0=1, A1=0 A2=0

---

richtig.

im datenbaltt steht ein schema:

Adresse ist 0 1 0 0 A2 A1 A0 0
also wenn alle drei adressjumper gegen masse stehen, dann 01000000
wenn alle gezogen sind (nicht auf masse) sind dann 01001110

du solltest versuchen, die adressen so weit wie möglich voneinander entfernt zu wählen, bei mir stören sich die chips etwas.

Achtung (auch @marvin =)
das niederwertigste bit ist das lese/schreib bit, wie bei allen i2c-bausteinen. die adresse 0x41 bedeutet also "lesen von adresse 0x40"

die jumper betreffen also die bytes mit der (dezimalen) wertigkeit 2,4 und 8 und NICHT das niederwertigste byte (1)

Stimmt natürlich was damaltor da schreibt. :oops:
Dann vergiß mal den Mist, den ich vorher geschrieben habe.

Wenn ich also
#define Dev8574 0x40
als Adresse vorgebe, kann ich mit
i2c_start(Dev8574+I2C_WRITE)
nur Daten auf die Prots schreiben aber nicht mit
(Dev24C02+I2C_READ) Daten von den Ports auslesen ?!?

Wenn ich also Daten mit (Dev24C02+I2C_READ)
von den Ports lesen will muß ich vorher
#define Dev8574 0x41
für den Baustein angeben ?!?

Ich kann also nicht einfach durch wechsel von
(Dev8574+I2C_WRITE) und (Dev24C02+I2C_READ)
zwischen lesen und schreiben wechseln.

Also für mich Dummi noch mal:
#define Dev8574 0x40 dann i2c_start(Dev8574+I2C_WRITE);
#define Dev8574 0x41 dann i2c_start(Dev24C02+I2C_READ);


Danke Euch allen.

nein, I2C_READ ist doch als 1 definiert I2C_WRITE als 0. Siehe i2cmaster.h

Code:

---

#define I2C_READ    1
#define I2C_WRITE  0

---

Damit wird ja beim Lesen die Adresse 0x41 errechnet 0x40+1. Und das ist ja die Leseadresse. Es bleibt also bei

Code:

---

#define Dev8574 0x40

---

für den ersten Porterweiterungs IC mit Adresse 000.

und

Code:

---

#define Dev8574_2 0x42        // 001
#define Dev8574_3 0x44        // 010
#define Dev8574_4 0x46        // 011
#define Dev8574_5 0x48        // 100
...

---

für die weiteren Porterweiterungs ICs.

Dev24C02 ist die BasisAdresse für ein I2C EEPROM und hat hier nichts verloren.

PUH !!!

Ich hatte mir Dev24C02+I2C_READ aus der i2cmaster.h
rausgesucht.

Aber wer lesen kann ist klar im Vorteil!!!
Es steht ja da:
Dev24C02 0xA2 // device address of EEPROM 24C02, see datasheet

Danke

benutzt du den EEPROM? was sind deine erfahrungen damit? (und warum benutzt du nicht den eingebauten eeprom? reichen 512 bytes nicht? =)

+I2C_READ ist eigentlich nur +1, ist schon richtig. sollte deshalb kein problem darstellen. allerdings kannst du nicht am gleichen baustein lesen und schreiben: wenn du zB alle ports des bausteins auf low ziehst (write 0x00) und dann strom drauf kommt (den du eigentlich lesen willst) dann ist das ein klassischer kurzschluss.

Nein ich wollte nich den EEPROM nutzen.
Das war ja mein Fehldenken, wo ich mich so verrannt hatte.

Mir hatte das Verständnis mit dem niederwertigsten bit gefehlt.
Darum bin ich in der i2cmaster.h auf dan falschen READ-Befehl gestoßen.

Nun habe ich den wechsel zwischen lesen und schreiben hoffentlich verstanden.

Das wird mich nun hoffentlich auch bei meinem nächsten Schritt
mit dem Ultraschall Entfernungsmesser SRF02 weiterhelfen.

Aber eins nach dem andern.

Heute wird erst einmal mit der Porterweiterung weiter gemacht.

na alles klar... meld dich wenn du hilfe brauchst. kleiner tip, falls du an der porterweiterung leds anschliessen willst: der strom, der von PCF kommt ist viel zu klein. wenn du allerdings die led mit plus an VCC und mit minus an den pcf anschliesst (vorwiderstand nicht vergessen, wolln mal nix riskieren... auch wenns ohne funktioniert) dann kannst du den port auf LOW schalten (0 senden) und die led leuchtet, schliesslich hat sie dann ja masse...

Ich habe für Testzwecke eine Low-Current LED mit 2mA genommen.
Bei einem Vorwiderstand von 1K7 tut das hoffentlich keinem Ausgang weh.

na das denk ich wohl auch. funktioniert denn alles ungefähr so wie es soll?

Also der eine Teil der Porterweiterung klappt jetzt 8 Ports lesen oder schreiben.
Den zweiten Teil der Platine werde ich morgen bestücken.
Und dann ausprobieren ob alle 16 Ports funktionieren.

Heute will ich erst einmal meine IR-Sensoren anstelle der Taser anschließen.
Die Taster als Bumper mag ich nicht.
Ausserdem will ich ausprobieren, das ich je 2 IR-Sensoren anstelle eines Tasters anbringen kann und das ganze dann anhand der Fahrtrichtung auswerten kann und dann erkenne ob vorne oder hinten ein Hindernis ist.

Hallo Falkenroby,

warum benutzt du für deine I2C-Erweiterung keinen zweiten ATmega8 als I2C-Slave? 16 zusätzliche digitale I/O's sind ja nicht schlecht, aber was willst du denn daran alles anschließen? Die meisten Sensoren (und die fehlen dem ASURO ja letztendlich) liefern doch analoge Signale (siehe ASURO-Bücher Band I und Band II) und Prallschalter sind ja auch so schon reichlich vorhanden.

Das ist ja eigentlich das Fatale am ASURO, dass man immer nur eine Erweiterung aus den Büchern anschließen kann und dafür auch noch die Sensorik für die Linienverfolgung "opfern" muss.

Sieh dir das mal an:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=27719

Mit einem zweiten ATmega8 hast du ausreichend digitale I/O's, 4 zusätzliche ADC-Eingänge für analoge Sensoren (z.B. GP2D12) und weitere Peripherie, wie den Analog-Komparator für ein US-Modul, 3 Timer, ..., zur freien Verfügung. Wenn du dann auch noch, wie von mir praktiziert, den Resonator entfernst, auf "internen 8MHz-Betrieb" umstellst und die beiden freien Leitungen, die der Resonator belegte, für das I2C-Interface nutzt, kannst du sogar die Linien-Sensorik behalten.

Noch besser wäre es, wenn man die vorhandene Software des ASURO so umschreibt, dass der ATmega8 als I2C-Slave mit Liniensensor und PID-Regelung für die Motoren arbeitet und einen I2C-Master mit z.B. einem ATmega32 aufbaut, der dann die Auswertung der verschiedensten Sensoren und die Steuerung des Slave übernimmt.

Peter (Ronny10)

Also das ganze mit dem zweiten Prozessor hat ja Hand und Fuß.
Ich selbst habe den ASURO erst seit knapp einen Monat und
muß mich in das ganze erst noch reinknien.
Mir fehlt noch die Möglichkeit über einen seperaten ISP zu proggen.
Und das proggen über die IR geht ja ganz gut.

Noch was zu den Sensoren. Die Taster gibt es bei mir nicht mehr.
Erst ein Crash zu haben, um ein Signal zu bekommen, hat mich gestört.
Ich habe alle durch IR-Detektoren mit IS471 ersetzt.
Aber das mit dem AD ist mir zu langsam und zu Fehlerbehaftet.
Besonders der K1 mit mit seinen 68K hat mir die meisten Fehler
gebracht. Habe schon die 68K durch 64K ersetzt und den Kondensator rausgeschmissen.
Es ist besser geworden, aber man muß den AD ja trotzdem mehrmals abfragen damit
man ein brauchbares Ergebniss bekommt. Und die Umrechnung dauert auch zu lange.

Ich werde die Variante mit dem zweiten Prokzessor im Auge behalten.

Also wegen den fehlerbehafteten Sensoren:
Es soll helfen für Motoren je 2 Konsensatoren anzulöten.
+ Leitung mit Motorgehäuse, - Leitung mit Gehäuse. Das Gehäuse danach "erden" ( zB schwarze Leitung, die von den Batterien geht. Die Ganze Platine, ausgenommen Leiterbahnen ist geerdet )
10µF Kondensatoren haben da ausgereicht, um die Stromschwankung spürbar zu reduzieren. ( Durch diese Schwankungen liefern Sensoren fehlerhafte Ergebnisse )

Wenn es interessant klingt, kann ich nochmal den Link zum Topic geben, wo es ausdiskutiert wurde, bzw getestet.

ein einfach erreichbarer massepunkt ist an der rechten seite (wenn der asuro mit der schnauze zu dir steht). da sind zwei lötpads mit einem strich verbunden. diese beiden punkte sind auf masse, eigentlich kann man hier einen kleinen bügel (zB altes, abgekniffenes beinchen eines bauteils) einlöten um einen messpunkt für die masse zu haben.