Hallo Ich suche nach einer Möglichkeit um zwischen 2 Atmega8 µC 2Byte in sehr kurzer Zeit zu übertragen. Für die Datenübertragung habe ich nur ein Fenster von 20µs zwischen 2 Timer Interrupts. Die Übertragung soll nur unidirektional erfolgen. Sinn der Sache ist, dass der empfangende µC die Daten auf einem LCD display darstellt. Die Übertragung neuer Daten soll nur etwa alle 100ms erfolgen. Nachdem ich mir mögliche Datenraten angeschaut habe scheint es jedenfalls sinnvoller die Daten über USART und nicht über den I2C Bus zu übertragen. Beide µC sollen mit 16 Mhz laufen. Ist es möglich und hilft es für höhere Geschwindigkeiten beide mit nur einem gemeinsamen Quarzoszillator zu betreiben? Gibt es andere Möglichkeiten 2 Byte innerhalb der 20 µs zu senden? Oder ist es sinnvoller 1 Byte zu senden, dann die Interrupt Routine abzuarbeiten und im nächsten Fenster das 2. Byte zu übertragen? Danke für eure Hilfe.
Wie wäre es über ein o. zwei Ports parallel, wenn genügend IOs frei sind.
Daniel K. schrieb: > Gibt es andere Möglichkeiten 2 Byte innerhalb der 20 µs zu senden? > Oder ist es sinnvoller 1 Byte zu senden, dann die Interrupt Routine > abzuarbeiten und im nächsten Fenster das 2. Byte zu übertragen? Parallele übertragung mit sagen wir mal 3x Daten + 1x Strobe Leitung? Dann kann man die zwei Byte in 4 Nibbles aufteilen. Fallende Flanke am Strobe = "Adresse" 1/2/3/4 Steigende Flanke an Strobe = Daten Sowas könnte in ungefähr 30-40 Taktzyklen geschehen. Parallele Übertragung mit 8x Daten und 1x Adressleitung? Der Ziel-AVR muss nur die Beiden Bytes abhängig von der "Adresse" in zwei Variablen stecken. Das geht ohne Synchroniastionsmechanismen und sollte in maximal 10 Prozessortakten hergehen. Frage: Warum muss es für so ein Display so schnell gehen? Oder hast du auf dem Main-Controller "keine Zeit"? mfg mf
Hi Was hat der Timerinterrupt mit der Übertragung zu tun? MfG Spess
Hallo Nimm doch einfach die serielle Schnittstelle. 2Byte + Start/Stopbit hast du doch bei nur 9600Bd in ca. 22mS übertragen. Das paßt doch lässig in deine 100mS rein. Gruß Joachim
Daniel K. schrieb: > Für die Datenübertragung habe ich nur ein > Fenster von 20µs zwischen 2 Timer Interrupts. Das ist die Zeit, die du hast, um die Daten ins UDR-Register zu schreiben. Die Übertragung macht dann der UART in Hardware, womit die Übertragungsrate erstmal völlig egal ist. Hauptsache die Daten sind "drüben", bevor die nächsten fällig werden. mfg.
ich bin nur Anfänger aber der AtMega8 schafft doch bei 16MHz takt 1MBaud? das sind doch grob geschätzt 10µs pro Byte oder irre ich mich da? das würde dann doch passen?
Danke für die schnelle Antworten Also der sendende Controller hat für das LCD-Display keine Zeit. Ich möchte mit dem Timer-Interrupt alle 25µs zwei Eingänge abfragen um damit einen Inkrementalgeber auszuwerten. Mehrere Ports zu verwenden ist eine gute Idee. Was für Übertragungsraten sind denn bei 16 Mhz und 1 Datenleitung realistisch? Thomas Eckmann schrieb: > Das ist die Zeit, die du hast, um die Daten ins UDR-Register zu > schreiben. > Die Übertragung macht dann der UART in Hardware, womit die > Übertragungsrate erstmal völlig egal ist. Hauptsache die Daten sind > "drüben", bevor die nächsten fällig werden. Achso die Datenübertragung läuft dann praktisch im Hintergrund und mein normaler Programmablauf des µC läuft ganz normal weiter?
benwilliam schrieb: > das sind doch grob geschätzt 10µs pro Byte oder irre ich mich da? > > das würde dann doch passen? Mag schon sein, ist aber irrelevant. Denn die Übertragung selbst macht der UART ganz von alleine nebenbei. Der UART darf nur nicht schneller gefüttert werden, als er übertragen kann. Und zwischen 2 Fütterungen vergehen 100ms (oder 50ms pro Byte), also mehr als genug Zeit für die UART die Übertragung abzuwickeln.
Vielen Dank das wusste ich nicht. Kann mir noch jemand sagen wie das beim I2C abläuft? Erfolgt die Datenübertragung hier auch im Hintergrund?
Daniel K. schrieb: > Danke für die schnelle Antworten > Also der sendende Controller hat für das LCD-Display keine Zeit. Glaub ich eigentlich nicht. 1 Zeichen auf dem LCD auszugeben dauert auch nicht wesentlich länger als 1 Zeichen per UART zu übertragen. Kein Mensch sagt, dass du eine Zahl in einem Rutsch auf das LCD schreiben musst. Wenn das LCD bei einem Interrupt 1 Zeichen hinmalt und beim nächsten dann das nächste, dann merkt das kein Mensch. > Ich möchte mit dem Timer-Interrupt alle 25µs zwei Eingänge abfragen um > damit einen Inkrementalgeber auszuwerten. OK. Macht ein Timer in einem Interrupt. Die Hauptschleife gibt die ermittelten Werte so schnell aus, wie sie kann (ist wahrscheinlich sowieso zu schnell, so schnell kann kein Mensch schauen). Wo liegt das Problem? > Achso die Datenübertragung läuft dann praktisch im Hintergrund und mein > normaler Programmablauf des µC läuft ganz normal weiter? Wenn du so fragst bin ich mir ziemlich sicher, dass dein 'Problem' mit lediglich einem µC locker zu lösen ist. Genaue Anforderungen auf den Tisch und dann überlegen wir uns mal was. Was ausser dem Inkrementalgeber hat der µC noch zu bedienen? Merke: mehrere Prozessoren einzusetzen, macht die meisten Dinge komplizierter und nicht einfacher.
Daniel K. schrieb: > Vielen Dank das wusste ich nicht. > Kann mir noch jemand sagen wie das beim I2C abläuft? Erfolgt die > Datenübertragung hier auch im Hintergrund? Frag dich ganz einfach: Hab ich für eine spezielle Anforderung (I2C, UART, ADC, ...) eine eigene Hardware oder hab ich sie nicht. Wenn du dafür eine eigene Hardware hast, dann laufen die Dinge parallel zur CPU, vulgo 'im Hintergrund'. Hint: I2C heißt bei Atmel aus rechtlichen Gründen TWI
Nimm doch SPI oder benutz den USART im synchronen modus.
Die einzige Aufgabe des Mikrocontrollers ist eigentlich einen Inkrementalgeber auszuwerten und dann etwa alle 10 Impulse einen Ausgang zu triggern zB für eine Zeilenkamera. Zusätzlich soll die zurückgelegte Strecke auf einem LCD-Display angezeigt werden. Optional würde ich gerne noch zur Laufzeit den Wert, wie oft der Ausgang getriggert werden soll, ändern. Der Inkrementalgeber hat 2048 Inkremente, was bei Auswertung jeder Flanke der beiden Spuren 8192 Flanken pro Umdrehung macht. Die Geschwindigkeit liegt bei bis zu 3 Umdrehungen pro Sekunde. Damit komme ich auf ca 40µs zwischen 2 Flanken. Wenn ich das mit einem Mikrokontroller lösen kann ich das natürlich noch besser.
Daniel K. schrieb: > Zusätzlich soll die zurückgelegte Strecke auf einem LCD-Display > angezeigt werden. > Optional würde ich gerne noch zur Laufzeit den Wert, wie oft der Ausgang > getriggert werden soll, ändern. > > Der Inkrementalgeber hat 2048 Inkremente, was bei Auswertung jeder > Flanke der beiden Spuren 8192 Flanken pro Umdrehung macht. Die > Geschwindigkeit liegt bei bis zu 3 Umdrehungen pro Sekunde. Damit komme > ich auf ca 40µs zwischen 2 Flanken. Bei 16Mhz sind das 640 Takte Zeit (ohne jetzt die 40µs nachgerechnet zu haben) Da löst dein µC nebenher noch teuflisch schwierige quadratische Gleichungen > Wenn ich das mit einem Mikrokontroller lösen kann ich das natürlich noch > besser. Dein Konzept muss stimmen, das ist alles. Das Zeitkritische, das Nachsehen an den Ports für den Inkrementalgeber und die Auswertung des Gelesenen + Pulsgenerierung, kommt in einen Timerinterrupt. Und von der Rechenzeit, die dann noch übrig ist, machst du die Ausgabe in der Hauptschleife bzw. das Benutzerinterface. Wenn die immer wieder von einem Interrupt unterbrochen wird, so ist das kein Beinbruch. Dein Benutzer wird das nicht merken. Ditto mit der LCD Ausgabe: Was du einhalten musst, sind Mindesttimings. Wenn die durch laufende Interrupts etwas länger werden, dann stört das das LCD nicht. Du darfst es langsamer ansteuern (nur nicht schneller, aber in die Gefahr läufst du ja nicht)
Karl Heinz Buchegger schrieb: > Bei 16Mhz sind das 640 Takte Zeit. Kann man das in Abhängigkeit von µC-Typ und Quarz berechnen? Oder gibt es eine Tabelle?
P. Gerber schrieb: > Karl Heinz Buchegger schrieb: >> Bei 16Mhz sind das 640 Takte Zeit. > > Kann man das in Abhängigkeit von µC-Typ und Quarz berechnen? Ähm. Wenn der µC mit 16Mhz angesteuert wird, wieviele Takte macht er dann in der Sekunde? Wieviele Takte macht er daher in 40µs? > Oder gibt es eine Tabelle? Was du wahrscheinlich meinst: Wieviele Befehle sind das? (ich hab nur von Takten gesprochen) Die meisten Befehle auf einem Mega laufen in 1 Takt durch, ein paar brauchen 2 Takte. Nimmt man durchschnittlich 1.5 Takte pro Befehl an, würde ich das als eher konservative Schätzung bezeichnen. 640 Takte sind dann ca. 420 Befehle. Immer noch mehr als genug um * Port abfrage * Inkrementalgeber Auswertung (per Tabellenzugriff a la MaWin) * Wegzähler updaten * Vergleich mit einem Pulsgrenzwert und bei Bedarf einen Ausgabeport toggeln Über den Daumen braucht das vielleicht 50 Befehle, seien wir großzügig: 100. Dazu noch der ISR Overhead von nochmal 20, macht in Summe maximal ca 120. D.h. ich würde erwarten, dass der Mega rund 1/3 (oder weniger) seiner Zeit für den Geber und die Pulse braucht. Bleiben 2/3 der Rechenzeit für den Rest übrig - bei sehr konservativer Schätzung. Mehr als genug für ein paar 100 LCD Updates in der Sekunde.
SPI kann alle 18 Taktzyklen einen Wert verschicken. Ich würde da einfach beide Mikrocontroller synchron betreiben. Da Du ja 18 Taktzyklen pro Wert hast, kann der Empfänger locker den Interrupt während des ersten Bytes bearbeiten und dann die nächsten Bytes direkt entgegen nehmen. Sprich ich würde den Anfang der Übertragung per Interrupt machen, dann aber gleich das ganze Datenpaket in einem Rutsch übertragen.
P. Gerber schrieb: > Karl Heinz Buchegger schrieb: >> Bei 16Mhz sind das 640 Takte Zeit. > > Kann man das in Abhängigkeit von µC-Typ und Quarz berechnen? > Oder gibt es eine Tabelle? 16MHz = 16 * 10^6 Takte/s Ein Takt ist 1/16MHz = 62,5ns lang. 20µs / 62,5ns = 640 mfg mf
Vielen Dank euch. Für den Fall, dass ich einen Mikrocontroller verwende: Tut mir leid wenn ich jetzt blöd Frage aber wie ist das wenn ich in der Übertragung unterbrochen werde? Steht dann möglicherweise ein falsches Zeichen auf dem LCD? oder kann das nicht passieren weil ich immer ein Byte(bzw. ein Nibble) gleichzeitig übertrage? Ich merke gerade, dass ich mich mit der Thematik noch viel zu oberflächlich beschäftigt habe. Wollte ich bisher was auf einem Display ausgeben ging das mit den fertigen Funktionen ganz einfach, da musste ich mir über solche Dinge keine Gedanken machen.
Daniel K. schrieb: > Tut mir leid wenn ich jetzt blöd Frage aber wie ist das wenn ich in der > Übertragung unterbrochen werde? Welche Übertragung? Wie ist dein LCD angeschlossen? > Steht dann möglicherweise ein falsches > Zeichen auf dem LCD? oder kann das nicht passieren weil ich immer ein > Byte(bzw. ein Nibble) gleichzeitig übertrage? Ich geh von einem Standard-LCD aus Steuerleitungen einstellen bischen warten Nibble an den Ausgabeport anlegen bischen warten Enable auf High bischen warten Enable auf Low anderes Nibble an den Ausgabeport bischen warten Enable auf High bischen warten Enable auf Low das ist der Standardmechanismus, der hier greift. An allen Stellen an denen 'bischen warten' steht, spielt es keine Rolle, ob dieses 'bischen' ab und zu mal ein bischen länger dauert. Wie gesagt: Du hast Mindestzeiten, die mindestens eingehalten werden müssen. Länger darf es immer werden. Das einzig Zeitkritische in deiner Anwendung ist die Fragestellung: krieg ich die gewünschte Polling-Frequenz für den Encoder per Interrupt hin oder nicht? Und mit Aufwands-Schätzen (*) ergibt sich: geht sich aus und es bleibt noch Rechenzeit übrig. (*) mit Schätzen ist hier nicht "aus den Fingern saugen" gemeint, sondern das was im englischen Sprachraum ein "educated guess" genannt wird.
Karl Heinz Buchegger schrieb: >> Oder gibt es eine Tabelle? > > Was du wahrscheinlich meinst: Wieviele Befehle sind das? (ich hab nur > von Takten gesprochen) Ja, so hab ich das gemeint. Vielen Dank für die Erklärung.
Ich hätte noch ne andere Frage wenn wir schon dabei sind, dass alles was ne eignen Hardware hat keine Rechenleistung des µC verbraucht: Ist es dann sinnvoll wenn der µC noch mehr als nur ein LCD-Display bedienen soll statt eines 2.µC einen IC für das Zählen der Impulse einzusetzen? Gibt es einen IC der zum einen die Impulse zählt (natürlich jede Flanke also eine Vierfachauswertung) und gleichzeitig auch das Toggeln eines Ausgangs alle X Impulse übernimmt? Außerdem habe ich gelesen, dass es µC geben soll die eine solche Funktion für das Zählen ebenfalls schon hardwaremäßig enthalten? Danke schonmal
Daniel K. schrieb: > Außerdem habe ich gelesen, dass es µC geben soll die eine solche > Funktion für das Zählen ebenfalls schon hardwaremäßig enthalten? Nennt sich Timer. Aber zu einer 16 Bit Zahl 1 dazuzuzählen ist für einen µC eine leichte Übung. Dafür wurden sie schliesslich gebaut, dass sie Rechnen können. > Ist es dann sinnvoll wenn der µC noch mehr als nur ein > LCD-Display bedienen soll statt eines 2.µC einen IC für das > Zählen der Impulse einzusetzen? Generell: Du musst immer abwägen zwischen * wieviel Aufwand ist es für den µC die Funktionalität in Software nachzubilden. Zu einer 16 Bit Zahl 1 dazuzuzählen und mit einer anderen Zahl zu vergleichen ist für den µC Pipifax * wieviel Aufwand ist die eigene Hardwarelösung in Einheiten von IC, Hühnerfutter rundherum, Platinenplatz oder in einem Wort zusammengefasst: Geldeinheiten. * Die Hardware arbeitet ja auch nicht still und leise vor sich hin sondern der µC muss mit ihr "kommunizieren". Einstellungen müssen gemacht werden, Ergebnisse müssen abgeholt werden. D.h. Da entsteht rein durch die Zusatzhardware ganz automatisch ein zusätzlicher Softwareaufwand, den du nicht hättest, wenn es die Hardware gar nicht gäbe. Wenn dieser Aufwand höher ist als der Aufwand die eigentliche Funktionalität in Software auszuführen, dann hast du mit Zitronen gehandelt.
Eigentlich meinte ich eher sowas wie ein Quadratur Encoder Interface. Was du sonst schreibst klingt absolut logisch. Allerdings würde ich einfach gerne mehrere Konzepte umsetzen und anschließend bewerten.
Daniel K. schrieb: > Eigentlich meinte ich eher sowas wie ein Quadratur Encoder Interface. Das kann schon sinnvoll sein. Wenn zu erwarten ist, dass der Encode seine Pulse so schnell bringt, dass der µC nicht mehr mitkommt. Aber ansonsten ist die Standardannahme meistens: Machs in Software. Software ist flexibel und kann auch im Nachhinein angepasst und verändert werden. Genau dieses begründet ja auch, warum man heutzutage oft kleine µC einsetzt, wo man vor einigen Jahren noch mit speziellen IC gearbeitet hat. Man ist einfach flexibler.
Dann werde ich es erstmal auf diesen Weg versuchen. Vielen Dank für deine Mühe!
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.