Ich habe eine kleine Lib in C für den BME280/BMP280. Die I2C-Funktionen sind für Atmel AVRs geschrieben (ich hatte einen Atmega328P bei der Entwicklung benutzt), können aber sicher auch für andere µCs angepasst werden. Vielleicht hilft es ja dem ein und andern. Zu finden ist die Lib unter: https://github.com/Sylaina/bme280
Hallo Sylaina, welches Display verwendest Du und könntest Du bitte mal den kompletten Code posten? Grüße Micha
Micha E. schrieb: > welches Display verwendest Du Findest Du auch in dem Verzeichnis: https://github.com/Sylaina/oled-display
Micha E. schrieb: > Hallo Sylaina, > > welches Display verwendest Du und könntest Du bitte mal den kompletten > Code posten? > > Grüße Micha Ist ein SSD1306-Display, dass ich bei eBay ersteigert habe. Den Code für das Display findest du, wie schon gesagt wurde, auch unter meinem oben verlinkten Github-Account: http://github.com/sylaina/
Zur Info, falls jemand danach sucht. Treiber gibts auch direkt von Bosch: https://github.com/BoschSensortec/BME280_driver Und in Linux auch: https://elixir.free-electrons.com/linux/v4.15.2/source/drivers/iio/pressure/bmp280-i2c.c#L56
Der Boschtreiber ist aber viel zu aufgeblasen und nutzt obendrauf noch floats. Da schreibt man den doch lieber selber, hab ich auch gemacht: http://www.fritzler-avr.de/HP/Librarys/BME280_his.php Beid er lib vom Köhler vermisse ich irgendwie die ganzen Einstellungsmöglichkeiten wie das Sampling, Filter und Standby.
Mw E. schrieb: > Beid er lib vom Köhler vermisse ich irgendwie die ganzen > Einstellungsmöglichkeiten wie das Sampling, Filter und Standby. Die macht man in der init bei mir, aktuell muss man dazu noch ins Datenblatt schaun ;)
Mw E. schrieb: > Der Boschtreiber ist aber viel zu aufgeblasen und nutzt obendrauf noch > floats. Korrekt. ich hab mich vor jahren mal mit dem BMP280 beschäftigt, und die Umrechnung gut optimiert. Im Endeffekt war dann eine float-Variante fast gleich schnell als die Bosch-int32 Variante. Beitrag "Re: Bosch BMP280: Umrechnungen vereinfachen?" Wenn ich mir euren Code ansehe, denke ich dass dieselben Optimierungen auch hier möglich wären...
Mw E. schrieb: > Beid er lib vom Köhler vermisse ich irgendwie die ganzen > Einstellungsmöglichkeiten wie das Sampling, Filter und Standby. Hatte grade etwas Langeweile und habe die Einstellmöglichkeiten implementiert. ;) Michael R. schrieb: > Korrekt. ich hab mich vor jahren mal mit dem BMP280 beschäftigt, und die > Umrechnung gut optimiert. Im Endeffekt war dann eine float-Variante fast > gleich schnell als die Bosch-int32 Variante. Bei mir sind es die im Datenblatt angegebenen Funktionen. Eigentlich bin ich damit auch recht zufrieden, werde mir deine Lösung aber mal anschaun.
Hallo Michael, ich bin auch gerade dabei mit eine Lösung für meinen Mikrocontroller zu finden ich habe einen Teach Dongle ADuC832. Ich bin kein Fachmann und weis nicht genau wie ich deinen Treiber weiter nutzen soll und ihn dementsprechend auf mein gerät anpassen soll. Ich weiß nur, dass es mit dem Controller möglich ist über i2c zu kommunizieren. Wäre echt klasse wenn du mir da weiterhelfen könntest. Viele Grüße Keanu
Diesen Mikrocontroller hab ich nicht, ich hab mir mal das Datenblatt angeschaut und eigentlich ist das nur ne Fleißarbeit. Ein wenig C kannst du ja sicher, daher empfehle ich dir dich ein wenig mit I2C mal zu beschäftigen für deinen µC. Ist wirklich nicht schwer.
M. K. schrieb: > Ein wenig C kannst > du ja sicher, daher empfehle ich dir dich ein wenig mit I2C mal zu > beschäftigen für deinen µC. es gibt doch lib's für i2c ....
Ja, die gibt es. Da stellt sich die Frage ob die Funktionen äquivalent ist zu der I2C-Lib, die ich geschrieben habe. Das muss halt entsprechend implementiert werden und wie gesagt, das ist nicht wirklich schwer aber man muss sich hinsetzen und es machen.
Ich habe die Library vor einigen Tagen aktualisiert, es können nun zwei BME/P 280 Sensoren an einem I2C-Bus angeschlossen und genutzt werden. Sensor 0 geht davon aus, dass SDO 1 ist, bei Sensor 1 muss er dementsprechend 0 sein.
M. K. schrieb: > Zu finden ist die Lib unter: https://github.com/Sylaina/bme280 Leider werden hier TWI-ISR nicht benutzt. Nur Byte gesendet und stupide gewartet... Mikrocontroller kann aber mehr als nur warten.
Maxim B. schrieb: > Leider werden hier TWI-ISR nicht benutzt. Nur Byte gesendet und stupide > gewartet... Mikrocontroller kann aber mehr als nur warten. Da hast du recht. Jedoch ist es bisher nicht erforderlich gewesen beim TWI mit Interrupts zu arbeiten, das war bisher immer schnell genug. Hast du eine zeitkritische Anwendung, bei der das von Relevanz ist?
M. K. schrieb: > Hast > du eine zeitkritische Anwendung, bei der das von Relevanz ist? Wenn ein Gerät nur und ausschließlich mit BME280 arbeitet, dann darf man vielleicht auf TWI-ISR verzichten. Im allgemeinen sollte man aber unnötiges Warten vermeiden, solange solche Möglichkeit besteht. TWI-ISR wurde in AVR implementiert, so sollte das auch benutzt werden. Mikrocontroller kann bestimmt etwas besseres machen statt dumm auf langsame TWI zu warten. ISR-Code sieht zwar ziemlich groß aus, ist aber sehr einfach: switch-case, mehr ist das nicht.
:
Bearbeitet durch User
Maxim B. schrieb: > Im allgemeinen sollte man aber > unnötiges Warten vermeiden, solange solche Möglichkeit besteht. Interessant. Schaun wir mal wie Atmel(Microchip) es macht, Quelle ist das Datenblatt zum Atmega328P: Siehe dazu den angehangenen Screenshot, Tabelle 26-2, Zeile 2, 4 und 6. Siehe da, das Beispiel macht es genauso wie ich. Maxim B. schrieb: > TWI-ISR > wurde in AVR implementiert, so sollte das auch benutzt werden.. Du hast sicher recht, eleganter wäre es gewesen das via ISR zu machen aber wenn der Mikrocontroller eh nichts zu tun hat kann er auch maximal 20 Zyklen (bei F_CPU = 1MHz) warten. Ich mein, was willste in 20 Zyklen machen? Den Mikrocontroller schlafen legen und wieder aufwecken? Und noch was: Niemand wird daran gehindert seine eigene TWI-Library zu benutzen. Also ich sehe hier das Problem nicht. Ich hatte noch nie so zeitkritische Anwendungen, dass ich nicht mal auf den TWI warten konnte. Und wie schon gesagt, Atmel(Microchip) kann ja offenbar auch warten.
M. K. schrieb: > Schaun wir mal wie Atmel(Microchip) es macht TWI-ISR hat Atmel in ihre AVR MEGA eingebaut. M. K. schrieb: > Ich mein, was willste in 20 Zyklen machen? Warum "in 20 Zyklen" ? Bei F_CPU = 1MHz kannst du TWI höchstens auf 62,5 kHz einstellen. Da für Byte je 9 Impulse gebraucht werden (mindestens), hast du pro Byte 144 CPU-Zyklen. Du kannst TWI mit ISR schalten, etwas machen und danach aus einem Array alles frei lesen, was BME280 hat. Ein Gerät nur für BME280 zu machen, das kommt so gut wie nie vor. Gewöhnlich gibt es noch LCD oder LED oder TFT und dazu noch Tasten, Uhr-IC ind vieles vieles andere.
:
Bearbeitet durch User
Maxim B. schrieb: > Warum "in 20 Zyklen" ? > Bei F_CPU = 1MHz kannst du TWI höchstens auf 62,5 kHz einstellen. Das hab ich in der Tat nicht nachgerechnet gehabt. Ich hatte das gemessen, bei der Startbedingung. Da sind es 20 Zyklen, beim Übertragen eines Bytes sind es 146 Zyklen (hab ich jetzt grade noch mal vermessen). Da steckt noch das Stoppen des Timers zum Messen mit drin, daher passt das mit den von dir berechneten 144 Zyklen. Und ja, der TWI ist da auf 62.5 kHz eingestellt. Wie gesagt, ich hatte es nicht nachgerechnet. ;) Maxim B. schrieb: > Ein Gerät nur für BME280 zu machen, > das kommt so gut wie nie vor. Echt? Wirklich? Was meinst du wie ich auf die Idee gekommen bin, dafür eine Lib zu schreiben? Tipp: War nicht nur aus Spass. Hast du mein Github genauer angeschaut? Die Lib zum LCD hast du auch gefunden? Ich glaub mein Library für das 24LC-EEPROM hab ich noch nicht hochgeladen bei Github. Ich nutze den BME280 auch nicht alleine. Wie gesagt, wenn man eine Anwendung hat, die so zeitkritisch ist, kann man das durchaus interruptgesteuert machen. Hat man keine entsprechend zeitkritische Anwendung ist die Interruptsteuerung auch nicht erforderlich. Meine Lib ist ja nicht das einzige Beispiel, dass wartet statt die ISR zu nutzen (vgl. Datenblatt Atmega328P ;)). ;)
M. K. schrieb: > Was meinst du wie ich auf die Idee gekommen bin, dafür > eine Lib zu schreiben? Wahrscheinlich wolltest du, wie oft, "eine Eierbringende Milchsau" machen, die auch Luftdruck messen kann :) So war meine Idee... Ich wollte nichts schlimmes sagen. Ich war aber gerade dabei, TWI-ISR in Lauf zu bringen. Das hat mir sehr gefallen. Deshalb habe ich gleich bemerkt: wie schade, wenn ohne ISR...
:
Bearbeitet durch User
Das ist jetzt ein wenig OT. Die Lib entstand aus einem Projekt heraus bei dem ich eben Luftfeuchtigkeit, Temperatur und auch den Umgebungsdruck wissen musste und der BME280 war nicht das einzige Gerät im I2C Bus.
M. K. schrieb: > Die Lib zum LCD hast du auch gefunden? Für LCD habe ich eigene LIB, die ich schon 3 Jahre lang verwende. Sie hat ähnliche Funktionen wie die für Graphik-LCD und für SPI-LCD, oder auch für SPI-farb-TFT. Ich brauche nur statt
1 | lcd_intern_string_P(PSTR("Ich bin Maxim!")); |
1 | graph_128x64_string_P(PSTR("Ich bin Maxim!")); |
oder
1 | tft9341_string_P(PSTR("Ich bin Maxim!")); |
1 | i2c_lcd_string_P(PSTR("Ich bin Maxim!")); |
zu schreiben (letztere hat einfache und ISR-Variante). So bleibt alles bei mir homogen. Über einen Zeiger auf Funktion kann ich das Ganze bequem verwalten, lediglich bei Init und bei Cursoreinstellung gibt es Unterschiede, weil ich mir das Vergnügen, von einem beliebigen Punkt auf dem Graphik-LCD eine Zeile zu schreiben, nicht ersparen möchte. Deine LIB für BME280 werde ich unbedingt ausprobieren.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.