Moin,
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?
Gruß,
Norbert
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.
RC = (Infrared) Remote Control?
Norbert S. schrieb:> 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.
Norbert S. schrieb:> 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.
Man nutzt einen 16 Bit Timer mit Input Capture.
Damit kann man das Signal mit 0,5µS auflösen. Ohne weitere Klimmzüge.
Das reicht für die meisten Anwendungen.
Peter D. schrieb:> 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.
Oliver
Johannes F. schrieb:> RC = (Infrared) Remote Control?
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.
Cyblord -. schrieb:> 0,5µS
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.
Rainer W. schrieb:> 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.
Depp
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.
Claus P. schrieb:> 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.
Johannes F. schrieb:> 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...
Peter D. schrieb:> 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.
Peter D. schrieb:> Typisch benutzt man allerdings nur einen Fernsteuersender und dann> kommen alle Kanäle nacheinander über nur einen Pin.
Du meinst wohl das Summensignal PPM, das liegt hier (oft) nicht vor.
Das ist nicht für genau einen Empfänger.
Cyblord -. schrieb:> Man nutzt einen 16 Bit Timer mit Input Capture.>> 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...
Matthias S. schrieb:> 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...
Norbert S. schrieb:> 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.
Norbert S. schrieb:> 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.
Cyblord -. schrieb:> Norbert S. schrieb:>> 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...
Michael B. schrieb:> 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.
Norbert S. schrieb:> Das ist in Bascom und da werden alle Register beim Sprung zur> INT-Routine gesichert.
Wenn das wirklich so erfolgt: 32*(PUSH+POP) = 128 Zyklen nur dafür.
Cyblord -. schrieb:> Was ein Unsinn.> Selbst mit einem STM32G07 kann man >10 Input Capture Kanäle haben.
Was für ein Geschwätz von Cyblord wieder, offenbar die Problemstellung
nicht gelesen
Norbert S. schrieb:> immer AVR 8-Bitter mit Bascom, auch hier wieder
Michael B. schrieb:> Norbert S. schrieb:>> immer AVR 8-Bitter mit Bascom, auch hier wieder> Wenn man nicht nachdenken will nimmt man Stumpf immer wieder die> gleichen altbackenen ungeeigneten AVR und niemals was modernes.
Hier gibt es 12 Capture Eingänge an einem popligen billigen STM32G07.
16 Bit natürlich.
https://www.st.com/en/microcontrollers-microprocessors/stm32g070kb.html
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!"
Norbert S. schrieb:> 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.
Cyblord -. schrieb:> 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?
Norbert S. schrieb:> Cyblord -. schrieb:>> 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.
Norbert S. schrieb:> 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?
Cyblord -. schrieb:> 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.
Cyblord -. schrieb:> Norbert S. schrieb:>>> 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?
Norbert S. schrieb:> 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.
Hallo,
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?
Veit D. schrieb:> Hallo,>> 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.
Veit D. schrieb:> 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.
Peter D. schrieb:> 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.
Dieter W. schrieb:> 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.
Peter D. schrieb:> 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.
Oliver
Oliver S. schrieb:> Peter D. schrieb:>> 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.
Oliver S. schrieb:> Die 0.5ms sind nicht überall gegeben, und die 20ms schon mal gar nicht.
Die 0,5 passen schon. Die 20 können heute auch deutlich weniger sein,
das ist korrekt.
Oliver S. schrieb:> Die 0.5ms sind nicht überall gegeben, und die 20ms schon mal gar nicht.
Ja, ich habe mich geirrt mit den 0,5ms. Es sind 1ms:
https://en.wikipedia.org/wiki/Servo_control
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.
Peter D. schrieb:> 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.
Cyblord -. schrieb:> 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.
Rainer W. schrieb:> Dann sollte der Artikel dringend überarbeitet werden.
Das ist ein Wiki. Jeder, der fachlich und schöpferisch in der Lage ist,
das zu verbessern, darf das jederzeit tun.
Peter D. schrieb:> Ja, ich habe mich geirrt mit den 0,5ms. Es sind 1ms:> https://en.wikipedia.org/wiki/Servo_control
Eigentlich musst du nur den Artikel lesen. Da steht alles drin.
Peter D. schrieb:> Natürlich wird es noch andere Protokolle geben. Nur kann man damit nicht> mehr die üblichen RC-Servos steuern.
Es gibt keine anderen Protokolle. Das ist immer ein pulsweitenkodiertes
Signal, und das versteht auch jedes RC-Servo.
Die 20ms sind schon seit vielen Jahren obsolet.
Oliver
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.
Dieter W. schrieb:> 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.
Peter D. schrieb:> Veit D. schrieb:>> 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.
Norbert S. schrieb:> 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.
Ob S. schrieb:> 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...
Norbert S. schrieb:> Bei 99,x% der Anwendungen ist das vollkommen egal
Das sagst du...
Dazu hast du aber nicht das Recht und auch nicht den Überblick.
Allenfalls könntest du sagen "bei 99,x% meiner Anwendungen..."
> 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".
> 50 Stufen, so what?
Wenn dir das reicht? Anderen wäre das halt zu grob.
> 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?
Ob S. schrieb:> Norbert S. schrieb:>> 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.
Hallo Norbert,
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.
Veit D. schrieb:> Hallo Norbert,>> 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.
Andi B. schrieb:> 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.
Thread beobachten
Seitenaufteilung abschalten