Forum

Servus Zusammen,

ich hab ein kleines Programm für den Arduino geschrieben, welches einen DHT22-Sensor (Temperatur und Luftfeuchte, kommuniziert über eins Datenleitung in beide Richtungen. Datenblatt: https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf ) und über I2C weitergibt. Zusätzlich liest das ganze auch noch die ADC-Pins des µC aus und gibt die Messwerte via I2C weiter.

Mit den Arduinos (ATMega328p 5V und ATSAM3X8E 3V3) klappt das wunderbar aber mit dem "blanken" ATMega328p auf dem Steckbrett geht das auslesen des DHT22 immer schief (Timeout). Versucht habe ich 8MHz interner Oszillator sowie 12MHz und 16MHz externer Oszillator bei 3V3 und 5V. Das abfragen der ADC-Pins funktioniert dagegen auch auf dem "blanken" ATMega328p.

Würde es mit dem 8MHz internen Oszillator funktionieren würde ich auf den Steckbrettaufbau als Fehlerquelle tippen. Aber da es mit dem Internen auf dem Steckbrett auch nicht klappt... Hat Jemand eine Idee was ich falsch machen könnte oder was ich noch versuchen könnte um den Fehler zu finden?

DHT22 und I2C sind mit Pull-Up-Widerständen versehen, die DHT22 sind immer auf dem gleichen Steckbrett aufgesteckt, nur das Kabel vom Daten-Pin habe ich umgesteckt um die unterschiedlichen Arduinos und den blanken ATMega zu verbinden.

Verwendest du in beiden Fällen den selben Chip, nicht nur den gleichen?

» Verwendest du in beiden Fällen den selben Chip, nicht nur den gleichen?
Nicht mal immer den gleichen. Auf dem DUE ist ein Atmel verlötet (ATSAM3X8E), auf den Nanos ein ATMega328p SMD und auf dem Steckbrett habe ich einen ATMega328p DIP. Hab heute noch einen anderen 328p auf das Steckbrett gesteckt und programmiert. Selbes verhalten.

Wenn ich an den DHT22 einen Arduino Nano und den Steckbrett-328p parallel anklemme kann der Nano den DHT22 ganz normal auslesen, der Steckbrett-328p bekommt weiterhin Timeouts.

Aktuell sieht es für mich so aus: Alle fertigen Boards können den DHT22 auslesen, alle Steckbrett-328p-Aufbauten nicht. Würde auch das Auslesen des ADC auf dem Steckbrett nur Mist liefern wäre es vermutlich der Chip order irgendetwas am Aufbau, aber der ADC liefert plausible Werte.

Ich hab auch mal ein Simples Programm auf den Steckbrett-328p hochgeladen, welches einfach ständig einen Pin von HIGH auf LOW umschaltet um so halbwegs die Taktfrequenz bestimmen zu können. Das schaut soweit auch passend aus, wenn ich eine andere Taktfrequenz einstelle (1MHz/8MHz interner Oszillator, 12MHz externer Oszillator) ändert sich auch die Frequenz am Pin entsprechend.

Kann es sein, dass der Bootloader den Unterschied ausmacht?

» Kann es sein, dass der Bootloader den Unterschied ausmacht?
Danke, interessanter Gedanke. Leider liegt es daran nicht, zumindest nicht nur daran.

Ich habe den Arduino Nano Bootloader auf den Steckbrett-328p gebrannt und dann via FTDI-Adapter das Programm drauf gebrannt. Gelegentlich bekomme ich jetzt Prüfsummen-Fehler aber zu 99% noch immer Timeouts. Interessanterweise lässt sich der Steckbrett-328p nur einmal nach dem brennen des Bootloaders mit dem USB-Seriell-Adapter beschreiben. Beim zweiten Versuch kann AVR-Dude nicht mehr Synchronisieren. Ich habe mal die Debug-Ausgaben via serielle Schnittstelle eingeschaltet. Auf der Konsole werden die Meldungen ausgegeben, beim programmieren kommt nichts mehr, dann sehe ich an den Debug-Meldungen, dass der 328p neu startet und weiter munter Debug-Meldungen raus schreibt. Via SPI lässt sich das Programm jederzeit neu brennen, nur die serielle Konsole muss ich danach neu starten um wieder Debug-Meldungen zu sehen. Sehr seltsam...

Ich bin weiterhin Ratlos, vielleicht hast du oder wer anders noch ne Idee in welche Richtung ich weitersuchen kann.

» Ich bin weiterhin Ratlos, vielleicht hast du oder wer anders noch ne Idee
» in welche Richtung ich weitersuchen kann.

Ich kann da leider nicht mehr weiter helfen, dazu bin ich mit den AVR und der Arduino-Plattform zu wenig vertraut.

» » Ich bin weiterhin Ratlos, vielleicht hast du oder wer anders noch ne
» Idee
» » in welche Richtung ich weitersuchen kann.
»
» Ich kann da leider nicht mehr weiter helfen, dazu bin ich mit den AVR und
» der Arduino-Plattform zu wenig vertraut.
Immerhin hast mir geholfen eine weitere Fehlerquelle auszuschließen. Danke.

Werde jetzt erstmal mit einem fertigen Arduino weitermachen und mich später nochmal mit dem Thema Steckbrett-Arduino befassen, ggf. löte ich auch mal eine Testplatine zusammen wenn ich etwas mehr Zeit für sowas habe.

Jetzt läufts auch auf dem Steckbrett.

Das Problem war der PROGMEM-Macro. Ich habe das Pin-Mapping DHT22-Pin <-> I2C-Register in ein Array geschrieben und das mit dem PROGMEM-Macro im Flash statt im RAM gehalten. Komischerweise standen in dem Array dann nicht die Pin-Nummern sondern irgendwelcher Mist drin. Damit wurde der falsche Pin angefragt was den Timeout erklärt. Ich lass das Array jetzt im RAM und die DHT22 lassen sich recht gut auslesen.

So ne serielle Schnittstelle hilft beim Debuggen ungemein Danke!