Zwischen 2 Atmegas Daten verschieben??

[raptor_79]

Hallo!

Will eigentlich nur mal wissen, ob und wie man daten zwischen 2 Atmegas verschieben kann.
Nur mal so generell... hab da jetzt an nicht spezielles gedacht. (noch nicht)
Also, wenn ich z.b. den einen als "Hauptcontroller" laufen lass, und den 2. als CoPro. würde sowas gehen?
Stell mir das so vor, daß der eine das "Hauptprogramm" drauf hat, und dann der 2. spezielle sachen wie z.b. die Sensoren übernimmt.
das hauptprogramm wäre für "herumfahren" und solche dinge da, der 2. für LCD und messdatenerfassung, und wenn sich da eine bedingung einstell, er dem "hauptcontroller" die info "fertig" gibt, und dieser dann weitermacht, oder sowas in der richtung.

ist sowas 1. besser über I2C oder seriell zu lösen??
2. sind die laufzeiten "gut genug" um vorgänge schnell genug erfassen zu können??


jo, danke schon mal......

[SprinterSB]

I2C ist seriell ;-)

UART: schnell implementiert, Probleme bei Multimaster/Multislave (ein wenig Hardwareunterstützung gib's aber im USART dafür)
I2C: schön erweiterbar, Multimasterfähig, neue Slaves einfach dranklatschen
SPI: Mehrere Slaves gehen, aber für jeden braucht man ein SS (Slave Select) Recht flott, einfach zu implementieren.

Von der Topologie her find ich es umgekehrt auch interessant:
Der Haupt-µC ist nicht Master, sondern Slave (Server). Und die ganzen Sensor-µC sind Clients, wolen also was (abliefern) und der Server muss springen.

[uwegw]

ich habe auf meinem bot nen mega8 und nen mega32 im einsatz, die per i2c vernetzt sind. das ganze läuft schon echt gut, die geschwindigkeit reicht locker aus...

von der software her ist es (je nach sprache/verfügbaren libs) meist einfacher, über rs232 zu gehen. man muss sich halt nen system von textcodes überlegen, und dann hat man die kommunikation recht schnell am laufen. ich habe es zuerst auch so gemacht. bei i2c ist das problem, dass man für die wenigsten sprachen vernünftige slave implementationen findet... das verkompliziert die programmierung...

meine seriellen kommandos beiginnen zb alle mit # und enden auf &. so kann der slave eindeutig die befehle unterstellen. #L+-sss& ist zb der befhel, den linken motor auf eine geschwindigkeit zu setzten, die durch den dreistelligen pwm-wert (sss) gegeben wird.
im empfangs-interrupt werden die einzelnen reinkommenden zeichen zu einem string zusammengesetzt. wenn das & kommt, wird der befehl in eine zweite variable kopiert, die dann ausgewertet wird.

[Florian]

Hallo raptor_79!

Will eigentlich nur mal wissen, ob und wie man daten zwischen 2 Atmegas verschieben kann.Ja, generaell geht das!
Es kommt allerdings darauf an, welche Art von Daten und in welcher Menge in welcher Zeit ...


ist sowas 1. besser über I2C oder seriell zu lösen??
2. sind die laufzeiten "gut genug" um vorgänge schnell genug erfassen zu können??Zu 1.) Seriell ist sicherlich bei einem Master und einem Slave bzw. zwei Gleichberehtigten das einfachste, aber I2C ginge auch.
I2C ist allerdings eher für mehr Controller geeignet!
Zu 2.) Es kommt darauf an in welcher Geschwindigkeit, aber theoretisch ist alles möglich!
Es gibt sogar spezielle I2C-LCD's, da brauchst Du selber keinen Controller mehr vorschalten.
Kleiner Tipp, das nutze ich selber auch:
http://www.roboter-teile.de/Shop/themes/kategorie/detail.php?artikelid=40&source=2

[becki]

und wie kann ich soetwas üebr UART in assembler coden? Als einfache Besipeil sie mal ATmega8-A und ATmega8-B gegeben. ATmega8-A hat einen Schalter, ATmega8-B eine LED. wenn ich den schalter drücke, sollte ATmega8-A den befehl des asnschaltens der LED an ATmega8-B geben. wie sende und empfange ich über UART?

[uwegw]

http://www.mikrocontroller.net/tutorial/uart (am besten den empfang über den interrupt laufen lassen)
an die stelle des gesendeten bytes, das in diesem beispiel auf eine port ausgegeben wird, müsstest du dir nun zb einen code für an und aus überlegen, zb $00 für aus und $ff für an. den anstelle der ascii-ode im beispiel senden, im empfänger prüfen, was reingekommen ist, und entsprechend schalten..

[becki]

gut, werde das mal angehen. danke für den link