ich habe schon oft RC-Signale eingelesen (immer AVR 8-Bitter mit Bascom, auch hier wieder) aber da wusste ich einigermassen, wie das reinkommt. Jetzt soll das etwas universeller werden und daher habe ich mir das mal neu überlegt.
Um das zu beurteilen ist die Sprache eigentlich wurscht und von RC-Signalen muss man auch nichts verstehen. Ich bitte nur um Hilfe bzw. kurzes Mitdenken bei der Logik.
Die Signale kommen etwa alle 20ms, sind idle low und dann jeweils für 1-2ms high. Um diese Zeit geht es.
Hier sind das erstmal nur zwei Signale, könnten aber auch mehr sein, die kommen jeweils auf eigenen Eingängen an.
Das Problem ist nun, daß die Reihenfolge der Signale und das Timing völlig random sind. Die können mit Pause dazwischen kommen, gleichzeitig starten, enden oder sich beliebig überlappen. Gängig ist sogar eher, daß die fallende Flanke des einen Signals mit der steigenden Flanke des anderen Signals nahezu gleichzeitig passiert. Also so gleichzeitig, wie eine flotte 32-Bit Hardware das hinbekommt, für einen armen ATTiny mit 8MHz ist das gleichzeitig.
Und es müssen nicht unbedingt beide Signale anliegen, kann auch nur eins sein.
Weiteres Problem ist, daß ich das auf einem ATTiny per PCINT nutzen möchte und da gibt es eben nur genau einen INT für alle PINs. Also wenn irgendeiner der Pins sich ändert -> Interrupt. Was genau passiert ist, muss ich dann selber nachschauen.
Das ist in Bascom und da werden alle Register beim Sprung zur INT-Routine gesichert. Das dauert etwas (50 Takte oder so) und somit könnte ich einen PCINT verpassen, wenn genau dann noch einer kommt. Ja, das kann man abschalten aber ein paar Register müsste man da immer sichern, auch in C oder Assembler. Das würde das Risiko nur verringern aber nie eleminieren!
Der Timer0 läuft frei als 8-Bit mit Prescaler 256 (max 8,2ms), alle Variablen sind auch 8-Bit. Das mit der Zeitberechnung bei frei laufendem Timer mit Überläufen soll hier nicht das Thema sein (das funktioniert so).
Sig1_in_hard und Sig2_in_hard sind die Eingangspins. Deren Zustand kopiere ich am Anfang, damit das kein Kuddelmuddel gibt, wenn sich das bei der Auswertung ändert, was durchaus sein kann. Das würde dann aber einen nächsten INT auslösen denn das Flag ist da ja dann bereits gelöscht.
Der Knackpunkt ist eigentlich, daß ich so hoffentlich keine Flanke verpasse. Wenn eine Flanke auslöst und die Andere kommt direkt danach bevor das PCINT-Flag gelöscht ist (Int verpasst), merke ich das trotzdem in der INT-Routine denn der Status des Pins hat sich ja geändert.
Ein kleiner Jitter des Signals, der dadurch entstehen kann (im µs-Bereich) ist zum Glück unerheblich und der Timer ist mit 32µs Auflösung ja auch recht grob. Das ist völlig ok so.
1
Sigint:
2
Sig1_in = Sig1_in_hard 'Copy for atomic detection
3
Sig2_in = Sig2_in_hard
4
If Sig1_in <> Sig1_in_old Then 'Check for change
5
If Sig1_in = 1 Then
6
Sigtime1a = Timer0 'Start
7
Else
8
Sigtime1b = Timer0 'End
9
Sigtime1 = Sigtime1b - Sigtime1a 'Works fine with overflow, all 8-Bit unsigned
10
End If
11
Sig1_in_old = Sig1_in
12
End If
13
If Sig2_in <> Sig2_in_old Then
14
Sig2_in_old = Sig2_in
15
If Sig2_in = 1 Then
16
Sigtime2a = Timer0
17
Else
18
Sigtime2b = Timer0
19
Sigtime2 = Sigtime2b - Sigtime2a
20
End If
21
End If
22
Return
Ich hoffe, das ist ansonsten selbsterklärend, wie ich mir das gedacht habe. Ist das so bullet-proof oder kann da noch was schiefgehen?
Habe jetzt deinen Code nicht durchdacht, aber ich habe das bisher mit einem µC gelöst, der 2 CCP Module (Capture-Compare-PWM) Module hat (z.B. PIC 16F18323), weil es sonst echt nicht leicht ist. Beide Module nutzen zwar den gleicher Timer, das ist aber unkritisch.
Bei steigender u. fallender Flanke wird jeweils ein INT ausgelöst und der Timer gesichert. Für jedes CCP Modul gibt es einen eigenen Interrupt. Das geht mit wenig Anweisungen, entsprechend hoch ist die Auflösung (ca. 2-3 µs selbst bei nur 4 MHz).
Aus der Differenz des Timers kann dann später in aller Ruhe die Impulslänge berechnet werden und was sonst noch so getan werden muss.
Vielleicht hat dein Controller auch solche CCP Module, ich kenne den ATTiny nicht. Vorteil: sehr einfach und sicher.
Weiteres Problem ist, daß ich das auf einem ATTiny per PCINT nutzen
möchte und da gibt es eben nur genau einen INT für alle PINs.
Ich nutze dafür keinen Pin Change Interrupt, sondern lese den Eingangspinzustand in einer Timer-ISR z.B. alle 100µs und vergleiche mit dem Zustand aus der vorherigen ISR. Die ISR-Aufrufe zwischen den Änderungen werden mitgezählt.
Sig1_in_hard und Sig2_in_hard sind die Eingangspins.
Vorzugsweise sollten die auf dem selben PIN-Port liegen, dann gehen sie auch auf den selben PCINT.
Dann nimmst Du noch eine Bytevariable für den alten Zustand und mit EXOR ermittelst Du, welcher Pin sich geändert hat.
Eine Änderung dabei löst danach sofort einen neuen PCINT aus, es geht also keiner verloren.
Typisch benutzt man allerdings nur einen Fernsteuersender und dann kommen alle Kanäle nacheinander über nur einen Pin.
Typisch benutzt man allerdings nur einen Fernsteuersender und dann
kommen alle Kanäle nacheinander über nur einen Pin.
Im letzten Jahrtausend war das mal so.
Seitdem der ganze Kram digital ist, kommen die analogen PWM-Signale einzeln aus den Servoanschlüssen am Empfänger. Vorher gibts da nur digitale Werte. Für Nostalgiker gibt's dann da vielleicht noch ein Summensignal.
Ist aber eigentlich auch egal. Das Thema RC-PWM und Microcontroller dürfte seit langem vollumfänglich gelöst sein, rein wie raus.
Wohl kaum. Die Abgaben "alle 20ms" und "jeweils für 1-2ms high" lassen eher vermuten, dass es sich um ein Servosteuersignal für Modellbauservos handelt.
Ja, ja. Eine Angabe von 0,5 Mikrosiemens hätte eher etwas mit Leitfähigkeit eines relativ guten Isolators zu tun ;-)
Aber wahrscheinlich hast du nur Probleme mit SI-Einheiten und meinst Mikrosekunden.
Ja, ja. Eine Angabe von 0,5 Mikrosiemens hätte eher etwas mit
Leitfähigkeit eines relativ guten Isolators zu tun ;-)
Aber wahrscheinlich hast du nur Probleme mit SI-Einheiten und meinst
Mikrosekunden.
Es ist durchaus berechtigt, erstmal das Setup in Frage zu stellen aber ich dachte ich hätte dargestellt, daß es hier Gegebenheiten gibt, bei denen Änderung keine Option ist. Das ist der µC, ein ATTiny 861 mit seinen Einschränkungen, mehrere Signale (nur hier als Beispiel sind es nur zwei) und ja, es handelt sich um klassische einzelne Servosignale. PPM (Summensignal) kann man viel eleganter und absolut ohne Jitter auswerten aber das kommt eben nicht aus jedem Empfänger raus.
Vieles hatte ich im ersten Beitrag schon geschrieben aber ich versuche trotzdem mal auf das Meiste einzugehen.
Habe jetzt deinen Code nicht durchdacht, aber ich habe das bisher
mit
einem µC gelöst, der 2 CCP Module (Capture-Compare-PWM) Module hat (z.B.
PIC 16F18323), weil es sonst echt nicht leicht ist. Beide Module nutzen
zwar den gleicher Timer, das ist aber unkritisch.
[...]
Vielleicht hat dein Controller auch solche CCP Module, ich kenne den
ATTiny nicht. Vorteil: sehr einfach und sicher.
Der hätte zwar zwei Input Capture bei dem Timer aber spätestens wenn es mehr Signale werden wird das damit nichts mehr.
Ich nutze dafür keinen Pin Change Interrupt, sondern lese den
Eingangspinzustand in einer Timer-ISR z.B. alle 100µs und vergleiche mit
dem Zustand aus der vorherigen ISR. Die ISR-Aufrufe zwischen den
Änderungen werden mitgezählt.
Die Auflösung wäre dann doch etwas grob und wenn man das schneller macht, macht der µC ja fast nichts anderes mehr. Allerdings ist das nicht die dümmste Idee, wenn man damit leben kann und für das was ich vorerst vor Augen habe, würde das sogar reichen. Es ist aber ja doch etwas rustikal...
Vorzugsweise sollten die auf dem selben PIN-Port liegen, dann gehen sie
auch auf den selben PCINT.
Dann nimmst Du noch eine Bytevariable für den alten Zustand und mit EXOR
ermittelst Du, welcher Pin sich geändert hat.
Eine Änderung dabei löst danach sofort einen neuen PCINT aus, es geht
also keiner verloren.
Bei diesem ATTiny861 gibt es für alle PCINT sowieso nur genau einen Interrupt.
Ansonsten ist das bisher die einzige sinnvolle Antwort, bei der das Problem verstanden wurde. Wenn was "passiert", prüfe ich die Eingänge und selbst wenn ich einen Int beim sichern der Register verpassen würde, merke ich das in der Int-Routine. Oder es kommt in der Int-Routine, dann löst das einen neuen Int aus.
Damit kann man das Signal mit 0,5µS auflösen. Ohne weitere Klimmzüge.
Das reicht für die meisten Anwendungen.
Dann braucht man für jedes Signal einen Input Capture, was hier für zwei noch geht aber bei mehr Signalen nicht mehr. Das Problem mit schnellerer Hardware zu bewerfen löst das Problem auch nicht im Geringsten, es fällt nur nicht mehr so auf weil es seltener passiert. Leider eine oft angewendete Taktik weil ohne Hirnschmalz möglich aber völlig unnötig, wenn man eigentlich wissen kann, was genau passiert.
"Das reicht für die meisten Anwendungen". Hmmm, die meisten Anwendungen sind also die mit 11-Bit Auflösung des Signals? Im Ernst, es gibt Fernbedienungen, die so eine hohe Auflösung haben aber das ist kompletter Unsinn und nur für den Verkaufsprospekt. Aber ein Zimmerthermometer auf zwei Nachkommastellen genau reicht ja auch für die meisten Anwendungen...
Rainer W. liegt da wohl nicht ganz falsch, das ist der am wenigsten hilfreiche Beitrag...
Je nachdem, wieviele Ports der AVR hat, hast du auch mehrere Gruppen von
PCInts. Ausserdem gibts es noch INT0 und manchmal auch INT1.
Wie geschrieben, dieser ATtiny 861 hat zwar zwei Gruppen PCINT, die man freigeben muss/kann (und dann natürlich die einzelnen Bits) aber es gibt dafür dann nur einen gemeinsamen Interrupt. Der T861 (X61) ist bei einigen Sachen etwas speziell...
Dann braucht man für jedes Signal einen Input Capture, was hier für zwei
noch geht aber bei mehr Signalen nicht mehr. Das Problem mit schnellerer
Hardware zu bewerfen löst das Problem auch nicht im Geringsten, es fällt
nur nicht mehr so auf weil es seltener passiert.
Einfach andere Hardware. Controller mit mehr Timern und mehr Input Capture HW nutzen.
Nicht jede HW und jeder Controller ist für jedes Problem geeignet.
Ein kleiner Jitter des Signals, der dadurch entstehen kann (im
µs-Bereich) ist zum Glück unerheblich und der Timer ist mit 32µs
Auflösung ja auch recht grob. Das ist völlig ok so.
Vielleicht sollte man das Problem nicht in BASIC lösen.
Deiner wirren Beschreibung nach möchtest du eine PCM Modellbaufernsteuerung auslesen und zwar nicht nur 1 Kanal, nicht das Funksignal, sondern mehrere Empfängerausgänge simultan.
Klassisch kommen zwar die Servoimpulse da zeitversetzt raus, d.h. der nächste beginnt wenn der vorherige endet, aber das muss nicht so sein und du möchtest universeller einlesen können.
Da der übliche uC mit seinen Timern zwar Impulslängen ermitteln kann aber mangels ausreichend vielen Timern bzw. mangels ausreichender Flexibilität nicht an mehreren Eingängen, muss eine Softwarelösung her.
Es können also steigende Flanken (beginnende Impulse) und fallende Flanken (Ende des Impuls) an mehreren Eingängen beliebig zeitversetzt auftreten.
Ausgehend davon, dass dein Programm in der Hauptschleife vermutlich genug zu tun hat, bieten sich pin change interrupts an. Kurz den Portinhalt und einen Timerstand eines freilaufenden times abspeichern, und eine spätere Routine kann in Ruhe zeitunkritisch auswerten welcher pin sich wann verändert hat. Allerdings muss die Auswertung passieren bevor das FIFO Array der gespeicherten Events überläuft.
Allerdings ist das gefährdet bei gestörten Signalen, wenn also erheblich mehr pin changes kommen als erwartet. Einfach nach einer steigenden flanke 0.9ms die fallende nicht einzulesen, nach einer fallenden 18ms die steigende nicht zu akzeptieren wäre eine Plausibilisierung die einen Überlauf verhindert, aber aufwändiger zu programmieren. Das sperren einiger pin change Interrupts und wiederaufheben der Sperre nach Ablauf eines timers erfordert geschicktes jonglieren mit 2 Interruptursachen.
Alernative ist die Abtastung aller Eingange in einer 32us timerinterrupt Routine. Das ist so schnell, das geht wohl nur per Assembler. Und das Array von 625 (1024) solcher Werte muss auch noch ausgewertet werden. Hoffentlich hat deine Programm-Hauptschleife nicht zu viel zu tun.
Dann braucht man für jedes Signal einen Input Capture, was hier für zwei
noch geht aber bei mehr Signalen nicht mehr. Das Problem mit schnellerer
Hardware zu bewerfen löst das Problem auch nicht im Geringsten, es fällt
nur nicht mehr so auf weil es seltener passiert.
Einfach andere Hardware. Controller mit mehr Timern und mehr Input
Capture HW nutzen.
Nicht jede HW und jeder Controller ist für jedes Problem geeignet.
Wenn man nicht weiter nachdenken will oder kann, dann mag das so sein.
Warum meine Lösung die Anforderungen aber nicht erfüllen sollte, kannst Du nicht sagen? Immerhin hast Du eingesehen, daß einfach nur ein schnellerer 16-Bit-Timer das Problem nicht ansatzweise adressieren würde.
Welcher Controller hätte denn so 4-6 Input Capture Hardware? Welche Toolchain müsste ich mir dafür antun und kriege ich die Platinchen noch mit ner Käsefräse hin?
Immerhin müsste ich dann aber nicht über 20 Zeilen simplen Code und überschaubare 8-Bit-Hardware nachdenken...
Da der übliche uC mit seinen Timern zwar Impulslängen ermitteln kann
aber mangels ausreichend vielen Timern bzw. mangels ausreichender
Flexibilität nicht an mehreren Eingängen, muss eine Softwarelösung her.
Was ein Unsinn.
Selbst mit einem STM32G07 kann man >10 Input Capture Kanäle haben.
RC Signale ohne Input Capture in HW ist immer Pfusch und niemals "Bulletproof".
Und Jitter in µs Bereich will man bei solchen Signalen auch nicht.
Und den Jitter kannst du ohne Input Capture einfach nicht vermeiden. Weil deine SW immer etwas Zeit braucht, den Kanal zu identifizieren und den Timer Wert zu speichern.
Wenn man nicht weiter nachdenken will oder kann, dann mag das so sein.
Sorry dann lös dein Problem selber du Schwätzer.
Wenn man nicht nachdenken will nimmt man Stumpf immer wieder die gleichen altbackenen ungeeigneten AVR und niemals was modernes.
Und wenn man so gar nie nicht nachdenken will programmiert man im Jahre des Herrn 2025 immer noch in BASIC.
Die Timer lässt man mit 0,5µs pro Tick laufen. Und kann damit locker die ganze 20ms abdecken. Mit 0,5µs Auflösung.
Unabhängig davon wann die Signale kommen. Ob zeitversetzt oder gleichzeitig.
Automatisch sind auch sämtliche Wiederholraten, 50Hz, 100Hz, 250Hz welche heute üblich sind mit abgedeckt. Ohne eine Zeile mehr Code. Weils keine Rolle spielt.
Mit genau diesem Controller habe ich vor kurzem 4x RC In + 4x Servo Out realisiert.
Ist wirklich lachhaft einfach. Ohne größte Not würde ich mir hier das AVR Gewürge mit unbrauchbaren 8 Bit Timern nicht antun.
Klar, ich steige jetzt von Bascom und 8-Bit-AVR auf ne komplett neue Sprache und IDE um. Weil Herr Cyblord es nicht versteht, daß das Problem auch wunderbar so zu lösen ist.
Dieser Mist ist an Arroganz kaum zu überbieten.
Ärgerlich ist, daß Projektleiter diesen Unsinn auch glauben und deswegen alles mit Hardware und der entsprechenden Einarbeitung und allen neuen Problemen bezahlt wird. Ich habe mit Software beruflich nichts mehr zu tun, da wird nun auch alles von den Softwerkern mit STM32 gemacht aber viel besser ist dadurch nicht viel geworden, zumindest was so hardwarenahe Sachen angeht. Es versteht keiner mehr, was da passiert, es ist alles nur so schnell, daß das nicht mehr so auffällt. Du hast ja auch nur mit Nachhilfe das eigentliche Problem überhaupt verstanden.
Ja, damit geht das problemlos, das wussten hier wohl alle auch vorher. Aber es sind nicht alle Softwerker, die damit komfortabel unterwegs sind.
Du kannst Dich gerne über die Amateure totlachen aber die kriegen das mit ihren völlig ungeeigneten Mitteln mit etwas Hirnschmalz eben auch hin.
Warum meckerst Du hier denn rum, wenn das nicht auf Deinem Niveau ist? Hast Du keine echten Probleme zu lösen, für die man tatsächlich einen 32-Bitter braucht? Warum diese Stänkerei?
"Mein Polo springt nicht an, was kann ich tun?" Und Du antwortest nur: "Kauf dir einen Neuwagen, der springt dann auch an!"
Klar, ich steige jetzt von Bascom und 8-Bit-AVR auf ne komplett neue
Sprache und IDE um. Weil Herr Cyblord es nicht versteht, daß das Problem
auch wunderbar so zu lösen ist.
Zeig mal wie. Es ist eben nicht wunderbar zu lösen.
Mit BASCOM und AVR kannst du eben nicht alles machen. Das musst du akzeptieren. Wenn du partout nicht umsteigen willst, dann gehen halt manche Dinge nicht.
Ja, damit geht das problemlos, das wussten hier wohl alle auch vorher.
Aber es sind nicht alle Softwerker, die damit komfortabel unterwegs
sind.
Wenn man keine SW Schreiben kann sollte man es lassen und vielleicht was machen was man auch machen kann. Gärtnern z.B.
Du kannst Dich gerne über die Amateure totlachen aber die kriegen das
mit ihren völlig ungeeigneten Mitteln mit etwas Hirnschmalz eben auch
hin.
So wie du? Wie ist denn deine Lösung? Das Ding wird Jittern wie verrückt. Das bekommst DU nie in den Griff.
Und STM32 ist längst Standard gerade bei "Amateuren".
Warum meckerst Du hier denn rum, wenn das nicht auf Deinem Niveau ist?
Ich versuche die passende Lösung vorzuschlagen. Eine die zuverlässig funktioniert.
Hast Du keine echten Probleme zu lösen, für die man tatsächlich einen
32-Bitter braucht?
32 Bit hin oder her. Es geht um die Anzahl der Capture Kanäle und die Breite der Timer.
Der vorgeschlagene Controller ist ein Wald- und Wiesen Controller der "Value Line". Also eben gerade nichts besonderes sondern billiger Standard.
Und wie gesagt, ich habe ein ähnliches Problem erst kürzlich mit exakt diesem Controller gelöst. Welcher Controller wäre deiner Meinung nach denn passender dafür gewesen?
Daß ein gewisser Jitter kein Problem ist hatte ich erwähnt, das hast Du wohl nicht gelesen.
Wenn Du für Geld so entwickelst, entwickelst Du zu teuer.
Warum das bei den Anforderungen nicht funktionieren soll, hast Du immer noch nicht geschrieben aber Du hast wohl auch die Problemstellung gar nicht richtig verstanden.
Gärtnern lasse ich lieber denn da wäre ich ja auch nur Amateur und wenn ich nicht alles wie ein Profi mache mit genau der richtigen rechts- oder linksdrehenden Bioerde, kommt irgendein Spinner an, der behauptet, daß meine Pflanzen so ja gar nicht gewachsen sein können. Nee, den Stress mit diesen arroganten Knallköppen der Gärtnerszene tue ich mir nicht an.
Zeig mal wie. Es ist eben nicht wunderbar zu lösen.
Oh, siehe oben, ganz am Anfang. Was daran erfüllt nicht die Anforderung?
Soll ich Dir Basic übersetzen oder liest Du das gar nicht, weil es BÄH
ist?
Für jemand der 20 Zeilen einfachste Logik in BASIC nicht auf die Kette bekommt hast du echt ne große Klappe.
Die Logik hinter einer SW Abtastung mit frei laufendem Zähler ist simpel und du findest dafür viele Beispiele. Dafür muss ich mir deinen Spagetti nicht an tun.
Letztlich speicherst du den Zählerwert bei einer steigenden Flanke und berechnest die Differenz zum aktuellen Zählwert bei einer fallenden Flanke.
Dabei den zwischenzeitlichen möglichen Überlauf betrachten. Im einfachsten Fall mit einer simplen if Konstruktion.
Dann bist du schon fertig.
Müssen wir über solche einfachsten Hauptschul-IT-Aufgaben hier wirklich reden?
Vielleicht müsste man mit dir mal allgemein über saubere Programmierung reden. Über gute Variablennamen oder irgendwie gekapselte Logik.
DAS wären gute Themen für dich.
Gibts in BASCOM keine Arrays? Wie willst du sowas für n Kanäle machen ohne Arrays?
Alles klar, Du hast das Problem überlesen bzw. nicht verstanden.
Das was Du jetzt beschreibt ist fertig (s.o.) und war gar nicht das Thema.
Es geht hier um die Hardware und den Ablauf der Interrupts. Aber vermutlich ist "Echtzeit" für Dich eine schnelle Reaktion auf einen Tastendruck.
Es geht hier um die Hardware und den Ablauf der Interrupts.
Das steht alles im Datenblatt des Controllers. So kompliziert ist das Interrupt System der AVRs nicht.
vermutlich ist "Echtzeit" für Dich eine schnelle Reaktion auf einen
Tastendruck.
Sind solche Aussagen wirklich notwendig an jemand gerichtet der versucht dir bei einem Problem zu helfen? Ich lese von dir immer nur persönliche Anfeindungen. Sind das Komplexe?
Vielleicht müsste man mit dir mal allgemein über saubere Programmierung
reden. Über gute Variablennamen oder irgendwie gekapselte Logik.
DAS wären gute Themen für dich.
Gibts in BASCOM keine Arrays? Wie willst du sowas für n Kanäle machen
ohne Arrays?
Ahh, einfach mal andere Sachen bemängeln, wenn einem nichts mehr einfällt?
"Spaghetticode", das ist das neue "Fakenews" oder wie? Damit diskreditiert man alles zuverlässig?
Klar geht das mit Array aber hier wohl nicht wirklich hilfreich, vor allem zum Verständnis des Codes. Wie das funktioniert, hast Du aber ja wohl nichtmal versucht zu verstehen.
Es geht hier um die Hardware und den Ablauf der Interrupts.
Das steht alles im Datenblatt des Controllers. So kompliziert ist das
Interrupt System der AVRs nicht.
vermutlich ist "Echtzeit" für Dich eine schnelle Reaktion auf einen
Tastendruck.
Sind solche Aussagen wirklich notwendig an jemand gerichtet der versucht
dir bei einem Problem zu helfen? Ich lese von dir immer nur persönliche
Anfeindungen. Sind das Komplexe?
Du versuchst ja nicht beim Problem zu helfen.
Was glaubst Du, warum ich Bascom und 8-Bit AVR nutze? Wie kann man so ignorant sein? Das sind die Gegebenheiten! Das ist hier keine Firma mit Hard- und Softwareabteilung mit allen Ressourcen sondern es geht um ne Bastelei! Wie verbohrt und beschränkt muss man sein, um das nicht zu kapieren?
Wie verbohrt und beschränkt muss man sein, um das nicht zu
kapieren?
Du weißt aber dass jeder 12 jährige heute STM32 programmiert und das nichts mit prof. Entwicklung vs. Basteln zu tun hat? STM32 SIND BASTELCONTROLLER.
Was glaubst Du, warum ich Bascom und 8-Bit AVR nutze?
Weil du lernfaul bist?
Welche Frage genau ist eigentlich jetzt bei dir noch offen? Tatsache ist, wenn man absolut keinen Wert auf Auflösung oder Jitter legt, passt auch deine Lösung. Auch wenn sie so unsauber ist, dass man sich quasi keine sinnvolle Anwendung dafür denken kann.
Und der Jitter mit der Anzahl der Kanäle zunimmt.
wenn alle Signale auch zeitgleich kommen können, dann wird hintereinander messen und Zwischenspeichern mit gleicher ISR nichts. Man benötigt dann leider für jedes Signal eine eigene ISR mit eigenem Interrupt Flag. Ansonsten gehen welche verloren. Also wenn die Signale wirklich wild durcheinander anliegen können, dass benötigst du für jedes Signal einen eigenen Timer und immer noch nach allen Pulsen und vor den 20ms eine Lücke um alle angefallenen Daten zu verarbeiten.
Wer oder was sendet denn alle Signale durcheinander?
wenn alle Signale auch zeitgleich kommen können, dann wird
hintereinander messen und Zwischenspeichern mit gleicher ISR nichts. Man
benötigt dann leider für jedes Signal eine eigene ISR mit eigenem
Interrupt Flag. Ansonsten gehen welche verloren. Also wenn die Signale
wirklich wild durcheinander anliegen können, dass benötigst du für jedes
Signal einen eigenen Timer und immer noch nach allen Pulsen und vor den
20ms eine Lücke um alle angefallenen Daten zu verarbeiten.
Wer oder was sendet denn alle Signale durcheinander?
Durch das Prüfen der Eingänge in der ISR erkenne ich doch auch die gleichzeitige Änderung von mehreren Signalen.
Das sollte doch im Beispielcode ersichtlich sein.
Die meisten Empfänger schicken die Signale nacheinander (wobei eine fallende Flanke mit der nächsten steigenden Flanke zusammenfällt) aber einige auch alle oder zumindest einige der Signale gleichzeitig.
Man
benötigt dann leider für jedes Signal eine eigene ISR mit eigenem
Interrupt Flag. Ansonsten gehen welche verloren.
Nö, ein gemeinsamer Interrupt reicht vollkommen aus. Sobald sich einer der freigegebenen Pins ändert, wird das Flag gesetzt.
Man braucht nur noch eine Variable zum Merken der vorherigen Pins, um auf Änderung zu überprüfen.
Verlieren würde man nur dann Änderungen, wenn sie schneller als die Zeit zwischen 2 Interrupts sind. Aber das ist durch das Protokoll ausgeschlossen. Jeder Puls muß mindestens 0,5ms lang sein mit 20ms Pause. Der µC hat also alle Zeit der Welt und langweilt sich noch.
Mit 32Bit Kanonen zu schießen, ist daher vollkommen sinnlos.
Natürlich ist Bascom nicht so optimiert, wie ein C-Compiler. Aber Fernsteuerungen sind ja keine Präzisionseingabegeräte, ein Jitter fällt also überhaupt nicht auf. Ebenso haben Servos oft ein erhebliches Spiel.
Verlieren würde man nur dann Änderungen, wenn sie schneller als die Zeit
zwischen 2 Interrupts sind. Aber das ist durch das Protokoll
ausgeschlossen. Jeder Puls muß mindestens 0,5ms lang sein mit 20ms
Pause.
Genau das scheint bei neueren Anlagen nicht mehr in jedem Fall zuzutreffen. Da werden die Ausgänge wild durcheinander geschaltet, auch Überlappungen können vorkommen.
Genau das scheint bei neueren Anlagen nicht mehr in jedem Fall
zuzutreffen. Da werden die Ausgänge wild durcheinander geschaltet, auch
Überlappungen können vorkommen.
Du hast die Aussage nicht verstanden. Jeder Puls hat eine Mindestlänge von 500us. Mit der zeitlichen Abfolge der Pulse hat das nichts zu tun.
Jeder Puls muß mindestens 0,5ms lang sein mit 20ms Pause.
Das war im letzten Jahrtausend zur Zeit der seligen gelben Graupner-Anlagen mal so. Seitdem hat sich in der RC-Fernsteuertechnik doch so einiges geändert.
Die 0.5ms sind nicht überall gegeben, und die 20ms schon mal gar nicht.
Jeder Puls muß mindestens 0,5ms lang sein mit 20ms Pause.
Das war im letzten Jahrtausend zur Zeit der seligen gelben
Graupner-Anlagen mal so.
Willst du damit sagen, dass sich die Spezifikation der Servosteuersignale geändert hat und die Beschreibung der Signale im Artikel Modellbauservo Ansteuerung mittlerweile überholt ist.
Dann sollte der Artikel dringend überarbeitet werden.
Natürlich wird es noch andere Protokolle geben. Nur kann man damit nicht mehr die üblichen RC-Servos steuern.
Es war aber auch nicht gefordert, alle Protokolle der Welt zu erkennen.
Ja, ich habe mich geirrt mit den 0,5ms. Es sind 1ms:
Nein. Das war korrekt. 1ms wird heute von so ziemlich jeder Standard Anlage unterschritten. 800us sind hier normal.
Servotester gehen gerne bis 500 runter.
Ich würde niemals eine RC Puls Erkennung machen die keine 500us schafft.
500-2500 ist ein sinnvoller Bereich.
Die 0,5 passen schon. Die 20 können heute auch deutlich weniger sein,
das ist korrekt.
Die 20ms waren noch nie wirklich fix. Einem Servo ist die Updaterate in relativ weitem Bereich egal, solange die Steuerbewegungen nicht schnell erfolgen müssen. Die Steuerinformation steckt ausschließlich in der positiven Pulsdauer. Die 20ms boten lediglich genug Zeit, um ein Summensignal für 8 Kanäle inklusive Synchronisation im Zeitmultiplex analog über die Funkstrecke zu übertragen.
Nach meinem Verständnis liegt das Problem darin, dass die Impulse der einzelnen Kanäle nicht mehr wie gewohnt schön einer nach dem anderen kommen, sondern wild durcheinander - auch überlappend - auftreten können.
Dadurch entstehen u.U. zwischen 2 Flanken von beliebigen Kanälen Zeiten im kurzen µs Bereich, die die geplante Mimik nicht mehr sicher erkennen kann.
Nach meinem Verständnis liegt das Problem darin, dass die Impulse der
einzelnen Kanäle nicht mehr wie gewohnt schön einer nach dem anderen
kommen, sondern wild durcheinander - auch überlappend - auftreten
können.
Ja, damit muss man heute rechnen. Ein Anwender könnte auch zwei Empfänger anschließen. Annahmen sollte man hier gar nicht treffen.
Dadurch entstehen u.U. zwischen 2 Flanken von beliebigen Kanälen Zeiten
im kurzen µs Bereich, die die geplante Mimik nicht mehr sicher erkennen
kann.
Doch, ist abgedeckt. Weil das Interrupt Flag einfach wieder gesetzt wird, auch wenn ein 2. Puls auftritt während die ISR ausgeführt wird.
Hängt aber auch wenig von der konkreten BASCOM Implementierung ab und wie das mit den I-Flags spielt.
Sollte aber passen.
Jittert halt wie verrückt. Auch weil BASCOM sowieso langsam ist und jeder ISR Aufruf sowieso schon enorm viel Zeit braucht.
D.h. man hat eine max. Auflösung von 32us + einige us Jitter.
Und das bei nominal nur 1000us Gesamtbereich.
Das Problem sieht man, wenn man mit diesem Puls wiederum ein Servo ansteuern würde. Das würde zittern und zucken wie verrückt.
Man
benötigt dann leider für jedes Signal eine eigene ISR mit eigenem
Interrupt Flag. Ansonsten gehen welche verloren.
Nö, ein gemeinsamer Interrupt reicht vollkommen aus. Sobald sich einer
der freigegebenen Pins ändert, wird das Flag gesetzt.
Man braucht nur noch eine Variable zum Merken der vorherigen Pins, um
auf Änderung zu überprüfen.
Verlieren würde man nur dann Änderungen, wenn sie schneller als die Zeit
zwischen 2 Interrupts sind. Aber das ist durch das Protokoll
ausgeschlossen. Jeder Puls muß mindestens 0,5ms lang sein mit 20ms
Pause. Der µC hat also alle Zeit der Welt und langweilt sich noch.
Mit 32Bit Kanonen zu schießen, ist daher vollkommen sinnlos.
Hallo,
hast recht, ich habe mir das nochmal überlegt. Gestern hatte ich in der Überlegung paar Probleme gesehen die nicht vorhanden sind. Die kritische Phase nach Eintritt in die ISR ist die nach dem Auslesen des Portregisters bis zum verlassen der ISR. Wenn hier zu viele Signaländerungen einprasseln, gehen Interruptanforderungen verloren. Das spielt hier aber keine Rolle, genau wie du geschrieben hast, weil unmittelbar nach Verlassen erneut in die ISR gesprungen wird um die Signaländerung am Port einzulesen. Ein selbst heilender Prozess. :-) Die anstehende Signallänge/Pulsdauer ist lang genug damit nichts verpasst wird. Das höchste der Gefühle was passiert sind Fehlmessungen durch zu spätes einlesen.
Nobert kann etwas verbessern. Er kann seinen Timer besser einstellen. Er kann 16Bit verwenden und einen kleineren Prescaler. Der Zählumfang muss nur mindestens 2000µs abdecken. Man kann 16 Bit und Prescaler 1 verwenden und deckt einen Messbereich von 8,1ms ab.
So langsam geht es in die richtige Richtung.
Zu den Servosignalen: Die 20ms waren schon immer nur ein Richtwert aber viele moderne Anlagen halten das heute ein. Allerdings gibt es auch etwas weniger oder bis zu 30ms. Den Servos ist das erstmal egal.
Alelrdings kann man moderne Anlagen auch von den 50Hz auf 400Hz umstellen. bei Reglern für Copter ist das Standard und ambitionierte Fahrer mit schnellen Autos nehmen das für entsprechend schnelle Servos.
Aber hier geht es nur um ca. (!) 20ms.
Das Signal ist üblicherweise 1000-2000µs, wo bei man bei eigentlich allen moderneren Funken erheblich weitere Bereiche einstellen kann, meist +/- 150% Ausschlag, was dann 750 - 2250µs ergibt. Die allermeisten Gerätschaften (Servos) kommen mit 500-2500µs klar.
Mit der Pause zur Synchronisation ist da bei 8 Kanälen natürlich Sense. Also gibt es Empfänger, die strecken das auf 30ms und/oder es kommen 1-8 und 9-16 oder so in Folge aber gleichzeitig. Wenn der Empfänger ein Summensignal ausgibt (PPM), dann sind das meist nur Kanal 1-8. Oder eben S.Bus bzw. die paar anderen Bussysteme, die es da gibt.
Daß die Software die Fallen umschifft wurde ja bereits erkannt. Jitter ergibt sich natürlich, wenn die nächste Flanke in der ISR kommt. Das bewegt sich aber wie erwähnt im µs-Bereich und ist hier ziemlich egal.
Das Wichtigste ist, daß nichts komplett verpasst wird und ich denke das wird erfüllt. Egal was passiert in der ISR, ein Int bleibt ja stehen und es werden sofort danach alle Eingänge geprüft.
Ein Summensignal kann man in Bascom (!) übrigens komplett jitterfrei auslesen, mit der gewünschten Auflösung bzw. was der 16-Bit-Timer hergibt.
Was immer alle mit Bascom haben - das beruht wohl zu großen Teilen auf Unwissen. Wenn mir der Sprung in die ISR mit Sicherung aller Register zu lange dauert (Vorteil: es ist immer die gleiche Verzögerung), dann schalte ich das komplett ab und sichere die nötigen Register manuell. Welche das sind, kann man in Bascom sehen. Das braucht man aber ja fast nie denn ohne Verzögerung geht es ja nicht.
Wenn man die Register für die Hardware direkt anspricht (Timer usw.), dann gibt es mit C exakt Null Vorteil. Der Unterschied ist, für einfache Dinge muss man das nicht tun.
Alles was direkt Hardware ist, setzt Bascom so um, wie man es in ASM direkt schreiben würde oder wie C es übersetzt.
Natürlich gibt es Arrays, hier sollte das aber erst ein Kanal werden und auch bei zwei bringt das noch nicht viel und ich hätte an etlichen anderen Stellen wieder ändern müssen.
Jitter
ergibt sich natürlich, wenn die nächste Flanke in der ISR kommt. Das
bewegt sich aber wie erwähnt im µs-Bereich und ist hier ziemlich egal.
Nunja. Wenn BASCOM wirklich immer alle Register sichert, kommt schon etliches an Takten zusammen. Hatte schon irgendwer vorgerechnet: 32*4 = 128. Bei 8MHz sind das immerhin 16µs allein für das Sichern und Wiederherstellen der Register. Dazu kommt der Interrupt-Frame (mindestens 8 Takte, meist aber 10) und natürlich die Rechenzeit für den eigentlichen Nutzcode.
Rundet man mal großzügig auf 20µs, sind das immerhin 2% des nominellen Messbereichs von 1ms. Oder anders ausgedrückt: Effektiv kann nur noch mit einer Auflösung von 50 Stufen zuverlässig detektiert werden.
Viel schlimmer ist aber: Selbst diese Rechnung geht natürlich nur dann auf, wenn der PCINT der einzige benutzte Interrupt im System ist ist. Konkurrierende Interrupts haben absolut das Potential, dieses Ergebnis noch massiv weiter zu verschlechtern.
Das Wichtigste ist, daß nichts komplett verpasst wird und ich denke das
wird erfüllt.
Das ja. Wenn man mal ein "sauberes" Signal auf allen Kanälen voraussetzt. Aber ein digitales Rauschen auf einem Kanal (z.B. durch einen "halb" ausgefallenen Empfänger) kann unmittelbar das gesamte System zum Erliegen bringen.
Blöd, wenn der Empfänger eines eines völlig unwichtigen Kanals das Modell zum Absturz bringt...
Bascom sichert immer alle Register nur dann, wenn man nicht selbst Hand anlegt. Bei 99,x% der Anwendungen ist das vollkommen egal un man muss sich nicht drum kümmern. Auch hier ist das egal. Auch wenn einige meinen, das müsste doch mit 0,5µs Auflösung und komplett jitterfrei passieren.
Das wird kein Empfänger nach dem Empfänger der Servos ansteuern soll (würde absolut keinen Sinn machen!) und zum Fliegen wird das schon gar nicht benutzt.
50 Stufen, so what? Ich hatte geschrieben, daß ich selbst mit dem Timer mit erbärmlichen 32µs Auflösung bestens leben kann.
Ich dachte, ich hätte alle Kompromisse bereits geschrieben und warum die vollkommen akzeptabel sind.
Aber ein digitales Rauschen auf einem Kanal (z.B. durch
einen "halb" ausgefallenen Empfänger) kann unmittelbar das gesamte
System zum Erliegen bringen.
Wie muss man sich denn digitales Rauschen durch einen halb ausgefallenen Empfänger vorstellen? Das wird keine Steuerung für einen Herzschrittmacher...
Das wird kein Empfänger nach dem Empfänger der Servos ansteuern soll
???
Die PWM-Signale stammen doch irgendwo her. Bei RC-Signalen halt typisch
aus einem Funk-Empfänger. Sagt schon das Acronym: RC = "radio control".
Wo sollen die Signale denn herkommen, ausser aus einem Empfänger? Wenn man damit Servos ansteuern will, dann steckt man die direkt an den Empfänger.
Die Zeiten von irgendwelchen Mischern in Modellen sind vorbei.
50 Stufen, so what?
Wenn dir das reicht? Anderen wäre das halt zu grob.
Wer sind denn die Anderen? Daß die Auflösung hier vollkommen untergeordnet ist, hatte ich auch bereits mehrmals geschrieben. Steht sogar in der Ursprungsfrage:
"Ein kleiner Jitter des Signals, der dadurch entstehen kann (im µs-Bereich) ist zum Glück unerheblich und der Timer ist mit 32µs
Auflösung ja auch recht grob. Das ist völlig ok so."
Ich dachte, ich hätte alle Kompromisse bereits geschrieben und warum die
vollkommen akzeptabel sind.
Wenn alles schick ist, warum hast du dann überhaupt diesen Thread
eröffnet?
Es ging die ganze Zeit nur darum, ob man so keine Flanke verpasst. Steht auch ganz oben so.
Aber alle erklären mir, daß man damit weder Verkehrsflugzeuge lenken und auch nicht Atomkraftwerke regeln sollte und für die Canardregelung eines überkritischen Militärjets reicht das wohl auch nicht.
Daß ich damit aber keine Flanke verpasse, das hattest auch Du bestätigt und nur darum ging es.
sehe es mal von unserer Seite. Das Forum möchte pauschal jedem helfen, Tipps geben, auf mögliche Probleme hinweisen usw. Nur wissen wir nicht was du mit den eingelesen Werten machst. Also schlägt jeder Ideen vor für die für ihn optimale Lösung.
sehe es mal von unserer Seite. Das Forum möchte pauschal jedem helfen,
Tipps geben, auf mögliche Probleme hinweisen usw. Nur wissen wir nicht
was du mit den eingelesen Werten machst. Also schlägt jeder Ideen vor
für die für ihn optimale Lösung.
Das kann ich ja auch irgendwie verstehen.
Allerdings wurden sehr viele Hinweise wiederholt gegeben, deren Irrelevanz ich in der Fragestellung bereits erklärt hatte. 32µs Auflösung des Timers plus Jitter wäre vollkommen ok, das hat wohl kaum einer gelesen. Zu 80% ging es darum, daß das so ja nie funktionieren kann und Bascom sei ja sowieso zu langsam.
Ich hätte die Frage ohne Erwähnung von Sprache, Auflösung des Timers und anderen Details stellen sollen.
Wenn man erwähnt, daß man das mit einer Ersa Station lötet, geht das Bashing von den Weller-Fanboys los und daß das damit ja sowieso nichts wird. Oder umgekehrt. Mal überzogen dargestellt. In Wirklichkeit löte ich privat mit Xytronic und jetzt geht der Shitstorm gleich wieder los ;-)
Ärgerlich ist, daß die ganzen Einwände dann mit den eigentlichen Thema nichts zu tun haben und auch gar kein Problem darstellen.
Auf die eigentliche Frage ist kaum einer eingegangen.
Deswegen fragen viele vielleicht mit so minimalen Informationen, was dann aber auch wieder nervt.
In diesem Thread liegt wohl das Hauptproblem daran, dass Norbert eine doch deutlich andere Auffassung von "so einigermassen bulletproof?" hat, als der Rest der Elektroniker.
In diesem Thread liegt wohl das Hauptproblem daran, dass Norbert eine
doch deutlich andere Auffassung von "so einigermassen bulletproof?" hat,
als der Rest der Elektroniker.
Jepp, ich möchte nur, daß die beschriebenen Erwartungen erfüllt werden. In den meisten Antworten ging es um Dinge, die nicht gefordert wurden.
Das sind schon andere Vorstellungen.
