Hallo! Frage: Kann man mit einem kleinen ARM-Mikrocontroller eine zeitkritische Impuls-Ausgabe bewerkstelligen ? Ich bräuchte das um VGA-Synchronsignale (30-40 kHz) zu erzeugen sowie eine zugehörige Pixelclock (12 MHz) an/auszuschalten. Die ARM scheinen ja alle Cache und Pipeline zu haben daher weiss man nie so genau wieviel Nanosekunden so eine Befehlsfolge braucht. Kann man vielleicht mit Interrupts etwas genaueres erreichen oder gibt es andere Kniffe ?
:
Bearbeitet durch User
Es gibt ARMe ohne ausgefeiltes Cachemanagement, und VGA-Timing sowie einen so langsamen Pixeltakt kann sogar ein 8-Bit-AVR erzeugen. http://www.jcwolfram.de/projekte/avr/ax81/main.php zeigt so etwas zusammen mit einem ZX81-Emulator. Letztlich: Ja, sollte auf jeden Fall gehen, sofern Du nicht einen "fetten" High-Performance-ARM verwendest.
Mit Timer/DMA Synchronisation geht das vielleicht sogar in Hardware. Durch Abschalten der Caches oder Ausführung im RAM kann man eine deterministische Laufzeit erreichen. Oder du lässt VGA ganz sein und benutzt zB einen STM32F7 welche direkt in Hardware große LCD's ansteuern kann. Vielleicht ist es sogar möglich mit einem externen DAC dieses Signal auf VGA umzubauen...
> Die ARM scheinen ja alle Cache und Pipeline zu haben Welche man bei den mir bekannten ARM's (STM32F1) deaktivieren kann. Dann musst du allerdings auch mit geringerer Taktfrequenz arbeiten - meist im Bereich zwischen 20 und 30Mhz. Das ist einfach das Limit der Flash Speicher. Oder man kopiert den kritischen Code-Teil ins RAM (daür gibt es auch eine Compiler direktive beim gcc), das kann immer mit der vollen Taktfrequenz arbeiten. > Kann man vielleicht mit Interrupts etwas genaueres erreichen Nicht wirklich, denn Interruptroutinen müssen auch aus den Flash geladen werden und außerdem wird immer mindestens der gerade ausgeführte Befehl zuende gebracht, bevor die ISR angesprungen wurd. Die muss dann aber einige CPU Regsister sichern, bevor DEIN Code ausgeführt wird. Das dauert alles seine Zeit. Ist machbar, aber macht es nicht einfacher. Signale im kHz Bereichn kannst du locker mit gängigen 8bit Controllern erzeugen. Die ATMega Controller kannst mit mit 20Mhz takten und sie erzeugen Signale bis zu 10Mhz. Die Xmega Serie kann sogar mit 32Mhz getaktet werde - ohne Cache und ohne Pipeline. 1 Takt pro Befehl (mit wenigen Ausnahmen). Mir ist nicht klar, was du mit dem Pixeltakt vor hast. Willst du den nur ein/aus schalten ohne das Signal selbst zu verändern oder gar zu erzeugen? Das müsste dann ja mit einem simplen Logikgatter gehen. Spannend wäre hier, wann genau du es denn ein- und wann du es ausschalten willst.
Stefan U. schrieb: >> Die ARM scheinen ja alle Cache und Pipeline zu haben > > Welche man bei den mir bekannten ARM's (STM32F1) deaktivieren kann. Dann > musst du allerdings auch mit geringerer Taktfrequenz arbeiten - meist im > Bereich zwischen 20 und 30Mhz. Das ist einfach das Limit der Flash > Speicher. Das ist bei den preisgünstigen STM32ern der Fall, andere Hersteller bieten da mehr. Bei den Cortex-Ms bis 50MHz ohne Waitstates, bei anderen Controllern wie Renesas RX600 auch schon mal 120MHz ohne WS. > Oder man kopiert den kritischen Code-Teil ins RAM (daür gibt es auch > eine Compiler direktive beim gcc), das kann immer mit der vollen > Taktfrequenz arbeiten. Das macht man entweder manuell oder konfiguriert das über das Linkerskript. >> Kann man vielleicht mit Interrupts etwas genaueres erreichen > > Nicht wirklich, denn Interruptroutinen müssen auch aus den Flash geladen > werden und außerdem wird immer mindestens der gerade ausgeführte Befehl > zuende gebracht, bevor die ISR angesprungen wurd. Die muss dann aber > einige CPU Regsister sichern, bevor DEIN Code ausgeführt wird. Nicht ganz richtig, der Prozessor sichert die wichtigsten Register selber. Daher kann man auf das Sichern in der ISR verzichten, wenn man darin keine weiteren Register nutzt.
> der Prozessor sichert die wichtigsten Register selber.
Ja, ich wollte damit sagen, dass auch das seine Zeit braucht.
Also AVR wird ja meist für soetwas empfohlen, da schnell und berechenbare Ausführungszeit. Übrigens soll die Pixelclock nicht vom Mikrocontroller erzeugt werden, sondern nur gestartet bzw angehalten werden. Erzeugt wird die Pixelclock von einem externen ladbaren 16-Bit-Zähler. Ich muss nämlich 2 VGA-Zeilen aufdoppeln also muss ich nach jeder Zeile die Pixeladresse um 200 (Zeilenbreite) zurückstellen. Da ich wohl sowieso irgendwann auf ARM zugehen muss dachte ich dass ich gleich damit was machen könnte. Eigentlich könnte das auch ein etwas flotterer 8051 machen :-)
H-G S. schrieb: > Ich bräuchte das um VGA-Synchronsignale > (30-40 kHz) zu erzeugen sowie eine zugehörige Pixelclock (12 MHz) > an/auszuschalten. Sollen nur diese Signale erzeugt oder auch der komplette Bildinhalt ausgegeben werden? Wenn ja: schwarz-weiß oder farbig mit welcher Farbtiefe? Dr. Sommer schrieb: > Oder du lässt VGA ganz sein und > benutzt zB einen STM32F7 welche direkt in Hardware Da dies ja ein 'kleiner' ARM ist, sicherlich die einfachste Lösung. Anderfalls bietet sich DMA an. Beispiel: http://mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-4
Stefan U. schrieb: > Nicht wirklich, denn Interruptroutinen müssen auch aus den Flash geladen > werden und außerdem wird immer mindestens der gerade ausgeführte Befehl > zuende gebracht, bevor die ISR angesprungen wurd. Das ist übrigens auch falsch. Der Cortex bricht die gerade ausgeführte Instruktion ab oder unterbricht sie, wenn ein Interrupt auftritt. Nach dem Interrupt wird sie dann entweder fortgesetzt (Multiple Load/Store) oder neu gestartet.
H-G S. schrieb: > Übrigens soll die Pixelclock nicht vom Mikrocontroller erzeugt werden, > sondern nur gestartet bzw angehalten werden. Komische Idee, den Pixeltakt lässt man durchlaufen (unbedingt synchron zum Takt des µC), man gibt in den Austastlücken keine Daten aus. Besser noch wäre es, wenn Du statt der unüblichen 12 MHz den korrekten Pixeltakt von 25.175 MHz verwenden würdest; die Pixel horizontal zu verdoppeln ist ja nun keine Raketenwissenschaft. Was genau ist das Ziel? Warum muss es VGA sein?
> Warum muss es VGA sein? Weil. Er braucht eine Grafikkarte für sein 8051-Board. Siehe seine anderen Threads.
1N 4. schrieb: > Weil. Er braucht eine Grafikkarte für sein 8051-Board. Siehe seine > anderen Threads. Hahaha, warum nicht den 8051 gleich mit simulieren auf dem ARM? Einen ARM als Helfer für einen 8051 abzustellen ist irgendwie eine verkehrte Welt...
Selbst für einfache FPGAs gibt es VGA Sample Code. Ich habe so etwas mit einem Spartan 3 gemacht (der ist jetzt 3 Generationen zurück) . Wäre vielleicht einfacher, als eine Prozessor zu missbrauchen. Dann stimmt wenigstens das Timing.
PittyJ schrieb: > Selbst für einfache FPGAs gibt es VGA Sample Code. Besteht das Problem nicht eher darin, genug RAM anzubinden? SDRAM-Controller sind ja etwas schwierig. Es wurde ja leider keine Aussage zur gewünschten Auflösung/Farbtiefe gemacht...
Warum nicht einfach einen ST CM4 oder sogar CM7 als Grafikkarte missbrauchen. Der hat doch einen Video Controller im Bauch. Der CM7 hat sogar schon so viel RAM damit es für VGA als Framebaffer locker reicht. Gruß Sascha
>> Selbst für einfache FPGAs gibt es VGA Sample Code. > Besteht das Problem nicht eher darin, genug RAM anzubinden? > SDRAM-Controller sind ja etwas schwierig. Wenn man nicht weiß, was man will, ist alles schwierig. Der TE hängt in einer Konzeptdauerschleife weil er sich auf bestimmte Dinge versteift und daran festhalten will. Es gibt genügend SDRAM-Controller als HDL-Code und wenn man sich ein bisschen mit FPGAs auseinandersetzt und endlich die Unterschiede zu einem uC begreift, ist das kein Hexenwerk.
1N 4. schrieb: >>> Selbst für einfache FPGAs gibt es VGA Sample Code. >> Besteht das Problem nicht eher darin, genug RAM anzubinden? >> SDRAM-Controller sind ja etwas schwierig. > > Wenn man nicht weiß, was man will, ist alles schwierig. Der TE hängt in > einer Konzeptdauerschleife weil er sich auf bestimmte Dinge versteift > und daran festhalten will. > > Es gibt genügend SDRAM-Controller als HDL-Code und wenn man sich ein > bisschen mit FPGAs auseinandersetzt und endlich die Unterschiede zu > einem uC begreift, ist das kein Hexenwerk. Mit Kanonen auf Spatzen? Es geht im Eingangsbeitrag um drei Dinge: - V-Sync - H-Sync - Pixelclock ein/aus Dazu brauche ich kein FPGA, da reicht ein CPLD oder u. U. - wie oben bereits angedeutet - ein AVR-Controller.
H-G S. schrieb: > Eigentlich könnte das auch ein etwas flotterer 8051 machen Kann er selbstverständlich: http://community.silabs.com/t5/8-bit-MCU/Random-Latency-with-Laser-Bee-Branch-Instructions/m-p/178156#M46046 > Die ARM scheinen ja alle Cache und Pipeline zu haben daher weiss man nie > so genau wieviel Nanosekunden so eine Befehlsfolge braucht Der 8051 oben hat auch Cache daher musste in Assembler etwas Aufwand betrieben werden. Das geht so auch in ARM Assembler, auch auf einem Raspberry Pi, die jeweilige Subroutine muss eben in den Cache passen und die Laufzeit der Pipeline ist bekannt und kann über Subtraktion vom PC kontrolliert werden. Allerdings Bare Metal oder RTOS erforderlich z.B. RISC OS pico: https://www.riscosopen.org/content/downloads/raspberry-pi
Du musst Dir keine große Gedanken über Latenzzeiten und definierte Ausführungszeiten der ISRs machen. Zumindet bei den STM32 hast Du bei den Timern Preload-Register, d.h. Du kannst den neuen Wert schon vorher hineinschreiben, und beim Overflow/Compare-Event wird ganz automatisch der neue Wert für Prescaler etc. geladen - und zwar innerhalb eines(!) Taktes. D.h., dass Du Dir bei der "Beschickung" der Timer mit neuen Werten eine ganze Timerperiode Zeit lassen und rumtrödeln kannst und es egal ist, wann in diesem Zeitraum Du "nachlädst". Der neue Durchlauf startet dann ohne weiteres Zusammenspiel mit dem Prozessor/Cache. Das macht das Timermodul vollkommen autark. Das ist ein großer Vorteil gegenüber den alten AVRs (k.A. ob die neuen das haben), wenn es schnell und/oder genau sein soll.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Zumindet bei den STM32 ... Das macht das Timermodul vollkommen autark Das mag sein, aber Cortex-M sind wegen nicht re-entranten Interrupts und Auto-Stacking / Lazy-Stacking prinzipiell nicht für "Harte Echtzeit" geeignet. Dafür empfiehlt auch ARM selbst immer noch die Cortex-R mit FIQ und Banked Register. Auch beim M7 der ja eigentlich dem R5 Konkurrenz machen sollte, bleibt das Problem. Die einzige "Lösung" mit Cortex-M sind mehrere Cores wie schon länger bei LPC54 und jetzt auch bei PSoC 6
Chris D. schrieb: > Das ist ein großer Vorteil gegenüber den alten AVRs (k.A. ob die neuen > das haben), wenn es schnell und/oder genau sein soll. Wie alt ist "alt"? Selbst der olle ATmega8 kann das: "The OCR1x Register is double buffered when using any of the twelve Pulse Width Modulation (PWM) modes. [...] The double buffering synchronizes the update of the OCR1x Compare Register to either TOP or BOTTOM of the counting sequence. The synchronization prevents the occurrence of odd-length, non-symmetrical PWM pulses, thereby making the output glitch-free." Sonst stimme ich dir aber zu, die STM32-Timer sind schon wesentlich mächtiger als die von den (alten?) AVR - das fängt schon beim beliebigen Prescaler und der puren Anzahl an 16/32-Bit-Timern an...
Lothar schrieb: > Das mag sein, aber Cortex-M sind wegen nicht re-entranten Interrupts und > Auto-Stacking / Lazy-Stacking prinzipiell nicht für "Harte Echtzeit" > geeignet. Das würde ich nicht ganz so sagen - harte Echtzeit bedeutet ja nur, dass bestimmte Deadlines eingehalten müssen, und nicht dass auf den Takt genau und auch nicht zu früh reagiert werden muss. Das lässt sich mit einem Cortex-M durchaus garantieren - man muss die Dauern der Interrupts und Worst Cases genau berechnen, aber das muss man beim -R ja wohl auch...
Dr. Sommer schrieb: > Lothar schrieb: >> Das mag sein, aber Cortex-M sind wegen nicht re-entranten Interrupts und >> Auto-Stacking / Lazy-Stacking prinzipiell nicht für "Harte Echtzeit" >> geeignet. > Das würde ich nicht ganz so sagen - harte Echtzeit bedeutet ja nur, dass > bestimmte Deadlines eingehalten müssen, und nicht dass auf den Takt > genau und auch nicht zu früh reagiert werden muss. Das lässt sich mit > einem Cortex-M durchaus garantieren - man muss die Dauern der Interrupts > und Worst Cases genau berechnen, aber das muss man beim -R ja wohl > auch... Im Übrigen hat ARM extra für "harte" Echtzeitfälle beim M0/M0+ das Zero Jitter Feature eingebaut. Damit kann die Interrupt Latenz an das Timing des Speichers angepasst werden. Die Latenz wird damit zwar im Durchschnitt größer, aber es gibt eben keinen Jitter.
Dr. Sommer schrieb: > "The OCR1x Register is double buffered when using any of the twelve > Pulse Width Modulation (PWM) modes. [...] The double buffering > synchronizes the update of the OCR1x Compare Register to either TOP or > BOTTOM of the counting sequence. The synchronization prevents the > occurrence of odd-length, non-symmetrical PWM pulses, thereby making the > output glitch-free." Stimmt - ist wohl doch schon zu lange her :-) Allerdings sind Prescaler, Autoreload beim STM32 eben auch "vorladbar". > Sonst stimme ich dir aber zu, die STM32-Timer sind schon wesentlich > mächtiger als die von den (alten?) AVR - das fängt schon beim beliebigen > Prescaler und der puren Anzahl an 16/32-Bit-Timern an... Ja, und so nette Sachen wie Singlepuls, Pulsfolge usw. :-) Wobei ST bei den 32-Bit-Timern zu viel gespart hat. Warum nicht alle Timer auf 32 Bit Breite und fertig? :-/ Dr. Sommer schrieb: > Das würde ich nicht ganz so sagen - harte Echtzeit bedeutet ja nur, dass > bestimmte Deadlines eingehalten müssen, und nicht dass auf den Takt > genau und auch nicht zu früh reagiert werden muss. Das lässt sich mit > einem Cortex-M durchaus garantieren - man muss die Dauern der Interrupts > und Worst Cases genau berechnen, aber das muss man beim -R ja wohl > auch... Die Definition sehe ich ähnlich. Das hat erstmal nichts mit reentranten Interrupts zu tun. Man muss sich sein System und sein Worstcase-Verhalten nur genau überlegen, dann kann man problemlos harte Echtzeit garantieren. Unsere Systeme müssen das zum großen Teil und das klappt auch problemlos, vom F0 bis zum F7.
H-G S. schrieb: > Hallo! > > Frage: Kann man mit einem kleinen ARM-Mikrocontroller eine zeitkritische > Impuls-Ausgabe bewerkstelligen ? Ich bräuchte das um VGA-Synchronsignale > (30-40 kHz) zu erzeugen sowie eine zugehörige Pixelclock (12 MHz) > an/auszuschalten. > > Die ARM scheinen ja alle Cache und Pipeline zu haben daher weiss man nie > so genau wieviel Nanosekunden so eine Befehlsfolge braucht. > > Kann man vielleicht mit Interrupts etwas genaueres erreichen oder gibt > es andere Kniffe ? Schau Dir die LPC15xx von NXP an, die haben SCTs, die das mit links und ohne große CPU-Last machen können.... MiWi
Ich habe zufällig gesehen dass für VGA unbedingt ein TVS-Chip mit Backdrive-Diode verwendet werden sollte, da sonst aus dem Monitor Spannung zurückfliessen kann in das ausgeschaltete Sendegerät. Die ganzen Homebrew-Projekte leben also etwas gefährlich :-) BTT: Es scheint also mit ARM und Co. möglich das VGA-Sync hinzukriegen mit Hilfe des Interrupts. Danke euch allen für eurer Wissen!
Chris D. schrieb: > Zumindet bei den STM32 hast Du bei den Timern Preload-Register, d.h. Du > kannst den neuen Wert schon vorher hineinschreiben, und beim > Overflow/Compare-Event wird ganz automatisch der neue Wert für Prescaler > etc. geladen - und zwar innerhalb eines(!) Taktes. > Das ist ein großer Vorteil gegenüber den alten AVRs (k.A. ob die neuen > das haben), wenn es schnell und/oder genau sein soll. Auch schon die "alten" AVRs hatten dieses Feature, zumindest in eingeschränkter Form. Konkret: * in allen PWM-Modi sind für alle OCRxn-Register Preload-Register vorhanden * zusätzlich bei PhaseAndFrequencyCorrect-PWM auch noch für das als TOP benutzte Register. Diesen Modus gibt es allerdings nur für die "Standard"-16Bit-Timer der Megas und einiger neuerer Tinys.
> da sonst aus dem Monitor Spannung zurückfliessen kann
Ich wüsste nicht, warum/wann das passieren sollte.
Stefan U. schrieb: >> da sonst aus dem Monitor Spannung zurückfliessen kann > > Ich wüsste nicht, warum/wann das passieren sollte. Im Empfänger (zB. Monitor) kann ein Schaltungsteil (zB. Spannungsteiler) sein dass dauernd Spannung führt. Diese kommt dann über die obere TVS-Diode zurück in den Sender und zieht dessen Vcc hoch nachdem der Sender keine Versorgungsspannung mehr hat weil man ihn abgeschaltet hat. Es kommt aber noch besser: Es gibt ja auch noch die interne ESD-Schutzdiode im Sender-Chip! Das heisst man muss den sendenden Chip so aussuchen dass er keine interne ESD-Diode besitzt und man darf die externe ESD-Schutzschaltung nicht ohne Backdrive-Diode verwenden. Zum Glück habe ich das zufällig gelesen beim herumgoogeln nach TVS/Schottky etc :-)
:
Bearbeitet durch User
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.