Hallo, mal eine Frage: Ist ein ARM (z.B. der LPC 1769) in der Lage, Signale "auf einen Cycle genau", also ohne Jitter relativ zu seinem eigenen Takt zu erzeugen? Ein AVR (Mega88) kann das doch, richtig? Danke! nicolas
Sicher kann der das. Aber es ist, so wie beim ATmega auch, von der SW abhängig. Aber es wird sicherlich zumindest eine Optimierung in Assembler notwendig sein. Gruß Jobst
Es ist allerdings deutlich schwieriger als bei AVRs, Pins exakt reproduzierbar per Software taktgenau zu steuern, da die Laufzeit von Befehlen nicht exakt festgelegt ist, sondern von Faktoren wie Wartezyklen und Flash-Puffern abhängt und auch von laufendem DMA beeinflusst wird. Wesentlich besser ist es, wenn man solche Tätigkeiten per Timer abwickelt. Es gibt zudem leistungsfähige Controller, die an solche Tätigkeiten weit besser angepasst sind als ausgerechnet ARMs wie LPC1700.
Möchtest Du ein bestimmtes digitales Protokoll per Bitbanging implementieren oder geht es um Signale die sich immer gleich wiederholen - wie z.B. PWM? PWM geht ohne Probleme über die verschiedenen Timer. Schau ins Datenblatt, da ist erklärt was da geht. Auf jeden Fall hast Du bei dem Hardware-PWM einiges Mehr an Möglichkeiten im Vergleich zum AVR. Wenn es um Bitbanging geht: Du kannst eine vordefinierte Bitfolge in den Speicher schreiben und dann per DMA timergesteuert auf die GPIOs schreiben lassen. Damit läuft das vom Timing her exakt nach Deinen Vorgaben. Ich finde letzteres übrigens bei den STM32 besser implementiert, dort kann man mit einem 32Bit-Wort gleichzeitig 16 Bit GPIOs und eine Bitmaske schreiben. Bei den LPC17xx sind Maske und Daten getrennt, die Zugriffe sind daher nicht atomic. Damit ist es schwer auf den selben Port gleichzeitig sowohl per DMA als auch per regulärem Programm zuzugreifen.
Hallo, erstmal vielen Dank für die Antworten! Also, der Controller erzeugt per Timer&Interrupt eine Sequenz von Pulsen. Das funktioniert auch auf einen Cycle genau. Das ganze wird gestartet von einem externen Puls, der einen ext. Interrupt auslöst. Und dieser Interrupt scheint relativ zum auslösenden Puls auf drei Latenzzeiten verteilt, die einige (~10) Cylcles auseinander liegen. Es geht nicht um ein digitales Protokoll, sondern um die Erzeugung einer belieb. Pulssequenz. Schwieriger: Ja, da stimme ich Dir zu! Das mit DMA und Flash-Wait-States dämmert mir auch so allmählich, das muss ich mir nochmal anschauen. Da fehlts noch eindeutig bei mir ;) Im Programm wird allerdings im Moment nichts mit DMA gemacht, und die CPU läuft mit 120MHz. Es ist nichts in Assembler programmiert, rein C. Bitbanging per DMA: Hm, da schau ich dann auch mal rein. Der externe Puls ist allerdings auch nicht in Phase mit dem Controllertakt, das verursacht vermutlich auch min 1 Cycle Jitter. Danke für die Tips! nicolas
Gerd E. schrieb: > Wenn es um Bitbanging geht: Du kannst eine vordefinierte Bitfolge in den > Speicher schreiben und dann per DMA timergesteuert auf die GPIOs > schreiben lassen. Damit läuft das vom Timing her exakt nach Deinen > Vorgaben. DMA wird zwar ASAP ausgeführt, ist aber nicht taktgenau. Der Bus wird ggf. erst frei, wenn der Prozessor ihn freigibt. Folglich hängt die Latenz davon ab, ob grad ein Zyklus läuft und wie lange der dauert.
nicolas schrieb: > geht nicht um ein digitales Protokoll, sondern um die Erzeugung einer > belieb. Pulssequenz. Da könnte SPI in Verbindung mit DMA helfen. Das ist taktgenau, zumindest so schnell wie das SPI-Modul zulässt. Eine Pinfrequenz von 60MHz (120MHz Takt) ist vermutlich sowieso nicht offiziell von der Hardware vorgesehen und auch nicht per Befehle möglich.
zu DMA: "ASAP" ?? Ich hatte mit DMA schon mal gespielt, RAM-Bereich per DAM in den DAC, das klappte super. War halt nur ein einziger DMA-Kanal in Benutzung. Ist das denn Taktgenau, wenn man sicherstellt das kein anderer DMA-Kanal dazwischenfunkt? (eine generelle Frage, ich würde schätzen ja) SPI: Es geht darum, Pulse auf vielen unabhängigen Kanälen zu erzeugen, SPI ist daher nicht so gut geeignet denke ich. Die Pulse müssen auch nicht besonders kurz sein oder kurze Abstände haben, 1 µs reicht völlig. Aber diese Timings sollten eben möglichst präzise stimmen und keinen/möglichst geringen Jitter haben.
nicolas schrieb: > in Benutzung. Ist das denn Taktgenau, wenn man sicherstellt das kein > anderer DMA-Kanal dazwischenfunkt? (eine generelle Frage, ich würde > schätzen ja) Nein. Prozessor und DMA teilen sich einen (oder mehrere) gemeinsam verwendete Busse. Es kann folglich ein paar Takte dauern, bis der DMA dran kommt.
Frank K. schrieb: > Ich denke, Dein Vorhaben lässt sich in einem FPGA deutlich besser > realisieren. Es geht schon mit Controllern, nur nicht ausgerechnet mit den üblichen ARMs. Beispielsweise sind Parallax Propeller und XMOS auf die Erzeugung von taktgenauem Pintiming optimiert.
Hallo, der Jitter, der jetzt da ist, lässt sich verkraften, die gewünschte Spezifikation ist erfüllt. Mir geht es nur darum, ob man da noch was machen kann, und darum das zu verstehen. Man kann das sicher eleganter und vermutlich auch effektiver mit einem FPGA oder anderem Controller lösen. >Nein. Prozessor und DMA teilen sich einen (oder mehrere) gemeinsam >verwendete Busse. Es kann folglich ein paar Takte dauern, bis der DMA >dran kommt. Hm, ok. Aber der Cortex-M3 hat ja diese "Bus-Matrix", kann man das irgendwie erreichen, dass die sich nicht gegenseitig stören, wenn man die Anwendung hinreichend beschränkt? Also quasi jeder seine Leitung benutzt? Ich hatte z.B. eine RAM Bank per DMA an den DAC gesendet, während die CPU etwas auf der anderen RAM-Bank gemacht hat. Und so wie ich das verstanden habe, hat jede RAM-Bank ihren "eigenen" Zugang zu der Bus-Matrix, und CPU und DAC auch. Hmhm, geht das überhaupt grundsätzlich? Grübel... >Da könnte SPI in Verbindung mit DMA helfen. Das ist taktgenau, >zumindest so schnell wie das SPI-Modul zulässt. Eine Pinfrequenz von >60MHz (120MHz Takt) ist vermutlich sowieso nicht offiziell von der >Hardware vorgesehen und auch nicht per Befehle möglich. Bei SPI geht es dann? Danke für die super Unterstützung hier, ich bin immer wieder begeistert! nicolas
nicolas schrieb: > Bei SPI geht es dann? Wenn man per DMA auf GPIO schaufelt, dann wirkt sich das DMA-Timing direkt auf die Pins aus. Nicht jedoch, wenn man per DMA den SPI-Puffer nachfüllt. Das SPI erwähnte ich, als noch nicht von vielen Kanälen die Rede war. Das ist nur bei einem Datenkanal pro SPI praktikabel.
Bleibt die Frage, ob man DMA so benutzen kann, dass es taktgenau z.B. DAC oder GPIO Pins bedient, s.o.
Weiss ich nicht. Dazu müsste ich zu tief in den verwendeten Controller einsteigen. Möglicherweise tiefer als die offizielle Doku hergibt. Da man sich damit auf ein Gebiet begibt, für dass diese nicht wirklich konzipiert sind, würde ich nicht auf erschöpfende Auskunft zu diesem Thema wetten.
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.