Ich suche nach einem Mikrocontroller, der möglichst schnell seine Pins schalten kann, um damit eine Sequenz (1024Samples) von 16Bit breiten Daten auszugeben. Hab mit mal ein paar DDS-Anwendungen mit dem AVR angesehen, aber ich bräuchte eben eine Möglichkeit, 16Bit auf einmal zu schreiben und das Ganze sollte auch noch mindestens doppelt so schnell gehen wie mit dem kleinen AVR. Welcher >=16Bit Controller mit einem durchgehenden 16Bit breiten Ausgabeport kann seine Pins am schnellsten schalten? Andere Anforderungen sind nebensächlich.
>Welcher >=16Bit Controller mit einem durchgehenden 16Bit breiten >Ausgabeport kann seine Pins am schnellsten schalten? Kann man bei richtiger Antwort etwas gewinnen? Schnelle Datenausgaben macht man mit einem Prozessor, der einen schnellen ext. Datenbus sowie DMA bietet. Renesas hat schöne Teile; aktuell wird der RX62N beworben, der 16Bit Daten mit 25MHz ausgeben könnte. Vielleicht reicht Dir aber auch schon ein H8SX oder SH2A Prozessor :-) Aber ich bin mir sicher, dass Du das garnicht brauchst.
> Vielleicht reicht Dir aber auch schon > ein H8SX oder SH2A Prozessor :-) Ich muss aber sagen das ich gerade an diesem Punkt vom SH2A etwas entaeuscht war. Man muss sich klar maches das es fuer IO-zugriffe halt noch einen eigenen Takt gibt und es dazwischen wohl noch Reibungsverluste. Gut, vermutlich will man auch garkeinen Prozessor der Daten mit 144Mhz ausgeben kann und wo alle Datenleitungen auch so schnell geschaltet werden. Aber schon mein alter Proffessor sagte: Wollt ihr es schnell, macht es seriell. Da seht ihr mal das auch Nachrichtentechniker eine poetische Ader haben. Olaf
>Ich muss aber sagen das ich gerade an diesem Punkt vom SH2A >etwas entaeuscht war. Für die hier geforderte Geschwindigkeit reicht es allemal, ist aber nicht dafür konstruiert, spinnerte Ideen umzusezen. Es gibt diverse transfer-modi u.a. auch den burst-Modus, bei dem die CPU dem ext. Bus nicht reinreden kann. Der single-address-mode schaufelt Daten gleich vom SRAM per EDACK ins ext. Device.
Hallo, nimm doch ein s.g. Dual Port Ram und deinen Standard uC. Oder ein 16bit FIFO, sowas wie MS81V10160, für 1024 Samples reicht das doch mfg Rene
Der MSP430F5438 ist in der Lage, zwei 8-Bit-I/O-Ports zu einem 16-Bit-I/O-Port zusammenzufassen und mit einer Maschineninstruktion ein 16-Bit-Datenwort auszugeben. Er kann zwar mit 25 MHz getaktet werden, braucht aber mehrere Taktzyklen für seine Maschineninstruktionen. Es ist allerdings auch ein DMA-Controller vorhanden, der die Angelegenheit beschleunigen könnte. Mit 256 kiB Flash-ROM und 16 kiB RAM ist er für einen MSP430 auch recht großzügig mit Speicher ausgestattet.
bis jetzt hat er noch nicht gesagt, wie schnell er wirklich die Samples ausgeben will. Wenn es im NF-Bereich bleibt, sollte es wohl noch mit einem AVR machbar sein. Mit 16/20MHz sollten sich wohl einige 10kHz Takt für die Ausgabe realisieren lassen.
>bis jetzt hat er noch nicht gesagt, wie schnell er wirklich die Samples >ausgeben will. Das ist doch völlig nebensächlich. Er will den schnellsten Prozessor dafür :-)
Jens G. schrieb: > bis jetzt hat er noch nicht gesagt, wie schnell er wirklich die Samples > ausgeben will. Naja, er will bei 16 Bit Auflösung eine Periode in 1024 Samples rastern. Wenn da noch etwas Frequenz rauskommen soll, dann braucht man schon Sampletraten, die der AVR nicht mehr schafft. > Wenn es im NF-Bereich bleibt, sollte es wohl noch mit > einem AVR machbar sein. Mit 16/20MHz sollten sich wohl einige 10kHz Takt > für die Ausgabe realisieren lassen. 10 kHz Ausgabe-Takt sind bei 1024 Samples pro Periode aber nur knapp 1 kHz Ausgangsfrequenz. Da ich nicht weiß, wozu der Generator dienen soll, halte ich mich auch mit dem Tip zurück, dass für die meisten Zwecke 8 Bit bei 64 bis 256 Samples pro Periode ausreichen sollten. ;-) ...
Luky schrieb: > und das > Ganze sollte auch noch mindestens doppelt so schnell gehen wie mit dem > kleinen AVR. Hab ich gesagt. Haben nur einige nicht gelesen... Der AVR ist zudem ungeeignet, da er die 16Bit nicht auf einmal schreiben kann. In der Zeit zwischen den Ausgaben liegt daher ein falsches Signal an. Also ist ein Zwischenbuffer mit enable notwendig, was die Sache nochmals langsamer macht.
Hannes Lux schrieb: > 10 kHz Ausgabe-Takt sind bei 1024 Samples pro Periode aber nur knapp 1 > kHz Ausgangsfrequenz. Nein, er will ja DDS. Damit kann man höhere Frequenzen als 1kHz ausgeben, braucht aber ein gutes Filter dahinter. In der Praxis gehen, soweit ich das verstanden habe, ungefähr 40% der Frequenz des Phasenakumulators noch gut. Man berichtige mich, wenn ich mich da irre. mfg mf
Ich will keinen DDS bauen, sondern eine vorher eingelesene Testdatensequenz abspielen. Der Prototyp läuft auf einem Atmrga32, die Geschwindigkeit und die Auflösung sind aber zu gering. Also 12-16Bit Datenbreite und >2x Geschwindigkeit als Avr mit asm.
In CPLDs einarbeiten möchte ich mich eben nicht unbedingt. Der µc muss nebenbei zudem noch andere Dinge steuern (nicht zeitgleich) und so viel mehr Geschwindigkeit brauche ich ja nicht. Wie schnell sind die kleinen ARM (STM32, LPC, Stellaris, ...) beim Portzugriff?
>> Ganze sollte auch noch mindestens doppelt so schnell gehen wie mit dem >> kleinen AVR. Was bedeutet das genau? Wieviele 16-Bit Werte pro Sekunde?
Angehängte Dateien:
-
STM32Toggle.png
6,7 KB
Luky schrieb: > Wie schnell sind die kleinen > > ARM (STM32, LPC, Stellaris, ...) beim Portzugriff? Zum STM32 (72MHz, 2WS) kann ich mal das berühmte Pin-Toggeln liefern. Folgender Code wurde ausgeführt: while (1) { GPIOA->BSRR = GPIO_Pin_9; GPIOA->BRR = GPIO_Pin_9; } Da ein 16Bit zugriff genauso lang dauern dürfte, wird die Ausgabe eines 16Bit Worts auch 28ns dauern. Sinnvoller wäre natürlich, das per DMA machen zu lassen, dann könnten wohl schon so 70MByte/s drin sein...
STM32 sieht gut aus, genau das was ich gesucht habe. Danke an alle die die Fragestellung gelesen haben ;-)
>Da ein 16Bit zugriff genauso lang dauern dürfte, wird die Ausgabe eines >16Bit Worts auch 28ns dauern. Du lieferst ein gutes Beispiel für Schönrechnerei. Ich sehe als Periodendauer 3 x 28ns. Du solltest auch ein Bild zeigen, wo ein Interrupt zwischen SET- und CLEAR-Befehl eintrifft :-)
>Ich will keinen DDS bauen, sondern eine vorher eingelesene >Testdatensequenz abspielen. Der Prototyp läuft auf einem Atmrga32, die >Geschwindigkeit und die Auflösung sind aber zu gering. Also 12-16Bit >Datenbreite und >2x Geschwindigkeit als Avr mit asm. Sag doch endlich mal, wieviel pro Sekunde da rauskommen sollen? Vielleicht ist ja auch Dein Code höchst unglücklich geschrieben, daß da nicht viel rauskommt.
@ Jens G. (jensig) >>Geschwindigkeit und die Auflösung sind aber zu gering. Also 12-16Bit >>Datenbreite und >2x Geschwindigkeit als Avr mit asm. >Sag doch endlich mal, wieviel pro Sekunde da rauskommen sollen? Um Gottes Willen, NEIN! Willst du diesen schönen Thread so jäh beenden, indem der OP einfach mal eine klare Aussage mit Zahlen macht? Das will nun wirklich niemand . . .
Es ist sehr typisch für dieses Forum, dass nicht versucht wird, einfache Fragen zu beantworten und damit anderen Leuten wirklich weiterzuhelfen, (Ausnahme Hannes S. , der jedoch dafür angegriffen wird (!) ) sondern die Projekte anderer schlechtzureden und Lösungen aus dem eigenen Erfahrungsbereich aufzuschwatzen. Ich hatte ja noch Glück, dass niemand mit Warnhinweisen wie wahnsinnig gefährlich dass sein kann gekommen ist ;-) Nein, ich wollte KEIN CPLD/FPGA/externe FIFO etc. sonst hätte ich wohl nach einem CPLD/FPGA/externe FIFO gefragt und NICHT nach einem Mikrocontroller. Und für alle Zahlenfetischisten unter euch: Ich habe auch keine konkreten Geschwindigeitsanforderungen hingeschrieben, da ich diese nicht habe. Es handelt sich um Testequipment und da lautet die Devise halt "so gut es geht". AVR war knapp zu langsam, also ergibt sich die Anforderung nach einer größeren Geschwindigkeit bei der Portausgabe als ein AVR. Viel mehr ist schön, irgendwann lohnt sich der Aufwand aber nicht mehr. So, das wars. Für alles weitere gilt: Don't feed the falk :-D
>(Ausnahme Hannes S. , der jedoch dafür angegriffen wird (!) )
Das hast Du falsch verstanden.
Du hast überhaupt nichts verstanden!
Das der STM32 den DMA nicht auf I/O Ports anwenden kann ist schon schade. Das bremst ungemein. Allerdings finde ich die Idee ein externes FIFO zu verwenden sehr elegant. Oder ein Ram, einen Oszillator und einen Zähler um die Adressen schnell genug durchzuklappern. Gerade wenn das Muster konstant bleibt geht das dann beliebig schnell. Der uC lädt die Daten rein und gibt ein enable, der Rest läuft autonom. Schnell, reproduzierbar und der uC hat Zeit wichtigeres zu machen. Teuer ist es auch nicht.
Luky schrieb: . . . > Und für alle Zahlenfetischisten unter euch: Ich habe auch keine > konkreten Geschwindigeitsanforderungen hingeschrieben, da ich diese > nicht habe. Es handelt sich um Testequipment und da lautet die Devise > halt "so gut es geht". AVR war knapp zu langsam, also ergibt sich die > Anforderung nach einer größeren Geschwindigkeit bei der Portausgabe als > ein AVR. Viel mehr ist schön, irgendwann lohnt sich der Aufwand aber > nicht mehr. Da hätten wir ja die Zahlen. Wenn du jetzt noch angeben würdest, wie schnell dein Signal JETZT getaktet wird, wäre "min. doppelt so schnell" schon recht präzise ausgedrückt. Theoretisch wäre etwa folgendes mit eine AVR machbar: 2x ld r17:r16, Z+ (4) 2x out PORTX, rx (2) Macht sechs Takte pro Sample bei ausgerollter Schleife. Bei nachgeschaltetem Latch für synchrone Ausgabe noch +2, mit Aufsplittung in 4 Blöcke à 256 Samples nochmal +2/+3 (bei geringem Jitter). Wären dann bei 20MHz Clock immerhin ca. 2MHz Ausgabe. Wie viel hast du jetzt? Ausserdem brauchst dich nun wirklich nicht über fehlende Lösungsvorschläge zu beklagen, für so eine unscharfe Fragestellung erhieltest du erstaunlich viele: Reneseas-Teile, MSP430, STM32, externer Speicher, FPGA/CPLD, usw. Dass Fragesteller zentrale Angabem zum Problem partout nicht preisgeben wollen ist übrigens auch sehr typisch für dieses Forum, du bist damit also nicht alleine.
Luky schrieb: > Es ist sehr typisch für dieses Forum, dass nicht versucht wird, einfache > Fragen zu beantworten und damit anderen Leuten wirklich weiterzuhelfen, > (Ausnahme Hannes S. , der jedoch dafür angegriffen wird (!) ) sondern > die Projekte anderer schlechtzureden und Lösungen aus dem eigenen > Erfahrungsbereich aufzuschwatzen. Ich hatte ja noch Glück, dass niemand > mit Warnhinweisen wie wahnsinnig gefährlich dass sein kann gekommen ist > ;-) Du hast es aber auch nicht geschafft, eine einfache Frage zu beantworten. Ich finde den Vorschlag mit einem externen SRAM nicht schlecht, aber ich glaub das ist wohl zu schnell...
5V ± 10% SUPPLYVOLTAGEin READ OPERATION FAST ACCESS TIME: 35ns <---------------- LOW POWER CONSUMPTION: – Active Current 35mA at 5MHz – Standby Current 100mA PROGRAMMING VOLTAGE: 12.75V ± 0.25V PROGRAMMINGTIME: 100ms/byte (typical) Nennt sich M27C1024 und du kannst eine 64K Sequenz einprogrammieren (x16 Bit busbreite). Davor noch einen schnellen Zähler an die Adressleitungen das war's. mar IO schrieb: > ich finde den Vorschlag mit einem externen SRAM nicht > schlecht, aber ich glaub das ist wohl zu schnell... Ist das gleiche nur ladbar. Und Sram nennt sich Sram weil es statisch ist (Takt >= 0Hz)
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.