www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik schneller uC


Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm nen AVR.

bei einem Befehl pro Takt und 20Mhz Taktfrequenz bist du so bei 50ns pro 
Befehl.

Autor: jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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))

Autor: jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also ein Atmel AVR Atmega128 mit 16 MHz braucht je nach Befehl 62.5ns
>bis 187.5ns.

Call, Ret und Reti brauchen 4 Zyklen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
XMega bei 32Mhz -> 31,25ns

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Silabs haben 8051-Cores mit 100MIPS.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ne Frage..

Weiss jemand wie es beim HC12 oder HC11 von Motorola (Freescale) 
aussieht? Da hätt ich schon die Entwicklungsumgebung dazu..

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Standard-HCS12 können eine Core-Frequenz bis 50MHz. Musst halt mal in 
der Parametersuche auf Freescale.com suchen.

Ralf

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiß braucht zB ein PIC16F84 @ 10Mhz 300ns pro Befehl.

MfG
Thomas Pototschnig

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Seppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Obwohl beide Controller mit 20MHz laufen ist der 32Bit CISC µC rund 4
>Mal schneller.


Komisch, daß Zilog den selber als 16Bit µC bezeichnet...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die A Variante kann aber 5 Mips, auch wenn sie Sauteuer ist, verglichen 
mit
den Pinkompatiblen Nachfolgern.

Autor: DG3YEV (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Seppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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..

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Skua C:\> (skua)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Puffer und LED¿

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.