Ich hab mal meine ganzen Libs von I2C-Chips zusammengestellt und die
Datenblätter dazugepackt.
Wird im Laufe der Zeit noch erweitert für den DS1307 und EEPROMs.
Ist glaub ich gut genug kommentiert, falls es noch Fragen gibt habt ihr
hier die Möglichkeit.
dabei ist die benötigte P.Fleury'sche I2C-Lib
LM75 (Temperatursensor)
MCP23017 (extrem mächtiger 16bit Portexpandern mit allem möglichem Zeug)
PCF8574 (ganz einfacher 8bit Portexpander)
MCP3421 (18bit delta/sigma ADC mit Differenzmessung, eingebauter
Referenz und internem ultralinearem einstellbarem Vorverstärker)
SHT21 (Luftfeuchte und Temperatursensor mit Kompensation und allem
möglichen Zeug, Werte direkt als BCD auslesbar)
TSL2561 (Lichtsensor mit indirekter IR-Kompensation und humanähnlicher
Kennlinie) (es fehlt allerdings noch die Umrechnung Rohwert-lux)
Kommt bald:
DS1307 (RTC)
allerlei EEPROMs
Und hier die aktuelle Lib mit der Lib von P.Fleury und folgenden Chips:
LM75 (Temperatursensor)
MCP23017 (extrem mächtiger 16bit Portexpandern mit allem möglichem Zeug)
PCF8574 (ganz einfacher 8bit Portexpander)
MCP3421 (18bit delta/sigma ADC mit Differenzmessung, eingebauter
Referenz und internem ultralinearem einstellbarem Vorverstärker)
SHT21 (Luftfeuchte und Temperatursensor mit Kompensation und allem
möglichen Zeug, Werte direkt als BCD auslesbar)
TSL2561 (Lichtsensor mit indirekter IR-Kompensation und humanähnlicher
Kennlinie) (es fehlt allerdings noch die Umrechnung Rohwert-lux)
DS1307(RTC)
HDMM01 (2-Achsenkompassmodul von Pollin)
EEPROMs (Universallib für alle mögliche I2C-EEPROMs)
Könnte mal n Mod all die alten Versionen von V1.1 bis V1.3 löschen
6.5MB und Archiv mit Datenblättern zu den Chips mit drin...
Lade doch einfach die einzelnen C- und Headerdateien hoch,
Syntaxhighlighting hast du dann inklusive.
Traffic sparen, viel übersichtlicher und man kann schnell mal
nachschauen.
Wer hat die Dateien zu den Bauteilen erstellt? Da wurde ja ganz gut
gemurkst!
1
intpcf8574_input(intportexaddress)
2
{
3
intportexin1;
4
intportexin2;
5
6
i2c_start(portexaddress+I2C_READ);
7
8
portexin1=i2c_readAck();
9
portexin2=i2c_readAck();
10
11
i2c_stop();
12
13
if(portexin1==portexin2)
14
{
15
returnportexin1;
16
}
17
else
18
{
19
return"ERR";
20
}
21
}
einen char* implizit in einen int konvertieren? Was soll das und wie
soll die entsprechende Überprüfung auf Fehler von außen erfolgen?
Grober Pfusch ist sowas.
Ist das überhaupt getestet?
Das macht mit Sicherheit nicht, was es soll:
1
floatread_mcp3421_adc(intbits)
2
{
3
volatilesignedintdata_adc;
4
volatilesignedfloatreadenvoltage;
5
volatileunsignedfloatonebitvoltage;
6
7
data_adc=read_mcp3421_adc_raw();
8
9
onebitvoltage=4,096/2^bits;
10
11
readenvoltage=onebitvoltage*data_adc;
12
13
returnreadenvoltage;
14
}
Komma ist in C nicht der Dezimalpunktoperator und Zirkumflex nicht der
Potenzoperator!
Da sind mit Sicherheit noch mehr grobe Schnitzer in den Dateien, habe
nur die Beiden angeschaut.
Daher lieber erst mal Hände weg, bis die alle überprüft wurden.
Achso und float ist hier bei AVRs Quatsch und Unsinn. Das geht mit
Festkomma-Arithmetik besser, einfacher und ressourcenschonender.
Was der User mit den ADC-Daten anfängt, sollte ihm selbst überlassen
bleiben um die Lib/den Treiber möglichst kein zu halten.
z.B. bei einem 12bit ADC reicht ein signed/unsigned short (je nach gew.
Vorzeichen) und die Funktion sollte nicht mehr machen, als den direkten
ADC-Wert auszugeben.
Umrechnungen, anzeigen auf Display, UART, xxxxx, ...., kann man ja als
Beispiel in einer main() unterbringen.
Nils S. schrieb:> Was der User mit den ADC-Daten anfängt, sollte ihm selbst überlassen> bleiben um die Lib/den Treiber möglichst kein zu halten.
Das kann man machen, wenn der Rest funktioniert ;-)
> z.B. bei einem 12bit ADC reicht ein signed/unsigned short (je nach gew.> Vorzeichen) und die Funktion sollte nicht mehr machen, als den direkten> ADC-Wert auszugeben.
Besser: uint16_t / int16_t
René Zahn schrieb:> Simon K. schrieb:>> Komma ist in C nicht der Dezimalpunktoperator> isn tippfehler
Das ist alles, was du dazu sagst? Tippfehler? In einem C-Programm?! Du
hast also das Ganze nicht mal kompiliert...
Ganz toll! Ich dachte immer das Hereinstellen von Sachen in die
Codesammlung setzt ein wenig Verantwortungsbewusstsein voraus.
Simon K. schrieb:> Ist das überhaupt getestet?
Ja mit Umrechnung noch nicht aber den AD-Wert bekomm ich zuverlässig
zurück (ausser wenn zeitgleich mein SNT rödelt dass Störungen aufm Bus
verursacht)
>> Da sind mit Sicherheit noch mehr grobe Schnitzer in den Dateien, habe> nur die Beiden angeschaut.> Daher lieber erst mal Hände weg, bis die alle überprüft wurden.> Festkomma-Arithmetik besser, einfacher und ressourcenschonender.
aber schiweriger und wenns funktioniert ists wurscht.
Wer ein super dupper ressourcenschonendes sich selber den Hintern
abwischendes Programm braucht, dass auch nicht mehr funktioniert als
diese soll das Bitte verdammt noch mal selber machen.
Nils S. schrieb:> z.B. bei einem 12bit ADC reicht ein signed/unsigned short
bei short und long spinnt bei mir teilweise der Compiler deshab hab ichs
so gemacht
Simon K. schrieb:> einen char* implizit in einen int konvertieren? Was soll das und wie> soll die entsprechende Überprüfung auf Fehler von außen erfolgen?
es funktioniert nicht mehr oder besser als ein anderes
zur überprüfung: die " " gehören weg und ERR ist bei mir definiert hab
ich vergessen mit einzufügen.
der pcf8574 sendet die eingangswerte zur überprüfung zweimal und wenn
ein fehler drauf unterschieden sich die beiden.
Mahlzeit,
also ich hab mal den Quelltext zum LM75 überflogen...
Ich sollte wohl nochmal einen C-Grundkurs machen, den irgendwie verstehe
ich die Prozedur Temperaturumrechnen() nicht. (zuerst dachte ich, dass
es vielleicht BASIC-Code sein könnte, da gibt es zumindestens ein ^ als
Potenz... :-))
Vielleicht könntest du mal erklären, wie das Zeugs funktionieren soll.
Es könnte sein, dass ich nicht hinter diese trickreiche Programmierung
steige.
Danke Uwe
PS.: ich bezweifle, dass dieser Codefetzen überhaupt warnung- und
fehlerfrei übersetzbar ist!
PPS.: deine abfällige Bemerkung zu den "Spinnern" die ressourcenarm
programmieren wollen, gefällt mir auch nicht besonders. Wenn der Rest
der Quelltexte ähnliche Qualität hat, solltest du es vielleicht sein
lassen...
Hallo ,
letztendlich eine brauchbare Basis und allemal besser als das
rumgefrotzel der Anderen.
Die können einem auch den Spass nehmen. Weiter so ihr Experten.
Und Danke an Rene für den Code.
Uwe Berger schrieb:>> ...und schon mal probiert, ob sich das Zeug fehler- und warnungsfrei> übersetzen läßt?
Und warum so abfällig über jemanden herziehen.
Probiere es doch selbst aus.
Da hat sich jemand mal die mühe gemacht , und schon wird er wieder
runtergemacht .
Ich denke Simon ging es primät darum, daran zu erinnern, daß es nun mal
erhöhter Selbstkritik bedarf, wenn man Code einstellt.
Man sollte nicht als profihafter Gönner auftreten und dann auch noch auf
Kritik und erkannte Fehler schmollend und nach Waden beißend reagieren.
Das ist unreif und unprofessionell. Und, nun ja, nichts anderes ist es
wenn man auf die Einwände der compilierbarkeit, unnötiger float
Verwendung etc (daß der Compiler spinnt ist eher unwahrscheinlich btw)
mit "Machs doch alleine wenns dir nicht passt" reagiert.
Ich finde das posten einer konkreten Chip Sammlung super! Das bereichert
das Forum natürlich und Anfängern ist das sehr dienlich. Die nehmen das
aber auch als Vorlage und da sollten auch möglichst keine blöden Sachen
gemacht werden. Eine compilierbarkeit sowiso vorausgesetzt.
Bedenke einfach, daß du nicht so erfahren bist, wie du meinst und dann
kannst du auf Kritik von anderen souveräner reagieren. Die infantilen
Antwoerten ignorier ich mal.
Danke dir für die Mühe!
tribel schrieb:> Probiere es doch selbst aus.>
...es reicht ein kurzer(!) Blick in ein paar Quellcode-Dateien:
lm75.h
1
volatile int string[16] AS Temperatur;
oder sht21.h
1
volatile int string[8] AS sht21_crc;
2
int string[16] AS sht21_data;
was ist das? Mit welchem C-Compiler soll das übersetzbar sein?
lm75.c
1
...
2
while ( Stelle >16)
3
{
4
char i2c_readAck(void)
5
Temperatur = i2c_readAck()
6
Stelle++;
7
}
8
...
Meine C-Compiler würden wegen fehlenden Semikolon meckern...
lm75.c
1
...
2
if ( Temperatur.(8-Stelle) = 1)
3
{
4
Temp = Temp + 2^Stelle
5
}
6
else
7
{
8
Temp = Temp + 0
9
}
10
...
Mal abgesehen von dem komischen "Temperatur.(8-Stelle)" (was soll das
sein?) fehlt in der if-Bedingung ein Gleichheitszeichen. Weiterhin habe
ich weiter oben schon angemerkt, dass "^" kein Operator in C ist!
sht21.c
1
...
2
int convert_sht21_str_sht21_val (int data, int type)
3
{
4
data.0 = 0;
5
data.1 = 0;
6
...
Auch hier scheine ich etwas beim Typ Integer in C etwas verpasst zu
haben... oder?
Reichen diese Beispiele?
Ich dachte bisher auch immer, dass gerade in der "Codesammlung" fertige
Software vorgestellt wird. Zu "fertig" gehört nach meiner Ansicht aber
auch, dass man die Software mal übersetzt und getestet hat.
Was bitteschön soll ein Anfänger mit soetwas anfangen können?
Grüße Uwe
Ich habe auch mal stichprobenweise reingeschaut:
ds1307.h:
1
#define ds1307_address 0x68;
Hier ist das Semikolon zuviel.
HDMM01.c:
1
_delay_ms(10);//wait 10ms to let the sensor take the measurement
Wie kann man _delay_ms() aufrufen ohne das dazu passende Include?
Da fehlen sowieso zig Include-Statments, allein schon, damit man
wenigstens die extern-Deklaration zur Fleury-Lib hat.
HDMM01.c:
1
#define Config_reg 0x00;
2
#define MSB_X_Axis 0x01;
3
#define LSB_X_Axis 0x02;
4
#define MSB_Y_Axis 0x03;
5
#define LSB_Y_Axis 0x04;
Auch hier sind alle Semikolons zuviel und führen garantiert zu einem
Syntax-Error.
PCF8574.h:
1
#define pcf8574_address_LLL 32;
2
#define pcf8574_address_LLH 33;
3
#define pcf8574_address_LHL 34;
4
#define pcf8574_address_LHH 35;
5
#define pcf8574_address_HLL 36;
6
#define pcf8574_address_HLH 37;
7
#define pcf8574_address_HHL 38;
8
#define pcf8574_address_HHH 39;
Dito.
So, mehr Dateien wollte ich mir nicht anschauen.
Fazit: Es gibt keine einzige Quelltextdatei, die durch irgendeinen
C-Compiler geht. Diese Software wurde weder jemals kompiliert noch wurde
sie getestet. Wie denn auch, wenn sie gar nicht übersetzbar ist?
Wie wäre es mal mit einem Statement vom TO, was dieser Thread hier soll?
Verarsche? Mal gucken, wieviele "Danke" sagen, obwohl die Software
unbenutzbar ist?
EDIT:
Ich sehe gerade, dass dieser Thread bereits ein Jahr alt ist. Mir ist
absolut schleierhaft, wie so etwas hier ein Jahr lang unkommentiert hier
rumlungern durfte.
ElectricJohnny schrieb:> also der SHT21 Code lässt sich auch nicht kompilieren...
Es haben hier schon mehrere Leute darauf hingewiesen, dass der Code
generell nicht kompilierbar ist und auch nie kompilierbar war. Am besten
ist es wohl, wenn dieser Thread verschwindet bzw. zumindest gesperrt
wird.
Schließlich sind wir hier in "Projekte & Code". Mit dem Code kann man
aber nichts anfangen. Ganz im Gegenteil: Anfänger werden in die Irre
geführt.
Ich drücke mal auf "Beitrag melden".
Thread beobachten
Seitenaufteilung abschalten