Hallo Allerseits, schon seit längerem wollte ich die Datenübertragung mit nur einem Anschluss zwischen 2 AVR-Prozessoren realiseren. Dazu habe ich ein Programm geschrieben, welches für einen Masterprozessor und einen Saveprozessor unterschiedlich kompiliert werden kann. Die Kommunikation hat im Moment folgende Eingenschaften: - Ping/Pong Verfahren: Die Kommunikation ist immer bidirektional - Übertragungsgesschwindigkeit: 1KByte/Sec bidirectional ( also ca. 20KBaud ) - Master/Slave: der Master schickt ein Byte zum Slave, der Slave ein Byte zurück Es gibt nur 2 Funktionen: masterping : sendet ein Byte zum Slave und wartet auf die Antwort slavepong : wartet auf das Byte vom Master und sendet ein Antwortbyte zurück Was haltet Ihr davon? Gruss, Christoph Der Code befindet sich hier: http://www.roboterclub-freiburg.de/AtmelAVR/Software/chEinAnschlussKom_V1.0.c.zip
Man kann vieles machen. Was soll's denn werden ? Einfach etwas in Konzepten stochern ?
Wie sieht das eigentlich mit dem Timing aus, wenn die AVRs neben der Kommunikation noch andere Arbeit erledigen müssen? Ich frage deshalb, weil ich (als unwissender C-Muffel) im Code keinerlei Synchronisation mit Timer finden konnte, dafür aber den Aufruf von Delay-Routinen. Meine AVRs sollen eigentlich andere Arbeit tun als in Software Wartezeiten abzuzählen. Dafür gibt es Timer, die machen das im Hintergrund (in Hardware) ganz akkurat, während sich der AVR sinnvolleren Dingen widmen kann. MfG, Blaubär
> Was soll's denn werden ? Einfach etwas in Konzepten stochern ? Ja, es geht mir ein wenig um Konzepte. Ausserdem möchte ich die Konzepte neu ordnen. Alle bisherigen Übertragungsverfahren haben ihre Anwendungen aber für bestimmte Anwendungen auch Nachteile z.B. benötigt der I2C-Bus 2 Leitungen und ist für einen Attiny13 ungeeignet. Die Ein-Anschluss-Schnittstelle ist sehr gut für 8-Pin Mikrokontroller geeignet. Ausserdem wird als Übertragunsverfahren Puls-Code-Modulation verwendet. Das hat gegenüber einem RS232 Protokoll den Vorteil, das die Taktfrequenzen der beiden Kontroller nicht so gut synchronisiert sein müssen. Das ist vor allen Dingen bei den internen RC-Oszillatoren wichtig. Meine grobe Schätzung ist ein verkraftbarer Taktfrequenzunterschied von 20%. >Ich frage deshalb, weil ich (als unwissender C-Muffel) im Code keinerlei >Synchronisation mit Timer finden konnte, dafür aber den Aufruf von >Delay-Routinen. Meine AVRs sollen eigentlich andere Arbeit tun als in >Software Wartezeiten abzuzählen. Ja, es sind Delay-Routinen. Einen Timer zu benutzen bedeutet allerdings auch schon wieder den Verbrauch einer Resource, die man im System vielleicht schon wieder an anderer Stelle gebrauchen kann. Es wäre natürlich schade, wenn der Prozessor seine Wartezeit mit Delays verbrät.Das kann man aber ändern, wenn man die Datenübertragung schnell genug macht. Ich halte es für möglich, mit dem dargestellten Konzept 250KBit/sec bis 500Kbit/sec zu erreichen, dann muss man für die Übertragung eines Bytes nur noch 40-80us warten. Das dürfte für die allermeisten Anwendungen ausreichend sein. Ausserdem ist die Kommunikation synchron ausgelegt. Man kann den Anschluss am Slave z.B. an den Interuptpin hängen. Dann löst der Master mit seiner Anfrage den Interupt aus. Bis der Slave die Anfrage beantwortet, entsteht in der aktuellen Implementation im Master eine Wartezeit. Wenn die Interrupt-Slave-Response Time allerdings kurz ist, kann man auch diese verkraften.
Mit deinen Worten: Einen Delay() zu benutzten bedeutet einen Resourceverbrauch von exakt 100% der gesammten MCU. Na da verbrauche ich aber lieber einen der vielen Timer und kann nebenbei noch das SPI, die RS232, den ADC, die PWMs, die Ports, den Analog Comparator, den EERPOM, FLASH, SRAM usw. benutzen. Die Frage nach den Delays() ist gerechtfertigt. Eine auf Benutzbarkeit angelegte Bibliothek sollte niemals delays() benutzen, zumindestens nicht so massiv wie in deinem Source. Gruß Hagen PS: Außnahmen bestätigen die Regel. Ein Bootloader kann auch mit Delays() seine Kommunikation erschlagen, da macht es Sinn. im Allgmeinen aber nicht.
Hagen Re wrote: > Mit deinen Worten: > > Einen Delay() zu benutzten bedeutet einen Resourceverbrauch von exakt > 100% der gesammten MCU. Genau. Während eines Delays geht nix Anderes, nichtmal ein Interrupt, denn der verfälscht ja das Delay. > > Na da verbrauche ich aber lieber einen der vielen Timer und kann > nebenbei noch das SPI, die RS232, den ADC, die PWMs, die Ports, den > Analog Comparator, den EERPOM, FLASH, SRAM usw. benutzen. Ich auch. > PS: Außnahmen bestätigen die Regel ... Stimmt, die Wartezeiten bei der (einmaligen) Initialisierung des LCDs generiere ich auch meist mit Zeitschleifen. Zur Eindrahtverbindung: Ich benutze gerne etwas Ähnliches. Allerdings schön langsam, damit es im (sowiso vorhandenen) Timer-Interrupt nebenbei mit laufen kann und daher nur ganz wenige Prozent der Rechenleistung beansprucht. Beitrag "Re: Taktstabilität beim Tiny 13" ...
> Hagen Re (hagen) >Na da verbrauche ich aber lieber einen der vielen Timer und kann >nebenbei noch das SPI, die RS232, den ADC, die PWMs, die Ports, den >Analog Comparator, den EERPOM, FLASH, SRAM usw. benutzen. Und was machst Du bei einem Attiny13 ohne SPI, RS232 und mit nur 5 nutzbaren Portpins? > Hannes Lux (hannes) >Zur Eindrahtverbindung: >Ich benutze gerne etwas Ähnliches. Allerdings schön langsam, damit es im >(sowiso vorhandenen) Timer-Interrupt nebenbei mit laufen kann und daher >nur ganz wenige Prozent der Rechenleistunght. Hallo Hannes, es wäre interessant, Deinen Code einmal zu sehen. Für viele Aufgaben ist eine langsame Übertragungsgeschwindigkeit ausreichend. Mir geht es bei meinem Versuch auch ein wenig darum, sehr hohe Geschwindigkeiten zu ermöglichen.
> Und was machst Du bei einem Attiny13 ohne SPI, RS232 und mit nur 5 > nutzbaren Portpins? Sicherlich mehr als nur die Kommunikation mit einem anderen. Damit die sinnvoll ist, muß man ja erstmal was zum Übertragen haben.
>Und was machst Du bei einem Attiny13 ohne SPI, RS232 und mit nur 5 >nutzbaren Portpins? Dann schicke ich den AVR in den Sleep Mode und spare so >60% Strom ein. Mann du möchtest diskutieren um des Diskutieren willens, das bringt nichts. Es ist fakt das eine Delay() die MCU zu 100% auslastet und ein Timer mit gleicher Verzögerung meistens nur 1-10% der Rechenzeit benötigt, die restliche Zeit kann man entweder andere Peripherie benutzen oder eben einfach den Sleep Mode aktivieren um kräftig Power zu sparen. Es ist einfach bescheuert ein Kabrio zu kaufen und niemals das Verdeck zuzumachen, statt dessen lässt man es reinregnen. Die Timer in einem AVR sind dazu da das man sie benutzt. Besser noch, mit deinem Auto kann man entweder Lenken oder den Motor anmachen, was nützt das ? Lenkrad nach Links, Moter einschalten par Meter fahren, Motor ausschalten, Lenkrad wieder nach Rechts, Motor wieder einschalten par meter fahren und wieder aus... Nungut es geht aber noch weiter. Du bietest eine Kommunikationsschnittstelle an mit der ich entweder nur kommunizieren kann oder nicht kommunizieren kann wenn der AVR noch andere Sachen erledigen soll. Damit ist diese Kommunikationsschnittstelle nur in 10% aller Fälle brauchbar, denn in 90% aller Fälle soll der AVR ja auch Daten sammeln um diese über diese Kommunikatinsschnittstelle zu versenden. Das Sammeln der Daten muß aber meistens in sehr exakten zeitlichen Intervallen erfolgen. Zb. wir möchten ein Mikrofon per ADC sampeln und diese Daten kontinuierlich versenden. Hm, deine Schnittselle blockt die gesamte MCU und ergo ein sauberes Sampling des ADCs ist nicht mehr möglich. Und falls doch mal der Fall eintreten sollte das alle Resourcen verbraucht sind dann heist dies meistens auch das die MCU zu mehr als 100% ausgelastet ist. Ergo: Fehler in der Planung man hätte gleich eine größere MCU nehmen müssen. Wo ist das Problem ? faktisch können also die Resourcen niemals ausgehen, man hat sich nur verplant, verschätzt und nimmt eine größere MCU. Gruß Hagen PS: das ist eine gerechtfertigte Kritik und soll in keinem Falle deine Bemühungen und den Willen dein Wissen mit uns zu teilen, in den Schatten stellen !
Christoph H. wrote u.a.: > Hallo Hannes, > Für viele Aufgaben ist > eine langsame Übertragungsgeschwindigkeit ausreichend. Für nur sehr wenige Aufgaben (Video, Sound) ist eine schnelle Übertragung nötig. Die kleinen AVRs können diese Aufgaben sowiso nicht bewältigen. > Mir geht es bei > meinem Versuch auch ein wenig darum, sehr hohe Geschwindigkeiten zu > ermöglichen. Diese sind bei kleinen AVRs sinnfrei, da die Speicherkapazität nicht ausreicht, um das Übertragungstempo zu rechtfertigen. Geschwindigkeit ist nicht alles, sie schafft oft mehr Probleme als Nutzen. "Sehr hohe Geschwindigkeiten" erhöhen auch das Unfallrisiko (Datensalat). ...
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.