Der AVR-/ARDUINO-Faden

[ferdimh]

Der Geschwindigkeitsunterschied C zu Assembler ist auf dem AVR noch relativ groß, weil der Compiler nicht so clever ist, wie auf dem PC.
Ich konnte da mal >50% rausholen.
C kann Inline-Assembler. Auch aufm AVR.
Damit kann man erstmal "drauf los" programmieren, und wenn die Zeit wirklich knapp ist, das relevante Stücken assemblieren.
Was sehr hilfreich ist: Ein unbelegter Portpin, der zu Beginn der Interruptroutine High gesetzt wird und am Ende (oder nach einer bestimmten kritischen Arbeit) wieder low geht, ermöglicht die Betrachtung der zeitlichen Situation mittels Oszi.

[xoexlepox]

Wenn ich mir das verlinkte Timing-Diagramm anschaue, geht es wohl darum, die Spannungspegel vor (oder nach?) einem Sync-Impuls zu bestimmen, richtig? In diesem Fall würde ich mir überlegen, ob die A/D-Wandler dafür überhaupt flink genug sind, oder ob eine kleine Hardware (mit z.B. vier Komparatoren) zur Problemlösung nicht einfacher wäre. Das würde m.E. zumindest zu einem wesentlich "entspannteren" Timing für den µC führen

[E_Tobi]

Ich würde das so lösen:
Es gibt immer einen Sprung von 0V auf -5V vor einem validen Wert.
Eine kleine Schaltung verschiebt diesen Sprung auf +3.3 auf 0V, und legt das auf einen Portpin.
Über den erzeugst du einen interrupt auf fallende Flanken. Dann hast du das Zeitfenster 15µs bis 50µs um ein paar mal das Signal zu messen. Das sollte zeitmäßig locker gehen.

Das Frame ist zu Ende wenn im Mess-Zeitfenster immer noch -5V Anliegen.

[Fritzler]

So wies aussieht werden wohl zukünftige GCC Versionen kein AVR Backend mehr haben:
https://www.mikrocontroller.net/topic/483643
(Johann ist einer derjenigen die sich da so richtig auskennen!)

So werden AVR Firmwares zwar noch mit uralt GCCs von 4 bis 7 gebaut, unter Linux eher kein Problem.
Aber zB bei Windoof10 gibts dann das Damoklesschwert, dass "inkompatible" Software beim halbjährlichen Zwangsupgrade einfach gelöscht wird und nicht mehr installierbar ist.
Microchip macht keinen Finger krumm das zu ändern*, denen sind die AVRs dann wohl doch nicht mehr so wichtig?

Inzwischen gibts ein Bounty, damit sich wer findet das zu ändern.
Also falls wer spenden will

*Der AVR Support ist in deren properitären XC8 Compiler gewandert, aber die free Version kann nicht ordentlich optimieren.

(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)

[ch_ris]

Naja, dann gibt's einen ARM-/Teensy-Faden. Vielleicht?
Je schneller je besser bitte.

[Fritzler]

Also bei ARM kann ich auch so helfen, insbesondere STM32.
Aber nur ohne Gammlduino Untersatz

[ferdimh]

(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)

Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden. Naja, egal.

So wie ich das sehe, ist das technische TODO um den Support zu erhalten garnicht so kompliziert. Schwieriger dürfte sein, die erzeugten Patches auch durch die Bürokratie zu kriegen (davon abgesehen, dass ich das Ganze mal wieder eine saublöde Aktion finde).

[sukram]

Puuh. Ich war gerade über den Jahreswechsel dabei, aus verschiedenen AVR Projekten eins für mich zusammenzufrickeln. Konkret in dem Fall yaMBSiavr (in der Ausprägung eines auf Github gefundenen Bodenfeuchtefühlerprojektes) und Fritzlers BME280 Lib.

Ziel war es, ein kompaktes Raumthermostat, wahlweise mit Analog-In und oder Digital I/O sowie Modbus RS485 auf einem 50x50mm Platinchen herzustellen. Es gibt vergleichbare Module fertig, z.B. von Thermokon (WRF07 P rH AO2V RS485Modbus), da kostet aber der Raumfühler mit Luftfeuchte, Modbus und I/O (0-10V und Digital) mal eben lässig >200Eur...

Derzeit existiert ein kompaktes Layout auf Basis eines Mega88 (der bis zum 328 Pinkompatibel sein sollte). Mit Stepdown von 24V auf 5V und 3.3V LDO für den BME280.

Jetzt überlege ich aber, ob ich das so wirklich baue. Kostenmäßig lande ich irgendwo bei 25-30Eur pro Modul, wenn das Layout keine groben Schnitzer hat (würde bei jlcpcb einkaufen). Schaue ich mich da ein wenkg um, finde ich bei Olimex ein niedliches kleines ESP32 Board mit LAN und PoE für ca 18Eur. Da kommt noch ein BME280 dazu (ca 6Eur) und fertig. Gut, das Modul ist 75mm Lang (+ LAN Stecker) und ich muss eine Sternverkabelung ziehen (Kabel muss so oder so eingebaut werden), aber am Ende lohnt es sich doch gar nicht, weiter über den Eigenbau nachzudenken, oder? Ich meine, wenn jetzt auch der Compilersupport zurückgefahren wird (stört mich jetzt nicht, aber wer weiß, wenn ich in ein paar Jahren da mal dran muss?)

Dass ich dann per LAN und nicht Modbus verkabele, ist egal - die Technik ist eh in einem isolierten Netzwerk...

[Fritzler]

Na das ist jetzt nicht zum Panik schieben da.
Dein Projekt wirste schon noch durchziehen können.
Das wird schon so 10J dauern bis da was stirbt.
Die letzte WinAVR Version is ja auch von 2011

Du hast eher das Problem der hohen Temperaturabweichung beim BME280, also pack noch ein LM75 daneben.

Ein ESP32 Brett mit POE und so günstig?
Jetz bin ich neugierig, zeig mal bitte.
Ich hab mir mal ein POE Switch zugelegt, weil ich diverses Testequipment mit ModbusTCP und POE bauen will.

Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden.

Wo drückt der ARM denn im Schuh?

[sukram]

Mal schauen, ich werde wohl erstmal vorsichtig in beide Richtungen experimentieren. Aufgrund akuter Faulheit bin ich aber geneigt, die weniger aufwendige Variante zu wählen.

Das ESP Board wäre das hier:

https://www.olimex.com/Products/IoT/ESP ... e-hardware

Ja, Versand und Steuer usw., aber trotzdem günstig, wenn man ein paar mehr kauft.

Mit den Temperaturwerten muss ich mal sehn, Platz für einen LM75 wäre noch, ggf. auch im TO Gehäuse mit langen Beinen - damit das Board weniger Einfluss hat.

[Fritzler]

Hmm, schade.
Leider nicht galvanisch getrennt.

Wenn die Temperatur so richtig genau sein soll gibts auchnoch sone Scherze:
https://www.mouser.de/ProductDetail/634-SI7051-A20-IM
https://www.mouser.de/ProductDetail/403-STS21

[sukram]

Den gibts auch in galvanisch getrennt, kostet knapp 7 eur mehr:
https://www.olimex.com/Products/IoT/ESP ... e-hardware

Ich bin mir nicht sicher, ob ich die Temperatur so genau brauche... Wichtig wäre mir nur, dass eine eventuelle Abweichung im Bereich 10-40°C linear bleibt, damit man die mit einem Offset rausrechnen kann.

Nunja. Schritt 1 wird erstmal ein Prototyp in Lochraster werden, da habe ich alles griffbereit. Wenn es klappt, dass der AVR mit 8 oder 10Mhz immer noch schnell genug ist, werde ich die Platine komplett auf 3.3V umstricken. Aber erstmal "im großen" Testen.

[Fritzler]

Ja, da hilft dann nur experimentieren.

Die bei Olimex sind aber auch lustig.
Ich weis jetzt nicht warum die das so gemacht haben:
Die verbauen einen "wunschlos glücklich" POE IC von SI -> SI3402.
Der hat die beiden POE Gleichrichter drinne und einen Flyback DC/DC für die galvanische Trennung.
Aber stattdessen nehmen die einen speziellen RJ45 MagJack mit integrierten Gleichrichter (die Dinger kosten mehr) und nutzen den DCDC des SI nur als StepDown.
Dahinter packen die dann einen 5V->5V DCDC für die galvanische TRennung.
Äh wädd?

Mit 25€ kom ich aber schon in die Selbstbauregion, vor allem hab ich dann einen STM32 drinne und muss nicht auf den ESP32 umschwenken.
(WLAN brauchts erstmal nicht).
Aber jetzt kenn ich einen wunschlos glücklich POE IC

[ferdimh]

Wo drückt der ARM denn im Schuh?

Komplexität überall.
Das ist weniger ein Problem des Prozessorkerns als der gefühlt 200 möglichen eingebauten oder nicht eingebauten Peripheriegeräte, die dann auch noch relativ komplex getaktet werden können.
Und dann gibts keine so etablierte Umgebung wie gcc+avr-libc, die "einfach so" da ist (=bei $LINUX_DISTRIBUTION enthalten). Wenn ich ein altes Projekt anfasse, gehts immer mit "wo habe ich denn jetzt die passenden libs+compiler archiviert?" los.
Das Problem würde sich mit steigender Etablierung lösen, wo sich wieder einzelne Typen (und auch Enwicklungsumgebungen) durchsetzen...

[Fritzler]

Und dann gibts keine so etablierte Umgebung wie gcc+avr-libc, die "einfach so" da ist (=bei $LINUX_DISTRIBUTION enthalten).

Doch
https://developer.arm.com/tools-and-sof ... /downloads
Natürlich kannst du den GCC auch selber zusammennageln wenn du auf Schmerzen stehst*.
Der avr-gcc ist doch auch nicht direkt enthalten und muss als Binärpaket nachinstalliert werden.

* Das ist auch immer das Selbe: gcc+newlib in der neusten Version und dann gehts los.
https://wiki.ubuntuusers.de/Archiv/GNU_ARM-Toolchain/

Komplexität überall.
Das ist weniger ein Problem des Prozessorkerns als der gefühlt 200 möglichen eingebauten oder nicht eingebauten Peripheriegeräte

So viel gibts davon garnicht, das sind immer dieselben SPI/UART/I2C etc, nur eben sehr viele paralel davon im Silizium.
Daher darfste eben nicht sowas schreiben wie: uart2_putc(char c)
sondern: uart_putc(struct uartregs* uart, char c);
struct uartregs ist ein memory mappd struct der uart Register und das ist Teil des Inits für zB deine SPI LCD Lib, kommt also im Anwendungscode nicht an.
Aber ja für den SDIO/Ethernet Block musste mehr Hirnschmlz investieren, aber sowas hat der AVR erst garnicht.

die dann auch noch relativ komplex getaktet werden können.

https://www.youtube.com/watch?v=pQsyuiPl1WY
Will sagen: gib Stoff! Wenn du nicht Stromsparen musst, dann dreh per PLL alles so hoch wies geht

Sobald du deine Grundblöcke hast ist das auch nurnoch mit Lego spielen.

[ch_ris]

Ich werd wahnsinnig.
Die aufgabe: einzelne Bytes über die serielle schnittstelle an den Labtop mit win10 schicken. Schnell.
Hab das getestet mit einem Uno, leuft.
Dann halbfertig aufgebaut mit Nano (CH340), hier kommt nur noch mist am laptop an, bei baudraten größer 230400.
Am Kabel liegts nicht, hab 3 ausprobiert.
stromversorgung usb/batterie macht auch keinen unterschied.
Treiber? ist 3.5.2019.1
unter win7 hatte das funktioniert bis hoch zu 921600.

[Sir_Death]

schon mal einen anderen nano genommen? - nicht dass der Eine einen Schaden hat?

[ch_ris]

ja hab ich.
hab auch bei den erweiterten seriellen einstellungen über den gerätemanager nix ausser fifo ja/nein.
da gabs doch noch mehr! latency etc.?

[Sir_Death]

was hat der UNO für einen USB-Chip? - Dann würde ich mir einen Nano mit gleichem Chip besorgen.

[Christian Knüll]

Der CH340 schafft locker 1Mbaud - an dem sollte es nicht liegen.

[Sir_Death]

Wenn es kein Fake ist

Ich denke nur, dass es - wenn es mit dem UNO geht und mit dem NANO nicht - an der Platine liegen muss, nicht am Rechner, nicht an der SW am Rechner, nicht an der SW für den Arduino.
Darum meine Frage nach einem möglichen Unterschied zwischen den Platinen.

[ch_ris]

glaub der uno hat nen ftdi.
Aber der ch340 kanns ja, und zwar genau dieser, hat er ja schon bewiesen.
Ich denke eher in richtung win10 bzw. treiber.
und da bin ich grad hilflos.
Wo kann ich bei dem win 10 die latency einstellen?

[Sir_Death]

hmmm...
dafür scheint der CH340 nicht ganz so toll geeignet zu sein. Er kann zwar 1 Mbaud, wenn die Daten in einem Strom kommen, aber bis sie ankommen...
https://forum.hobbycomponents.com/viewt ... 1782#p6387
https://www.alfaowner.com/threads/vag-c ... ue.523161/

latency kannst du einstellen, wenn es der Treiber unterstützt - FTDI kann das...
https://www.campbellsci.com/blog/usb-rs ... ble-issues

[ch_ris]

mit der Lupe nochmal geguckt: ist kein ftdi auf dem Uno, sondern Atmega8U2 (...programmed as a USB-to-serial converter.)
Mag sein das der ch340 nicht so toll ist, aber es ging ja vorher mit win7, für mich bleibt der Arsch in der Geschichte das f....g win10.
Das ist jetzt kein Lösungsansatz, aber die Schuldfrage muss geklärt sein

[Sir_Death]

OK, wenn dir jetzt leichter ist

[Raja_Kentut]

Ich bin am durchdrehn... das Programm soll meine Kellerfensterlüftung automatisieren.
Es sieht so aus als würde "fenster_schliessen" nie durchlaufen. Ich komm nicht drauf warum ? Die Schalter "Hand_Zu" und "Hand_Auf" liefern ihre 5V sauber an den Pins ab.
Die Signale "ZylAus_I" und "ZylEin_I" sind auf dauerhigh gelegt.
Ist warscheinlich wieder son Anfängerding...

Code: Alles auswählen

//*************** HW Pinbelegung Leonardo Micro ***************************
//Pin 2 - I2C SDA
//Pin 3 - I2C SCL
//Pin 4 - OneWire Data (mit PullUp 4k7 an Vcc)
//Pin 5 - ZylAus_O Output für Signal Zylinder ausfahren
//Pin 6 - ZylEin_O Output für Signal Zylinder einfahren
//Pin 7 - ZylAus_I Input für Signal Zylinder ausgefahren (hinter Endschalter Endposition)
//Pin 8 - ZylEin_I Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
//Pin 9 - Hand_Auf Input für Signal Fenster manuell öffnen
//Pin10 - Hand_Zu  Input für Signal Fenster manuell schliessen

//  ************* Libraries **************************
                             // Library starten

//  ************* Variablen ******************************
  int ZylAus_O = 5; // Output für Signal Zylinder ausfahren
  int ZylEin_O = 6; // Output für Signal Zylinder einfahren
  int ZylAus_I = 7; // Input für Signal Zylinder ausgefahren (hinter Endschalter Endposition)
  int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
  int Hand_Auf = 9; // Input für Signal Fenster manuell öffnen
  int Hand_Zu = 10; // Input für Signal Fenster manuell schliessen

//  ************* Setup ******************************
void setup() 
{
  Serial.begin (9600);  // UART Kommunikation initialisieren und auf 9600 Baud
  
// ************* Pinzuweisungen I/O *****************
  pinMode(ZylAus_O, OUTPUT);
  pinMode(ZylEin_O, OUTPUT);
  pinMode(ZylAus_I, INPUT);
  pinMode(ZylEin_I, INPUT);
  pinMode(Hand_Auf, INPUT);
  pinMode(Hand_Zu, INPUT);

  digitalWrite(ZylAus_O,LOW);  //Bei Programmstart Ausgänge auf LOW setzen
  digitalWrite(ZylEin_O,LOW);
  
}

// ************* Routinen für öffnen und schliessen *****
// ******** offnen *******************
void fenster_oeffnen ()   // Starten der Funktion Fenster öffnen
{
  if(digitalRead(ZylAus_I) == HIGH)    // Wenn Endschalter nicht belegt, Zylinder ausfahren sonst Ausgang auf 0 setzen
  {
    digitalWrite(ZylAus_O, HIGH);// Wenn Endschalter nicht belegt, Zylinder ausfahren über Pin ZylAus_O (9)
    Serial.println("fenster_oeffnen gelaufen");
    delay(1000);        //Nur zum testen weil noch ohne Endschalter
  }
   else
   {
    digitalWrite(ZylAus_O,0);      // Wenn Endschalter nicht belegt, Ausgang auf 0 setzen
   }
}
// ******** schließen ***************
void fenster_schliessen ()
{
  if(ZylEin_I == HIGH)
  {
    digitalWrite(ZylEin_O, HIGH);
    Serial.println("fenster_schliessen gelaufen");
    delay(1000);        //Nur zum testen weil noch ohne Endschalter
  }
   else
   {
    digitalWrite(ZylEin_O,0);
   }
}

// ************* Ende Routinen für öffnen und schliessen *****
  
// ************* Hauptprogramm ***********************

void loop() {
  // put your main code here, to run repeatedly:

  if(digitalRead(Hand_Auf) == HIGH)
   {
    fenster_oeffnen();
    Serial.println("Fenster ist offen");
   }
    else
    if(digitalRead(Hand_Zu) == HIGH)
    {
     fenster_schliessen();
     Serial.println("Fenster ist zu");
    }
      else
      {
   Serial.println("Automatik");
      }
}

[ch_ris]

mach doch mal eine ausgabe zu jeder Anweisung.

[Raja_Kentut]

ich hab ja in jedem Teil die "println" drin.
Bis auf "fenster_schliessen gelaufen" kommen auch brav die Meldungen zum passenden Moment.
Signal "ZylEin_O" (Output für Signal Zylinder einfahren) wird nie gesetzt. Daher glaube ich das das Programm nie daran vorbei kommt.

Die Signale "ZylAus_I" und "ZylEin_I" sind inzwischen auch über Schalter.

Da muß doch in der Hauptschleifenfuktion was in die Hose gehen... oder?
// ************* Hauptprogramm ***********************

void loop() {
// put your main code here, to run repeatedly:

if(digitalRead(Hand_Auf) == HIGH)
{
fenster_oeffnen();
Serial.println("Fenster ist offen");
}
else
if(digitalRead(Hand_Zu) == HIGH)
{
fenster_schliessen();
Serial.println("Fenster ist zu");
}
else
{
Serial.println("Automatik");
}
}

[Hightech]

Im else steht ein if hintenan, soll das so?
Da bekomme ich einen Knoten im Hirn, da müsste ich mir erstmal ein Plan zu zeichnen.

[Raja_Kentut]

das soll ein "else if" sein, das Handbuch sagt so :
zit:
'else' kann auch noch weitere 'if' Abfragen enthalten, so dass mehrfache Test zur selben Zeit stattfinden können. Es ist sogar möglich eine unbegrenzte Anzahl von diesen 'else' Abzweigungen zu nutzen. Allerdings wird je nach den Bedingungen nur ein Set von Anweisungen ausgeführt:
if (inputPin < 500)
{ doThingA; }
else if (inputPin >= 1000)
{ doThingB; }
else
{ doThingC; }
ende zit

(das if braucht nicht in der gleichen Zeile zu stehen wie das else (hab ich ausprobiert))

[ch_ris]

es ist ja nun nix mit breakpoints und Debugger. bleibt nur konsequent alles zu loggen, dann siehste sofort wo es klemmt.
sag ich, wasser predigend.....

[Bastelbruder]

Prost!

[ferdimh]

Ich sehe hier das größte Fehlerpotential in der Pinzuordnung.
Ich würde da mal ein Testprogramm schreiben, das den fraglichen Pin als Ausgang konfiguriert und daran irgendwas eindeutig identifizierbares tut.
Dann den Pin als Eingang konfigurieren und den Zustand ausgeben.
Dann im fraglichen Programm die "nie aufgerufenen" Bedingung durch eine 1 ersetzen, so dass sie immer aufgerufen wird.
Dann ist der Fehler schon mal sehr weit eingegrenzt.

Die Konstante "HIGH" ist mir auch neu, hier besteht auch noch eine Fehlermöglichkeit.

[j.o.e]

Code: Alles auswählen

void fenster_schliessen ()
{
  if(ZylEin_I == HIGH)
  {
    digitalWrite(ZylEin_O, HIGH);
    Serial.println("fenster_schliessen gelaufen");
    

Code: Alles auswählen

  if(digitalRead(ZylEin_I) == HIGH)

sollte es tun

Edith meinte, ich sollte das noch erklären.

Oben schreibst Du

Code: Alles auswählen

  int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)

auf deinem if(ZylEin_I == HIGH) wird damit if(8 == HIGH) - und das trifft halt nie ein, höchstes es verderht dir jemand das ZylEin_I.

Da das sowieso nicht gewollt ist, schreibt man besser

Code: Alles auswählen

  const int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)

oder eben

Code: Alles auswählen

#define ZylEin_I  8

[Raja_Kentut]

Danke ! Werd ich morgen mal angehen. If digitalRead dürfte es gewesen sein...
Das wars! Ich habe bestimmt 20mal über die Zeile geschaut es selbst aber nicht gesehen...
EDIT:
So, es hat funktioniert DANKE WIEDER MAL ANS FORUM !

Und hier der Endgültige Code - das Gesamtkunstwerk kommt mit Bildern in "Eure Projekte..." wenns fertig ist.

Code: Alles auswählen

//*************** HW Pinbelegung Leonardo Micro ***************************
//Pin 2 - I2C SDA
//Pin 3 - I2C SCL
//Pin 4 - OneWire Data (mit PullUp 4k7 an Vcc)
//Pin 5 - ZylAus_O Output für Signal Zylinder ausfahren (Relais oder SSR für Ausfahrmotor [oder Drehrichtung 1]
//Pin 6 - ZylEin_O Output für Signal Zylinder einfahren (Relais oder SSR für Einfahrmotor [oder Drehrichtung 2]
//Pin 7 - ZylAus_I Input für Signal Zylinder ausgefahren (Endschalter Endposition belegt)
//Pin 8 - ZylEin_I Input für Signal Zylinder eingefahren (Endschalter Anfangsposition belegt)
//Pin 9 - Hand_Auf Input für Schalter-Signal Fenster manuell öffnen
//Pin10 - Hand_Zu  Input für Schalter-Signal Fenster manuell schliessen

//  ************* Libraries **************************
#include <OneWire.h>            // für Dallas 18B20 Temp.-Chip
#include <DallasTemperature.h>  // für Dallas 18B20 Temp.-Chip 
#include "Wire.h"               // für SHT31 Temp./RH-Chip
#include "SHT31.h"              // für SHT31 Temp./RH-Chip

OneWire oneWire(4);                    // Data Pin von Sensor am Pin 4 angeschlossen (4)
DallasTemperature sensors(&oneWire);   // Library starten
SHT31 sht;                             // Library starten

//  ************* Variablen ******************************
  float gradC_I;   // Innentemperatur in Grad Celsius
  float gradC_A;   // Aussentemperatur in Grad C
  float humid_RH;  // Aussenfeuchte in %RH
  float tp;        // Taupunkt in Grad C

  int ZylAus_O = 5; // Output für Signal Zylinder ausfahren
  int ZylEin_O = 6; // Output für Signal Zylinder einfahren
  int ZylAus_I = 7; // Input für Signal Zylinder ausgefahren (hinter Endschalter Endposition)
  int ZylEin_I = 8; // Input für Signal Zylinder eingefahren (hinter Endschalter Anfangsposition)
  int Hand_Auf = 9; // Input für Signal Fenster manuell öffnen
  int Hand_Zu = 10; // Input für Signal Fenster manuell schliessen

//  ************* Setup ******************************
void setup() 
{
  Serial.begin (9600);  // UART Kommunikation initialisieren und auf 9600 Baud
  sensors.begin();      // Dallas 18B20 initialisieren

  Wire.begin();         // I2C Initialisieren
  sht.begin(0x44);      // SHT31 initialisieren
  Wire.setClock(1000);  // I2C Geschwindigkeit auf 1000 setzen

// ************* Pinzuweisungen I/O *****************
  pinMode(ZylAus_O, OUTPUT);
  pinMode(ZylEin_O, OUTPUT);
  pinMode(ZylAus_I, INPUT);
  pinMode(ZylEin_I, INPUT);
  pinMode(Hand_Auf, INPUT);
  pinMode(Hand_Zu, INPUT);

  digitalWrite(ZylAus_O,LOW);  //Bei Programmstart Ausgänge für Zylindermotoren auf LOW setzen
  digitalWrite(ZylEin_O,LOW);
}

// ***************Funktionsroutinen *****************
//void fenster_oeffnen()   // Funktion Fenster öffnen
//void fenster_schliessen()// Funktion Fenster schliessen
//float werte_einlesen     // Funktion Sensoren ausesen

// ************* Routinen für öffnen und schliessen *****

// ******** öffnen *******************
void fenster_oeffnen()   // Starten der Funktion Fenster öffnen
{
   digitalWrite(ZylEin_O,LOW);    // Sicherstellen, dass nie beide Zylindermotoren gleichzeitig laufen
   digitalWrite(ZylAus_O, HIGH);  // Zylinder ausfahren über Pin ZylAus_O (5)
   
    while(digitalRead(ZylAus_I) == HIGH) // Solange Endschalter nicht belegt, bleibt ZylAus_O = HIGH, sonst ZylAus_O zurücksetzen
   {
    digitalWrite(ZylAus_O, HIGH);
   }
  digitalWrite(ZylAus_O, LOW);
  }
// ******** schließen ***************
void fenster_schliessen()
{
  digitalWrite(ZylAus_O,LOW);
  digitalWrite(ZylEin_O, HIGH);
  
  while(digitalRead(ZylEin_I) == HIGH)
  {
   digitalWrite(ZylEin_O, HIGH);
  }
  digitalWrite(ZylEin_O, LOW);
  }
// ************* Ende Routinen für öffnen und schliessen *****

// *************Routine Werte aus Sensoren einlesen***********
float werte_einlesen()
{
// ---   Messwerte aus Sensoren einlesen   ---
    // Anfang Messung Innentemperatur ( gradC ) vom Dallas Temperatursensor
    sensors.requestTemperatures();     // Temperaturmessung starten
    gradC_I=sensors.getTempCByIndex(0);  // gemessene Temperatur der Variablen gradC_I zuweisen
    //Ende Messung Innentemperatur vom Dallas Temperatursensor. Temperatur nun in der Variable gradC

    // Anfang Messung Aussentemperatur (gradC_A) und Feuchte (humid_RH) vom SGT31 Sensor
     sht.read();         //SHT31 Messung starten
     gradC_A=sht.getTemperature(), 1;  //SHT31 Temperaturwert in Variable gradC_A speichern
     humid_RH=sht.getHumidity(), 1;    //SHT31 Feuchtewertt in Variable humid_RH speichern
    // Ende Messung Aussentemperatur (gradC_A) und Feuchte (humid_RH) vom SGT31 Sensor
// ---      Messwerte sind eingelesen      ---
}
// ************** Routine Taupunktberechnung ****************
float taupunkt_berechnen()
{
    // verwendete Variablen :
    //  float gradC_I;   // Innentemperatur in Grad Celsius
    //  float gradC_A;   // Aussentemperatur in Grad C
    //  float humid_RH;  // Aussenfeuchte in %RH
    //  float tp;        // Taupunkt in Grad C
    //--- Formel für Taupunktberechnung ---------------------
      tp = 243.12*((17.62*gradC_A)/(243.12+gradC_A)+log(humid_RH/100))/((17.62*243.12)/(243.12+gradC_A)-log(humid_RH/100));
    // *************Ende Routine Taupunktberechnung***********
// ---          Messwerte ausgeben         ---
      Serial.print("Innentemperatur:  ");
      Serial.println (gradC_I);            // Variable gradC_I auf UART ausgeben
      Serial.print("Aussentemperatur: ");
      Serial.println(gradC_A);           // Variable gradC_A auf UART ausgeben
      Serial.print("Aussenfeuchte RH: ");
      Serial.println(humid_RH);          // Variable humid_RH auf UART ausgeben
      Serial.print("Taupunkt:         ");
      Serial.println(tp);
      delay(1000);
// ---      Messwerte sind ausgegeben     ---
// *************Ende Routine Werte aus Sensoren einlesen***********
}
  
// ************* Hauptprogramm ***********************
void loop() 
{
// --- Prüfung Hand- oder Automatikbetrieb ---
  werte_einlesen();                             //Sensorwerte einlesen
  taupunkt_berechnen();                         //Routine taupunkt_berechnen anspringen
  
 if(digitalRead(Hand_Auf) == HIGH)
   {                                           //WENN "Handbetrieb öffnen" dann Routine fenster_oeffnen anspringen
    fenster_oeffnen();                          //Routine fenster_oeffnen anspringen
    Serial.println("Handbetrieb(öffnen)");      //Statusmeldung "Handbetrieb(öffnen)" auf UART ausgeben
   }
    else if(digitalRead(Hand_Zu) == HIGH)
    {                                            //SONST1, wenn "Handbetrieb schliessen" dann Routine fenster_schliessen anspringen
     fenster_schliessen();                       //Routine fenster_schliessen anspringen
     Serial.println("Handbetrieb(schliessen)");  //Statusmeldung "Handbetrieb(schliessen)" auf UART ausgeben
    }
                                                 //SONST2, wenn kein Handbetrieb ausgewählt, dann Automatikmodus
     else if(gradC_A < gradC_I)
     {                                            //WENN Aussentemperatur kleiner als Innentemperatur, dann Routine fenster_schliessen anspringen
      Serial.println("Automatik schliessen A<I"); //Statusmeldung "Automatik schliessen A<I" auf UART ausgeben
      fenster_schliessen();                       //Routine fenster_schliessen anspringen
      while(gradC_A < gradC_I)                    //So lange hier bleiben wie Aussentempertaut kleiner Innentemperatur
        {
        werte_einlesen();
        Serial.print("Innentemperatur:  ");
        Serial.println (gradC_I);            // Variable gradC_I auf UART ausgeben
        Serial.print("Aussentemperatur: ");
        Serial.println(gradC_A);           // Variable gradC_A auf UART ausgeben
        Serial.println("Aussen kälter als Innen");//Statusmeldung "Aussen kälter als Innen" auf UART ausgeben
        }                       
     }  
       else if(tp > gradC_I)
       {                                            //SONST3, wenn Taupunkt über Innentemperatur, dann Routine fenster_schliessen anspringen
        Serial.println("Automatik schliessen TP>I");//Statusmeldung "Automatik schliessen TP>I" auf UART ausgeben
        fenster_schliessen();                      //Routine fenster_schliessen anspringen
       }  
        else if(tp < gradC_I) 
        {                                          //SONST4, wenn Taupunkt unter unter Innentemperatur, dann Routine fenster_oeffnen anspringen
         Serial.println("Automatik öffnen TP<I");  //Statusmeldung "Automatik öffnen TP<I" auf UART ausgeben
         fenster_oeffnen();                        //Routine fenster_oeffnen anspringen
        }
         
}

[Cubicany]

Auf Geheiß poste ich hier mal mein derzeitiges Problem.

Was es können soll:

Einen Motor, den ich an 24V AC habe und der im Steinmetz angeschlossen ist, in der Drehrichtung alle 10 Sekunden umschalten.
Der Motor braucht 8 Sekunden bis er eine Endlage erreicht und hat 2 Sekunden Wartezeit.

Geschaltet werden soll er über so eine China Relaiskarte mit 8 Relais. Ich brauche zwar nur eins, habe aber nur die Karte hier.

Der Programmcode dazu ist dieser:

Code: Alles auswählen

const int RELAY1 = 10;
unsigned long startzeit_1 = 0;
unsigned long laufzeit_1 = 10000;
void setup()
  {
  Serial.begin(115200);
  while (!Serial);
  digitalWrite(RELAY1, HIGH);
  pinMode(RELAY1, OUTPUT);
  }


void loop()
  {
  if (millis() - startzeit_1 >= laufzeit_1)
    {
    Serial.println(startzeit_1);
    startzeit_1 = millis();
    digitalWrite(RELAY1, !digitalRead(RELAY1));
    Serial.println(startzeit_1);
    }
  }

Über den Monitor sollte man eigentlich die 10 Sekunden Steps ablesen können.

Was aber passiert, ist, dass der Serielle Monitor nichts mehr anzeigt, sobald das Programm läuft UND die 24V AC geschaltet werden.

Also scheint die Wechselspannung irgendwie zum disconnect zu führen. Außerdem hängt sich die Schleife
nach einiger Zeit auf.


So ist der Motor am Relais dran:

Über den Mittelkontakt kommen die 24V AC rein, an den beiden äußeren Kontakten (NO/NC) hängen die beiden Leiter
für die Drehrichtungen.

Und der N geht wieder zurück.

Gespeist wird das über einen Modellbahntrafo und der Arduino versorgt sich über USB.

[ch_ris]

wie und wo kommt der arduino ins Spiel?
Das ist doch die wesentliche Information

[Cubicany]

Ach so, der Arduino ist dazu da, das eine Relais (und später über Taster zwei andere) zu schalten.

Spannung für die Relais und der Steuerpin kommen vom Arduino und gehen da drauf.

Hätte nicht gedacht, dass eine Anwendung, die eigentlich jedes Zeitrelais drauf hat, so schwer sein würde.

[sysconsol]

Was mir als erstes auffällt:

Code: Alles auswählen

digitalWrite(RELAY1, HIGH);
  pinMode(RELAY1, OUTPUT);

Du setzt irgendwas und definierst dann die Richtung.
Soll das so?

Spannung für die Relais und der Steuerpin kommen vom Arduino und gehen da drauf.

Wie viel Strom zieht das Relais?
Freilaufdiode vorhanden?
Was macht die Betriebsspannung vom Arduino, wenn das Relais schaltet?

Ggf. kommt da noch ein Transistor als Schalter rein.
Und eine stabile 5V-Versorgung, für das Relais gern extra.


Hängt sich die Schleife auch auf, wenn die 24V AC nicht vorhanden sind, jedoch das Relais schaltet?
Hängt sich die Schleife auch auf, wenn weder Relais noch 24V AC vorhanden sind?

[berlinerbaer]

Was aber passiert, ist, dass der Serielle Monitor nichts mehr anzeigt, sobald das Programm läuft UND die 24V AC geschaltet werden.

Also scheint die Wechselspannung irgendwie zum disconnect zu führen. Außerdem hängt sich die Schleife
nach einiger Zeit auf.

Das müsste eigentlich funktionieren.

Jetzt gilt es, potentielle Fehlerquellen einzukreisen:

• Läuft die Schleife störungsfrei, solange die 24V nicht anliegen?
• Immer noch, wenn die Verkabelung zu Trafo und Motor hergestellt sind, aber noch kein Strom auf dem Trafo ist?
• Probier mal ein anderes Relais, sieben haste ja noch
• Und ein anderes, bekannt verlässliches, kurzes USB-Kabel
• Mach mal lieber Serial.begin(9600); , wir hams ja nicht eilig
• Schau Dir mal die Relais-Platine genau an. Sind da vielleicht Fluxreste drauf, die Kriechströme vom Wechselstrom auf die Arduino-Versorgung ermöglichen?
• Lass den Arduino mal über einen Akku-versorgten laptop laufen, vielleicht ist das 230V-Netz am Problem beteiligt

Das ist jetzt natürlich alles stochern im Nebel, denn eigentlich sollte der Aufbau so elektrisch funktionieren, Code hab ich mir nicht angeguckt.

[Cubicany]

Ich gehe das alles mal von oben nach unten durch.

Der Code wurde mir im den Arduino Forum so empfohlen.
Den habe ich noch nicht mal selber gemacht.
Ich verstehe noch nicht mal alles, was da steht.

Wie viel Strom das Relais zieht?

Kann nicht so viel sein. Außerdem hatte ich ein anderes Programm, wo
alle Relais an sind und das lief. Also ein Spannungseinbruch schließe ich
mal gewagt aus.

Freilaufdiode?

Haben diese China Karten eventuell schon eine drauf? Ich weiß es ehrlich gesagt nicht.

Die Schleife hängt sich auch auf, wenn weder Last, noch Trafo oder so in egal welcher
Konstellation da sind.

Es ist auch egal, welches Relais, welches Kabel oder Rechner.

Ich habe auch echt keine Idee mehr, was ich noch machen soll.

Ich bin echt drauf und dran, das alles raus zu schmeißen und einfach ein Zeitrelais mit
zwei Tastern dran zu machen. Geht auch.

[ch_ris]

war quatsch.

wie jetz? der code läuft nicht sobald du das relais anschließt?

[Raja_Kentut]

Probier mal aus was sysconsol schrub. ERST die Richtung definieren, dann DigitalWrite.
Ich hatte auch sonderliche effekte, ihne das der Compiler meckerte.

[berlinerbaer]

Was mir als erstes auffällt:

Code: Alles auswählen

digitalWrite(RELAY1, HIGH);
  pinMode(RELAY1, OUTPUT);

Du setzt irgendwas und definierst dann die Richtung.

Das ist schonmal ein sehr berechtigter Einwand.

Diese beiden Zeilen sollten die Plätze tauschen, denn sonst ist der interne pullup beim digitalWrite noch aktiv, es sei denn, der compiler biegt das hinter Deinem Rücken wieder gerade. Würde ich mich nicht drauf verlassen und stattdessen sauber arbeiten.

Das könnte die beim Relais ankommende Spannung derart begrenzen, daß es nicht mehr verlässlich schaltet.

Ansonsten ist das Deine Baustelle, wenn also Dein Code nicht funzt und Du auch nicht den Ehrgeiz hast, herauszufinden woran das liegt, weil irgendwelche Arduino-Foristen, die nicht in der Lage sind, die Doku sinnentnehmend zu lesen (https://www.arduino.cc/reference/de/lan ... italwrite/) und meinen, das passt schon, dann sieht das nicht sehr erfolgversprechend aus.

Klar kann das frustrierend sein, aber auch eine Herausforderung, an die man positiv herangehen kann...

Verstehe ich das richtig, daß, auch wenn Du nur die Relais-Platine schaltest, jedoch keine Kabel mit dem Leistungsteil der Relais verbunden sind, trotzdem Probleme auftreten?

[Cubicany]

Das eben war gerade wtwas in Rage in die Tastatur gehauen.

Ich kniffel da schon gerne dran rum.

Aber um auf die Frage zu kommen:

Tatsächlich tritt das auch ohne Last auf.

Sehr selten, aber die Schleife kommt dann zum Erliegen. Vermutlich, weil ja die
Bedingung "geschaltetes Relais" nicht mehr kommt. Ich versuche mal, das mit den
getauschten Zeilen drauf zu ziehen.

Mit Last tritt der Effekt schneller auf.

Nur wundert es mich, dass die Arduino.cc Leute das genau so empfohlen haben.

Aber da gibt es so viele Ansichten wie Widerstandswerte in der Norm. Das durfte
ich da schon lernen.

[Sven]

Mal dir mal als Ablaufdiagramm auf, was dein Programm tun soll. Daraus lässt sich dann leichter funktionierender Code ableiten als aus nicht funktionierendem Code und Beschreibungstext zur gewünschten Funktion.

[ch_ris]

ich hab mir den code nicht angesehen...
mach mal n 9v block dran, vielleicht taugt der usb nix?

[Cubicany]

Ich habe den auch an Netzgerät gehabt und über USB dann ausgewertet. Den Port habe ich auch mal gewechselt.

Momentan läuft es und ich bin mal vorsichtig optimistisch, das es jetzt geht.

Ablaufdiagramm habe ich bisher nur einmal eins gemacht und das war ein Krampf, wie ich damals fand.

Wie gesagt, ich hatte ganze 2 Stunden Info.

[Sven]

Ablaufdiagramm habe ich bisher nur einmal eins gemacht und das war ein Krampf, wie ich damals fand.

Wie gesagt, ich hatte ganze 2 Stunden Info.

Es muss ja nicht nach Norm sein. Allerdings funktioniert planloses Programmieren nicht. Gerade Anfänger sollten
sich tunlichst erstmal klar machen, was sie überhaupt erreichen wollen. Also mal dir eben auf, was dein Programm überhaupt tun soll. Außerdem erleichtert es uns dann, dir zu helfen.
Wenn die logische Struktur in der Programmidee schon nicht korrekt ist, wie soll dann das Programm denn richtig funktionieren?


Ich bin seit vielen Jahren als Softwareentwickler unterwegs und kritzel mir immer noch Pläne, Zustandsmatrizen und ähnliches, wenn komplexere
Dinge angegangen werden. Das ist nämlich 75% der eigentlichen Arbeit. Der Rest ist dann "nur noch" übersetzen in eine dem System verständliche Sprache.
Für einfachen Kram braucht man sowas später nicht mehr, das ist klar.

[Anse]

Nur wundert es mich, dass die Arduino.cc Leute das genau so empfohlen haben.

Arduino ist für Quereinsteiger entwickelt. Was hast Du erwartet? Wirst in so einem Forum nur sehr wenige µC Profis, wenn überhaupt, finden.
Denkt mal, die Erfahrungs-Dichte ist hier deutlich größer.

Zur eigentlichen Frage, um eine AVR so richtig aus dem Tritt zu bringen braucht es schon mehr. Off kommt das von Störungen auf der Versorgung. Also mal einen Elko parallel und eine Induktivität in reihe in die Versorgung. Kann auch sein, dass der Spannungsregler auf dem Board bei kurzer Überspannung für einen Moment zu macht.
Dann eventuell auch mal die Relais Ansteuerung mit einem Optokoppler abtrennen. Ist zwar doppelt aber so ein Relais kann gerade bei AC auch Störungen übertragen. Freilaufdiode übers Relais ist aber hoffentlich selbstverständlich.