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
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).
...
