Hallo Zusammen!
Ich habe das MyAVR-Board MK3 und will damit einen SHT11 ansteuern umd
auslesen. Ich bin ein Anfänger in Sachen µCs und habe nun verschiede
C-codes probiert, doch es funktioniert nicht. Mit dem Oszi habe ich die
Funktion überprüft, der Sensor gibt auch ein ACK und irgendwas zurück,
aber es ist halt Blödsinn!
Kann es sein, dass der Atmega2560 zu schnell ist und der Sensor damit
nicht klarkommt? Der ATmega läuft mit 16 MHz.
Auch habe ich den Sensor an einem relativ langen, ca. 50 cm, Kabel,
könnte dies Probleme bereiten?
Vielen Dnk schon mal für Eure Hilfe!
MfG
Konrad
Konrad Bethmann schrieb:> Kann es sein, dass der Atmega2560 zu schnell ist und der Sensor damit> nicht klarkommt?
Du musst den I²C halt langsam genug betreiben. Standard-I²C benutzt
100 kHz Taktrate, “fast” benutzt 400 kHz. Im Zweifel lieber erstmal
mit 100 kHz rangehen.
Ich habe schon erfolgreich mehr als einen SHT-21 an ATmega128RFA1
betrieben, die ebenfalls mit 16 MHz laufen.
Die Länge des Busses ist bei I²C auch nicht so kritisch. Das ist ja
keine Hochfrequenz. Denk dran, den Bus hat Philips so konzipiert,
dass man damit die Bedienelemente innerhalb eines Fernsehgeräts
anschließen kann. Die liegen auch nicht alle auf 10 cm beieinander.
Jörg Wunsch schrieb:> Du musst den I²C halt langsam genug betreiben. Standard-I²C benutzt> 100 kHz Taktrate, “fast” benutzt 400 kHz. Im Zweifel lieber erstmal> mit 100 kHz rangehen.
Der SHT11 hat kein I2C. Ist aber ähnlich.
Jörg Wunsch schrieb:> Die Länge des Busses
Ich betreibe einige SHT11 an 5m abgeschirmter Mikrofonleitung, also
richtig viel Kapazitätsbelag. Das geht zuverlässig, allerdings nicht mit
100kHz Takt.
Der Sensor ist recht unkritisch im Handling.
A. K. schrieb:> Der SHT11 hat kein I2C.
Ja, hatte ich so dunkel in Erinnerung. Daher hat's auch keinen Sinn,
meinen SHT-21-Code zu posten.
> Ist aber ähnlich.
Eben, insofern unterscheiden sie sich elektrisch nicht viel. Man kann
halt nur nicht das TWI-Modul zur Ansteuerung nehmen, sondern muss es
„zu Fuß“ implementieren.
Danke an Alle für die schnellen Antworten!
Ich werde mal heute Abend ein Bild machen, aber ich habe Den Widerstand
und den Kondensator richtig angeschlossen!
Ich hänge einfach mal den Quellcode mit an, vielleicht ist der Fehler
dort versteckt!
Danke schon mal im Voraus!
LG
Konrad
P.s.:
Ich habe eine RAR-Datei angehangen und alle Datein noch mal so, kann
sein, das einige das RAR nicht öffnen können
Die Haupt datei ist : LCD_BOARD.c, die Unterprogramme liegen in
SHT_TEST.c, und MK3_2560_LCD.h ist für das Display, nur zur Erklärung!
Danke A.K., deine code habe ich mir auch schon angesehen, da ich aber
absoluter Änfänger bin, konnte ich nicht recht was mit anfangen, wäre
super, wenn du mir einenen lauffähigen code geben könntest, also mit
Main. Ich weiss, es klingt doof, doch ich plage mich nun schon recht
lange damit rum und komme auf keinen Grünen Zweig, dass mir die Lust
bald vergeht!
LG
Konrad
Konrad Bethmann schrieb:> wenn du mir einenen lauffähigen code geben könntest, also mit Main.
Sinnlos, da konfigurationabhängig.
PS: Die Messroutine ist in
Beitrag "Re: Sensirion SHT11 Code"
Wann das auch nicht reicht, dann fang man mit dem üblichen Beispiel
einer blinkenden LED an.
Hi A. K.!
Alles klar, dann werde ich mich mal mit der Messroutine
auseinandersetzen.
Die Konfiguration einstellen und auch ne LED blinken lassen, dass klappt
schon. Soweit bin ich dann doch!
Was mir gerade aufgefallen ist, ich sollte vielleicht die
Compillerwarnungen nicht ganz ignorieren, das hilft bestimmt!
LG
Konrad
Konrad Bethmann schrieb:> ich sollte vielleicht die Compillerwarnungen nicht ganz ignorieren, das> hilft bestimmt!
Das ist immer eine gute Idee.
Man kann natürlich gelegentlich auch mal eine Warnung in Kauf nehmen,
aber nur, nachdem man sich gründlich vergewissert hat, dass sie für
eine konkrete Situation tatsächlich bedeutungslos ist.
In der Regel fährt man mit einer “zero warnings policy” immer noch am
besten.
Ich habe bissel was geändert und nun keineWarnungen mehr, aber leider
auch den Sensor nicht da, um ihn auszuprobieren, werde heute Abend
berichten!
LG
Konrad
Hi Zusammen!
Auf den Rat von A.K. hin habre ich seinen Code genommen und mir ein
Programm zum Auslesen des SHT11 gebastelt, aber es passiert immer noch
nichts. Vielleicht könnte ja der ein oder andere mit Erfahrung mal über
das Programm schauen und vielleicht findet er ja den Fehler. Ich hänge
auch mal die Source datei von A.K. mit an, damit ihr wisst von welchen
Unterfunktionen die rede ist.
Ich denke, dass die Ergebnisse in der Variable "v" gespeichter werden
und deshalb wollte ich sie mir auf dem Display anzeigen lassen, aber da
kommt entweder eine 0 oder, wenn ich v vorher initialisiere eben die
Zahl, mit der ich initialisiert habe, keine Ahnung, wo mein Fehler
liegt.
Vielen Dank schon mal fürs ansehen!!
VG
Konrad
P.s.: Das Display funktioniert, also da kann es keine Probleme geben!
Hier der Code:
Beim Code im Anhang nützt es garantiert nix, den Takt nach <delay.h> zu
definieren. Und der direkt gepostete Code ruft die Messung nicht auf.
Es fehlt die Hardware-Beschreibung, also Schaltbild und Foto, sowie und
dein config.h.
Sorry, natürlich habe ich in der Main while-schleife das Unterprogramm
"feuchte_messen()" drin, da ist mir ein Fehler beim kopieren passiert
die config.h hänge ich mit an
Tut mir leid, dass ich nicht gleich alles vollständig hatte!
VG
Konrad
Hi zusammen!
Leider kann ich gerade keinen Schaltplan erstellen und auch kein Foto
machen. Der SHT11 ist wie im Datenblatt verdrahtet, sprich 100
nF-Kondensator zwischen GND und Vcc, sowie ein Widerstand, 10 k,
zwischen DATA und Vcc und dann halt an das MK3-Board, die Leitungen sind
nun auch kürzer, ca 10 cm, es sollte alles passen, aber es tut sich
nichts!
Danke für die Hilfe im _Voraus!
VG
Konrad
hi zusammen!
Nun habe ich doch noch ein bild der Sensorbeschaltung machen können,
aber laut datenblatt dürfte das so passen!
hat jemand zeit gefunden, mal in den code zu schauen, ob es da einen
fehler gibt?
Danke noch mal!VG
Konrad
Hallo Konrad,
was mir auf die Schnelle aufgefallen ist, dass das toggeln der
Clock-leitung mit 2u recht kurz ist. Laut Datenblatt ist typisch 0,1 Mhz
angegeben.
Versuche als mal alle Delays auf 10u hochzusetzen.
Kannst Du Dir die Clock und Data mit einem Ozi oder Logikanalyser
ansehen?
Gruß
Thomas
mein Datenblatt ist schon älter von 2008.
Max ist dort mit 5Mhz angegeben, typisch aber mit 0,1 Mhz bei 5V.
Schaden kann es jedenfalls nicht, die Clock mal zu senken.
Gruß
Thomas
Thomas E. schrieb:> mein Datenblatt ist schon älter von 2008.
Interessant. Da hat sich wohl nicht nur das Datasheet geändert.
Meine Datasheet war bisher die V3 von 2007. Ein "typ" Wert steht dort
nicht drin. "Data sheet valid for SHTxx-V4 and SHTxx-V3"
In der aktuellen völlig anders gestalteten V5 des Datasheets steht nun
"Reference to V3 sensors eliminated."
Konrad Bethmann schrieb:> Nun habe ich doch noch ein bild der Sensorbeschaltung machen können,> aber laut datenblatt dürfte das so passen!
Dem Bild lässt sich die Beschaltung nicht wirklich entnehmen.
Beispielsweise wo der Widerstand dran hängt, und mit welchen Pins vom
Controller der Sensor verdrahtet ist.
Hi!
Ich werde mal versuchen, die Taktrate zu senken, vielleicht hilft es.
Der Widerstand ist an DATA und an Vcc.
Data und CLOCK sind an PORT D, DATA PD7 und CLOCK PD4.
GND und Vcc sind an der Spannungsversorgung des MK3-Boards, mi U = 4,9V
Das sollte also alles passen.
VG Konrad
Konrad Bethmann schrieb:> Ich werde mal versuchen, die Taktrate zu senken, vielleicht hilft es.
_delay_us(5) statt _delay_us(2) schadet sicher auch nicht.
Und mach ein _delay_ms(11) vor die Initialisierung.
Nun habe ich das Delay raufgesetzt und auch vor der Initialisierung eins
gemacht, es ändert sich rein gar nichts, was mich echt nervt!!
Vielleicht lege ich das Teil erstmal zur Seite und sehe morgen oder
übermorgen weiter, heute wird das glaube nichts mehr!
VG
Konrad
Guten Morgen zusammen!
Nun habe ich nochmals bissel am Code gefeilt und es passiert trotzdem
nichts!!
Leider habe ich auch gerade kein Oszi zur hand, was mich ärgert!
Hier kommt mal der CODE, vielleicht hat ja einer ne Idee
VG
Konrad
p.s.: er wurde problemlos compiliert!
Konrad Bethmann schrieb:> #define sht_port DDRB // Richtungsregister definieren> #define sht_o PORTB // Ausgangsport definieren> #define sht_i PINB // Eingangsport definieren> #define data PB0 // Datenleitung zum Sensor> #define clk PB1 // Steuerleitung zum SensorKonrad Bethmann schrieb:> Data und CLOCK sind an PORT D, DATA PD7 und CLOCK PD4.
Also was nun? Port D/4+7 oder Port B/0+1?
Konrad Bethmann schrieb:> void data_lo(void) // 0 an DATA> {> sht_o &=~(1<<data);> }
Bedenke, dass die DATA Leitung als open drain angesteuert werden sollte.
Also einmalig PORTx.y=0 setzen und dann nur noch über DDRx.y steuern,
mit 0=high/input und 1=low.
Beachte, dass der Sensor nach Powerup und Reset-Befehl ein Weilchen
nicht ansprechbar ist.
Entschuldige A.k., ich hatte einen neuen Code geschrieben und da war die
Portbelegung anders, also an Port B und nicht D. Danke für deinen
Hinweis mit der DATALeitung!
VG
Konrad
Guten Abend zusammen!
Da ich diese Woche nicht mehr AN EIN VERNÜNFTIGES oSZI KOMME; WERDE ICH
WOHL ERST mONTAG WIEDER MICH DEM sENSOR WIDMEN1! Zufälligerweise hatte
ich noch eine NI-Karte da, doch die kann nur 100k S/s damit konnte ich
nichts richtiges anfangen!
Also, am Mo gehts weiter, muss doch irgendwann mal klappen!
VG
Konrad
Hi zusammen!
Nun habe ich zwei sht11 ausprobiert, nichts rührt sich!
Gibt es irgendeine möglichkeit, mit der ich testen kann, ob die Sensoren
noch funktionieren?
VG
Konrad
for(i=0x80;i>0;i/=2)// Mit einer Schleife das 8-Bit Datenwort
3
// bitweise einlesen
4
{
5
clk_hi();delay();
6
if(PINB)cWert=(cWert|i);
7
...
ist mir in der Lesroutine etwas zu progressiv. Den kompletten PINB zu
benutzen, dürfte recht sicher nicht zielführend sein.
Ausserdem: Wieso steht da PINB direkt im Code und nicht sht_i?
1
...
2
for(i=0x80;i>0;i/=2)// Mit einer Schleife das 8-Bit Datenwort
3
// bitweise einlesen
4
{
5
clk_hi();delay();
6
if(sht_i&(1<<data))cWert=(cWert|i);
7
...
weiter hab ich dann nicht mehr geschaut. Insbesondere hab ich nicht
überprüft, ob die Reihenfolge der Pinbewegungen Sinn ergeben und/oder
mit den Vorgaben vom Sensor übereinstimmen.
Ausserdem wäre drauf hinzuweisen, dass
char i;
for(i=0x80;i>0;i/=2)
mit Sicherheit nicht die gewünschte Wirkung hat, wenn man bedenkt, dass
der char Typ ein Vorzeichen hat und GCC deshalb die Schleife komplett
entfernt.
A. K. schrieb:> Ausserdem wäre drauf hinzuweisen, dass> char i;> for(i=0x80;i>0;i/=2)> mit Sicherheit nicht die gewünschte Wirkung hat, wenn man bedenkt, dass> der char Typ ein Vorzeichen hat und GCC deshalb die Schleife komplett> entfernt.
Ja, darüber wollte ich schon (fast) schreiben. Aber der Code ist so
grauslich formatiert, dass ich mir den nicht weiter antun will.
Übrigens kommt das PINB Problem auch noch an anderen Stellen im Code
vor.
Hallo zusammen!
Dankefür die schnellen Antworten, ich habe nun die Änderungen eingebaut
und den Code auch (hoffentlich) besser formatiert.
Aber es brachte leider gar nichts. Vielleicht könnt ihr ja nochmal
drübersehen.
Nun habe ich zwar im Code die ganzen Displaysachen rausgenommen, doch
ich habe die Funktion des Sensors mit dem Oszi kontrolliert und er gibt
nichts zurück!
Die Textformatierung sah in meinem Editor viel besser aus, sorry dafür!
Und auch sorry, wenn ich zusehr damit rumnerve, ich würde den Sensor nur
gern zum Laufen bringen
Konrad Bethmann schrieb:> Die Textformatierung sah in meinem Editor viel besser aus, sorry dafür!
Das ist meistens so, wenn man TABs verwendet. Und als Anhang statt
inline hätte sich das auch nicht schlecht gemacht.
Der 'char ist beim gcc signed' Fehler ist immer noch drinnen.
Merke: WEnn du mit Bytes hantierst, dann nimmst du nicht den Datentyp
'char' sondern entweder 'unsigned char' oder 'uint8_t'.
Du fährst am besten, wenn du dir angewöhnst, dass es 3(!) kleine
Datentypen gibt.
* "signed char" bzw. "int8_t"
Die nimmst du für alles, wofür du nur kleine Zahlen brauchst, die aber
mit Vorzeichen. Also zb wird eine WOhnraumtemperatur wohl selten größer
als +127 bzw. kleiner als -128° Celsius sein. Ein int8_t wäre also
passend, wenn keine Kommastellen gebraucht werden, aber negative Zahlen
möglich sein sollen.
* "unsigned char" bzw. "uint8_t"
Die nimmst du immer dann, wenn du kleine Zahlen ohne
Vorzeichenerweiterung brauchst. Genau das ist der Datentyp der Wahl wenn
man mit Bytes hantiert. Denn hier will man keine Sonderbahandlung eines
Bits als Vorzeichenbit haben. Ansonsten natürlich für alles, was nicht
negativ werden kann. Zb die Anzahl an Schweissgeräten im Lager einen
kleinen Schlosserei wird eher selten negativ sein und wohl auch selten
größer als 255.
* "char"
Reine 'char' benutzt du nur dann, wenn du Textverarbeitung machst. Da
kannst du es dem Compiler überlassen, ob er einen char als signed char
oder als unsigned char implementiert. Aber auch nur da! In allen anderen
Fällen überlässt du es nicht dem Compilerbauer sondern benutzt explizit
entweder signed oder unsigned
Und Programm erst mal abspecken.
Du hast Probleme mit der Kommunikation? Dann interessiert die Auswertung
erst mal überhaupt nicht. Was dich interssiert ist, dass du 1 Byte zum
Sensor schickst und vom Sensor 1 Byte (oder mehrere) als Antwort
kriegst. Alles andere in deinem Programm ist erst mal nur überflüssiger
Ballast, der selbst wieder Fehler enthalten kann.
in deinem Editor besser aussieht.
Abgesehen davon, dass es immer noch falsch ist. PINB durch sht_i zu
ersetzen löst nicht das Problem, dass du immer noch den kompletten Port
einliest und nicht nur den einen interessierenden Pin.
Ich hab jetzt das Datenblatt des SHT nicht studiert. Darf man eigentlich
das Timing der Ansteuerung beliebig langsam machen? Wenn ja, dann würde
ich das mal empfehlen.
Es hat sich eingebürgert, den Namen von Präprozessordefinitionen gross
zu schreiben. Wenns nicht grad das Äquivalent einer Funktion ist. So ist
beispielsweise dein "data" für geübte Leser von C Quellcode ziemlich
irritierend.
Karl Heinz schrieb:> Darf man eigentlich> das Timing der Ansteuerung beliebig langsam machen?
Ja.
> Wenn ja, dann würde ich das mal empfehlen.
Und dabei zusehen.
Apropos Timing, zum ca. dritten Mal: Der SHT ist ein Morgenmuffel. Wie
viele seiner Anwender auch, darf er anfangs erst einmal ein Weilchen
nicht angesprochen werden.
Karl Heinz schrieb:> Was dich interssiert ist, dass du 1 Byte zum> Sensor schickst und vom Sensor 1 Byte (oder mehrere) als Antwort> kriegst.
Oder zunächst einmal das ACK Bit der grob an I2C orientierten
Kommunikation.
Konrad Bethmann schrieb:> void data_lo(void) // 0 an DATA> {> sht_i |= (1<<data);> }>> void data_hi(void) // 1 an DATA> {> sht_i &=~(1<<data);
Um einen Ausgang zu steuern muss man den Eingang verändern?
Wäre nicht sht_o der geeignetere Kandidat?
In einigen der gängigen Libs wird entgegen dem Datenblatt nicht Open
Drain genommen sondern "hart" angesteuert. Wenn man den Takt
entsprechend steuert, geht das prima. Über den Eingang geht es definitiv
aber nicht.
Georg G. schrieb:> In einigen der gängigen Libs wird entgegen dem Datenblatt nicht Open> Drain genommen sondern "hart" angesteuert.
Bei 8051 Ports ist das auch nicht wirklich "hart". Um den Pullup kommt
man auch dann nicht herum und falsch bleibt auch dann falsch, wenn es
funktioniert. Es geht auch nur um die Datenleitung. Die Taktleitung ist
unidirektional.
Der TO verwendet einen ATMega. Und auch die Libs, auf die ich mich
beziehe, sind für ATMega. Glaub mir einfach, es funktioniert
hervorragend. Der SHT11 wird nur bei passendem Taktpegel niederohmig. Du
hast alle Zeit der Welt, den Ausgang umzuschalten.
Hi Zusammen!
Vielen Dank nochmal für die Hinweise!
Ich habe nun den Verdacht, dass der Sensor kaputt ist, da ich den Befehl
für die Temperaturmessung gesendet habe, Oszi sei dank, konnte ich es
auch "ansehen".
Aber es fehlt die Bestätigung des Sensors, das der Befehl gültig war.
Es kann sein, dass ich ihn vorhin beim anschliessen verkehrt gepolt
habe, das nimmt er mir bestimmt übel, schöner Mist!
Einen Sensor habe ich noch, mal sehen, ob es damit klappt!
VG
Konrad
Hi!
Anscheinend ist auch ein weitere Sensor kaputt, er gibt keine
Bestätigung, wenn ich ihm ein Komando sende!
Ich warte erstmal, bis ich neue Sensoren bekomme und sehe dann weiter!
VG
Konrad
hi Dirk!
Ja, es ist nicht sehr wahrscheinlich, aber ich denke mal, zwei Sensoren
sind durch meinen Dummheit kaputt gegangen, da ich sie verkehrt gepolt
angeschlossen habe, bei einem habe ich es auch gerochen, also eigene
Dummheit!!
VG
Konrad
Hi zusammen!
Als ich mir noch makl alles angesehen habe, auch meine
Osziaufzeichnungen, fiel mir auf, dass ein Hight an DATA nur knapp 2V
sind, der Sensor braucht aber laut Datenblatt min. 80%Vdd was in meinem
Fall 3,84 V sind, die aber nicht anliegen. Kann es sein, dass dadurch
nichts passiert, klingt mir sehr logisch!
Ich habe extra noch mal nachgesehen, es ist auch ein 10k Widerstand, der
zwischen DATA und Vdd hängt, wie im Datenblatt angegeben!
Die meisten hier nehmen auch die 10 K, und es funktioniert, nun verstehe
ich den Fehler erst recht nicht!
Viele Grüße
Konrad
Konrad Bethmann schrieb:> Als ich mir noch makl alles angesehen habe, auch meine> Osziaufzeichnungen, fiel mir auf, dass ein Hight an DATA nur knapp 2V> sind
Ohne Sensor ?
Wenn keine Kommunikation läuft, dann sollte auf der DATA Leitung über
den Pullup-Widerstand die volle Versorgungsspannung anliegen. Wenn das
nicht der Fall ist, dann ist was faul. Egal ob das 10K sind oder
weniger, die Leitung ist muss offen sein.
Bei einem defekten Sensor ist an dieser Stelle natürlich alles möglich.
Wenn die 2V aber auch ohne Sensor zu messen sind, dann hast du ein
gänzlich anderes Problem.
Hi zusammen!
Welch Wunder, nun funktioniert es doch irgendwie, zumindest sieht es so
aus, dass der Sensor meinen Befehl akzeptiert und was misst. Er legt die
Datenleitung nach dem Befahl kurz auf Low und dann wieder higth. Nun
dauert es ne Weile und dann wird die Datenleitung wieder low. Habe ich
das Datenblatt richtig verstanden, dass ich nach dem Low auf der
Datenleitung (nach der Messung) Wieder pulse auf die SCL-Leitung geben
muss und bit für bit die Messwerte auslesen kann?
VG
Konrad
Ist die DHT22 Software nicht zu den DHT11 / SHT11 kompatibel ?
http://moretosprojects.blogspot.de/2014/01/dht22-blocking-library-for-avr.html
Sie funktioniert bei mir wunderbar.
Man kann aber nur maximal alle 2 Sekunden einen neuen Wert bekommen,
steht jedenfalls so im Datenblatt.
Im DHT22 ist ein 4k7 Ohm Widerstand von Vcc nach Data schon integriert.
Anscheinend funktioniert der Sensor wirklich, denn wenn ich den Befehl
zur Feuchtemessung gebe, ist die Datenleitun viel eher wieder auf low,
als wenn ich den Temperaturbefehl sende.
Nach dem ich einige Leute bestimmt zur Verzweiflung getrieben habe,
wofür ich mich entschuldige, ist das Fazit des Ganzen, nicht einfach
Blind fremden Code zu übernehmen, sonsdern selbst was tun!
Danke trotzdem für die Hilfe und wenn ich auch richtige Daten habe(z.B.
Temperaturwerte), dann werde ich mich wieder melden!
VG
Konrad
In dem DHT22 Code von dem Brasilianer kann man das mit den Zeiten
wunderschön sehen, der Code ist übersichtlich und hat mir sehr geholfen.
Ich hatte damals auch Probleme damit, zum einen weil mir eine
Interruptroutine immer während des Lesevorganges reingesprungen ist und
ein anderes mal weil ich + und Data vertauscht hatte.
Guten morgen zusammen!
Evtl. Können mir die C-Profis noch mal helfen!
Nachdem ich nun Hoffnung habe, dass der Sensor tut, was er tun soll,
komme ich nicht weiter. Laut datenblatt legt der SHT11 während einer
Messung DATA auf higth und wenn die Messung beendet ist zurück auf low.
Nun wollte ich mit folgender Schleife warten, bis wieder Low ist und
dann weitermachen, doch es klappt nicht und ich erkenne den Fehler
nicht!
for (a=0;a<65035;a++)
{
if (!(PIND & (1 << data)))
{break;}
else {_delay_us(6);}
}
// Byteeinlessen
...
Wie gesagt, nichts passiert!
VG
Konrad
@Mike
Danke für deine Hinweise, bin noch nicht dazugekommen, mir den Code
richtig anzusehen!
Warum nimmst du nicht erst einmal eine erprobte Lib und änderst dann
nach deinen Vorlieben?
Hier eine simple Leseroutine (die den Port nicht Open Drain macht, aber
dennoch funktioniert).
Die Messung mit Warteschleife:
Hallo Georg!
Danke dir. Ich habe schon einige Libs probiert und nie hat was
funktioniert, deshalb habe ich aus den verschiedenen Versionen selbst
was zusammen gesetzt, ohne viel Gedöns, aber es klappt nicht so wie ich
das will, ich werde wohl noch mal was tun müssen!
VG
Konrad
Hallo Zusammen!
Nun läuft es wunderbar!!!
Ich habe den Code von A.K. genommen und es klappt!
Ich habe einen ziemlich dummen Fehler gemacht, aber es funktionier und
hatte nichts mit dem Auslesen des Sensors zu tun!!
Vielen Dank noch mal an alle, aUCH WENN ES VERMEIDBAR GEWESEN WÄRE; SO
HABE ICH ZUMINDEST VIEL GELERN; DAS IST MIR AUCH WICHTIG!
VG
Konrad