Hallo Ich suche einen uC (oder FPGA), der schnell Befehle ausführen kann. Ich habe bisher nur Erfahrungen mit PIC gemacht. Diese können Befehle schnellstens in einer us ausführen, das ist mir aber zu langsam. Kennt jemand einen uC der das schneller kann? Gruss Beni
AT89LP4053. 20 MIPS bei 20 MHz. Gilt für Befehle mit einem Maschinenzyklus. Manche Befehle brauchen 2,3 oder 4 Zyklen (bedeutet aber immer noch 5 MIPS). Schau Dir mal das Datenblatt an.
Also ein Atmel AVR Atmega128 mit 16 MHz braucht je nach Befehl 62.5ns bis 187.5ns. Ist das schnell genug? Ich bin mir aber sicher, dass es auch PICs (igit-igit) gibt, die deutlich weniger als 1 us für einen Befehl brauchen... ;o))
>Also ein Atmel AVR Atmega128 mit 16 MHz braucht je nach Befehl 62.5ns >bis 187.5ns. Call, Ret und Reti brauchen 4 Zyklen.
Gast wrote: > Hallo > Diese können Befehle > schnellstens in einer us ausführen, das ist mir aber zu langsam. Kennt > jemand einen uC der das schneller kann? > > Gruss Beni Wie komste auf 1µS ? des dürften einist nS sein habs ber noch nie schneller versucht des braucht man so selten.
Der PIC24H hat maximal 40 MIPS. Also weitaus mehr als ein ATMega. 8-Bit PICs gehen glaub ich bis 16 MIPS (PIC18) Wenn du es richtig schnell haben willst nimmst halt nen ARM
> Wie komste auf 1µS ? des dürften einist nS sein habs ber noch nie > schneller versucht des braucht man so selten. Steht so im Datenblatt dass die 1us pro Befehl brauchen. Gemessen habe ich das aber noch nie. Danke für die vielen Antworten! Gruss Beni
Noch ne Frage.. Weiss jemand wie es beim HC12 oder HC11 von Motorola (Freescale) aussieht? Da hätt ich schon die Entwicklungsumgebung dazu..
Standard-HCS12 können eine Core-Frequenz bis 50MHz. Musst halt mal in der Parametersuche auf Freescale.com suchen. Ralf
Steht doch im Datenblatt. Musst nur die maximale Befehlsdauer durch die maximale Taktrate teilen. Bei 40 MHz (so läuft mein HC12) dauert ein MUL-Befehl (1 Takt) daher 25ns. Ich glaube die meisten einfachen (ADD...) brauchen so lange. er hat aber auch Befehle die 13 Takte dauern.
Gast wrote: >> Wie komste auf 1µS ? des dürften einist nS sein habs ber noch nie >> schneller versucht des braucht man so selten. > > Steht so im Datenblatt dass die 1us pro Befehl brauchen. Gemessen habe > ich das aber noch nie. Bei 4MHz Taktfrequenz und den alten PICs kommt das hin. Die führen einen Befehl in (min.) 4 Takten aus.
PIC16Fxxx : 2MIPS -> 500ns/instruction PIC18Fxxx : 10-12MIPS -> 83-100ns/instruction PIC24Fxxx : 16MIPS -> 62.5ns/instruction PIC24Hxxx : 40MIPS -> 25ns/instruction PIC30/33F : 35-40MIPS -> 25-29ns/instruction PIC32 : 120DMIPS -> mind. 8.3ns/instruction ..ich staune immer wieder wie die leute glauben, dass die PICs bei der 16er architechtur stehen geblieben sei :-(
Master Snowman wrote: > PIC16Fxxx : 2MIPS -> 500ns/instruction > > ..ich staune immer wieder wie die leute glauben, dass die PICs bei der > 16er architechtur stehen geblieben sei :-( jo grober Richtwert da gibt es ne menge Variationen beim pic16f628a sind es 300ns und beim 16f887 nur 200ns
pototschnig wrote: >Soweit ich weiß braucht zB ein PIC16F84 @ 10Mhz 300ns pro Befehl. Kann nicht sein. Es steht sogar auf Seite1 des 16F84 Datenblatts: Bei 10 MHz ergibt sich eine Taktperiode zu 400ns. Ich dachte immer, die Formel sei jedem klar. FCY=1/(FOSC/4) supachris wrote: >Bei 4MHz Taktfrequenz und den alten PICs kommt das hin. Die führen einen >Befehl in (min.) 4 Takten aus. Allerdings steht in keinem Datenblatt, dass man einen 4MHz-Takt benutzen muss. Gruß, Edson
Für die Auswahl des µC ist auch die Art der zu verarbeitenden Daten entscheidend. Wenn man überwiegend 16/32Bit Daten/Indizes hat oder viel mit Gleitkomma rechnen muss dann ist ein 32Bit Controller hilfreich. Nicht zu unterschätzen ist auch der Geschwindigkeitsvorteil eine 1 Zyklen CISC- gegenüber einem 1 Zyklen RISK-Controller. Für ein Projekt mit viel Gleitkomma Berechnungen benutze ich gerade ein 32Bit ZNEO µC. Da ich das Projekt in seiner ersten Version auf einem ATmega168 realisiert hatte kann ich jetzt einigermaßen vergleichen. Obwohl beide Controller mit 20MHz laufen ist der 32Bit CISC µC rund 4 Mal schneller. Genau kann ich es nicht sagen weil ich beim ATmega überall an der Datenbreite gespart habe während ich beim ZNEO das Meiste mit Gleitkomma rechne. Erstaunlich ist auch der um den Faktor 2 bis 3 kleinere FLASH Verbrauch des 32Bit CISC µC.
>Obwohl beide Controller mit 20MHz laufen ist der 32Bit CISC µC rund 4 >Mal schneller. Komisch, daß Zilog den selber als 16Bit µC bezeichnet...
die 16xxx von Pic können bis 5Mips. Es gibt einige, wie z.B. der 12f509 , welche nur 1Mips können, sowie auch 10Fxxx da es <=8pin sind, und es keinen Sinn macht, einen externen Quarz anzuschließen, was man aber machen kann, sind aber auf Spannung sowie Strohmverbrauch optimiert, und deshalb nur 1Mips. Im 14pin Gehäuse gibt es den gleichen Core, welcher dann wieder 5Mips schafft. Die Pin-Kompatiblen 18f können dann 10Mips. Der 16f84 ist schon seit Ewigkeiten nicht mehr Lieferbar und durch billigere sowie bessere pic Typen ersetzte worden.
Henry wrote: > Erstaunlich ist auch der um den Faktor 2 bis 3 kleinere FLASH Verbrauch > des 32Bit CISC µC. Erstaunlich ist das nicht. Ein CISC kann viele Operationen direkt auf dem RAM ausführen, ein RISC muß dagegen alles erstmal in Register laden. Peter
Die 50Mips/75/100Mips pic heißen Scenix oder jetzt Ubicom. Früher gab es die mit 75 sowie 100 Mips, sind aber mit 12f zu vergleichen, sowie keine interne Peripherie.
chris wrote: > Der 16f84 ist schon seit Ewigkeiten nicht mehr Lieferbar und durch > billigere sowie bessere pic Typen ersetzte worden. Doch als A Variante aber so wie ich das gesehen habe stellen sie momentan alle 16f auf die A Varianten nach und nach um.
chris wrote: > Die 50Mips/75/100Mips pic heißen Scenix oder jetzt Ubicom. Ne, Ubicom wollte mit den kranken SX auch nichts mehr zu tun haben, die hat sich Parallax andrehen lassen. http://www.parallax.com/tabid/248/Default.aspx Ich hatte mich damals glücklicher Weise von den 800,-DM für den Programmieradapter abschrecken lassen. Der Blick auf die spartanische Peripherie und den bescheidenen Befehlssatz hatte mich aber auch stark ernüchtert. Peter
Die A Variante kann aber 5 Mips, auch wenn sie Sauteuer ist, verglichen mit den Pinkompatiblen Nachfolgern.
Ich kenn ja die Anwendung nicht, von daher ists schwer zu sagen, was der Themenstarter wirklich braucht. Vielleicht verrät er uns das mal kurz? Falls alles immer noch nicht genug ist: ARM7. Da gibts hier ja auch schon jede Menge Chips, Tools, Hobbyprojekte und Boards. Und 60MHz ist dort gerademal die unterste Stufe in der Liga.
Arm7 ist doch veraltet. Wenn, dann den Nachfolger Cortex-M3. Die Krücke Arm7 will doch keiner mehr programmieren, der gerade umsteigt. Alleine die nicht deterministische und extrem lange Interruptlatenz ist doch schon ein Trauerspiel, von spurious Interrupts, zwei Befehlssätze... So was von anachronistisch...
OT: Parallax ist nur der US-Distributor von Ubicom. Die 800$ sind ein Wucherpreis. Wenn du ihn programmieren willst, poste ich dir einen 10Euro Schaltplan. Wenn du den Dongle zum debuggen brauchst, 60Euro kostet der.
>Komisch, daß Zilog den selber als 16Bit µC bezeichnet...
@Der Seppel
Der ZNEO hat 14 universelle 32Bit Register für Arithmetik und Pointer.
Von da her bezeichne ich ihn als 32-bitig.
Beim Lesen/Schreiben von FLASH und RAM werden aber immer nur 16 Bit in
einem Takt transportiert.
Ist also Ansichtssache.
Zilog benutzt die Bezeichnung 16 Bit Controller wohl aus
markttechnischen Gründen um den ZNEO vom, gerade in Einführung
befindlichen, ARM9 abzugrenzen. So haben sie 8, 16 und 32 Bit µC im
Programm.
Man merkt dem ZNEO auch seine Nähe zu den 8 Bittern an. Er ist primitiv
wie ein ATmega und wird auch so programmiert. Kein Vergleich zu einem
XMEGA.
> Ich kenn ja die Anwendung nicht, von daher ists schwer zu sagen, was der > Themenstarter wirklich braucht. Vielleicht verrät er uns das mal kurz? Ich muss ein 1.2 Mbps Signal (0.8us/Zeichen) speichern und auswerten. Da ich im Datenblatt vom PIC gelesen habe, dass ein Befehl in einer us ausgeführt wird, wäre der zu langsam gewesen um das Signal zu erkennen und auszuwerten. Aber anscheinend stimmt das ja nicht..
> Ich muss ein 1.2 Mbps Signal (0.8us/Zeichen)
Bist Du Dir sicher, daß Du da nicht etwas durcheinanderbringst? Was ist
ein Zeichen ? Was für ein "1.2 Mbps Signal" ist das?
> Bist Du Dir sicher, daß Du da nicht etwas durcheinanderbringst? Was ist > ein Zeichen ? Was für ein "1.2 Mbps Signal" ist das? Es ist ein 600kHz Signal, also werde 1.2 Megabits pro Sekunde übertragen. Ein Zeichen ist ein Bit, also ein High oder ein Low. Ist irgend ein serielles Signal, was genau weiss ich nicht.
wenn es ein SPI-, I2C- oder ein "RS232"-signal ist, ist's viel einfacher zu verarbeiten, weil der PIC dafür schon eine fertige peripherie hat. es wäre also gut zu wissen, um was für ein signal es sich handelt..
> Ist irgend ein serielles Signal, was genau weiss ich nicht.
Das zu wissen wäre aber äußerst hilfreich, weil sich dann
möglicherweise Hardwareunterstützung zur Decodierung des Signales
verwenden ließe, wie z.B. die UART bei asynchroner Übertragung (mit
Start- und Stopbits) oder meinetwegen auch SPI, sofern es möglich ist,
den Takt zu rekonstruieren.
Wo tritt das ominöse Signal denn auf? Was soll damit geschehen?
> Das zu wissen wäre aber äußerst hilfreich, weil sich dann > möglicherweise Hardwareunterstützung zur Decodierung des Signales > verwenden ließe, wie z.B. die UART bei asynchroner Übertragung (mit > Start- und Stopbits) oder meinetwegen auch SPI, sofern es möglich ist, > den Takt zu rekonstruieren. Ich will eigentlich nur detektieren ob ein Signal kommt oder nicht, daher spielt das Protokoll absolut keine Rolle. UART oder so was ist nicht nötig. > Wo tritt das ominöse Signal denn auf? Was soll damit geschehen? Es ist ein Signal auf einer RS485 Leitung. Aber wie gesagt, will nur wissen ob ein Signal kommt oder nicht, mehr nicht.
> Puffer und LED¿
Will natürlich schon Funktionen ausführen wenn Daten kommen, resp. keine
kommen. Aber mit den Daten selbst will ich nichts machen. Deshalb ein uC
aber kein UART oder ähnliches.
1. nimm einen timer, der dir z.b. alle 2ms einen interrupt auslöst 2. verbinde deine datensignalleitung mit einem intertup-on-change-pin des uC (z.b. interrupt auf steigende flanke) 3. wenn ein ein interrupt aus 2 auftritt, setzt du den timer auf null und zählst eine variable hoch (du wirst zwar nicht alle aufeinanderfolgende flanken detektieren, was aber in deinem fall egal ist). hat die variable einen bestimmten wert erreicht, weisst du, dass daten kommen -> setze ein flag, damit du im normalen code (hauptroutine) weisst, dass du was machen musst. erzeugt der timer aber einen interrupt, dann wird die variable des interrupts aus 2 auf null zurück gesetzt. edit: ggf. musst du, wenn die variable den entsprechenden wert erreicht, den interrupt aus 2 abschalten, damit dieser dir nicht den uC blockiert und du so das machen kannst, was du wolltest, wenn die daten kommen. danach halt wieder einschlaten. so, das ist no meine lösung, die mir spontan in den sinn kommt - wahrscheinlich gibts noch eine bessere...
> Ich will eigentlich nur detektieren ob ein Signal kommt oder nicht, > daher spielt das Protokoll absolut keine Rolle. UART oder so was ist > nicht nötig. Wenn "Signal" bedeutet, daß "an der Leitung gewackelt" wird, dann musst Du überhaupt nicht mit einer hohen Abtastrate arbeiten. Hier würde ein Monoflop genügen, dessen Ausgang an einem simplen Port eines beliebigen µC angeschlossen wird. Die Zeitkonstante des Monoflops ist passend zum Pollzyklus des µC zu wählen, wird am betreffenden Pin beispielsweise im Millisekundentakt nachgesehen, so sollte die Zeitkonstante eben etwa 1 Millisekunde betragen. Ist das Monoflop "retriggerable", wie beispielsweise 74xx123, dann steht dessen Ausgangssignal eine Millisekunde (oder welche Zeitkonstante auch immer) nach der Übertragung des letzten Bits auf der zu prüfenden Leitung an.
Mach einfach ein RC-Glied (Tiefpass) und messe das Signal per ADC. Somit kannst Du Deine Aufgabe ganz simpel mit zwei Zusatzkomponenten (Widerstand und Kondensator) und praktisch jeder Krücke von uC lösen, sogar wenn die CPU mit dem Takt eines 32kHz Uhrenquarzes versorgt würde.
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.