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