Zitierendann hatte ich ja doch gar nicht soo unrechtmit dem abschalten der LED =)
Hallo robo,
ja - er hat eine AGC. Jetzt klappts mit LED auschalten und anschließendem Warten von 1ms.
Vielen Dank!
Gruss
M.
dann hatte ich ja doch gar nicht soo unrechtmit dem abschalten der LED =)
Hallo sternthaler.
Es gibt einen Zwischenbericht, aber eher keinen Zwischenstand und leider noch kein wirkliches Zwischenergebnis.
Ein Punkt kommt mir wichtig vor. Einmal schreibt das Datenblatt 2000-01-01 für den 5110 auf Seite 3 unten: Die volle Empfindlichkeit wird bei einer Burstlänge von mindestens 6 Pulsen erreicht. Und das Datenblatt General Application Note for SFH511X (January 30, 2002) sagt auf Seite 1, rechts unten: To improve the SNR (signal to noise ratio) further the filter has a certain time constant. This will make sure, that only light bursts with more than 4 pulses/bit are being detected.
Fazit1: ich muss für eine saubere Messung erst einmal abwarten, bis die PWM den eingegebenen Sollwert angefahren hat. Dann wird es einen Puls dauern, bis der Empfänger das gerafft hat. Und dann sind wohl noch weitere vier bis sechs abzuwarten.
Fazit2: Jetzt muss ich ein bisschen sparsam mit der Zeit umgehen. Immerhin brauche ich für eine komplette Entfernungsbestimmung mindestens 6, besser 7 Iterationen. Mit je sechs Pulsen mindestens
. Da habe ich bis zur Mitte 128 (die beiden Enden der PWM verhalten sich ziemlich identisch - leider hatte ich das früher nicht richtig gesehen). Also step 1: 128. Das ist 2^7. Also - sieben Schritte.
Immerhin stelle ich fest, dass ich mit meiner derzeitigen Ausrüstung doch locker über 1,5 m Distanz komme. Das hatte ich aber noch nicht mit dem hier skizzierten Verfahren gemessen, sondern mit wesentlich längeren Messzyklen. Ausserdem scheint es ziemlich sicher, dass die Abweichung der "optimalen" Frequenz zu einer feineren Unterteilung im Nahbereich führt. Derzeit kenne ich aber auch noch nicht die Unterschiede bei unterschiedlicher Beleuchtung. Es ist ein dämlich langer Weg.
Ciao sagt der JoeamBerg
[OT]Die erste Textfassung ging gründlich daneben - mitten im Bericht - Noteinsatz[/OT]
Mehrere Dinge habe ich bei meinen Tests mit der Sensorplatine (siehe posting vom 12.Feb.) mittlerweile festgestellt. Einschränkend muss ich sagen, dass diese Ergebnisse (vorerst) nur mit ein und demselben Satz 415/5110 gefahren wurden, ich werde (vielleicht) später meine restlichen Bausteine unter meinen Standardbedingungen testen und dann auch weitere, übliche Flächen anstrahlen. Vermutlich werde ich vorrangig noch eine "Dauer-irLeuchte" anbauen, um die deutliche Funktion der AGC zu beeinflussen und zu stabileren Ergebnissen bei unterschiedlichen Bedingungen zu kommen.
Die Geschichte hatte meine dünnen C-Kenntnisse bloßgestellt - und es war wirklich recht Cäh. Vermutlich, nein: sicherlich, ist der Code, der erschreckend kurz für die lange Programmierarbeit ist, nicht optimal. Aber es läuft recht ordentlich.
1) Übersprechen der SendeLED auf Receiver ist durch Schrumpfschlauch nicht zu verhindern
2) Übersprechen der SendeLED auf Receiver ist durch ein Messingrohr zu verhindern, es muss der LED-Fuß zusätzlich z.B: durch einen (dickwandigen) Schrumpfschlauch abgeblendet werden. Der blanke Boden der 415 stört eindeutig nicht.
3) Übersprechen der SendeLED auf Receiver ist beim Aufbau nach 2) ohne Rückenblende des Receivers abgesichert.
4) Übersprechen tritt wieder auf, wenn vor das MSRohr ein Schrumpfschlauch gezogen wird (übersteht).
5) Deutliche Unterschiede der Entfernungsmesswerte zwischen Tages- und Kunstlicht und Dunkelheit.
6) Deutliche Unterschiede der Entfernungsmesswerte je nach Messkörperabmessung und -oberfläche.
7) Es sind wohl nur Bereiche definierbar, wenn man unabhängig von Tageslicht und Oberfläche bleiben will : Nah- Mittel- und Fernbereich.
8 ) Praktisch gleiche Entfernungsmesswerte (unter sonst gleichen Bedingungen) bei PWM-Plateau von „unten“ : 1, 2 …. und „oben“ (ICR1-1, ICR1-2 …).
9) Der 5110 schaltet nur korrekt, wenn die bursts die in den Datenblättern geforderten mind. 6 Pulse aufweisen. Es ist sicherer, mit 7 Pulsen zu arbeiten. 4 Pulse führen eindeutig zu Fehlmessungen.
10) Eine erste Messung bei Tageslicht ist hier vorgestellt, es wurden jeweils ca. 15 Messpunkte für eine Distanz erfasst. Ein Messpunkt besteht aus 100 einzelnen Messungen, deren PWM-Werte für diesen Abstand dargestellt sind. Als Zielfläche diente ein Standard-Papiertaschentuch, eben auf eine Plexischeibe aufgespannt; Ziel der SFH415 war Mitte der Taschentuchs.
11) Zur Frequenz der SFH415 ein Auszug aus meinen Projektnotizen:
Grob ist festzustellen: bei Zimmerbeleuchtung „Essecke“ (alles an, Hängelampe gedimmt) ist ein guter Lauf bei 37,7 kHz festzustellen. 40 kHz gibt praktisch ab 2..3 cm nur „high“. 34 kHz ist ebenfalls recht schlecht. 36kHz ergibt einen eher gröberen Nahbereich bei ähnlichen Werten im Fernbereich wie 37,7. 37,0 kHz (mit irDME_mo1_x14-37.h; ICR1 ist 270) scheint die beste Wahl für feinen Nah- und grossen/fernen Fernbereich zu sein.
12) Die ursprünglich geplanten 6-7 Iterationen zur Bestimmung des Messwertes sind mit meinen C-Kenntnissen nicht machbar - ich musste auf ein stufenweises Hochzählen der Pulsbreite der LED-PWM zurückgreifen. Hier überlege ich noch . . . .
..................................Bild hier
Der Code. Wie gesagt - es war für mich als C-Anfänger schwer, zum Glück hat hier niemand meine anfängliche Stöpselarbeit gesehen. Es fehlte halt an allen Enden, z.B. wie funktionierte die while()-Abfrage ... Aber ich habe ein bißchen dazugelernt.
Der zweimalige Aufruf dieser LED-Puls-Zähl-Zeilen wird nicht als Unterprogramm gefahren, das spart etwa 15 % der immer noch unsinnig langen Laufzeit. Die Routine braucht bei (m)einem mega168/20MHz etwa 6 ms bis ein korrekter Wert da ist - das hängt naturgemäß vom Messwert ab: hohe Messwerte brauchen drastisch weniger Zeit. Ich habe keine Ahnung, wie ich den Programmablauf in C schneller machen kann, allerdings läuft der Compiler noch mit -O0. Sicher wäre das auch eine Möglichkeit für Assembler, aber ich bin ja in die µC-Technik, bzw. embedded computing, eingestiegen, weil ich schon lange C lernen wollte.Code:// ================================================================================= int ReDiM(void) // Relative Distanz Messung, Rückgabewert = Wert der PWM-Ansteuerung { uint8_t mpwm = 0; // mpwm ist der jeweis aktuelle "PWM-Stellwert" bzw. der // endgültige Messwert uint8_t tmp = 0; // temporärer Wert tmp = PINB; // Test, ob ein Signal anliegt mpwm = 1; // Sicherheitshalber PWM ganz klein setSRV1(mpwm); // Ansteuerung der PWM auf for(uint8_t n = 1; n <= 6; n = n + 1) //Es wird die LED auf n Pulse geprüft // Warten, bis irLED dunkler/heller wird. Im Datenblatt des SFH5110 sind sechs Pulse // je burst als Minimum gewünscht. Bei 36 kHz dann ca. 6*26 µs bis zum nächsten Test { // dies statt: // chk_irLED(); //Warte n Pulse der irLED ab while (!(PINB & (1<<PINB1))); // Bit 1 (0..7) gelöscht? <==> irLED aus while (PINB & (1<<PINB1)); // Prüfe, ob Bit 1 (0..7) gesetzt <==> irLED an } for (i = 128; i >= 2; i=i-1) { if (i > 6) i = i-1; if (i > 20) i = i-2; if (i > 40) i = i-6; mpwm = i; setSRV1(mpwm); //PWM für irLED ansteuern for(uint8_t n = 1; n <= 7; n = n + 1) //Es wird n Pulse lang geprüft { // dies statt: // chk_irLED(); //Warte n Pulse der irLED ab while (!(PINB & (1<<PINB1))); // Bit 1 (0..7) gelöscht? <==> irLED aus while (PINB & (1<<PINB1)); // Prüfe, ob Bit 1 (0..7) gesetzt <==> irLED an } tmp = PINB; //Der Empfänger müsste jetzt korrekt schalten if (tmp & 0x08) //Bit 4 gesetzt? Input high? Freistrahl? { //Bit ist high = frei, PWM verstellen break; } else // Bit ist low = bedämpft { } } return mpwm; } /* ============================================================================== */ /* ============================================================================== */ // Aufruf, z.B. aus main mit mecho = ReDiM(); // ================================================================================
Die Timerinitialisierung und PWM-Ansteuerung erfolgt so:
Für beide Abschnitte nehme ich Verbesserungen des Codes gerne an , wie gesagt ....Code:/* ============================================================================== */ /* == PWM-Routinen zur IRLED-ansteuerung auf OC1A/PB1 ======================= */ void TC1SRV_init(void) //Init Timer/Counter 1, PWM-Signal für Servo hin-her { // normale PWM aktivieren (nicht invertiert) TCCR1A |= (1<<COM1A1); //Clear/set OC1A on Compare Match, doc S132. // also Port PB3, vgl. auch PWM-routine unten TCCR1B |= (1<<CS10); // cs10 <=> clk/1 => no prescaling doc S 134 TCCR1B |= (1<<WGM13); // PWM, Phase+Frequency correct doc S 134 ICR1 = 270; // =>PWM-Frequenz 20MHz/(2*nn) => 37,0kHz/ TIMSK1 &= ~(1<<OCIE1A)|(1<<OCIE1B); // Tmr/Cntr1 Oput CompA/B Mtch intrrpt disab TIMSK1 &= ~(1<<TOIE1); // Tmr/Cntr1 Overflow interrupt disabled } /* ============================================================================== */ void setSRV1(uint16_t speed1) //Relative Pulslänge auf OC1A/PB1 {OCR1A = speed1;} // z.B. für SFH5110 oder Servo /* ============================================================================== */
Variablen, die hier nicht deklariert erscheinen, sind in meiner COMMON-h enthalten. Diese ist hier nicht vorgestellt.
Nachtrag 23:28 Uhr: Diagramm aktualisiert mit "Kunstlicht"
Ciao sagt der JoeamBerg
Hallo oberallgeier,
gerade wollte ich auf deinen ersten Beitrag antworten.
Nun macht es aber Sinn eher auf den aktuellen zu antworten.
1) Deine Auswertung, vor allem die mit dem Übersprechen auch mit Schrumpfschlauch, ist sehr hilfreich. Nun, da auch noch die Rückseite abgeschottet ist, scheint von der Seite nun kein Problem mehr zu kommen. Man muss es nur mal von dir vorgemacht bekommen.
2) Die Unterschiede zwischen Tageslicht / Kunstlicht / .. und bei unterschiedlichen Reflektoreigenschaften wurde hier ja schon vorausgesagt. Dies habe ich auch schon 'empirisch' selber nachvollziehen können/müssen. Da müsste man mal versuchen, ob man auch hier durch eine Dunkle-/Hellmessung eine Differenz ermitteln kann, an der man die Umgebungshelligkeit abschätzen kann.
3) So schlimm sieht deine Programmierkunst nun doch nicht aus. Bis auf ein paar winzig Kleinigkeiten ist das doch bestens.
In Cäh schreibt man i = i + 1; In C kann man das mit i++; abkürzen.
Das geht auch am Ende einer for (xxx; yyyy; n++)-Klammer.
In C kannst du i -= 6; schreiben, wenn du i = i - 6; meinst.
Das geht schon mal mit allen +-*/ - Zeichen: x *= 3; <=> x = x * 3;
4) Nun aber ein Problem in meinem Kopf:
Deine Konstruktion zum warten auf n Pulse will mir nicht so recht einleuchten. Ist sauber in C geschrieben, ich meine den Sinn dieser Warterei.
Du wartest mit der Schleife doch auf ein n-faches Pulsen vom Empfängersignal. Dieses Signal aber ist, so wie ich es sehe, schon vom SFH5110 am Ausgang geliefert worden. ****Hier kann mein Denkfehler sein, dass du am PINB1 nicht den Ausgang, sondern etwas anders misst****
Wenn der SFH5110 aber dein Datenlieferant ist, dann benötigst du an dieser Stelle keine Pulse mehr. So wie ich das Datenblatt interpretiere, hat sich da nämlich schon der Baustein drum gekümmert.
Als Datenblatt habe ich immer gerne die Infineon-Datenblätter, da die häufig Deutsch- und Englischsprachig sind. (Ist für mich zum üben der Deutschen äh ne, der englischen Sprache perfekt.)
Hier mal das Dingsda: SFH5110.pdf
Unten im Bild habe ich den Ausschnitt zum Thema 6 Pulse rausgeholt.
Ich bin mir sicher, dass die Pulse nicht von der Software bearbeitet werden müssen.
Hier wird meiner Meinung nach nur mitgeteilt, dass die Bit-Länge eine gewisse Anzahl von Pulsen aufweisen muss. Und somit ergibt sich daraus die maximale Datenübertragungsrate.
Min. 6 Pulse bei 36 kHz für ein Bit sind dann irgendwelche ms oder us. Und das ist dann eben die Obergrenze der Bitgeschwindigkeit.
Ich hoffe, dass ich daneben liege, und du nicht gefrustest bist.
Auf alle Fälle hänge ich hier deine Programmstücke aber mal so dran, wie ich sie schreiben würde. Evl. hilft das beim Übergang von Cäh nach C.
Gruß SternthalerCode:/* ======================================================================== */ /* == PWM-Routinen zur IRLED-ansteuerung auf OC1A/PB1 ================= */ /*---------------------------------------------------------------------------- Init Timer/Counter 1, PWM-Signal für Servo hin-her normale PWM aktivieren (nicht invertiert) ----------------------------------------------------------------------------*/ void TC1SRV_init ( void) { TCCR1A |= (1<<COM1A1); // Clear/set OC1A on Compare Match, doc S132. // also Port PB3, vgl. auch PWM-routine unten TCCR1B |= (1<<CS10); // cs10 <=> clk/1 => no prescaling doc S 134 TCCR1B |= (1<<WGM13); // PWM, Phase+Frequency correct doc S 134 ICR1 = 270; // =>PWM-Frequenz 20MHz/(2*nn) => 37,0kHz TIMSK1 &= ~(1<<OCIE1A)|(1<<OCIE1B); // Tmr/Cntr1 Oput CompA/B Mtch intrrpt disab TIMSK1 &= ~(1<<TOIE1); // Tmr/Cntr1 Overflow interrupt disabled } /*---------------------------------------------------------------------------- Relative Pulslaenge auf OC1A/PB1 ----------------------------------------------------------------------------*/ void setSRV1 ( uint16_t speed1) { OCR1A = speed1; // z.B. für SFH5110 oder Servo } /*---------------------------------------------------------------------------- Relative Distanz Messung, Rückgabewert = Wert der PWM-Ansteuerung ----------------------------------------------------------------------------*/ int ReDiM ( void) { uint8_t mpwm = 0; // mpwm ist der jeweis aktuelle "PWM- // Stellwert" bzw. endgueltiger Messwert uint8_t tmp = 0; // temporaerer Wert uint8_t n; tmp = PINB; // Test, ob ein Signal anliegt mpwm = 1; // Sicherheitshalber PWM ganz klein setSRV1 (mpwm); // Ansteuerung der PWM auf /* Es wird die LED auf n Pulse geprueft. Warten, bis irLED dunkler/heller wird. Im Datenblatt des SFH5110 sind sechs Pulse je burst als Minimum gewuenscht. Bei 36 kHz dann ca. 6*26 µs bis zum naechsten Test */ for (n = 1; n <= 6; n++) // Warte n Pulse der irLED ab { while (! (PINB & (1<<PINB1))) // Bit 1 (0..7) geloescht? <==> irLED aus ; while (PINB & (1<<PINB1)) // Bit 1 (0..7) gesetzt? <==> irLED an ; } for (mpwm = 128; mpwm >= 2; mpwm--) { if (mpwm > 6) mpwm -= 1; if (mpwm > 20) mpwm -= 2; if (mpwm > 40) mpwm -= 6; setSRV1 (mpwm); // PWM fuer irLED ansteuern for (n = 1; n <= 7; n++) // Warte n Pulse der irLED ab { while (! (PINB & (1<<PINB1))) // Bit 1 (0..7) geloescht? <==> irLED aus ; while (PINB & (1<<PINB1)) // Bit 1 (0..7) gesetzt? <==> irLED an ; } tmp = PINB; // Der Empfaenger muesste jetzt korrekt schalten if (tmp & 0x08) // Bit 4 gesetzt? Input high? Freistrahl? break; // Bit ist high = frei, PWM verstellen } return mpwm; } /* ======================================================================== */ /* ======================================================================== */ // Aufruf, z.B. aus main mit mecho = ReDiM(); /* ======================================================================== */
Lieber Asuro programieren als arbeiten gehen.
Hallo Sternthaler,
schlimm, schlimm, schlimm. Da denke ich es sei ausführlich - aber danke, dass Du die missverständlichen Passagen so konstruktiv aufzeigst.
NEIN - die Rückseite der LED ist nicht abgeschottet - aber es ist wichtig, diesen kleinen Bord vom Boden zum eigentlichen body der LED seitlich gegen Abstrahlungen abzudichten. Mein enges Messingrohr sitzt leider auf diesem Bord auf - einen grösseren Rohrinnendurchmesser wollte ich aber nicht nehmen. Dort am Boden ist die Intensität gering und es reicht eben ein Schrumpfschlauch - aber ohne dem müsste ich den 5110 abschotten. Ich verwende an dieser Stelle den dickwandigen, verschweissenden Schrumpfschlauchtyp ohne thermische Behandlung. Weder die Rückseite der LED noch irgendeine Fläche des 5110 ist abgeschottet - siehe Bild.Zitat von Sternthaler
Nachtrag 29.2.08 22:38: Dieser Bord ist an der nackten LED im Bild im ersten Posting dieses Threads sehr gut zu erkennen.
....................................Bild hier
Sonne an und Sonne aus? Welcher Port am Mega168 schaltet mir die Sonne? Ernsthaft: wie messe ich die Beleuchtung (das Umgebungslicht) mit dieser Ausrüstung? Da habe ich keine Ahnung.
Ja, danke, das kenne ich. Aber es gibt nur unwesentlich weniger Tastenanschläge, der Maschinencode ist derselbe und ich finde, dass die Leserlichkeit nicht verbessert wird. Genausogut könnte man das in UPN schreiben, oder, noch schlimmer, ohne Umkehrung, in PN ...
Wie ich im Posting vom 22. Feb. geschrieben habe, erkennt der 5110 laut Datenblättern einen Burst erst nach ein paar Pulsen und reagiert mit einem low-Pegel am SigOUT. Wenn Du das von Dir eingestellte Bild im oberen Posting ansiehst, dann ist dort deutlich gezeigt, dass der Ausgangspegels des 5110 erst nach ein paar Pulsen auf low geht - der Transmitter rattert schon ein paarmal, bevor der Detector reagiert. Dieses feature ist ja ein Teil seiner Tages-/Fremdlicht-Unempfindlichkeit. Daher frage ich den Steuerport der irLED415 ab, und warte eine bestimmte Anzahl (Soll-) Pulse (leider ohne tatsächliche Kontrolle ob die LED an ist), bevor ich den 5110 nach seiner Meinung frage. Sorry, das hatte ich wirklich total missverständlich dargestellt. Und ich sehe in meinen Messungen deutlich: bei vier Pulsen schaltet der 5110 oder auch nicht. Total zufällig. Und bei fünf gehts ähnlich, wenn auch besser. Bei sechs ist die Schaltsicherheit gut - aber wer sagt mir, dass ich gerade am Anfang eines Pulses prüfe? Es könnte ja das Gerade-noch-an-Ende des LED-Pulses sein, daher meine sieben Pulse. Danach kann ich sicher sein, dass der 5110 mein Blinksignal durch die LED verstanden hat und entsprechend reagiert.
Wie dargestellt - NICHT vom Detector - siehe auch Kommentar in meinem Code, z.B. "// Bit 1 (0..7) gelöscht? <==> irLED aus ".
Danke noch für Deine Cäh nach C - Übersetzung. Ich werde das durchgehen - [OT] bin eine Woche in den Tauern und wenn das Wetter schlecht ist oder ich eine lange Snowboardabfahrt habe, oder einen endlos langen Gleitschirmflug (Drachen bleibt in der Garage) - dann habe ich sicher Zeit zum Lesen und Lernen. [/OT]
Warum sollte ich gefrustet sein? Im Gegenteil. Ich weiss ein bißchen besser Bescheid über diese ir-Geschichte mit der Entfernungsmessung mit dem asuro - oder ohne - und das war ja mein anfängliches Problem. Und vielleicht hilft diese Beschreibung anderen Kollegen weiter.
Geändert von oberallgeier (17.10.2016 um 18:48 Uhr) Grund: neuer Bildserver
Ciao sagt der JoeamBerg
Bei LED´s im Allgemeinen, vielleicht. Aber hier .... konnte ich weder vor Deinem Posting noch bis jetzt feststellen. Hattest Du das bei der SFH415 festgestellt? Wie?
Ciao sagt der JoeamBerg
Alle Achtung, ihr treibt die Untersuchung ja ganz schön weit. =D>
Es ist mehr eine Annahme. Früher habe ich einige Versuche mit LED's mit sichtbarem Licht gemacht.Hattest Du das bei der SFH415 festgestellt? Wie?
Ich kann das Experimt mit einer ultrahhellen LED im Schrumpfschlauch empfehlen, das kann man richtig sehen, wo das Licht überall durchkommt. Auch interessant wäre, ob das Platinenmaterial das IR-Licht eventuell etwas durchläst.
Gruß,
robo
Hallo robo.fr,
na ja, ich hatte schon sehr früh festgestellt, dass der von mir verwendete, ca. 1 mm dicke Schrumpfschlauch für die IR-Strahlung der SFH415 recht gut durchlässig ist. Erst mit dem Metallröhrchen wurde die Abschottung sehr gut - und erst mit dem bedeckten "Boden"bordring der LED sah ich über die gesamte Ansteuerungsrampe der LED keinerlei Übersprechen der LED auf den Detector - eine perfekte Strahlendichtheit, sicher auch wegen des elastischen Innenbelags des verschweißbaren Schrumpfschlauchs. Allenfalls ist diese Aussage so einzugrenzen: die durchgelassene Reststrahlung ist bei meiner vorgestellten Konstruktion unterhalb der Nachweisgrenze für den von mir verwendeten 5110
Ciao sagt der JoeamBerg
Hallo oberallgeier,
oh je, dann fehlte mir also tatsächlich nur das genaue lesen und interpretieren deines Kommentars im Code: "Es wird die LED auf n Pulse geprüft"
Jedenfalls war ich schon auf dem Dampfer dies so zu interpretieren.
Nun also mit Volldampf zur Iteration.
Hier erst einmal nur die Idee dies zu realisieren.
Deine Hauptschleife läuft von 128 an abwärts. Wenn wir hier noch eins abziehen, dann kommen wir auf ein Bitmuster von "0111 1111".
Wenn wir nun in 7 Iterationen fertig sein wollen, brauchen wir somit nur die 7 1-en 'irgendwie' zu bearbeiten.
Um, wie es sich gehört, bei der ersten Iteration anzufangen, muss der zu prüfende Wert in der Mitte vom kompletten Bereich (127) liegen.
Bei unserem bisherigen Bitmuster reicht es also, die höchste, gerade zu bearbeitende, Bitstelle auf 0 zu setzen um den Bereich zu halbieren.
Dieses Bitmuster ist nun genau das, was wir für den zu iterierenden PWM-Wert benötigen.
Iteration 7-0:
- Schiebe ein Bit um 7-0 Stellen nach links
- Lösche an dieser Stelle aus dem aktuellen Bitmuster/PWM-Wert das Bit
- Ergibt Bitmuster/PWM-Wert "0011 1111"
- Messen
- Ergebnis: Hindernis (zu weit gemessen)
--- Lasse Iterations-Bit wie es ist ===> Fall 7-0.0
- Ergebnis: Kein Hindernis (zu kurz gemessen)
--- Setze Iterations-Bit wieder auf 1 ===> Fall 7-0.1
Iteration 7-1:
Fall 7-0.0
- Schiebe ein Bit um 7-1 Stellen nach links
- Lösche an dieser Stelle aus dem aktuellen Bitmuster/PWM-Wert das Bit
- Ergibt Bitmuster/PWM-Wert "0001 1111"
- Messen
- Ergebnis: Hindernis (zu weit gemessen)
--- Lasse Iterations-Bit wie es ist ===> Fall 7-1.0.0
- Ergebnis: Kein Hindernis (zu kurz gemessen)
--- Setze Iterations-Bit wieder auf 1 ===> Fall 7-1.0.1
Fall 7-0.1
- Schiebe ein Bit um 7-1 Stellen nach links
- Lösche an dieser Stelle aus dem aktuellen Bitmuster/PWM-Wert das Bit
- Ergibt Bitmuster/PWM-Wert "0101 1111"
- Messen
- Ergebnis: Hindernis (zu weit gemessen)
--- Lasse Iterations-Bit wie es ist ===> Fall 7-1.1.0
- Ergebnis: Kein Hindernis (zu kurz gemessen)
--- Setze Iterations-Bit wieder auf 1 ===> Fall 7-1.1.1
Und schon können wir über die 7 zu bearbeitenden Bits loopen. (Vornehm sagen wir nun iterieren.)
Klar, für "Iteration 7-x" machen wir eine for()-Schleife mit "for (n = 7; n > 0; n--)"
Damit haben wir im Zähler n dann den Schiebewert um uns eine Bit-Maske zu basteln: Bit-Maske = (1<<n)
Und nun noch das Bit-Masken-Bit im Bitmuster/PWM-Wert löschen mit: Bitmuster/PWM-Wert &= ~Bit-Maske
Wenn wir bei "Ergebnis: Hindernis .." nun das Bit wieder setzen sollen, nutzen wir wieder die Bit-Maske um die 1 an der richtigen Stelle im Bitmuster/PWM-Wert wieder einzutragen. Bitmuster/PWM-Wert |= Bit-Maske
Eine Besonderheit gibt es noch.
Die übliche Extremwertbetrachtung kann uns zu einem Bitmuster/PWM-Wert von "0000 0000" bringen.
Hier musst du überlegen, ob es a) zulässig ist, und b) wie man diese Situation sonst abfängt.
That's all.
Cäh in C-Wandlung die 2.te:
Bei der Bitmanipulation wird nun auch mit dem Bit-bezogenem & (and) und dem Bit-bezogenem | (or) eine Kombination bei der Zuweisung mit dem = gemacht. Geht hier somit auch, und wird in C immer wieder gerne genutzt.
Zu der Kurzform n++ kommt noch die Form ++n hinzu. Unterschied? Bei n++ wird 'hinterher', bei ++n 'vorher' an n manipuliert. Lustig wird es damit bei Dingen wie einem Funktionsaufruf á la "TuWas (n++);" oder eben "TuWas (++n);"
Und nun noch ein bisschen smalltalk: Ich wünsche dir/euch? viel Spaß, guten Schnee und angenehmen Aufwind für den Tauern-Aufenthalt. Lass den Schlapptop zu Hause und brich dir nicht die Knochen.
P.S.:Wenn du beim Umsetzen in C Kummer haben solltes, kann bestimmt geholfen werden.
@robo.fr
Da kann man mal sehen, was so alles aus der Kombination waste-IR-Decoder und US-Cirp und Erweiterungsplatine an Arbeit entstehen kann. Irgendwie hatte ich es im Blut, als ich mich doch erst geziert hatte deine Erweiterungsplatine zu nutzen. Das hat man nun davonNur gut, dass oberallgeier hier die ganze Arbeit macht!
Gruß Sternthaler
Da fällt mit noch ein, dass ich etwas zur Sonne schreiben wollte.
Genormt ist der Pin 3 am Port B laut CCG. Im Moment sind da wohl einige abgeschaltet. Zumindest auf der Nordhalbkugel.
Um aber Sonne an und aus zu simulieren, könnte es doch ausreichen, eine Messung mit ganz großer Lichtleistung zu machen und eine Messung mit reduziertem Licht. Irgendwo wird sich bestimmt ein Reflektor finden. Eine Messung sind dann natürlich wieder ein paar 100 Bits die jeweiles gezählt werden. Wenn nun die gezählten Hell-/Dunkelmessungen irgendwie in ein Verhältnis gesetzt werden können, wäre das eventuell die Lösung.
Nun aber Schluß
Lieber Asuro programieren als arbeiten gehen.
Berechtigungen
Lesezeichen