Hallo, Ich habe eine eigentlich sehr einfache Aufgabe zu lösen: Es soll nach einem externen Ereignis (Trigger) ein Puls mit einer definierten Verzögerung (1,00µs-2,00000ms) und Dauer (100ns-10,00µS) erzeugt werden. Die Verzögerung soll per PC (RS-232 oder USB) einstellbar sein. Problem: Die zeitliche Auflösung mit die Verzögerung+Dauer eingestelt werden können sollen beträgt nur 10ns-20nS. -ein ATMega ist zu langsam (16MHz->62.5ns). Ausserdem hat der soweit ich das überblicken kann ausser "Bit-Banging" keine Mechanismen mit der man eine zeitliche unsicherheit von nur 1 Takt erreicht. -ein ATXMega ist von Takt schon besser (32MHz->31,25ns), und hat mit dem Event-System auch die möglichkeit den Timer mit einer unsicherheit von einem Takt zurückzusetzen. Die Anforderung von 10-20ns erfüllt er aber noch nicht ganz. Ausserdem ist er natürlich völlig überdimensioniert (Pin-Count etc)... -ein Cortex-M3 oder ein PIC32 wären zwar schnell genug getaktet (50-100MHz--> 10-20ns), sind aber noch überdimensionierter. Ausserdem kenn ich mich mit denen nicht aus und es scheint mir das spziell der M3 eine längere Einarbeitungszeit erfordert. (Ich will doch nur einen Puls ;-) ) Hat irgendjemand eine idee für eine (relativ einfache) Lösung dieses Problems ? Ist ein MC überhaupt für so eine Aufgabe geeignet ? Was sonst ? vielen Dank im vorraus für eure Antworten...
@ Dominik R. (drum42) >Hat irgendjemand eine idee für eine (relativ einfache) Lösung dieses >Problems ? CPLD oder FPGA mit 100 MHz Takt. > Ist ein MC überhaupt für so eine Aufgabe geeignet ? Nein, ausser vielleicht Spezial-ICs. MfG Falk
Hmm, an ein CPLD hatte ich auch schon gedacht. Hab auch mal ne doku von einem geeigneten Baustein angesehen, aber bei VeriLog etc. aufgehört zu lesen... wollte eigentlich keinen eigenen Chip designen, da brauch ich doch sicher ein Paar Monate bis ich mich eingearbeitet hab´, oder ?
Sehr einfache Geschichte mit dem Propeller! Der lässt sich auch mit 100MHz betreiben. Es gibt Instruktionen, die auf einen bestimmten Zustand des Ports warten (der Impuls), Instruktionen, die auf einen taktgenauen Wert eines internen Takt-Zählers warten (die Verzögerung) und für den Impuls kann man einen frei definierbaren counter benutzen, der dann bei 100MHz auch eine Auflösung von 10ns hat. Ein anderer COG kümmert sich dann um das serielle Interface. Die Programmierung für das Problem ist sehr einfach und auf jeden Fall einfacher, als wenn man sich neu mit CPLD oder FPGAs auseinandersetzen müsste.
@ Dominik R. (drum42) >Hmm, an ein CPLD hatte ich auch schon gedacht. Dann hast du richtig gedacht. >wollte eigentlich keinen eigenen Chip designen, Das dürfte 99,999% der Forumsteilnehmer überfordern, mich eigeschlossen ;-) > da brauch ich doch > sicher ein Paar Monate bis ich mich eingearbeitet hab´, oder ? Nein, du sollt ihn ja "nur" programmieren. Wenn du 2ms mit 10ns Auflösung per Zähler verzögern willst, brauchst du 200.000 Schritte. Das sind ~18 Bit. Kann man bei 100 MHz nicht mehr ganz so einfach hinschreiben, kriegt man aber mit Pipelining hin. Lange Rede, Kurzer Sinn, nimm einen FT232 + AVR, die machen die Kommunikation zum PC. Der AVR gibt den Sollwert per SPI an den CPLD vor, ist ein einfaches Schieberegister, schafft man als Anfänger in 1 Tag. Dann ein etwas aufwändigerer Zähler, fertig. Worst Case für einen Anfänger 2 Wochen würde ich schätzen. MfG Falk
@Falk: Hmm, klingt ja doch nicht so erschreckend wie ich gedacht habe... mein erster Post war übrigens etwas verkürzt, die 10ns sind nur bei verzögerungen bis 200µs erforderlich, bei 2ms reichen 100nS (ür die Verzögerung) --> nur 20000 Stufen nötig, also reichen schon 15bit+umstellmöglichkeit für den Takt des CPLD auf 1/n*100MHz.(n=1..16) @MagIO: beim Propeller war ich etwas skeptisch wegen des Herstellers, der vorgänger SX wurde ja einfach so abgekündigt. Scheit eine relativ kleine kaschemme zu sein. Trozdem werde ich mir die Specs wohl nochmal ansehen, als alternative zum CPLD. Vielen Dank für eure Antworten....
Das Webtools fuer das FPGA kann auch mit einem Schema modus arbeite, dabei kann man Zaehler generieren, damit ist man innerhalb eines Tages fertig.
Der SX wurde von Parallax nicht selbst entwickelt/produziert und wurde vom Hersteller abgekündigt. Dagegen konnte Parallax nix unternehmen. Der Propeller ist dagegen eine Eigenentwicklung und Parallax lässt den in Auftrag fertigen. Solange also der Herstellungsprozess an sich Verfügbar ist, wird es nach Aussage von Parallax auch Propeller geben! Zum ausprobieren reicht ein Quarz (6.25MHz um auf 100MHz internen Takt zu kommen), ein Steckbrett und ein USB 2 serial Interface (ich habe mit einem 10€-Teil vom C angefangen).
Dominik R. schrieb: > Hmm, klingt ja doch nicht so erschreckend wie ich gedacht habe... Die avisierten 2 Wochen von Falk sind m.E. für einen blutigen Anfänger schon sportlich, wenn der wie du bisher offenbar "nur" mit uCs zu tun hatte... Das klappt nur mit aktiver Hilfestellung in der Zeit. Der logische nächste Schritt wäre, gleich die serielle Schnitte mit aufs CPLD zu packen... ;-) http://www.lothar-miller.de/s9y/categories/49-RS232-IO Ein Oschi schrieb: > damit ist man innerhalb eines Tages fertig. Ich schaff das in 2 Stunden incl. Simulation... :-o
Dann hab ich jetzt ordentlich zu tun... in CPLD und Propeller oberflächlich einarbeiten um festzustellen was mir geeigneter erscheint... aber besser 2 Lösungen als gar keine ;-) Danke für eure Hilfe, Dominik
Dominik R. schrieb: > Es soll nach einem externen Ereignis (Trigger) ein Puls mit einer > definierten Verzögerung (1,00µs-2,00000ms) und Dauer (100ns-10,00µS) > erzeugt werden. > Die Verzögerung soll per PC (RS-232 oder USB) einstellbar sein. Hi, Dominick, googele mal unter "variable delay line". Ich kenne keine, die 1us bis 2ms abdeckt, aber mit einer Kombination von Schaltungen sollte das schon klappen. Nebenbei sinniere ich gerade, in einen Timer-IC wie NE555 oder seine CMOS-Variante den Strom eines D/A-Wandlers einzuspeisen. Ciao Wolfgang Horn
Es gibt Microcontroller, bei denen man einen Timer asynchron schneller als den internen CPU-Takt takten kann, so gar bei bestimmten AVRs, wenn ich mich richtig erinnere. Allerdings sind 100 MHz natürlich schon sportlich für ein kleinen Feld-Wald-Wiesen MCU...
Hier sind 2 Forderungen zu erfüllen: Die Länge des Pulses und die Verzögerung nach dem Trigger und beide müssen auf 10ns genau sein. Soweit mir bekannt gibt es unter den AVRs mit synchronem gegenüber dem Core vervielfacht arbeitenden Timer keinen, der beides hergibt. Zusätzlich sollte man bei Controller-Lösungen auch ein Auge auf die maximale Pingeschwindigkeit werfen. Die ist nicht selten geringer als von der Logik her möglich. Eine Controller-Alternative zum Propeller wäre möglicherweise die dazu entfernt verwandte und hardwareseitig wenig komplexe aber erheblich schnellere XMOS-Familie. Nur dass die ganz offiziell mit 400MHz Takt und 100MHz Befehlszyklus arbeiten, also nicht übertaktet werden müssen.
@ Ideengeber Hast du vielleicht eine ahnung welcher (ungefähr? ATMega ?). Danach hab ich nämlich auch schon geschaut aber nix derartiges gefunden. Die µCs die ich gefunden hab synchronisieren auch bei externem Takt mit dem Internen, und dann darf der externe Takt nur 1/2 des internen betragen. @ A.K. Den XMOS kannte ich ja nun gar nicht.. muss ich erstmal sacken lassen (sprich doku lesen). Welcher AVR hat denn Timer die mit vervielfachtem Takt arbeiten ? hat da einer >50MHz ? der XMega hat nur eine "HiRes" einheit die mit CPU-Takt*4 läuft. Das funktioniert aber nur für "internes" PWM, da sich der Timer nur "normal" über die I/O pins starten lässt, die nur mit 1*CPU-Takt gesampled werden.
XMOS ist auch nicht schlecht, aber oversized. Der Einfache wird nicht reichen, da sich die threads den Prozessor teilen, so wie ich das verstanden habe. Damit kann XMOS zwar die minimale Leistung per Thread garantieren, heißt aber auf der anderen Seite eben auch, dass einzusätzlicher Thread die Leistung die für andere Threads zur Verfügung steht schmälert. Da ist dann nix mit seriellem Interface UND Verzögerung gleichzeitig ... Ok, ich gebs zu, ich hab nur mal flüchtig was an XMOS specs gelesen und das ist auch schon ne Weile her. Könnte darum auch nicht ganz richtig sein wenn das mit 400MHz -> 100MHz gemeint war. Aber ich lese das erst mal so, dass 100MHz der Befehlszyklus ist und bei 2 Threads dann "nur" noch 50MHz pro Thread übrig bleiben. Beim Propeller ist das anders. Hier hat jeder Prozessor-Kern die vollen 20MIPS. Wobei die Äuflösung mit der Instruktionen warten können nicht an die Befehlszyklen, sondern wirklich an den Takt gebunden sind. Es ist zwar richtig, dass die ursprüngliche Spec für den Propeller nur einen 5MHz-Quarz vorsieht (mit interner PLL x16 wird daraus dann 80MHz), aber selbst Parallax nutzt den Propeller offiziell mit 6,25MHz und 16fach PLL = 100MHz. Es hat sich herausgestellt, dass das Chip-Design besser war, als geplant und es gibt keinen Propeller, der mit dieser Taktung je Probleme gemacht hat. Deshalb würde ich dabei nicht von Übertakten reden.
MagIO schrieb: > heißt aber auf der anderen > Seite eben auch, dass einzusätzlicher Thread die Leistung die für andere > Threads zur Verfügung steht schmälert. Soweit ich mich erinnere, kommt es erst ab dem 4. Thread zu einer Minderung der Leistung.
Ideengeber schrieb: > Es gibt Microcontroller, bei denen man einen Timer asynchron schneller > > als den internen CPU-Takt takten kann, so gar bei bestimmten AVRs, wenn > > ich mich richtig erinnere. Attiny 25/45/85: 32 bzw. 64 MHz. Das betrifft aber nur den Timer1 im asynchronen Modus. Die Ausgabe auf einen Port geschieht dann wieder synchron zum CPU-Takt. mfg.
@mehmet: Eben ... beim großen XMOS. Der hat 4 kerne und kann damit 4 Threads ohne Einbuße ausführen. Pro Kern kann man dann noch mal 4 Threads ausführen. Der kleine XMOS hat nur einen Kern und damit wird die Leistung eben sofort aufgeteilt.
Wenn du zu faul bist dich mit CPLDs/Propeller zu beschäftigen und Stromverbrauch und Platz keine Rolle spielen, kannst du das Problem auch mittels TTL-Grab lösen. Ist zwar ein wenig aus der Mode gekommen, wäre aber IMHO am einfachsten.
MagIO schrieb: > Eben ... beim großen XMOS. Der hat 4 kerne und kann damit 4 Threads ohne > Einbuße ausführen. Ist schon eine Weile her, dass ich mit diesen Prozessoren geliebaeugelt habe. Und soweit ich in Errinnerung habe: Der XS1-L1 ist z.Bsp. so ein 1 Kern Prozessor. Trotzden kann er bis zu 8 Threads ausführen. Und erst ab Thread 4 kommt es zu einer Leistungsminderung.
Zitat xs1_Architecture document: "The threads in an XCore are intended to be used to perform several simultaneous real-time tasks such as input-output operations, so it is important that the performance of an individual thread can be guaranteed. The scheduling method used allows any number of threads to share a single unified memory system and input-output system whilst guaranteeing that with n threads able to execute, each will get at least 1=n processor cycles. In fact, it is useful to think of a thread cycle as being n processor cycles."
Copy und Paste aus dem PDF heraus hat aus 1/n ein 1=n gemacht. Also ... 1 thread hat höchstens 1/n an instruktionszyklen ... MINDESTENS ... ein Thread kann natürlich darauf verzichten, dann werden die nicht benötigten Zyklen auf die anderen Threads aufgeteilt.
@Thomas Eckmann die 64MHz klingen erstmal gut, hab grad in die Doku gesehen, 8-Bit Timer ist zwar etwas nervig aber ansonsten passt der tiny eigentlich gut in mein Beuteschema. Aber das mit der Synchronisierung der Ausgänge mit dem CPU-Takt könnte die eignung wieder zunichte machen... wenn die Angabe in der Doku auf S.99 "-1 CLK" als "bis zu 1 Takt" zu interpretieren ist ist die Zeitauflösung ja wieder hin... Ich verstehe allerdings nicht wozu der tiny dann überhaupt einen 64MHz-Zähler hat wenn die Ausgänge dann doch wieder einen Jitter von 1/20MHz haben. Das bedeutet doch das ich die Zeit zwar fein einstellen kann aber dann noch ein Fehler von 0-1 CPU-Takten hinzu kommt, oder sehe ich das Falsch ? wie gesagt, eine deterministische Verzögerung von ein paar CPU-Takten wäre wurscht (geht im Delay unter), aber jeder nicht-deterministische Jitter ist ein Problem... Dominik
@MagIO Hab nochmals ins Datenblatt geguckt. Du hast recht. Hatte mich in der Vergangenheit mit der G4 Serie beschaeftigt, was der Grund dafür zu sein scheint, dass in meinem Kopf die Sache mit den 4 Threads herumspukte. Danke für die Richtigstellung.
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.