www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Verzögerten Puls mit 10ns Zeitauflösung erzeugen


Autor: Dominik R. (drum42)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominik R. schrieb:
> Was sonst
> ?

FPGA.

Autor: Falk Brunner (falk)
Datum:

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

Autor: Dominik R. (drum42)
Datum:

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

Autor: MagIO (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Dominik R. (drum42)
Datum:

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

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Webtools fuer das FPGA kann auch mit einem Schema modus arbeite, 
dabei kann man Zaehler generieren, damit ist man innerhalb eines Tages 
fertig.

Autor: MagIO (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Dominik R. (drum42)
Datum:

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

Autor: Wolfgang Horn (Gast)
Datum:

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

Autor: Ideengeber (Gast)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Dominik R. (drum42)
Datum:

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

Autor: MagIO (Gast)
Datum:

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

Autor: Mehmet Kendi (mkmk)
Datum:

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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: MagIO (Gast)
Datum:

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

Autor: Lukas K. (carrotindustries)
Datum:

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

Autor: Mehmet Kendi (mkmk)
Datum:

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

Autor: MagIO (Gast)
Datum:

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

Autor: MagIO (Gast)
Datum:

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

Autor: Dominik R. (drum42)
Datum:

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

Autor: Mehmet Kendi (mkmk)
Datum:

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

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.