CombiePin schnelle I/O Bibliothek

[larsfcfa]

Hallo Combie und Anwender der genialen Lib,

ich möchte mit der Bibliothek einen DHT22-Sensor betreiben, wie mir inzwischen schon mitgeteilt wurde muss der Port/Pin dazu im Open Collector mode betrieben werden.

In der CompiePin Lib kann ich kein Beispiel dazu finden, hätte es aber mal so versucht:

Original-Code:

  digitalWrite(pin, LOW); // Send start signal
  pinMode(pin, OUTPUT);
  delayMicroseconds(800);
  pinMode(pin, INPUT);
  digitalWrite(pin, HIGH); // Switch bus to receive data
....
if digitalRead(pin) == 1 then //hier Auswertung wenn High;

mit CombiePin:

OpenDrainPin<8> dht_sensor_1;
dht_sensor_1.init();
dht_sensor_1.setLow
??
delayMicroseconds(800);
??
dht_sensor_1.setHigh
....
if dht_sensor_1.isHigh then //hier Auswertung wenn High;

Ist der Ansatz so grundsätzlich in Ordnung? Wie kann die Umschaltung des PinMode zwischen Eingang und Ausgang mit CombiePin erfolgen?

Nur noch mal zum Verständnis:
Open Collector bedeutet, dass der Pin nur auf GND geschaltet werden kann, bei High ist der Ausgang "Floatend" und muss über einen Pull-Up auf definierten High-Pegel gezogen werden -> stimmt das so im wesentlichen?

Vielen Dank für eure Unterstützung

[zwieblum]

Das ganze ist irgendwie ... verwirrend? Kannst du dich klar ausdrücken, was du machst in welcher Sprach?

[larsfcfa]

Ich möchte gerne mit einem Arduino Pro Mini AVR einen DHT22 Sensor in der Arduino IDE ansprechen.
Dazu benutze ich eine DHT-Lib, die an sich gut funktioniert, aber die ganze PinMode Ansteuerung mit der Arduino Standard Lib abwickelt. Diese Arduino Standard Lib verursacht aber einen enormen Overhead. Deshalb gibt es von Combie eine CombiePin Lib, die das PinMode, Digitalread etc. sehr schlank erledigt.

Port Byteweise abfragen JO-IT-Mega r3

Manchmal kann man das gebrauchen. es kann/wird Speicher sparen (wenn man es richtig macht) ca. Faktor 20 bis 30 kann man an Geschwindigkeit raus holen Hier mal ein Test für meine Lib: #include <CombiePin.h> using Out = Combie::Pin::OutputPin<8>; int main(void) { Out{}.init(); for(;;) Out{}.toggle(); // 2,66Mhz mit einem UNO } Der Sketch verwendet 140 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes. Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speic…

Damit möchte ich nun die DHT22 Lib „tweaken“ wobei ich Hilfe benötige

[HotSystems]

@larsfcfa

Ich möchte gerne mit einem Arduino Pro Mini AVR einen DHT22 Sensor in der Arduino IDE ansprechen.

Und du bist dir sicher, das dies für die Nutzung nur eines Pins Sinn macht ?
Um einen Sensor an einem Pin zu betreiben, braucht es doch keine zusätzliche Library. Dadurch wird der Overhead doch erst unnötig größer.

[combie]

@larsfcfa

Ist der Ansatz so grundsätzlich in Ordnung?

Ich denke schon, würde es aber etwas einfacher gestalten.

#include <CombiePin.h>


using Dht = Combie::Pin::OpenDrainPin<8>;

Dht dht;

void setup()
{
  dht.init();
}


void loop()
{
  //dht_sensor_1.setLow
  dht = 0; // oder false

  delayMicroseconds(800);

  //dht_sensor_1.setHigh
  dht = 1; // oder true

  //....
  //if dht_sensor_1.isHigh then //hier Auswertung wenn High;
  if(dht)
  {
    //tuwasWennHigh();
  }

}

@larsfcfa

Wie kann die Umschaltung des PinMode zwischen Eingang und Ausgang mit CombiePin erfolgen?

Das macht die Klasse OpenDrainPin automatisch, dafür wurde sie u.A, erfunden.

[larsfcfa]

Hallo,

also ich habe noch eine paar mehr PINs in Nutzung.

Hast du mal ins compilat reingeschaut, was die Arduino-LIB der Kompatibilität und Abstraktion zu liebe aus einer

pinMode(PIN, INPUT);
digitalWrite(PIN, HIGH);

macht?
Neben der Geschwindigkeit (ist bei mir in diesem Fall nicht das Kriterium) wird auch ein großer Overhead im Flash erzeugt. Wenn es da knapper zugeht, freust du dich wenn es anders geht. Natürlich kann ich das auch komplett "zu Fuß" erledigen, aber die CombiePin LIB erspart mir das durch "Hardcoding zur Compilezeit".
Finde ich gut, daher meine Anfrage hier.

[larsfcfa]

Super, vielen Dank, ich werde das ausprobieren!
Ist ja eigentlich straight foreward, ich konnte das nur nicht der Doku so entnehmen

[HotSystems]

@larsfcfa

also ich habe noch eine paar mehr PINs in Nutzung.

Na prima, nur erraten konnte ich das leider nicht.

[larsfcfa]

Du hast Recht, für 1 Sensor-Pin wäre das nicht notwendig gewesen

[Kai-R]

Vor allem bei einem Sensor, der eh nur min. alle zwei Sekunden gelesen werden sollte. Zumindest was die angesprochene 20-30 fache Geschwindigkeitssteigerung betrifft. Es gibt aber auch noch digitalReadFast/digitalWriteFast…. ist etwas weniger „umgewöhnungsbedürftig“.

[larsfcfa]

Nur zur Ergänzung: manchmal ist auch der Flash limitierend und da ist eine schlanke Implementierung nützlich. Beim AVR ist meiner Erfahrung nach eine effiziente Implementierung manchmal sowohl schlank als auch schnell, natürlich nicht immer.
Hier ist es m.M.n. der Fall.
Für diesen speziellen Sensor ist in der Tat Geschwindigkeit irrelevant.