PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : I2C bei Asuro?



der aller dümmste Anfänge
06.08.2005, 14:16
Ich frag hier mal nach ob der Asuro kompatibel mit I2C schnittstelle ist.

izaseba
06.08.2005, 14:52
Die Frage verstehe ich nicht so ganz....
Was heißt hier kompatibel mit I2C ?
Mach Dir zwei Pins am Asuro Frei (vorzugsweise PC4 und PC5)
und schon hast Du Deine I2C schnittstelle.
Daß Du dann auf andere Funktionen vom Asuro verzichten mußt ist Dir aber klar oder?

Gruß Sebastian

luma
06.08.2005, 21:58
Ich glaub er meinte einfach ob es sowas wie I²C beim Asuro gibt. Das heißt bei Atmel (und damit auch beim Asuro) TWI (Two Wire Interface). Schauh mal im Datenblatt nach, da steht mehr.

luma
06.08.2005, 22:18
@ izaseba: Wenn wir schon dabei sind... An welche Pins würde ich denn die RS232-Schnittstelle finden. Ich hab mir nämlich schon Gedanken über ne Funkverbindung gemacht... (RN-Funk).

izaseba
06.08.2005, 22:31
@ lutz,

Du meinst UART ?

Also RX hängt an PD0 - pin 2
und TX an PD1 - pin 3

I2C an PC5 und PC4, wobei wenn man die nehmen will, kann man kein Batteriezustand und
was schlimmer ist die Taster nicht mehr abfragen.

Es sei denn man schreibt sich selber ein I2C protokol und nimmt halt andere Pins.

Gruß Sebastian

luma
06.08.2005, 23:11
RS232 != UART?!?!
Keine Ahnung, aber ich denke UART ist wohl das selbe...

izaseba
06.08.2005, 23:25
Ja, es ist das selbe

der aller dümmste Anfänge
07.08.2005, 10:23
aber die Könnte ich doch über nen anderen Baustein der auch ne I2C schnittstelle hat abgreifen odedr lieg ich da falsch?

izaseba
07.08.2005, 10:43
aber die Könnte ich doch über nen anderen Baustein der auch ne I2C schnittstelle hat abgreifen odedr lieg ich da falsch?



Ja aber Du brauchst zwei Freie Pins für die Aktion, und wenn Du dir die Schaltung von Asuro anschaust, hast Du keine mehr frei.

2 Lösungen gibt es da, aber dann mußt Du den Asuro schon was umbauen:

1. PC5 und PC4 für I2C benutzen, ist aber doof, weil Du dann denn Zustand der Batterie nicht abfragen kannst(nicht so schlimm) und die Taster nicht mehr abfragen kannst(viel schlimmer)
Angenommen, Du nimmst das in kauf, kannst Du die TWI funktionen von Mega8 schön benutzen.

2. Du machst Dir irgendwelche anderen Pins frei, und schreibst Die Ansteuerung dafür selber.

Gruß Sebastian

der aller dümmste Anfänge
07.08.2005, 10:46
Das war mir fast klar das ich da noch ein wenig um bauen muss.

RCO
08.08.2005, 13:11
RS232 != UART?!?!

Es ist nicht das selbe wenn man es genau nimmt, es sind andere Pegel:

RS232:

Eine logische '0' wird durch eine Spannung von +12 Volt, eine logische '1' durch -12 V dargestellt.

ACU
08.08.2005, 13:23
Wieso benutzt ihr nicht PC5 und PC4?
Auf einer extra Platine kann man ja einen I²C Portexpander unterbringen, damit man den Taster und die Batteriespannung weiter auslesen kann.


MfG ACU

der aller dümmste Anfänge
12.08.2005, 10:26
Ich studiere grad den schaltplan muss mal gucken. Vielen Dank

der aller dümmste Anfänge
12.08.2005, 10:28
Ich glaub so machs ich. wenn ich die grenzen vom Asuro ausgetestet hab bau ich hin um.

RCO
12.08.2005, 13:24
Wie genau stellst du dir denn den Umbau vor, hast du da schon genaue Pläne?

der aller dümmste Anfänge
12.08.2005, 19:39
Nein die werde ich mir um die Herbstferien von Bay. machen dan gibts warscheinlich neues.

luma
13.08.2005, 16:11
1. PC5 und PC4 für I2C benutzen, ist aber doof, weil Du dann denn Zustand der Batterie nicht abfragen kannst(nicht so schlimm) und die Taster nicht mehr abfragen kannst(viel schlimmer)
Angenommen, Du nimmst das in kauf, kannst Du die TWI funktionen von Mega8 schön benutzen.


Ich glaub das ist spätestens dann nicht mehr arg schlimm, wenn man sich überlegt RN-Controll wie TWI anzuschließen...

linux_80
19.08.2005, 12:58
1. PC5 und PC4 für I2C benutzen, ist aber doof, weil Du dann denn Zustand der Batterie nicht abfragen kannst(nicht so schlimm) und die Taster nicht mehr abfragen kannst(viel schlimmer)

solange man den Asuro mit dem BootPrg betreibt, kann man den PC5 nicht abklemmen von der Batteriespannung, weil der dann nicht mehr geht, denn die Batteriespannung wird beim Booten abgefragt, und wenn die Spannung nicht stimmt, blinkt nur die LED und es geht sonst nix mehr !
Hab ich schon mal probiert :-(
Und ich will den Bootsektor lassen, weils sonst nur noch ein halber Asuro wäre.

noize
27.08.2005, 10:27
solange man den Asuro mit dem BootPrg betreibt, kann man den PC5 nicht abklemmen von der Batteriespannung, weil der dann nicht mehr geht, denn die Batteriespannung wird beim Booten abgefragt, und wenn die Spannung nicht stimmt, blinkt nur die LED und es geht sonst nix mehr !

Und wenn man PC5 nach dem Booten umschaltet?

der aller dümmste Anfänge
28.08.2005, 19:33
Das ist eine Perfekte idee aber das muss man ja noch händisch machen oder?

uwegw
28.08.2005, 19:58
das kann dann über nen transistor vom controller erledigt werden, der dan am i2c hängt...

m.a.r.v.i.n
28.08.2005, 21:53
hallo,

ich plane zur Zeit ebenfalls eine i2c Erweiterung für meinen ASURO.

Die Erweiterungsplatine für den US Sensor dient dazu als Basis.
Für den i2C Bus werden die Ports des Linienfolgers PC3 und PC2 verwendet.

Der i2c Bus wird mit Hilfe der i2cmaster Bibliothek von Peter Fleury http://jump.to/fleury simuliert.

Näheres dazu auch auf meiner Homepage unter Erweiterungen.

Gruß m.a.r.v.i.n

bergowitch
29.08.2005, 08:27
Super Idee. Warum bin ich nicht auf die Idee gekommen? Ich verstehe es auf deiner HP richtig, dass der Ausro als Slave arbeiten soll? Wie weit bist du in deinem Project?
Ich habe ja eigentlich vor den AVR zu ersetzen und auf den Sockel eine Platine mit einem Mega32 aufzusetzen (und komme aus Zeitmangel nicht weiter...)
Sollte das eine Alternative sein?
Gruß Stefan

m.a.r.v.i.n
29.08.2005, 10:17
Hallo bergowitch,

nein der Asuro muß I2C Master sein, weil eine Simulation als I2C Slave zu aufwändig wäre. Die USI Schnittstelle des AVR169 unterstützt I2C Slave per Hardware und ist somit unkritisch.

Das Projekt ist leider ebenfalls aus Zeitmangel noch in der Planung. Nach erfolgreicher Umsetzung werde ich es natürlich hier im Forum vorstellen.

Gruß m.a.r.v.i.n

der aller dümmste Anfänge
31.08.2005, 21:38
Danke,
für die Inos.

bergowitch
01.09.2005, 06:45
Hallo,
das ist schade, das mit dem slave-modus.
Da mir ja immer noch die Erweiterung mit einem anderen uC vorschwebt, wäre es praktisch gewesen den ASURO als Untersatz der über den Master gesteuert wird zu betreiben, da man sich ein Programm für den ASURO hätte schreiben können und ihn dann hätte vergessen können... und über i2c kontrollieren
Gruß
Stefan

m.a.r.v.i.n
01.09.2005, 10:50
Hallo Stefan,
das man den Asuro von einem I2C Slave nicht kontrollieren kann, ist ja deshalb nicht ausgeschlossen.
Ich hatte mir das so vorgestellt:

Anzeige:
Asuro schreibt zyklisch seine aktuellen Status Werte zum Butterfly Board . Dort werden die Sensordaten angezeigt.

Steuerung:
Das Butterfly Board kann den Asuro über noch zu definierende Kommandos steuern, die er im Ausgabebuffer ablegt.
Der Asuro liest zyklisch diese Kommandos vom Butterfly Board und führt sie aus.

Master/Slave gilt nur für den I2C Bus. Der Master initiiert die Datenübertragung.
Durch das zyklische Abfragen ensteht allerdings eine gewisse Verzögerung.

Gruß m.a.r.v.i.n

bergowitch
01.09.2005, 16:25
Hallo,
ich denke du hast schon recht. Allerdings auch mit dem Kernporblem


Durch das zyklische Abfragen ensteht allerdings eine gewisse Verzögerung

Der Vorteil den Asuro als Slave am i2c Bus zu haben, wäre eben der, dass man ihm je nach Einstellung der Sensoren flott Befehle geben könnte und nicht erst auf die nächste Schleife warten müsste. Allerdings weiß ich nicht wie sich diese Verzögerung praktisch auswirkt!? Ist es denn so, dass der i2c slave erkennen kann ob ein Befehl/Daten aus dem Buffer ausgelesen wurden? Oder muss der Master erst eine Bestätigung an den Slave schicken, damit dieser erfährt dass der Buffer ausgelesen wurde?
Gruß
Stefan

m.a.r.v.i.n
01.09.2005, 17:05
Hallo Stefan,

Ob der Befehl abgeholt wurde weiß der Slave nach erfolgreicher Übertragung natürlich.
Danach muß er den Ausgabebuffer freigeben. Der Asuro soll ja beim nächsten Lesevorgang nicht nochmal dassselbe Kommando vorfinden.

Ebenso müßte der Slave prüfen ob der Buffer frei ist, bevor er das nächste Kommando sendet.
Man könnte auf Slave Seite natürlich auch einen Ringbuffer o.ä. schaffen der mehrere Kommandos zwischenspeichert.
Wieviele Zeichen man je Busübertragung schickt läßt sich auch vereinbaren.

Alles nur eine Frage der Software.

Die Größe der Verzögerung richtet sich danach, wie oft der Asuro Kommandos vom Slave liest. Für meine Anwendung, ist dies zugegeben weniger kritisch. Zeiten von 20ms sollten aber ohne weitere machbar sein.

Es ist ja auch die Frage wie komplex die Kommandos an den Asuro sind. Ich dachte an sowas wie 'Fahre 10cm geradeaus' oder 'Drehe dich um 90 Grad nach rechts' o. ä.

Guck doch mal die Beispielprogramme zum Thema I2C für AVR auf der Atmel Homepage an.

Gruß m.a.r.v.i.n

bergowitch
01.09.2005, 23:22
Vielleicht hast du Recht. Ich sollte mich mal genauer in das Tehma einarbeiten.
Mein Ziel ist es den Asuro RobocupJunior tauglich zu erweitern (soccer 2on2).
Ich brauche dazu also einen Graustufensensor - sollte mit dem Vorhandenen möglich sein (evtl. durch Umbau auf IR?) einen besser drei IR-Sensoren um den Ball zu finden, (und evtl. eine Möglichkeit mit dem Mannschaftkameraden zu kommunizieren und eine Möglichkeit die anderen Mitspieler grob zu lokalisieren (UV-Sensor?) Ich fürchte da sollte die Kommunikation zwischen Slave und Master möglichst flott sein? Deshalb wollte (will) ich mittels einer Platine einen größeren AVR montieren.
Mal genauer nachdenken...
Danke soweit
Gruß
Stefan

m.a.r.v.i.n
02.09.2005, 10:21
Hallo Stefan,

dein Projekt hört sich interessant an. Wäre für mich eindeutig eine Stufe zu hoch. Roboter-Fußball ist ein sehr komplexes Thema.

Viel Glück bis dann

m.a.r.v.i.n