schneller uC

nimm nen AVR.

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

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.

Silabs haben 8051-Cores mit 100MIPS.

> 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

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

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.

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.

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

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

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

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.