Hi, ich hätte eine Frage bzgl. der Taktfrequenz eines Mikrocontrollers. Angenommen ich habe einen Bus, der mit 2 MHz läuft. Welche Taktfrequenz sollte dann der Mikrocontroller mindestens haben, um die Daten noch einwandfrei verarbeiten zu können? Gibt es da irgendeine Faustformel? mfg Freeze
> Angenommen ich habe einen Bus, der mit 2 MHz läuft. Was ist das für ein Bus? Was hat der für Steuersignale? Welche Synchronisationsmethode verwendet der Bus? Wie kommt der in den uC? Wird die Busankopplung in Software oder Hardware gemacht? > Gibt es da irgendeine Faustformel? Nein. Bestenfalls die Faust aufs blaue Auge... ;-)
Das hängt ein bischen davon ab - wieviele Takte er für einen Ladebefehl braucht, - was er mit den Daten machen will, - ob er sich auf irgendwas synchroniseren muss. Im einfachsten Fall braucht er 1 Takt um Daten vom Bus zu laden und man schreibt diesen Befehl 10000 mal hintereinander. Dann sind es 2 MHz. Nur arbeitet er dann als sinnlose Datensenke. M.a.W: Sinnlose Fragen führen zu sinnlosen Antworten.
Aufgrund der präzisen Fragestellung: >0 wäre zu empfehlen.
Okay, okay :-) Ich sehs ja ein. Mit Bus hab ich mich auch falsch ausgedrückt. Im Endeffekt wird es sich wohl um eine SPI Schnittstelle handeln. Es gibt also keine Synchronisation. Der Slave ist ein Sensor, der einfach stupide mit irgendwelchen 8bit-Daten auf die angefragte 8bit-Adresse seitens des µC als Master antwortet. Das passiert dann etwa 350 mal in Folge und das dann alle paar Millisekunden. Ich werde wohl einen STM Controller nehmen, der das SPI Interface schon integriert hat.
> ... eine SPI Schnittstelle handeln. > Es gibt also keine Synchronisation. Eine SPI-Schnittstelle ist absolut synchron, die liefert ihren Takt auf einer eigenen Leitung mit. Darüber hinaus ist jedes Wort mit einem Slave-Select synchronisiert, was will man mehr. > Der Slave ist ein Sensor, der einfach stupide mit irgendwelchen > 8bit-Daten auf die angefragte 8bit-Adresse seitens des µC als Master > antwortet. Wie das? Bei SPI gibt es per Definition nur 1 Master. Es kann also nicht einmal der uC anfragen und das andere mal der Sensor loslegen (das wären ja schon 2 Master auf 1 Bus).
Sie ist automatisch synchron, weil nur der Master den Takt vorgibt. Also gibt es keine Synchronisation. Und natürlich antwortet der Slave und bleibt dabei auch Slave. Ein Slave kann nicht nur Daten empfangen sondern auch senden. Aber langes Gerede um den Brei... darum gehts nicht.
> Ein Slave kann nicht nur Daten empfangen sondern auch senden. Und das sogar gleichzeitig ;-) > Aber langes Gerede um den Brei... darum gehts nicht. Dass das jetzt erst klar ist, ist der ursprünglichen Fragestellung zu verdanken: >> Angenommen ich habe einen Bus, der mit 2 MHz läuft. >> Welche Taktfrequenz sollte dann der Mikrocontroller mindestens haben, >> um die Daten noch einwandfrei verarbeiten zu können? Das kommt darauf an, was du mit den Daten machen willst. Ein Regler oder Speichern in ein Flash ist braucht mehr Rechenleistung, als wenn du "nur" die Daten irgenwo in ein RAM legst.
Um SPI-Daten mir 2Mhz sinnvoll verarbeiten zu können, sollte der Controller schon mit 16Mhz getaktet sein.
"Um SPI-Daten mir 2Mhz sinnvoll verarbeiten zu können, sollte der Controller schon mit 16Mhz getaktet sein." Wie kommst Du denn darauf ? Das Ganze hängt doch auch sehr stark davon ab, wie der µC programmiert wird: Bei Assembler-Programmierung kann man den Takt etwas mühselig ausrechnen, ist das Programm dagegen in C geschrieben, hilft nur noch ausprobieren und mit einem Oszilloskop nachmessen. Gast27
Hi, die Daten sollen erstmal nur im RAM gespeichert werden. Alle weiteren Berechnungen usw. bleiben hier mal außen vor. Mir gehts wirklich nur um die reine Kommunikation. Im Prinzip will ich "nur" wissen, wieviele Takte ich brauche um den Clock zu erzeugen und gleichzeitig ein Bit rauszusenden bzw. zu lesen und im RAM abzulegen. mfg E. Fries
>> Ich werde einen Controller nehmen der das SPI Interface integriert hat. > wieviele Takte ich brauche um den Clock zu erzeugen > und gleichzeitig ein Bit rauszusenden bzw. zu lesen Gar keinen, wenn du Hardware-SPI verwendest. Das macht dann die SPI-Hardware ganz automatisch. Du schreibst nur ein Byte/Wort in das TX-Register, und startest (damit) die Übertragung. Nach der Übertragung kommt dann ein Interrupt, der anzeigt, dass ein Byte/Wort gesendet und empfagen wurde. Erst dann bist du wieder am Zug, holst die daten ab und schreibst neue.....
Was verstehst du denn unter Hardware-SPI? Mein Hardware-SPI hat doch bestimmt auch eine Clock und die muss ja dann auch einiges schneller sein als die SPI-Clock.
> Was verstehst du denn unter Hardware-SPI? Hardware SPI: Du hast eine SPI-Einheit auf dem uC, der du nur Daten zur Übertragung bereitstellst. Software SPI: Du zerrst mit Port-Befehlen selber an den Pins herum, und liest den MISO Pin per Software ein. >>> Ich werde einen Controller nehmen der das SPI Interface integriert hat. Schreib diesen Satz zehnmal an die Tafel: Wenn du einen Controller verwendest, der das SPI-Interface integriert hat, und auf diesem Contoller das integrierte SPI-Interface verwendest, dann benützt du Hardware-SPI. > Mein Hardware-SPI hat doch bestimmt auch eine Clock Das steht im DB zum uC. > die muss ja dann auch einiges schneller sein als die SPI-Clock. Dein uC ist der MASTER und bestimmt damit auch den Takt. Und wenn du mit nur 100 Hz auf dem Bus fahren willst, dann richten sich alle Slaves danach. Es wird niemals ein Slave schneller sein (können). Zum Thema BUS: SPI ist nur ein Schieberegister, das auf mehrere Teilnehmer aufgeteilt ist.
Mir ist schon klar, dass sich die Slaves nach dem Master richten. Aber ich will die Schnittstelle mit 2MHz fahren und würde jetzt gerne wissen, welche Taktfrequenz mein Hardware-SPI bzw. welche Taktfrequenz mein µC haben muss, falls ich eine Software-SPI programmiere. Kann doch nicht so schwer sein die Frage, oder? ;-)
2MHz = 2MBit/s oder ? Wenn ja, dann teile 2MHz durch 8 = 250kHz = 250kByte/s Multipliziere diesen Wert mit der Anzahl der µC-Zyklen, die zum Lesen und speichern (Verarbeiten) eines Bytes notwendig sind. Wenn dies z.B. 50 sind, so ergibt sich als kleinste Takfrequenz für den µC 250kHz * 50 = 12.5MHz. Sind es 100 Zyklen pro Byte, so erhält man 25MHz. Alles klar ? Wolfgang
Was nicht ganz klar ist (zumindest mir nicht) - geht's Dir um die reine Taktrate, oder geht's um die effektive Datenrate fuer laengere Datenpakete? Letztere ist immer niedriger, weil - wenn Du z.B. Daten vom Slave per SPI empfaengst und im uC speicherst, gibt's Pausen zwischen den einzelnen Bytes fuer diese Verarbeitungsschritte. Eine weitere "Kleinigkeit" - welchen uC verwendest Du denn? Atmel AVR verarbeitet einen Befehl pro Takt, Mikrochip PIC aber nur einen Befehl alle 4 Takte (kann dafuer aber viel hoeher Taktfrequenzen fahren). Damit ist ein Atmel auf 4 MHz bei der Datenverarbeitung in etwa so schnell wie ein PIC bei 16 MHz. Zweitens, fuer die Hardware-SPI musst Du das jeweilige Datenblatt lesen. Das gibt dann den Zusammenhang zwischen uC-Taktrate und SPI-Taktrate (und dieses Verhaeltnis ist oft noch verstellbar). Bei Microchip ist glaube ich der schnellste Harware-SPI-Takt 1/4 Prozessortakt, also z.B. 2 MHz mit 16 MHz-Oszillator. Wolfgang
>Kann doch nicht so schwer sein die Frage, oder? ;-)
Deine Fragestellung ist dermaßen chaotisch, bodenlos genial. Vom Bus,
über SPI, über Takte zum Verarbeiten von Informationen.
> Kann doch nicht so schwer sein die Frage, oder? ;-) Diese Frage nach der Frage mal ausnahmsweise nicht, nein. > ... ich will die Schnittstelle mit 2MHz fahren und würde jetzt gerne > wissen, welche Taktfrequenz mein Hardware-SPI haben muss ... So um die 2 MHz vielleicht? Ich bin dann weg hier ;-)
> Multipliziere diesen Wert mit der Anzahl der µC-Zyklen, die zum Lesen > und speichern (Verarbeiten) eines Bytes notwendig sind. Genau diese Anzahl an µC-Zyklen will ich wissen. Denn genau die Rechnung, die du durchgeführt hast, wollte ich auch machen. > Was nicht ganz klar ist (zumindest mir nicht) - geht's Dir um die reine > Taktrate, oder geht's um die effektive Datenrate fuer laengere > Datenpakete? Mir gehts um die effektive Datenrate für längere Pakete, d.h. ich muss nach einem empfangenen Byte dieses auch zwischenspeichern. Verarbeitet wirds erst irgendwann später, was hier wie gesagt nicht betrachtet wird. > Eine weitere "Kleinigkeit" - welchen uC verwendest Du denn? Wird wohl ein STM werden.
> Wird wohl ein STM werden. Ach so, der STM... Haben die nur noch einen uC im Portfolio? > Genau diese Anzahl an µC-Zyklen will ich wissen. Das kann dir nur dein Compilerbauer sagen :-/ Es sein denn du programmierst den in Assembler, dann kannst du selber zählen, wie es Wolfgang Schmidt schon vorgemacht hat.
> Ach so, der STM... > Haben die nur noch einen uC im Portfolio? Wie soll ich Dir denn sagen, welchen STM ich benutze, wenn ich noch nicht mal die nötige Taktrate kenne?
Also die Zyklenzahl fuer einen bestimmten Codeabschnitt (in dem Fall Lesen eines Bytes ueber SPI-Schnittstelle und dann Speichern im internen RAM) kann man nur dann mit vernuenftiger Genauigkeit abschaetzen, wenn man sowohl den verwendeten Mikrokontroller als auch den verwendeten Compiler kennt und den Code geschrieben hat (oder alternativ schon den Assemblercode geschrieben hat). Dann kann man den vom Compiler erzeugten Assemblercode anschauen und Befehle/Zyklen zaehlen (oder den Code im Simulator laufen lassen, der sagt einem ueblicherweise die bisher verbrauchte Zyklenzahl / Ausfuehrungszeit). Wenn Du das nicht schon alles hast, kannst Du leicht um einen Faktor 2 - 100 (ernst gemeint!) daneben liegen. Wie gesagt, schon die Tatsache, dass manche Mikrokontroller 1 Takt pro Befehl brauchen (z.B. Atmel AVR), andere 4 (Microchip PIC), andere bis ueber 11 (8053), macht die Frage nach der TAKTFREQUENZ (in Gegensatz zu Zyklenzahl) ohne genaue Angabe voellig sinnlos - mit derselben Anzahl an Befehlen gibt das schon eine Variation um mehr als den Faktor 10. Dazu kommt, dass unterschiedliche Compiler unterschiedlich effizienten Code erzeugen. Variation um den Faktor 2 ist da schon drin. Dann haengt es davon ab, wie Dein Algorithmus zum Speichern ausschaut. Z.B. kommst Du mit einem 8-bit-Adresszaehler aus, oder musst Du mehr Daten empfangen und brauchst einen mit 16 Bit (auf einem 8-But uC ist das langsamer). Im Zusammenhang damit - 8-bit oder 16-bit-Mikrokontroller (ich bin sicher, STM hat alle beiden Typen im Angebot, so wie die anderen uC-Anbieter auch). RISC oder CISC-Architektur? Dann die Frage - wieviele Bytes schickst Du per SPI, um ein Byte Daten einzulesen? Z.B. 2 - eines fuer den Befehl und eines fuer die Adresse? Davon haengt der effektive Verarbeitungs-Overhead ab. Usw usf.
Nungut, ich bedanke mich für die Antworten. Dann bleibt mir wohl nichts anderes übrig, als das mal auszucoden und zu gucken wie lange das dauert.
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.