Hallo,
ich habe mit dem Hope Drucksensor HP03 etwas experimentiert und dafür
ein Programm in Bascom-AVR geschrieben.
Nach einigen Anlaufschwierigkeiten liessen sich die Kalibrierdaten
auslesen und auch der Zugriff auf die Luftdruck- und Temperaturdaten
klappt grundsätzlich.
Während der Rohwert der Luftdruckdaten (D1) mit etwa 30000 im
erwartbaren Bereich liegt, sind die Werte meiner ausgelesenen
Roh-Temperaturwerte (D2) mit ca. 36000 m.E. viel zu hoch. Im Beispiel
des Datenblatts liegen sie bei 4100 und bei anderen Nutzern ( die mit
einem völlig anderen Prozessorsystem unter Verwendung auch einer anderen
Programmiersprache arbeiten ) lagen sie auch im Bereich zwischen etwa
3000 und 8000.
Bei unzähligen Versuchen habe ich dann irgendwann festgestellt, dass ich
"vernünftige" Temperatur- und Luftdruckwerte erhielt, wenn ich vom
ermittelten D2-Wert den Betrag 32768 abzog und damit in eine
Größenordnung von etwa 3000 kam!
Jetzt kann ich mit dem System zwar irgenwie arbeiten, aber es ist
natürlich hochgradig unbefriedigend nicht zu wissen, warum die
abgefragten D2-Werte so danebenliegen. Hat dazu vielleicht Jemand eine
Idee?
Klaus
Anbei noch die Befehlsfolge, die ich zum Abruf der D2-Temperaturrohdaten
verwende:
'hole Rohdaten Temperatur
'-----------------------------------------------------------------------
---
Portd.7 = 1 'hierueber steuere ich XCLR
Waitms 50
I2cstart
I2cwbyte &HEE
I2cwbyte &HFF
I2cwbyte &HE8
I2cstop
Waitms 50
I2cstart
I2cwbyte &HEE
I2cwbyte &HFD
I2cstart
I2cwbyte &HEF
I2crbyte Hi , Ack
I2crbyte Lo , Nack
I2cstop
Portd.7 = 0
Hi = Hi * 256
D2 = Hi + Lo
'Hi, Lo und D2 wurden vorher als "Long" dimensioniert
Hi
>...ermittelten D2-Wert den Betrag 32768 abzog...
Damit löscht du das höherwertigste Bit eines 16-Bit Wertes. Bei einem
16-Bit Integer ist das das Vorzeichen. Kann es sein das da irgend etwas
mit vorzeichenlosen und vorzeichenbehafteten Werten
durcheinandergekommen ist?
MfG Spess
> Kann es sein das da irgend etwas mit vorzeichenlosen und> vorzeichenbehafteten Werten durcheinandergekommen ist?
So etwas Ähnliches hatte ich auch schon vermutet. Versuchsweise habe ich
daraufhin die zum Auslesen benutzen Variablen nur noch als "Word"
deklariert und schliesse damit negative Vorzeichen aus. An dem Ergebnis
hat das aber leider auch nichts geändert.
Viel mehr als zuerst das MSB auszulesen, es mit 256 zu multiplizieren,
danach das LSB auszulesen und Beides zu addieren kann man doch nicht
machen, zumal das Ganze bei den Luftdruckwerten so auch einwandfrei
klappt!
Klaus
Hi,
die Werte kommen vermutlich als Integer mit Vorzeichen (so wie das in
Bascom dimensioniert ist).
Mach mal:
Dim Hi as Integer
Dim Lo as Byte
Dim D2 as Integer
nach dem Auslesen:
Shift Hi , Left , 8
D2 = Hi + Lo
Das müsste dann tun.
Edit:
Im Datenblatt müsste irgendwo was von Zweierkomplement stehen, das ist
das Stichwort für den Hintergrund.
Gruß,
Norbert
gpsklaus schrieb:> I2crbyte Hi , Ack> I2crbyte Lo , Nack> I2cstop> Portd.7 = 0> Hi = Hi * 256> D2 = Hi + Lo>> 'Hi, Lo und D2 wurden vorher als "Long" dimensioniert
Was soll das eigentlich?
Wenn Hi als Long definiert ist, dann ist es eine 4 Byte Zahl (mit
Vorzeichen) und "eigener Speicherlogik".
Es ist schlicht unzulässig, 1 Byte in eine Long-Variable einzulesen
(hatte ich auch einmal, hatte der Long-Variablen 24 zugewiesen und im 1.
Byte steht 96). Nimm doch Hi1 und Lo1 als Byte definiert und lese die
mit I2crbyte ein, dann kannst du: Hi=Hi1*256 und D2=Hi1+lo1 berechnen.
Karl schrieb:> Nur mal so am Rande. Warum benutzt eigentlich niemand MAKEINT?
Das sollte eigentlich egal sein in diesem Fall.
Auch mit Integer oder Single müsste das funktionieren, da sich alles
weit weg vom Vorzeichenbit abspielen sollte.
Lies doch mal die Bytes separat aus (als Byte) und lass sie anzeigen.
Ich glaube jetzt nicht mehr, daß es an den Variablen liegt denn wie
gesagt, das müsste mit auch mit Integer oder Long funktionieren wenn da
nix negatives bei ist.
Gruß,
Norbert
Norbert S. schrieb:> Karl schrieb:>> Nur mal so am Rande. Warum benutzt eigentlich niemand MAKEINT?>> Das sollte eigentlich egal sein in diesem Fall.> Auch mit Integer oder Single müsste das funktionieren, da sich alles> weit weg vom Vorzeichenbit abspielen sollte.
Eben nicht, wenn ich ein Byte in eine Long-Variable einlese, dann wird
die in das Byte1 der Long-Variablen gelesen, die Long-Variable wird aber
anders gespeichert. Also wenn ich x=24 sage, steht z.B. in der
Long-Variablen x im Byte 1 der Wert 96. Also unbedingt Bytes in
Byte-Variablen einlesen.
>> Lies doch mal die Bytes separat aus (als Byte) und lass sie anzeigen.
Eine gute Idee
Manfred S. schrieb:> Eben nicht, wenn ich ein Byte in eine Long-Variable einlese, dann wird> die in das Byte1 der Long-Variablen gelesen, die Long-Variable wird aber> anders gespeichert. Also wenn ich x=24 sage, steht z.B. in der> Long-Variablen x im Byte 1 der Wert 96. Also unbedingt Bytes in> Byte-Variablen einlesen.
Nö, siehe Simulation.
Norbert S. schrieb:> Manfred S. schrieb:>> Eben nicht, wenn ich ein Byte in eine Long-Variable einlese, dann wird>> die in das Byte1 der Long-Variablen gelesen, die Long-Variable wird aber>> anders gespeichert. Also wenn ich x=24 sage, steht z.B. in der>> Long-Variablen x im Byte 1 der Wert 96. Also unbedingt Bytes in>> Byte-Variablen einlesen.>> Nö, siehe Simulation.
Ausprobieren, bei i2crbyte bin ich mir sicher, dass er nicht die ganze
Long-Variable bedienen kann, sondern nur das Byte0 mit Daten versorgt.
Was dann, wenn vorher in den anderen 3 Bytes schon was drinnen gestanden
ist (z.B. aus der Multiplikation in der Schleife) - Warum also nicht
(sicherheitshalber) Byte-Variablen zum Einlesen verwenden. Hab selbst
leidvoll erfahren müssen, dass implizite Typkonvertierungen in Bascom
immer zu schleierhaften Fehlern führen..
Hi,
Manfred S. schrieb:> Ausprobieren, bei i2crbyte bin ich mir sicher, dass er nicht die ganze> Long-Variable bedienen kann, sondern nur das Byte0 mit Daten versorgt.> Was dann, wenn vorher in den anderen 3 Bytes schon was drinnen gestanden> ist (z.B. aus der Multiplikation in der Schleife)
Linke Nummer wenn das so ist.
Bei einer einfachen Zuweisung wie
Long = Byte
wird alles in der Long überschrieben.
Kann natürlich sein, daß das bei I2crbyte nicht so ist.
Also müsste mit Sicherheit das hier gehen:
Dim Hi as Byte
Dim Lo as Byte
Dim D2 as Integer
nach dem Auslesen:
D2 = Hi
Shift D2 , Left , 8
D2 = D2 + Lo
Gruß,
Norbert
Bei Pollin gibt es eine recht umfangreiche Dokumentation. Unter anderem
folgenden Hinweis:
"Setzen Sie Pin XCLR auf low bevor Sie die Koeffizienten auslesen,
andernfalls können die ausgelesenen Daten
fehlerhaft sein."
Liegt es evtl. daran?
Die Prozedur zum Auslesen der Druckdaten und Temperaturdaten sieht
gleich aus (siehe Programmbeispiel in der Dokumentation).
noch ein tip ... das geshifte und addieren kann man sich komplett
schenken
durch Overlayvariablen.
Dann stehen die bytes gleich da wo sie hin gehören.
Dim D2 as Integer
Dim Hi as Byte at D2 overlay
Dim Lo as Byte at D2+1 overlay
Portd.7 = 1 'hierueber steuere ich XCLR
Waitms 50
I2cstart
I2cwbyte &HEE
I2cwbyte &HFF
I2cwbyte &HE8
I2cstop
Waitms 50
I2cstart
I2cwbyte &HEE
I2cwbyte &HFD
I2cstart
I2cwbyte &HEF
I2crbyte Hi , Ack
I2crbyte Lo , Nack
I2cstop
Portd.7 = 0
Ich habe mir den Sensor kürzlich gekauft und ihn unter BASCOM zum laufen
bekommen. Das Programm gibt momentan die Temperatur und den
physikalischen Luftdruck über die serielle Schnittstelle aus. Vielleicht
hilft es Euch ja weiter.
Hallo Sebastian
Leider bist du nur als Gast angemeldet. Dein Code sieht ja super aus.
Wie ich sehe, hast du sogar den 32K Quarz per Software emuliert. Ich
hätte aber dennoch Fragen, könntest du dich mal bei mir melden?
Ich wollte das Ganze auf einem ATmega8 laufen lassen, aber das
scheint nicht zu klappen, das Programm wird gar nicht ausgeführt...
Viele Grüsse
Thomas
Hallo Thomas,
was genau funktioniert denn nicht?
Ein paar Zeilen vom Code solltest natürlich anpassen, insbesondere:
$crystal = 16000000
Dann kannst Du noch $lib "i2c_twi.lbx" auskommentieren und die
Geschwindigkeit der TWI (I2C) Schnittelle mit TWI=xxxx beeinflussen.
Den Timer solltest Du natürlich auf den Quarz anpassen.
$hwstack = 64
$swstack = 64
$framesize = 64
habe ich nur auf verdacht gesetzt. Vielleicht ist das der Grund.
Bei avr-praxis habe ich einen Diskussionsbeitrag darüber eröffnet.
Viele Grüße,
Sebastian
