Hallo, ich wollte ein paar Daten vom AVR an den PC senden. Nun frage ich mich, wie der Zusammenhang zwischen kbs und aufgewandte Rechenzeit vom AVR ist. Angenommen ein Mega32 läuft mit 4MHZ quarz. Schafft er es ca 50 Integerwerte 6mal in der Sekunde zu sende, ohne das seine anderen Aufgaben (ADC, Display, Berechnungen) beeintächtigt werden? Welche kbs-wert wäre da am sinnvollsten? Oder erstmal von 4MHZ gleich auf 16MHZ hoch? Vielen Dank.
Gast
#325578
Welche Baud-Rate?
Gast
#325579
Es kommt wohl eher auf das Programm (und die Baudrate) an. Wenn du den Datenverkehr dadurch realisierst, dass du immer abfragst, ob das Byte schon gesendet wurde, dann wartest du ziemlich viel. Wenn du die Sache aber per Interrupt (und Ringpuffer) steuerst, beeinflussen sich die einzelnen Aufgaben weniger. Es kommt auf die Programm-Struktur nicht unbedingt auf die Taktfreequenz an.
Gast
#325580
Die Datenmenge ist und Baudrate ist da nicht das Problem. Eher die Implementierung. Wenn die Daten in einen Ringpuffer gestellt werden und per ISR die UART bedient wird merkt der uC herzlich wenig von der Kommunikation. Jedes zu sendende Byte wird dann nur wenige cycles benoetigen um es in den UART data buffer zu transportieren und die Bufferverwaltung zu erledigen.
Gast
#325581
Ich würde zu 38400 Baud raten, damit man noch etwas Luft hat. Und da siehts bei 4MHz schon schlecht aus, Du brauchst ein 3,6864MHz Quarz (oder 7,3728MHz, 11,0592MHz, ...). Peter
Das kommt drauf an (normal schafft er das locker): Integer (AVR) 2 Byte 50 6 = 600 Byte/sek das entstspricht (etwa) 6000 Baud/sek + Overhead für Übertragungsprotokoll. Da du mit 4 MHz vermutlich nur eine geringe Baudrate mit 9600 Baud zusammen bringst (verwende besser einen "Baudratenquarz" mit 3,68 MHz) könnte dieser Punkt hier schon knapp werden. Von der Rechenleistung sollte der AVR aber locker ausreichen (16 MHz sind da schon der overkill). Die anderen Aufgaben werden aber schon (geringfügig) beeinträchtigt. Irgendwo muss die Rechenleistung ja her kommen. Hier mal ein Rechenbeispiel: Wenn wir jetzt mal annehmen du hast einen Quarz von 3,68 MHz und 115200 Baud (sind ca. 12 Kb/s) und ein Integer + Overhead braucht 3 Byte dann schaffst du ca. 4000 Integers / Sekunde. (Limit von der Schnittstelle) für jeden Integer hast dann 920 Takte/Befehle zur verfügung, wobei simples rüberschaufeln ca 100-200 Takte brauchen wird. Wenn du nicht mit jedem Integer noch eine aufwändige Berechnung durchführst und das interruptgesteuert programmierst, bleibt dir in der Mainloop selbst bei dieser Geschw. noch genügend Rechenleistung (ca. 80%), das Display aktualisieren. Gruß Roland
Gast
#325583
4.000.000 8 38400 - 1 = 12,02 Wenn er wirklich mit einem 4MHz Quarz läuft, dann würde diese Lösung mit Double-Speed-Bit gehen. Es verschlechtert den Empfang vom UART, aber er will ja nur senden.
puh...also ich werde jetzt auf 8MHZ und den vorgeschlagenen 38,4 gehen und einfach mal testen. Vielen Dank für eure Anregungen
Gast
#325585
Nimm lieber 7,37...MHz, die sind baudraten kompatibel.
habe ich aber nicht. und bei 38,4 und 8mhz soll es "nur" eine abweichung von 0,16% gében
Gast
#325587
@Roland "wobei simples rüberschaufeln ca 100-200 Takte brauchen wird". Erklaer bitte was du mit "Rueberschaufeln" meinst. Den Transfer leistet die UART ohne Hilfe des cores. Der muss bei 115200 Baud nur alle 87 usec ein paar wenige cycles (<< 30) spendieren um die UART mit einem weiteren Datenbyte zu fuettern. Daraus ergibt sich ein Lastanteil von 0,00082% bei 3,68MHz Taktfrequenz fuer die Bedienung der UART. Hab ich da was falsch verstanden ?
Gast
#325588
Aeh, Bloedsinn. Das waehre bei einem byte / sec. Lastet man die UART bei 115200 Baud voll aus kommt der Lastanteil auf 9,4%.
Hmmm... Ich "schaufle" da garnicht, ich überlasse das dem LCD-Treiber (mit 256 Bytes Ringbuffer), der schiebt das im sowiso aufgerufenen Timer-Interrupt statt auf LCD einfach an UART. Das hat den Vorteil, dass ich alle (für das LCD vorhandenen) Print-Routinen (Umwandlung von Variablen oder Konstanten in ASCII-Text) für die Ausgabe nutzen kann. Beispiel: http://www.hanneslux.de/avr/stopuhr/index.html ...