BME280 - noch blocking lesen?

[Ing-Dom]

Arduino zieht einfach. Ich meine, ich hab schon lange bevor es Arduino gab mit den Atmel Atmegas gearbeitet und ich komme als Dipl Inf. auch ohne Arduino aus.
Aber es macht halt sovieles soviel einfacher und schneller. Und Hardware bekommt auch nachgeschmissen.

Projekte wie selfbus fristen ein Schattendasein, weil die Einstiegshürden so hoch sind (meine Meinung). Die muss man niedrig halten um neue Entwickler anzuziehen.

Und Arduino war ja darauf konzipiert, dass Kinder, Hausfrauen und Holzfäller auch damit "programmieren" können.

[Bernator]

Da hast du sicher recht aber das gilt eigentlich nur für einzelne Aufgaben die synchron nacheinander ablaufen, sobald man mehrere "parallel" ausführen will kommt man um einen asynchronen aufbau nicht herum und da wird sich der Holzfäller dann schon schwer tun. Die meisten libraries sind ja Aufgrund der Einfachheit gar nicht dafür ausgelegt den Prozessor mit anderen zu teilen. Es gibt ja praktisch kein Technik Forum wo es nicht zig Threads ala: "library A läuft library B läuft aber wie bekomme ich die zusammen" gibt ( der hier ist im Prinzip ja das gleiche )

[ChriD]

"Eigentlich" sollte man KONNEKTING außerhalb des Arduino Universums entwickeln.

Würde das nicht schon gehen? Mit dem Precompiled flag seit der Arduino IDE 1.8.6 bzw. Builder 1.4.0?

https://github.com/arduino/Arduino/w...es-file-format

[Eugenius]

Das mit 400us hat sich schon mit beta4b entschärft. Die Bytes vom Bus werden per Interrupt (Atmel sei dank) in ein RX Buffer gespeichert. Ich habe jetzt die Größe nicht in Kopf, aber 2-3 Telegramme sollen reinpassen. Es werden wohlgemerkt alle Telegramme, eigentlich Bytes, reingeschrieben, also auch die, die nicht für dieses Device adressiert waren. Wenn Buffer voll ist, werden die ältesten Bytes gelöscht, somit geht schon mal mindestens ein Telegram verloren. Die Bytes werden ohne Interrupt mit Serial.read in unserem Task gelesen, Telegrammweise. D.h. nach jedem Telegramm springt man zurück zum Loop.

soweit denke verständlich?

D.h. blockieren an sich, vor allem für 1-2ms sollte kein Problem sein, da uns Buffer rettet. Wenn aber auf dem Bus viel los ist und Task für mehrere 100ms nicht aufgerufen wird, hat man ein Problem.
Wobei man auch hier unterscheiden muss: Sender das Device nur (z.B. Sensor) dann kann man quasi nur Programmiertelegramm verpassen, die von der Suite aber mehrmals gesendet, also nicht so tragisch.

ist das ein Aktor, hat man echt ein Problem. Ich habe im Einsatz ein i2c 16 CH Dimmer Baustein, da geht bei mir das Licht öfter nicht an oder aus...(da ist aber noch die alte Beta Version)

[Ing-Dom]

ist das ein Aktor, hat man echt ein Problem. Ich habe im Einsatz ein i2c 16 CH Dimmer Baustein, da geht bei mir das Licht öfter nicht an oder aus...(da ist aber noch die alte Beta Version)

ja das kenne ich, bei meinem 12ch dimmer prototyp hatte ich meine Erfahrung mit der DS18B20 Sensor lib gemacht..

soweit denke verständlich?

jupp.

SERIAL_RX_BUFFER_SIZE ist standardmäßig 64 Byte (kann aber bei Bedarf erhöht werden!).

Das reine TP-Telegramm ist 8 - 29 byte groß ("normale" 8-11). Den Overhead durch das Protokoll (FT1.2 oder?) vom NCN / TPUART kenne ich nicht...

Einsatz ein i2c 16 CH Dimmer Baustein

PCA9685 ? liegts da an der lib für den Baustein?

[Eugenius]

Irgend ein PCA... i2c Kommunikation braucht bis zu 20ms. Es werden zu viele Daten geschickt.


DS18B20 kann man auf ca. 1ms mit einem Parameter reduzieren...
https://github.com/KONNEKTING/Konnek...nctions.ino#L9

[Ing-Dom]

DS18B20 kann man auf ca. 1ms mit einem Parameter reduzieren...
https://github.com/KONNEKTING/Konnek...nctions.ino#L9

jo, das hast du mir damals schon gesagt

[fluppie]

Would increasing the I2C busspeed help? https://www.arduino.cc/en/Reference/WireSetClock
I see in Eugenius' his examples that he sets it to 400 kHz.

I now have a BME680 connected to the HTU21D example just reading temp & hum, but I want to read pressure and gas resistance as well. So I will be blocking the sensor for a longtime I think? BME280 and BME680 support up to 3.4 MHz I2C bus. According to Microchip/Atmel this should work: https://cdn.sparkfun.com/datasheets/..._Datasheet.pdf

[Sonnengruesser]

I2C usually is no problem since you can set the bus speed up as you suggested.
The DS18B20 is using OneWire, which is way slower.

If you want to read more values and are afraid of blocking the loop too long, just read only one value in each loop cycle instead of all 4 at once.

[fluppie]

Is the ms reading in the serial debug reliable?

I2C set to default 400 kHz:

currentTemp: 22.16 C time: 176 ms
currentHumd: 54.12 % time: 0 ms
currentTemp: 22.16 C time: 176 ms
currentHumd: 54.26 % time: 0 ms
currentTemp: 23.17 C time: 176 ms
currentHumd: 91.14 % time: 0 ms
currentTemp: 23.41 C time: 176 ms
currentHumd: 84.89 % time: 0 ms
currentTemp: 23.38 C time: 176 ms
currentHumd: 80.82 % time: 0 ms

I2C set to 3.4 MHz with "Wire.setClock(3400000L);":

currentTemp: 22.12 C time: 176 ms
currentHumd: 54.74 % time: 0 ms
currentTemp: 22.12 C time: 176 ms
currentHumd: 54.45 % time: 0 ms
currentTemp: 22.12 C time: 176 ms
currentHumd: 54.56 % time: 0 ms
currentTemp: 22.13 C time: 176 ms
currentHumd: 54.53 % time: 0 ms
currentTemp: 22.13 C time: 176 ms
currentHumd: 54.63 % time: 0 ms

I was expecting a shorter time. I'm using the Adafruit BME280 and BME680 library

There is a asyncrous option in the Adafruit library: https://github.com/adafruit/Adafruit...me680async.ino
When using that I also get 176 ms?? Even when disabling line 65, the delay of 50ms I get 176ms

[Sonnengruesser]

Just had a very short look at the lib - the time you get is the time it takes for the measurement itself. However the example is partially blocking the µC (after the delay(50) it waits for finishing the measurement within the endReading()).
To have a really non-blocking reading you have to add one if() before reading the result:

if (millis()>= endTime) {
    if (!bme.endReading()) {  
    // put all of this here, including the debug outputs and delay (2000)
}

This is untested and hopefully explained so you can understand it

Also if you want to know the time it takes for transmitting the values via I2C you have the output the millis before and after the bme.endReading (which is a rough estimation).

[Techi]

Ich bin nicht so auf Arduino, aber lassen sich in Arduino nicht auch die etwas spezielleren Funktionen von einzelnen Prozessoren verwenden.
Wenn ich z.B. ein Projekt mit einem STM32 habe, und dort USART, I2C, SPI, USB .... alles gleichzeitig laufen soll, dann mache ich hier exessive Verwendung von DMA kanälen und zugehörigen IRQ's. Bei passenen MCU's kann man damit die komplette IO im hintergrund fahren, wären die Daten dann z.B. über Array (oft z.B. in DMA Ringpuffer Konfiguration) und Flags läuft.
Da interessiert mich das Timing im eigentlich Programm so gut wie gar nicht. Wenn das gut gemacht ist, dann zweigt der Prozessor nur noch für us in eine zugehörige IRQ Routine ab um mal schnell Flags und/oder Konfigs zu modifizieren oder ein paar Variabeln hin und her zu kopieren.

[Sonnengruesser]

Stimmt genau Techi. Blöderweise sind viele Arduino Libraries nicht dafür gemacht - hat vermutlich auch was mit Kompatibilät zu tun - und sehr viele "Anfänger" können auch mit Statusmanagern nix anfangen, weshalb viele Libraries intern mit delays arbeiten. Die Kommunikation selbst ist dann schon asynchron, aber trotzdem wartet das Programm bis sie fertig ist anstatt einfach den Status abzufragen.