Du musst meine Beiträge zuvor beachten. Es gibt ja anscheinend noch ein Vorsichen (Bit)?
Ich müsste erst mal schauen wie TempH und TempL genau aufgebaut sind, leider fehlt mit die Zeit dafür.
C Temperaturanzeige (DS1621) auf 4 - Digit 7-Segmentanzeige
- Ersteller Janiiix3
- Erstellt am
Du musst meine Beiträge zuvor beachten. Es gibt ja anscheinend noch ein Vorsichen (Bit)?
Ich müsste erst mal schauen wie TempH und TempL genau aufgebaut sind, leider fehlt mit die Zeit dafür.
Ja, es gibt noch ein Vorzeichen Bit.
Du kennst dich ja am besten in "C" aus, wann könntest du denn mal drüber schauen ?!
Ich kann da mal am Wochenende nach schauen. Gut wäre es, wenn mir jemand erklärt, wie die beiden ErgebnisBytes aufgebaut sind ... oder im Thread die stelle nennt, wo das steht.
Du meinst jetzt in meinem Programm oder vom Sensor her ?
Je nachdem. Ich würde erst mal sagen, was vom Sensor kommt, also was in TempH und TempL steht.
Ich könnte mir auch das Datenblatt anschauen aber keine zeit im Moment.
Eigentlich gibt es kein richtiges Vorzeichen-Bit. Das Ergebnis des Sensors ist eine binäre vorzeichenbehaftete 9-Bit-Zahl, also als Zweierkomplement. 1 Bit entspricht einem halben Grad Celsius. Die 9 Bit landen in 2 Bytes, logisch. Aber eben links orientiert. Also ist das Bit für das halbe Kelvin das MSB des zweiten Bytes, das erste Byte enthält den ganzzahligen Anteil.
Gemäß der Zweierkomplement-Darstellung ist das MSB (des ersten Bytes) nur bei negativen Zahlen gesetzt. Das halbKelvinBit unterliegt auch der Zweierkomplement-Invertierung, ist es gesetzt entspricht es 0.5 mehr im positiven bzw 0.5 weniger (!) im negativen. Ein 9-bit-Integer eben.
Um jetzt aus der linksorientierten ne rechtsorientierte Zahl (in einer 2 Byte, 16 Bit Darstellung) zu erhalten, kann man entweder 7mal rechtsschieben (über beide Bytes), oder einmal links. Im Sinne der Zweierkomplement-Darstellung mus das rechtsschieben arithmetisch erfolgen, beim linksschieben ggf vorher alles auf 1 gesetzt werden.
Eigentlich sind die Integer doch gerade Datentypen für vorzeichenbehaftete Ganzzahlen in Zweierkomplement-Darstellung. Da gibt's garantiert 'ne Hochsprachenfunktion, die unter Einhaltung des Vorzeichens aus 8bit 16 macht.
Eigentlich hab ich hier mehr gequatscht als geholfen...
Gemäß der Zweierkomplement-Darstellung ist das MSB (des ersten Bytes) nur bei negativen Zahlen gesetzt. Das halbKelvinBit unterliegt auch der Zweierkomplement-Invertierung, ist es gesetzt entspricht es 0.5 mehr im positiven bzw 0.5 weniger (!) im negativen. Ein 9-bit-Integer eben.
Um jetzt aus der linksorientierten ne rechtsorientierte Zahl (in einer 2 Byte, 16 Bit Darstellung) zu erhalten, kann man entweder 7mal rechtsschieben (über beide Bytes), oder einmal links. Im Sinne der Zweierkomplement-Darstellung mus das rechtsschieben arithmetisch erfolgen, beim linksschieben ggf vorher alles auf 1 gesetzt werden.
Eigentlich sind die Integer doch gerade Datentypen für vorzeichenbehaftete Ganzzahlen in Zweierkomplement-Darstellung. Da gibt's garantiert 'ne Hochsprachenfunktion, die unter Einhaltung des Vorzeichens aus 8bit 16 macht.
Eigentlich hab ich hier mehr gequatscht als geholfen...
Aber auf dieser Art kann man es gut erlernen
Das finde ich sehr gut das ihr euch die Mühe macht für die Leute die dort noch ihre Probleme haben 0,75s ist die Coversionszeit, die der Sensor benötigt. Das letzte vollständigere Listing steht in #18.
Da wird der Sensor in der CompareA-ISR von Timer1 ausgewertet. Der Controller läuft mit 8MHz, Timer1 im CTS (OCR1A) Prescaler =1024, CompareA ist 50000.Aber eigentlich egal... hatte ich Deine Idee richtig verstanden/interpretiert?
Wenn Dich das wirklich interessiert, such ich was zu dem verwendeten Sensor-Chip des Kalorimeters raus. Ursprünglich war das'n TO-10 oder so.
AFAIR war da'n TC drin, wir haben aber auch den Spannungsabfall an den internen Heizwiderständen gemessen.
Ausgewertet/erfaßt wird das letztendlich über dieses "Spielzeug für größe Jungs" - dazwischen noch ein OPAMP-Grab (diverse AD711 und AD620)
@Thomas: falls das mit Peaktech bei Dir nix wird, soll ich Dich da mal erwähnen? Die PC-seitige SW soll komplett neu gestaltet werden, hat aber keiner so richtig Ahnung von und ausreichend Zeit...
TommyB
Team Bitschubse
TempH ist als signed byte zu sehen mit dem ganzzähligem Teil. TempL hat nur das MSB als Indikator nenne ich es mal für 0.5 Grad. Gaanz laienhaft gesagt. LotadaC hat das ja aber schon fachlich korrekt ausgedrückt
TempH ist als signed byte zu sehen mit dem ganzzähligem Teil. TempL hat nur das MSB als Indikator nenne ich es mal für 0.5 Grad. Gaanz laienhaft gesagt. LotadaC hat das ja aber schon fachlich korrekt ausgedrückt
Gut, ich denke dann könnte man es zum Beispiel so lösen:
(Ich habe mich bei den Variablen an den bestehenden Sourcecode gehalten)
Code:
int16_t summe, ergebnis;
uint8_t TempH, TempL;
uint8_t j;
uint8_t IsNegative;
uint8_t TempAbs;
[B]// Mittelwert bilden:[/B]
summe = 0;
for (j=0; j<16; j++)
{
[COLOR=#0000ff][B] // hier die Messung machen[/B][/COLOR]
if (!(TempH & 0b10000000))
{
// positiv
summe += ((uint16_t)TempH<<1) | (TempL>>7);
} else {
// negativ
summe += (0b1111111<<9) | ((uint16_t)TempH<<1) | (TempL>>7);
}
}
ergebnis = summe/16;
[B]// Fuer die Ausgabe vorbereiten:[/B]
if (ergebnis < 0)
{
IsNegative = 1;
TempAbs = ~(ergebnis) + 1;
} else {
IsNegative = 0;
TempAbs = ergebnis;
}
[B]// Nun zur Ausgabe:[/B]
if (IsNegative)
{
// Minus anzeigen
} else {
// ggf. Plus anzeigen
}
uint8_t d;
// Temperatur in vollen Grad
d = TempAbs>>1;
// 0,5 Grad als Dezimalstelle 0 oder 5
d = (TempAbs&1)*5;TommyB
Team Bitschubse
Das klappt so aber nicht da der Mess-IC fast ne Sekunde braucht um nen neuen Wert zu generieren. Daher fällt For : Next flach. Lösung: Zählervariable und Summenvariable. In der ISR den neuen Wert (TempH) zu einer 16bittigen Zahl addieren, den Zähler inkrementieren und denn, wenn Zähler 16 ist die Summe / 16 und zuweisen. Vom Prinzip wie du sagtest, nur ohne For : Next.
Nicht persönlich nehmen, aber ich kenn wen der sonst in ner Schleife den (selben) Wert 16x direkt hintereinander vom Sensor pollt, den Durchschnitt daraus berechnet (der natürlich identisch dem Wert ist) und sich dann wundert dass es nicht geht ;P
Die messung muss man natuerlich abwarten und nicht andauernd den selben registerinhalt auslesen. Also in einer timer ISR würde ich das auch nicht machen. Wenn eine Messung so lange dauert, vielleicht reicht es ja, wenn man vier mal summiert. Wenn nicht, dann eben über ein fifo gefiltert, alle möglichen Lösungen kann ich allerdings nicht bringen. Zunächst ging es um eine Mittelwertbildung vorzeichenbehaftet. Wenn die sich nicht eignet, dann würde ich das mit dem fifo machen ... Das ist eigentlich ebenfalls recht simpel zu realisieren.
Hi Janiiix,
mach dir da man keinen Kopf Auch andere haben mächtig Lehrgeld bezahlt bis sie so weit waren.
Auch bei mir sind schon einige Halbleiter verdampft oder Schaltungsfehler erst beim Auseinanderlöten aufgetaucht.
Gruß
Dino
Aller Anfang ist schwer ! Die einen werden als "super Brain" geboren (so wie du) die anderen brauchen halt etwas länger
mach dir da man keinen Kopf
Auch andere haben mächtig Lehrgeld bezahlt bis sie so weit waren. Auch bei mir sind schon einige Halbleiter verdampft oder Schaltungsfehler erst beim Auseinanderlöten aufgetaucht.
Gruß
Dino
TommyB
Team Bitschubse
Ob da wohl noch Spannung drauf ist?
BÄM!
Ok, jetzt nicht mehr...
Und um komplett OT zu werden:
[video=youtube;NaEfU47QY_k]https://www.youtube.com/watch?v=NaEfU47QY_k[/video]
BÄM!
Ok, jetzt nicht mehr...
Und um komplett OT zu werden:
[video=youtube;NaEfU47QY_k]https://www.youtube.com/watch?v=NaEfU47QY_k[/video]
Das mit dem Mittelwert passt denke ich mal soweit.
Nur es ist keine Verbesserung vorhanden. Er springt immer noch zwischen zwei Temperaturen hin und her...
Oder habe ich bei der Mittelwertbildung noch was falsch gemacht ?
Nur es ist keine Verbesserung vorhanden. Er springt immer noch zwischen zwei Temperaturen hin und her...
Oder habe ich bei der Mittelwertbildung noch was falsch gemacht ?
Code:
ISR (TIMER1_COMPA_vect)
{
if (I <= 16)
{
I++;
i2c_start(DS1621_Read);
TempH = i2c_readAck();
TempL = i2c_readNak();
i2c_stop();
if ((TempL & 0b10000000) == (0b10000000))
{
TempH++;
}
Summe += TempH;
}
if (I == 16)
{
Ergebnis = Summe / 16;
I = 0;
Summe = 0;
}
if (Ergebnis < 0)
{
IsNegative = 1;
TempAbs = ~(Ergebnis) + 1;
}
else
{
IsNegative = 0;
TempAbs = Ergebnis;
}
if ((TempL & 0b10000000) == (0b10000000))
{
TempAbs = TempAbs + 1;
}
Wert = ((((TempAbs / 10) % 10) << 8) | ((TempAbs % 10) << 4) | (0x0A)); // Wert entspricht dem "Wert" aus dem Array (Zahlen)
if (TempAbs == 0)
{
Wert = 0xCC0A;
}
else if (TempAbs >= 100)
{
Wert = (Wert | 0x1000);
}
else if (TempAbs < 10)
{
Wert = (Wert | 0xCC00);
}
else if (TempAbs < 100)
{
Wert = (Wert | 0xC000);
}
if (IsNegative == 1)
{
Wert = (Wert & 0x0FFF) | (0xB000);
}
}Dies verstehe ich nicht ganz:
Du inkrementierst ein ganzes Grad, wenn das Bit für 0,5 Grad in TempL gesetzt ist?!
Code:
if ((TempL & 0b10000000) == (0b10000000))
{
TempH++;
}TempL hat bei dir grundsätzlich direkt Einfluss auf TempAbs unabhängig von der Mittelwertbildung, das passt auch nicht:
Code:
if ((TempL & 0b10000000) == (0b10000000))
{
TempAbs = TempAbs + 1;
}Ein paar Post´s davor hatte Lotadc schon erklärt, dass wenn mein Sensor jetzt 22,6 ° mist er diesen Wert immer abrundet... Deshalb werte ich das Bit aus & rechne dann einfach manuel + 1
TempL hat bei dir grundsätzlich direkt Einfluss auf TempAbs unabhängig von der Mittelwertbildung, das passt auch nicht:
Das habe ich raus genommen! Du hast Recht, dass war blödsinn.
Jetzt schwangt er nicht mehr so schnell
Code:
if ((TempL & 0b10000000) == (0b10000000))
{
TempAbs = TempAbs + 1;
}Das habe ich raus genommen! Du hast Recht, dass war blödsinn.
Jetzt schwangt er nicht mehr so schnell
Code:
if (I <= Mittelwert)
{
I++;
i2c_start(DS1621_Read);
TempH = i2c_readAck();
TempL = i2c_readNak();
i2c_stop();
if ((TempL & 0b10000000) == (0b10000000))
{
TempH++;
}
Summe += TempH;
}
if (I == Mittelwert)
{
Ergebnis = Summe / Mittelwert;
I = 0;
Summe = 0;
}