Datenübertragung zwischen zwei atmega8 auf dem asuro

[damaltor]

Soo... Die erste Schnapsidee sieht so aus:

Die Prozessoren sind über Zwei Pins Miteinander Verbunden. Im folgenden werden die Pins so bezeichnet:

Atmega1,Pin1:Pin11 (Interrupteingang!)
Atmega2,Pin1:Pin21 (Interrupteingang!)
Atmega1,Pin2:Pin12
Atmega2,Pin2:Pin22

Die erste Verbindung (Zwischen Pin11 und Pin21) ist für den Sendestatus, die Zweite für die daten.

Zum Ánfang beginne ich mit bitweisem senden von daten. das ist nicht sonderlich effektiv, aber reduziert die fehlerquote.

Im Standartzustand Liegen alle Pins auf LOW. Pin11 und Pin21 werden als Interrupteingang geschaltet. Jeder Prozessor macht seine Arbeit.

Beispiel: Prozessor 1 Will eine Logische 1 an Prozessor2 Senden. Dazu macht er folgendes:

Er setzt den DATENpin (Pin12) auf High (um eine 1 zu senden, low um eine 0 zu senden).
DANN setzt er den Statuspin(Pin11) auch auf high und wartet ca 1ms.
Dadurch wird bei Prozessor2 ein interrupt ausgelöst. Er Liest seinen Pin22 aus, findet heraus, dass strom anliegt und speichert eine 1 (wäre pin12 auf low geblieben, hätte er eine 0 gespeichert). DANN WARTET AUCH ER EINE millisekunde, damit er nicht nochmal das gleiche empfängt.

NAchdem Prozessor1 gewartet hat, schalteter den pin11 wieder auf low. beide prozessoren machen weiter das, was sie sollen. evtl kann in der isr noch eine Variable "datenempfangen" gesetzt werden, dann kann der prozessor2 die daten gleich verarbeiten.

genauso gehts umgekehrt.

nochmal in kurzfassung:

Sendender Prozessor legt auf den datenpin das, was er senden will (high für 1, low für 0). dann legt er den statuspin auf high.
beim empfangende prozessor wird ein interrupt ausgelöst, dieser liest den status des datenpins aus und speichert eine 0 oder 1.
prozessor1 setzt nach kurzer wartezeit seinen statuspin wieder auf low und macht weiter mit dem was er vorher auch gemacht hat. prozessor zwei wartet auch kurz, und macht dann mit dem wieiter was er vorher gemacht hat, oder verarbeitet das bit was gerade angekommen ist, oder...


was sagt ihr dazu? immerhin eine übertragungsrate von fast 1000 Baud, wenn die Prozessoren wirklich nix anderes zu tun habenn... =)

[EDH]

die idee klingt ganz gut.
aber: gesetzt den fall asuro 1 sendet alle seine mommentanen daten an den asuro 2
dann sendet der
(1) motor_richtung kommt
(2) fwd fwd
(3) motor_speed kommt
(4) 140 140
(5) odo daten kommen
(6) 432 654
(7) liniensensoren daten kommen
(8) 786 986
(9) taster daten kommen
(10) 16

das ganze muss asuro 1 ins binär system umwandeln, dann muss asuro 2 die enstsprechenden befehle (motor_speed kommt, odo daten kommen....) interpretieren, die empfangenen 0 en und 1 en in EINE variable schreiben, und dann ins dezimalsystem umwandeln

da kommt eineiges an verwaltungsaufwadn zusammen

das einzige was mir mommentan als vorschlag einfällt ist, das man einen dritten port für die übertragung von steuerzeichen (oder so was halt) nutzen könnte. allerdings sind ports am asuro bekanntlichermasen kostbar

mfg EDH

[damaltor]

tja das stimmt...

man müsste sich halt vorher festlegen was was bedeuten soll. man könnte sonst auch evvtl pakete von 4 bits oder sogar einem byte übertragen. das risiko ist halt, dass irgendwann zwischendurch ein anderer interrupt ausgelöst wird, dann bricht die ganze sache zusammen.

ausserdem ist es eigentlich völlig egal, ob die steuerzeichen in binäre "codewörter" umgewandelt werden und über die zweite leitung oder die dritte umgewandelt werden. der empfangende prozessor kann sich eh nur eins zur zeit anschauen, eine parallele datenübertragung fällt mehr oder weniger flach.

[EDH]

parallel geht garantiert nicht, das stimmt.
aber mit einem driten port wüsste der asuro wenigstens ob jetzt daten oder befehle kommen. das müsste er dann nicht erst selbst rausfinden

[damaltor]

na er muss doch dann den gesendeten bytecode umwandeln in einen befehl. also soll er das probieren. und wenn das was er da emfangen hat nicht der steuercode für den motor, nicht der für die liniensensoren, nicht der für die geschwndigkeit und auch keiner der anderen ist, dann sind es offensichtlich daten...

aber das erste problem wäre ja folgendes: meinst du dass die datenübertragung auf oben genannte weise überhaupt theoretisch funktionieren könnte, mal ganz davon abgesehen, was der zweitprozessor dann mit den empfangenen bytes macht?

[uwegw]

Wenn du zwei Pins nimmst, kannst du auch gleich I2C nutzen... und weil Ports knapp sind, kann man auch nen 1wire-ähnliches System mit nur einer bidirektionalen Leitung aufbauen...

Und die Wartezeit im Empfänger kannst du dir auch sparen. Der Interrupt wird von der steigenden Flanke der "Status"-Leitung (ist ja eher ne Taktleitung) ausgelöst, dann wird der Datenpin abgefragt. Das ganze wiederholt sich dann erst, wenn die nächste steigende Taktflanke ankommt.

Wie kommen die Pins auf den Low-Ruhezustand? dazu währen Pulldown-Widerstände nötig, die man extern anschließen müsste. Bei nem High-Ruhepegel könnte man die internen Pullups verwenden, was für einige Zentimeter Entfernung locker ausreicht.

Ist das System bidirektional ausgelegt? Das kann ich noch nicht so richtig rauslesen. Wie würde dann der Fall gelöst, dass beide AVRs gleichzeitg anfangen zu senden?

[EDH]

[....] was für einige zentimeter entfernung locker ausreicht

welche entfernung ?

[damaltor]

naja man könnte natürlich auch einen high-ruhezustand nutzen... aber die steigende flanke gibts eben nur bei einem LOW-ruhezustand.

allerdings wird der interrupt doch immer wieder ausgelöst, solange ein High pegel anliegt, oder nicht ? beim tasterinterrupt z.B. wird dieser immer und immer wieder ausgelöst, slange ien taster gedrückt wurde... wobie hier auch ein low pegel anliegen muss um den interrupt auszulesen.

naja dann eben ein high pegel... =)

ich wollte gerade die porterweiterung umgehen, um etwas eigenes zu entwickeln. einen zweiten atmega habe ich noch liegen, eine porterweiterung nicht =)

bidirektional: ja.

wenn beide gleichzeitig anfangen... öhm... keine ahnung. ich habe das risiko als gering genug angesehen, um es zu vernachlässigen... ansonsten passiert wahrscheinlich gar nix. =(

[m.a.r.v.i.n]

Hi,

Wie uwegw schon sagte. Mit 2 Pins kann man doch den I2C Bus verwenden.
Vorteil dabei:
* ist ein bekanntes Protokoll, das einfach umzusetzen ist.
* Adressen, Kommandos, Daten ist im Portokoll alles schon vorhanden.
* fertige C-Libs zum Einbinden vorhanden.

Der Asuro würde dabei als I2C Master laufen, der Co-Controller als I2C Slave. Da der TWI (I2C nach Atmel Bezeichnung) Bus beim Asuro durch die A/D Wandler für Batterieabfrage und die Schalter belegt ist, müßte man eine I2C Software Emulation schreiben. Die bibt es ebenfalls schon fertig von P.Fleury und wurde von mir auch schon erfolgreich auf der Asuro I2C Porterweiterung eingesetzt.

Beim Co-Controller würde man natürlich die Hardware TWI benutzen.

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

[damaltor]

hmm... sag mal ich hab grad im asurowiki geschaut =)

kann es sein dass da in der platinenzeichnung ein fehler ist? die widerstände r7,r8,r9 sollen laut schaltplan an vcc kommen, bei der platine sind sie jedoch am ende nur in einem loch, welches nicht mit vcc in verbindung steht...

[EDH]

@ m.a.r.v.i.n
freilig kann man auch dat mit der I2C porterweiterung machen.
aber was neues zu entwickeln ist genauso lustig
auserdem ist der lerneffekt viel größer.

[damaltor]

ausserdem hat man miz einem zweiten atmega neue adc ports zur verfügung...

[EDH]

da scheint in der tat ein fehler im asuro wiki zu sein. r1 r2 r3 sind ja auch wie im schaltplan an vcc angeschlossen.

[damaltor]

irgendwie glaub ich stimmt die platine ohnehin nicht so ganz mit dem schaltpaln... ich glaube wenn man den jumper setzt dann ist int0 des asuro dauerhaft mit int0 verbunden...

[m.a.r.v.i.n]

Hi,

ich glaube ihr versteht mich nicht richtig. Es geht doch hier nicht darum eine I2C Porterweiterung nachzubauen, sondern es sollen zwei mega8 miteinander kommunizieren. Und dazu bietet sich nunmal I2C an.
Sicher, wenn man die Zeit und Muse hat, kann man das Rad auch immer neu erfinden.

Richtig, da sind einige Fehler im Layout. Hat ja lange gedauert, bis das jemand gemerkt hat. #-o
Das liegt halt an dem verwendeten Layout Programm, besser gesagt Malprogramm Lochmaster. Es gibt keine Möglichkeit Schaltplan und Layout miteinander abzugleichen. Eventuelle Fehler merkt man dann erst beim Zusammenlöten.

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

[damaltor]

hmm... lad dir doch mal die eagle demo version runter... ich glaub damit gehts oder?

http://www.cadsoft.de/

[raid_ox]

Gibt es eigentlich eine fertige Library für I2C Slave mode? Oder kann jemand kurz erklären, wie man ein ATMega als slave programmieren kann?

Danke im Vorraus

[Pascal]

Es gibt dazu fertige libs und auch Erklärungen. Beides findest du hier im Forum. Dazu gabs in letzter Zeit ziemlich viele threads.

[m.a.r.v.i.n]

Hi,

die Procyon AVRlib beinhaltet z.B. neben I2C Master auch I2C Slave Routinen.
http://hubbard.engr.scu.edu/embedded/avr/avrlib/

[raid_ox]

Hallo m.a.r.v.i.n,

Kannst du mal trotzdem eine beispielnutzung geben?

[raid_ox]

Ich meine mit dem avrlib, wie man es umsetzen soll...

[m.a.r.v.i.n]

Hi,

ein Beispiel für I2C Master und Slave ist in AVRlib dabei.
Odner examples/i2c
Leider etwas sehr unübersichtlich, da Master und Slave im gleichen Beispiel verwendet werden.

Ich selber habe auch noch keinen I2C Slave programmiert, habe das aber schon länger vor. Ich will den tiny24 dafür verwenden. Der hat allerdings ein USI Interface, kein TWI.