Hallo, ich will mir einen Vierqudrantensteller für Gleichstrommotoren bauen. Dafür bräuchte ich etwas Steuerelektronik wie z.B. eine Rechteckpulsgenierung, Flipflops, einen Komparator usw. Früher hätte man sowas mit ein paar TTL- oder CMOS-Käfern und einem Komparator aufgebaut. Jetzt ist mir die Idee gekommen, dafür einen ATTiny zu verwenden und ein kleines Progrämmchen in Assembler zu schreiben. Dann bin ich viel flexibler als mit Hardware-Logik. Außerdem verlerne ich dann das Assembler Programmieren nicht ganz ;-) Ich habe etwas mit dem AVR-Simulator gespielt und das sieht gar nicht so schlecht aus. Mit den geringen Latenzzeiten kann ich leben. Ich würde auch den Analogkomparator benutzen und das entsprechende Bit pollen. Interrupts soll es keine geben. Dann kann ich mir doch sicher sein, dass die im AVR-Simulator sichtbaren CPU-Zyklen in Wirklichkeit auch eingehalten werden, oder? Oder gibt es außer Interrupts irgendwas, was den Controller kurzzeitig von der Abarbeitung der Main-Loop abhalten könnte? Oder gibt es sonst irgendwas, was ich in diesem Zusammenhang übersehen habe? Danke. Third-Eye
Third Eye schrieb: > Oder gibt es außer Interrupts irgendwas, was den Controller kurzzeitig > von der Abarbeitung der Main-Loop abhalten könnte? Nur wenn du sowas wie ein (Realtime-) Betriebssystem verwendest, das du nicht überschauen kannst. Das Prinzip einer endlosen Mainloop entspricht einer SPS, die zyklisch ihre Befehle ausführt - die Zykluszeit ist damit die kürzeste Reaktionszeit. Das ist millionenfach bewährt, allerdings bei weitem nicht so reaktionsschnell wie TTL-ICs, reicht aber für Maschinensteuerungen usw. Gruss Reinhard
>Ich habe etwas mit dem AVR-Simulator gespielt und das sieht gar nicht so >schlecht aus. Die benötigten CPU-Takte stehen im Manual drin, sind also sozusagen schon im Voraus berechenbar. >Oder gibt es außer Interrupts irgendwas, was den Controller kurzzeitig >von der Abarbeitung der Main-Loop abhalten könnte? Nein gibts nicht (sofern sichergestellt ist, dass INTs wirklich nicht zur Ausführung kommen). >Oder gibt es sonst irgendwas, was ich in diesem Zusammenhang übersehen >habe? Schon wenige AVR-Befehle brauchen doch etliche ns..ua, noch schlimmer wird es mit zunehmender Softw-Komplexität. Bei Hardware (TTL, PLD etc) funkt. alles parallel, dort zunehmende Komplexität erhöht den Schaltungs-Aufwand, aber nicht die Durchlaufzeit.
@Third Eye (third-eye) >ich will mir einen Vierqudrantensteller für Gleichstrommotoren bauen. >Dafür bräuchte ich etwas Steuerelektronik wie z.B. eine >Rechteckpulsgenierung, Flipflops, einen Komparator usw. >Früher hätte man sowas mit ein paar TTL- oder CMOS-Käfern und einem >Komparator aufgebaut. Früher war die Welt analog. >Jetzt ist mir die Idee gekommen, dafür einen ATTiny zu verwenden und ein >kleines Progrämmchen in Assembler zu schreiben. Dann bin ich viel >flexibler als mit Hardware-Logik. Außerdem verlerne ich dann das >Assembler Programmieren nicht ganz ;-) Jo, heute ist sie fast komplett digital. Was du da beschreibst ist ein digitaler Regler. Das ist auch nicht mehr wirklich neu, solche Sachen sind immer mehr auf dem Vormarsch. Schaltnetzteile etc. Bei Motoren schon lange. >Ich würde auch den Analogkomparator benutzen und das entsprechende Bit >pollen. Genau. >Interrupts soll es keine geben. Dann kann ich mir doch sicher sein, dass >die im AVR-Simulator sichtbaren CPU-Zyklen in Wirklichkeit auch >eingehalten werden, oder? Ja. >Oder gibt es außer Interrupts irgendwas, was den Controller kurzzeitig >von der Abarbeitung der Main-Loop abhalten könnte? Nein. Der Controller arbeitet wie ein Logikautomat. >Oder gibt es sonst irgendwas, was ich in diesem Zusammenhang übersehen >habe? Klar ist so eine Software auch mit 20 MHz, RISC und Assembler nicht so schnell wie Hardwarelogik ala TLL/CPLD und FPGA, aber für normale Motorregler reicht es schon. Je nach Anspruch liegen dort die Zykluszeiten bei einigen Mikro- Millisekunden.
Zusammen mit Motoren und Mechanik müssten die ATTiny- und ATMega-Prozessoren ausreichend schnell sein. Asymmetrien im Ablauf können normalerweise aus folgenden Ursachen resultieren: 1. Unterbrechungen 2. Der "vergessene" Wachhund. 3. Durch if's verschandelte Funktionen. 4. Durch die Verwendung von Bibliotheken, z.B. Fließkommaarithmetik. Dabei können schon, abhängig von den übergebenen Werten, stark variierende Laufzeiten entstehen. 5. "Echte" Fehler mit einem kurzen Ausflug ins Nirwana. Wobei praktisch alle Stufen unabhängig vom Prozessor und Hersteller sind. Vermeiden lassen sich diese ab Punkt 3 nur durch völlig überdimensionierte Rechner, bei denen sich diese Toleranzen nicht messbar bemerkbar machen.
Bitte 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.