Der AVR-/ARDUINO-Faden

[jodurino]

Hallo

so zum Programm debuggen ist der IDE Seriellemonitor nicht schlecht, habe mir noch Hterm herunter geladen weil manche Sachen ja nicht auf dem IDE Monitor gehen sollen.

Ich möchte gerne wen ich den Monitor oder das Terminalprogramm starte erst mal nix, maximal nur "." angezeigt bekommen.

Dann bei zB Taste "D" sollen Werte angezeigt werden:

Wert 1
Wert 2
Wert 3
.
.
.
Wert 7
mit Serial.prinln(wert)
klappt es auch gut, nur scrollt er dann natürlich nach oben

Hatte schon das her probiert als clearscreen:

Serial.print(27,BYTE); //Print "esc"
Serial.print("[2J");

funktioniert aber nicht da BYTE nicht mehr unterstützt wird.

Gibt es da eine Lösung für eine rudimentäre GUI?

cu
jodurino

[Finger]

Benutze sprintf mit %c, so in etwa

char buf [20];
sprintf (buf, „%c“, 27);
Serial.print (buf);

Ist deutlich flexibler als der Arduino-Kram, braucht aber auch mehr Speicher.

Oder ne VT100-Lib benutzen...

[Weisskeinen]

Wie wär's mit "Serial.write(27)"?

[jodurino]

Hallo
ok das mit dem VT100 klappt so einigermaßen, muss mich damit noch mehr befassen.

Jetzt wieder was völlig neues, bei dem einen ArduinoNano geht es bei dem anderen nicht.

An DigitalPin2 ist ein OptokopplerAusgang und 10kPullUp Widerstand an 5V. Lege ich 12V mit Vorwiderstand an de Optokopplereingang wird DigitalPin2 auf Low gezogen.

Code: Alles auswählen

#include <avr/sleep.h>

void INT_PINisr(void)
  /* ISR fuer Pin 2 */
  {
  /* detach Interrupt, damit er nur einmal auftritt */
  detachInterrupt(0);
  }

void enter_sleep(void)
  {
  attachInterrupt(digitalPinToInterrupt(2), INT_PINisr, LOW);
	
  //attachInterrupt(0, INT_PINisr, LOW);
  /* Arduino schlafen legen */
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sleep_mode();
  sleep_disable(); 
  }

Also bei dem einen Nano funktioniert es ich rufe in der loop irgendwann die enter_sleep auf und wecke ihn wieder mit dem Interrupt an pin 2

bei diesem geht es nicht, wenn ich 12V anlege und der pin 2 auf low ist hält das Programm einfach an.

Was ist den da nu wieder?

attachInterrupt(digitalPinToInterrupt(2) probiert ohne Erfolg
cu
jodurino

[Finger]

Das

detachInterrupt(0);

in der ISR ist irgendwie nicht koscher (finde ich). Warum machst du das? Irgendwie riecht das nach "Ist eher Zufall das das mal geht", weniger nach Abhängigkeit von einer Hardware...

[jodurino]

Das

detachInterrupt(0);

in der ISR ist irgendwie nicht koscher (finde ich). Warum machst du das? Irgendwie riecht das nach "Ist eher Zufall das das mal geht", weniger nach Abhängigkeit von einer Hardware...

Hallo

Code: Alles auswählen

#include <avr/sleep.h>

#define INT_PIN 2
#define LED_PIN 13

void INT_PINisr(void)
  /* ISR fuer Pin 2 */
  {
  /* detach Interrupt, damit er nur einmal auftritt */
  detachInterrupt(0);
  }

void enter_sleep(void)
  {
  attachInterrupt(0, INT_PINisr, LOW);
  /* Arduino schlafen legen */
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sleep_mode();
  sleep_disable(); 
  }

void setup()
  {
  Serial.begin(9600);
  Serial.println("Starte ...");
  /* Pin 2 als Interrupt-Pin, Pullup einschalten */
  pinMode(INT_PIN, INPUT);
  digitalWrite(INT_PIN, HIGH); 
  pinMode(LED_PIN, OUTPUT);
  Serial.println("Init erfolgt ...");
  delay(100);
  }

void loop()
  {
  /* warten, bis der Interrupt-Eingang wieder frei ist */
  while (digitalRead(INT_PIN) == LOW)
    {
    Serial.println("*** Taste loslassen ***");  
    delay(500);
    }
  Serial.println("Gehe schlafen ...");  
  delay(100);
  /* LED umschalten und wieder schlafen */
  digitalWrite(LED_PIN, ! digitalRead(LED_PIN));
  enter_sleep();
  Serial.println("Bin aufgewacht ...");  
  delay(100);
  }

ich habe es von hier, nur das ich keinen Taster sondern einen Optokoppler an den Eingang angeschlossen habe.
Der Beispielcode funktoniert nur mein Spahhhrgelgetti code nicht.

Habe noch mal neu angefangen und Stück für Stück Ergänzt mal sehen wo der Fehler ist.

cu
jodurino

[Hightech]

Ich hab hier einen ESP8266 als Telegram-Client, der Nachrichten von einem Telegram-Bot empfängt.
Das funktioniert schon mal ganz gut, jedoch wenn der Eingabetext zu lang ist, ca 300-500 Zeichen, kommt am Bot nichts mehr an und auch wenn ich den ESP neu Starte und den Bot neu starte kommen keine Nachrichten mehr am ESP an. Nur wenn ich einen neuen Bot generiere, klappt alles wieder.

Hat da jemand einen Plan von?
Ich vermute irgend ein Server-Puffer bekommt die Daten nicht in den ESP-Puffer und dann bleibt der Brocken da stecken, kann ich da irgendwo einen Timeout bei Telegram setzen oder im ESP einen Inputbuffer Zwischendengeln?

Hier der Code auf dem ESP8266

Code: Alles auswählen

/*******************************************************************
    A telegram bot for your ESP8266 that responds
    with whatever message you send it.

    Parts:
    D1 Mini ESP8266 * - http://s.click.aliexpress.com/e/uzFUnIe
    (or any ESP8266 board)

      = Affilate

    If you find what I do useful and would like to support me,
    please consider becoming a sponsor on Github
    https://github.com/sponsors/witnessmenow/


    Written by Brian Lough
    YouTube: https://www.youtube.com/brianlough
    Tindie: https://www.tindie.com/stores/brianlough/
    Twitter: https://twitter.com/witnessmenow
 *******************************************************************/

#include <ESP8266WiFi.h>
#include <WiFiClientSecure.h>
#include <UniversalTelegramBot.h>
#include <strings.h>

// Wifi network station credentials
#define WIFI_SSID "SSID"
#define WIFI_PASSWORD "PASSWD"
// Telegram BOT Token (Get from Botfather)
#define BOT_TOKEN "TELEGRAMTOKEN"

void nadel_convert(int a)
{

switch(a){
  case 150: //Ö
    a=92;
    break;    
    case 182: //ö
    a=124;
    break;    
    case 156: //Ü
    a=93;
    break;        
    case 188: //ü
    a=125;
    break;    
    case 132: //Ä
    a=91;
    break;
    case 164: //ä
    a=123;
    break;    
    case 159: //ß
    a=126;
    break;
    case 91: //[
    a=40;
    break;
    case 93: //]
    a=41;
    break;
    case 123: //{
    a=40;
    break;
    case 125: //}
    a=41;
    case 92: //\
    a=47;
    break;    
    default:
    break;    
    }
  if ((a>126)||(a<10)){
      ;;}
  else{
    if (isAscii(a)){  
      //Serial.println(int(a));
      Serial.write(a);}
      }          
}

const unsigned long BOT_MTBS = 1000; // mean time between scan messages
String texte;
int len;

X509List cert(TELEGRAM_CERTIFICATE_ROOT);
WiFiClientSecure secured_client;
UniversalTelegramBot bot(BOT_TOKEN, secured_client);
unsigned long bot_lasttime; // last time messages' scan has been done

void handleNewMessages(int numNewMessages)
{
  for (int i = 0; i < numNewMessages; i++)
  {
    texte=(bot.messages[i].text);
    len = texte.length();
    if (len>300){
      bot.sendMessage(bot.messages[i].chat_id,"Der Beitrag ist leider zu lang, >3000 Zeichen");
      }
    else{
        for (int a=0;a<len;a++){
         //Serial.write(texte[a]);
          nadel_convert(texte[a]);
            }
          Serial.write("\n");
          }
    bot.sendMessage(bot.messages[i].chat_id,"Danke für Deinen Beitrag");
    }
}

void setup()
{
  Serial.begin(9600);
//  Serial.println();

  // attempt to connect to Wifi network:
//  Serial.print("Connecting to Wifi SSID ");
// Serial.print(WIFI_SSID);
  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
  secured_client.setTrustAnchors(&cert); // Add root certificate for api.telegram.org
  
  while (WiFi.status() != WL_CONNECTED)
  {
//    Serial.print(".");
    delay(500);
  }
//  Serial.print("\nWiFi connected. IP address: ");
//  Serial.println(WiFi.localIP());

//  Serial.print("Retrieving time: ");
  configTime(0, 0, "pool.ntp.org"); // get UTC time via NTP
  time_t now = time(nullptr);
  while (now < 24 * 3600)
  {
//    Serial.print(".");
    delay(100);
    now = time(nullptr);
  }
//  Serial.println(now);
}

void loop()
{
  if (millis() - bot_lasttime > BOT_MTBS)
  {
    int numNewMessages = bot.getUpdates(bot.last_message_received + 1);

    while (numNewMessages)
    {
     // Serial.println("got response");
      handleNewMessages(numNewMessages);
      numNewMessages = bot.getUpdates(bot.last_message_received + 1);
    }
    bot_lasttime = millis();
  }
}

[lüsterklemme2000]

Hallo, ich bin mir nicht ganz sicher ob das hier hergehört, aber ich möchte keinen extra Faden aufmachen:

Langsam wird es bei mir mal Zeit für den Umstieg von der Atmega Serie Richtung STM32. Bisher habe ich im Programmers Notepad die Software editiert, und mit dem GNU Compiler kompiliert. Der Upload erfolgte dann mittels AVRDUDE und USBAsp.
Kein IDE-Krams, sondern simples Registergeschubse auf unterster Ebene.
Eigentlich würde ich auch bei den STM32 weiterhin auf HAL und co. verzichten wollen. Ich weiß halt gerne, was der Controller auf Registerebene tut. Ganz ohne wird es aber wohl aufgrund der gesteigerten Komplexizität nicht gehen.
Die meisten Tutorials wollen mir entweder die Arduino-IDE, oder die CUBE-IDE andrehen. Nun bin ich von der Arduino-IDE kein Freund, und die CUBE-IDE gefällt auch nicht wirklich (damit könnte ich mich aber anfreunden, wenn es keine Alternative gibt).

Daher wäre meine Frage:
Welche Entwicklungsumgebung/Programme/Toolchain verwendet Ihr und könnt Ihr empfehlen, um von der Idee bis zum fertig programmierten Controller zu kommen (muss auch keine IDE sein)?

Vielen Dank und einen schönen 4.Advent,
Lüsterklemme

[Fritzler]

Du kannst immernoch beim Programmers Notepad und GCC bleiben.
Brauchst eben den ARM GCC: https://developer.arm.com/tools-and-sof ... /downloads
Das ist dann sogar der heißeste sch**ss, der AVR GCC ist ja ziemlich stehen geblieben in der Entwicklung.

Als "brenner" nimmste den stlinkv2, der hat auch ein Commandline Tool und ist damit vom makefile aus bedienbar.
Dieser ist auf den STM32 devboards von ST direkt drauf.
Meine Empfehlung geht aber eindeutig zu einem J-Link edu (66€), aber das erst wenn du gefallen an ARM gefunden hast.
Der kommt dann auch mit einem standalone debugger (Ozone).

Eigentlich würde ich auch bei den STM32 weiterhin auf HAL und co. verzichten wollen. Ich weiß halt gerne, was der Controller auf Registerebene tut. Ganz ohne wird es aber wohl aufgrund der gesteigerten Komplexizität nicht gehen.

So Komplex ist der nun auch wieder nicht.
Es muss ja nicht gleich DMA beim UART genutzt werden.
Beim STM32 gibts das "datasheet", dieses enthält welche Periph es gibt und an welcher Basisadresse diese schlummern.
Dann noch ein reference manual und da sind die Periph dann aufs Bit genau erklärt inkl. Init bzw Handling Sequenzen.

Die Bitdefines sind ARM Universum weit im sogenannten CMSIS vorgehalten.
Für die STM32 kommste da über CubeMX ran.
Das Teil ist übrigens recht brauchbar für Pinbelegungen

Ansonsten Helfe ich hier gerne.

Im Anhang mal Beispielcode für ein startmakefile.
Einmal C und einmal CPP.

[lüsterklemme2000]

Vielen Dank. Das bringt mich denke ich schonmal deutlich weiter. Schön, dass es scheinbar doch unkompliziert geht.
Das Refernce Manual ist ja total geil, jedes Register bis aufs letzte Bit aufgeführt . Das war das was mir immer gefehlt hat. Ich kannte nur das Datasheet und dachte das sei alles, was man dazu bekommt (bei Atmel ist das zumindest bei den ATmega und SAM Serien so).

Dann werde ich mich da mal die Tage dran versuchen und bei Fragen wiederkommen.

[j.o.e]

Welche Entwicklungsumgebung/Programme/Toolchain verwendet Ihr und könnt Ihr empfehlen, um von der Idee bis zum fertig programmierten Controller zu kommen (muss auch keine IDE sein)?

Ich würde Dir auf jeden Fall eine Make-Umgebung empfehlen mit GCC.

Um Code auf das Zielsystem zu schaufeln (angeschlossen über RS-232/TTL) verwende ich seit 8051-Zeiten einen Bootmonitor (Bootloader und Monitor, damals RISM-51). Compiler war imho Keil.

In der 4ma hatten wir das mehr oder weniger genau so beibehalten. Das funktioniert sogar bei gemischten Systemen z.B. ARM und TMS320.

Ich weiß, das stinkt etwas nach Arduino, aber alles ist ja auch nicht schlecht an den Dingern. Und außerdem ist die Technik schon vieeeeel älter.
Genau genommen würde ich sogar den Arduino-Bootloader übernehmen - weil, er ist ja schon da, zumindest für AVR und ARM.

Für die Eingeweide tat's GDB ganz gut, rangetüddelt über JTAG.

[Fritzler]

Die STM32 kommen schon mit Bootloader vom Hersteller.
Ansprechbar mit einem STM32 Commandline Tool.
Die USB Fähigen STM32 haben sogar einen USB Bootloader (DFU: Device Firmware Upgrade).
Damits brauchts dann garkein spezielles STM Tool mehr, das ist ein Standard.

Der mitgelieferte stlink auf den devboards ist aber erstmal besser für den Einstieg.

[j.o.e]

Die STM32 kommen schon mit Bootloader vom Hersteller.
Ansprechbar mit einem STM32 Commandline Tool.

Commandline ist gut, könnte man im "make install" aufrufen.

[ch_ris]

ich probiere grade mit Encodern rum.
https://koraykaraman.com/blog/3546/Ardu ... ed-Library
hab diese lib installiert, dort steht:
There are three options.

Best Performance: Both signals connect to interrupt pins.
Good Performance: First signal connects to an interrupt pin, second to a non-interrupt pin.
Low Performance: Both signals connect to non-interrupt pins, details below.

die dritte, also ohne interupt, geht, selbst bei einfach dran rum drehen, gar nicht.
mit einem interupt scheint's soweit zu funktionieren.
jetzt hat der nano ja nur 2.
meint ihr da geht was per software interupt?

[IPv6]

Im Mikrokontrollerforum stehen da ein paar grundlegende Dinge sehr übersichtlich.
Also was man da für Lösungen wählen kann und wo die Vor- und Nachteile liegen.
Was genau davon deine Lib umgesetzt hat müsstest du nachsehen...

https://www.mikrocontroller.net/articles/Drehgeber

Der Link ist aber gerade nicht verfügbar, im Webarchiv aber einsehbar:
https://web.archive.org/web/20200806064 ... /Drehgeber

[Anse]

meint ihr da geht was per software interupt?

So was wie ein Software Interrupt gibt es bei AVRs nicht.
Die Low Performance Variante nutzt wahrscheinlich einen Timer Interrupt um die Zustandsänderung zu erfassen. Ist der Timer vielleicht schon belegt?
Eigentlich sind so Encoder eine simple Sache, besonders, wenn sie nur als Input Device für den Benutzer dienen sollen. So was lässt sich recht einfach selber schreiben. Man muss eigentlich nur periodisch die Eingänge Abfragen, und vergleichen, ob sich was verändert hat. Wenn ja, dann entscheiden, ob es einen Schritt vorwärts oder rückwärts ging.
Die Interrupt Variante finde ich nicht so toll. Prellende Kontakte können da zu unschönen Effekten führen.

[ch_ris]

ich meinte mittels pinchangeint interrupts zu emulieren.

nee das sind so highspeed encoder mit 2400s/U.
ich glaube da prellt nix.

Code: Alles auswählen

Output :AB 2phase output rectangular orthogonal pulse circuit, the output for the NPN open collector output type
Maximum mechanical speed: 5000 R / min
Response frequency: 0-20KHz

den Artikel +1 muss ich mal durchsehen.
was ich bis jetzt gelesen hab legt schon mal nahe das viel performance viel hilft und evtl. was anderes als nano hier besser wäre.

[Bastelbruder]

Es gibt nichts schlimmeres als die Haptik diverser Drehknöpfe In modernen Heilix Blechle.

In irgendeiner Amateurfunke hat man die Gefahr verlorener Flanken vor gut 30 Jahren etwas anders gelöst. Da schiebt der Encoder seine Impulse in einen Zähler (4029 ?) und das viel zu behäbige Kleinhirn holt bei Gelegenheit die 4 Bits ab.

[Fritzler]

In irgendeiner Amateurfunke hat man die Gefahr verlorener Flanken vor gut 30 Jahren etwas anders gelöst. Da schiebt der Encoder seine Impulse in einen Zähler (4029 ?) und das viel zu behäbige Kleinhirn holt bei Gelegenheit die 4 Bits ab.

Ordentliche Controller haben inzwischen Hardwaretimer, die auch Encoderpulse zählen können.
Inkl Entprellfilter!

Der Softwerker muss nurnoch genug Ahnung haben das auch zu nutzen.
Aber genau da haperts dann leider meistens

PS:
Damit meine ich jetz nich irgendwelche Heimfrickler, sondern durchaus Leute, die fürs Coden bezahlt werden.

[Raja_Kentut]

Moin, könnte bitte mal die Gemeinde über meinen Codeschnipsel schauen und sagen "löppt woll" oder "geit nich, wägn...".
Compilieren tut er, auf Hardware testen geht grade nicht weil der Chinamann noch auf sich warten lässt.
Ich hab da erstmalig in meiner Programmierkarriere eine IF innerhalb einer ELSE, darf das überhaupt?
Funktion : Zwischen zwei Öffnungsvorgängen soll mindestens 10 minuten gewartet werden (schließen immer sofort).
Das Hauptprogramm springt "fenster_oeffnen_auto" an, wenn dafür die Voraussetzungen gegeben sind. Geht bisher, die Sache mit den millis() hab ich nachgestrickt.

Code: Alles auswählen

// ******* öffnen Automatikbetrieb *******
void fenster_oeffnen_auto ()                     // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
  if(gradC_Ai < gradC_Ii)                        // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
    {
     fenster_schliessen();                       // Routine fenster_schliessen anspringen
    }
      else                                       // sonst prüfen ob Zeit "VerzAuf" vergangen ist und dann fenster öffnen
         {
         neuMillis = millis();                   // beim allerersten Programmdurchlauf ist altMillis = 0 wegen Deklaration
          if (neuMillis - altMillis >= VerzAuf)  // vor öffnen prüfen ob Verzögrungszeit "VerzAuf" in ms vergangen ist
            {                                    // wenn das der Fall ist...
            fenster_oeffnen();                   // Routine fenster_oeffnen anspringen
            }                                    // sonst zurück zum Hauptprogramm springen aber vorher noch
         altMillis = neuMillis;                  // altMillis auf neuMillis hochsetzen
         }
}

[Anse]

Ist "altMillis" eine Globale Variable?

Ifs zu Schachteln ist kein Problem.
Aber hier muss eine Klammer rein:

Code: Alles auswählen

 if ((neuMillis - altMillis) >= VerzAuf)

[Raja_Kentut]

altMillis kommt von ganz oben : (ist das dann global?)

Code: Alles auswählen

//  ************* 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;  // Relative Luftfeuchtigkeit
  float tp;        // Taupunkt in Grad C

  unsigned long altMillis = 0;      // Speichert alten millis Wert
  unsigned long neuMillis = 0;      // Speichert aktuellen millis Wert
  const long VerzAuf = 600000;      // Verzögerungszeit für Fenster öffen in Automatikbetrieb im ms (600.000 = 10 minuten)

  int ZylAus_O = 5; // Output für Signal Zylinder ausfahren
  int ZylEin_O = 6; // Output für Signal Zylinder einfahren

..das mit der Klammer macht Sinn!

[IPv6]

Die Funktion zum Fenster öffnen wird dann regelmäßig alle "VerzAuf" aufgerufen, solange es draußen wärmer ist als innen.
Die Fenster schließen Funktion entsprechend bei jedem Durchgang wenn die Bedingung erfüllt ist.
Je nach dem was da hintendran steht könnte das ein Problem sein, muss aber nicht.
Man könnt ein einer Variablen den Zustand des Fensters speichern und nur dann öffnen bzw. schließen, wenn der gewünschte Zustand noch nicht gegeben ist.

Um Pins einen Klarnamen zu geben ist "#define outputpin 1" die schönere Variante als "int outputpin = 1", funktioniert aber auch.

[Anse]

altMillis kommt von ganz oben : (ist das dann global?)

Ja, das nennt man global. Für diesen Fall solltest Du dir mal das Schlüsselwort static ansehen. Damit kann man lokalen Variablen kennzeichnen, die ihren Wert zwischen den Funktionsaufrufen behalten sollen. Sie verhalten sich wie globale aber man behält bessere Übersicht. Das ist sinnvoll, wenn man eine unbeabsichtigte Veränderung ausschließen möchte.

Code: Alles auswählen

// ******* öffnen Automatikbetrieb *******
void fenster_oeffnen_auto ()                     // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
static int  altMillis=millis();
static int FensterStatus=0;
  if(gradC_Ai < gradC_Ii && FensterStatus==1)                        // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
    {
    FensterStatus=0;
     fenster_schliessen();                       // Routine fenster_schliessen anspringen
    }
      else                                       // sonst prüfen ob Zeit "VerzAuf" vergangen ist und dann fenster öffnen
         {
         neuMillis = millis();                   // beim allerersten Programmdurchlauf ist altMillis = 0 wegen Deklaration
          if (neuMillis - altMillis >= VerzAuf && FensterStatus==0)  // vor öffnen prüfen ob Verzögrungszeit "VerzAuf" in ms vergangen ist
            {             
            FensterStatus=1;                       // wenn das der Fall ist...
            fenster_oeffnen();                   // Routine fenster_oeffnen anspringen
            }                                    // sonst zurück zum Hauptprogramm springen aber vorher noch
         altMillis = neuMillis;                  // altMillis auf neuMillis hochsetzen
         }
}

Und denk daran, millis() läuft nach X Tagen über. Den Wert hab ich nicht mehr im Kopf.

[IPv6]

Und denk daran, millis() läuft nach X Tagen über. Den Wert hab ich nicht mehr im Kopf.

Das hatten wir etwas weiter oben im Thread schonmal, der Überlauf macht keine Probleme solange die Überprüfung "zeitNeu - zeitAlt > Intervall" lautet und solange die Variable "zeitAlt" von selben Typ ist wie das, was millis() zurückgibt (unsigned long).

Edit:
Das war in einem anderen Thread, nur wo genau nochmal...?

[Raja_Kentut]

vielen Dank erstmal!
Da lag ich ja bis auf die Klammern schonmal richtig - und hätte mich totgesucht wenn ich es auf der HW ausprobiert hätte und nix geht
Das "schon auf" oder "schon zu" nicht geprüft wird ist nicht schick, aber es läuft - und macht mir als Anfänger alles übersichtlicher.
Die Feinheiten kommen so nach und nach ins Hirn
Das mit dem Überlauf soll nach ca. 50 Tagen passieren. Dann stimmen halt worst case einmal die 10 Minuten nicht. Das steht tatsächlich ein paar Seiten im Thread weiter oben.

Das Gesamtprogramm falls es wer haben möchte :

// (c)Rolf Kowalsky 02.01.2021 / Kellerfenstersteuerung_V3
// Änderung zu Version Kellefenstersteuerung :
// 1)Einfügung einer Hysterese bei der Entscheidung Fenster öffnen oder Fenster schließen
// durch rechnen mit INTEGER. Dadurch werden sehr kleine Änderungen ignoriert. Das soll
// vermeiden das bei Wettersituationen im Grenzbereich das Fenster mehrmals kurz hintreinander
// auf- und zu fährt.
// 2)Berichtigung, so dass Fenster öffnen per Hand auch funktioniert,
// wenn Aussentemperatur kleiner Innentenperatur
// 3)Funktionsroutinen hinter Hauptprogramm geschoben
// Änderung zu Version Kellefenstersteuerung_V2 :
// 1)Verzögerung um "VerzAuf" ms beim automatischen öffen des Fensters.
// Dadurch soll das Fenster erst geöffnet werden nach Ablauf der Zeit "VerzAuf". Dadurch soll bei
// Wetteränderungen abgewartet werden bis sich Temperatur und Luftfeuchtigkeit stabilisiert haben.
// VerzAuf in Millisekunden.
// Verzögerung eingebaut in Funktion "fenster_oeffnen_auto ()"
//
//*************** 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; // Relative Luftfeuchtigkeit
float tp; // Taupunkt in Grad C

unsigned long altMillis = 0; // Speichert alten millis Wert
unsigned long neuMillis = 0; // Speichert aktuellen millis Wert
const long VerzAuf = 600000; // Verzögerungszeit für Fenster öffen in Automatikbetrieb im ms (600.000 = 10 minuten)

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
int gradC_Ii = 0; // Integerwert gradC_I
int gradC_Ai = 0; // Integerwert gradC_A
int tpi = 0; // Integerwert für Taupunkt in Grad C

// ************* 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);
}

// ************* Hauptprogramm ***********************
void loop()
{
werte_einlesen(); //Sensorwerte einlesen
taupunkt_berechnen(); //Routine taupunkt_berechnen anspringen

tpi = (int)tp; // Umwandeln von tp in Integerwert. Verhindert öffnen/schließen bei minimalen Änderungen
gradC_Ii = (int)gradC_I; // Umwandeln von gradC_I in Integerwert. Verhindert öffnen/schließen bei minimalen Änderungen
gradC_Ai = (int)gradC_A; // Umwandeln von gradC_A in Integerwert. Verhindert öffnen/schließen bei minimalen Änderungen

// --- Prüfung Hand- oder Automatikbetrieb ---
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(tpi > gradC_Ii) //Vergleich mit Integerwerten um öffnen/schließen bei kleinsten Aänderungen zu vermeiden
{ //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(tpi < gradC_Ii) //Vergleich mit Integerwerten um öffnen/schließen bei kleinsten Aänderungen zu vermeiden
{ //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_auto(); //Routine fenster_oeffnen anspringen
}
}

// ***************FUNKTIONSROUTINEN *****************
//void fenster_oeffnen() // Funktion Fenster öffnen
//void fenster_schliessen() // Funktion Fenster schliessen
//void fenster_oeffnen_auto() // Funktion Fenster öffnen mit vorheriger Prüfung ob Aussentemperatur über Innentemperatur
// und Verzögerung um "VerzAuf" ms
//float werte_einlesen() // Funktion Sensoren ausesen

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

// ******** öffnen Handbetrieb *******************
void fenster_oeffnen() // Starten der Funktion Fenster öffnen (Zylinder Eingefahren = fenster auf)
{
digitalWrite(ZylAus_O,LOW); // Sicherstellen, dass nie beide Zylindermotoren gleichzeitig laufen
digitalWrite(ZylEin_O, HIGH); // Zylinder ausfahren über Pin ZylEin_O (Pin6)

while(digitalRead(ZylEin_I) == HIGH) // Solange Endschalter nicht belegt, bleibt ZylEin_O = HIGH, sonst ZylEin_O zurücksetzen
{
digitalWrite(ZylEin_O, HIGH);
}
digitalWrite(ZylEin_O, LOW);
}
// ******* öffnen Automatikbetrieb *******
void fenster_oeffnen_auto () // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
if(gradC_Ai < gradC_Ii) // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
{
fenster_schliessen(); // Routine fenster_schliessen anspringen
}
else // sonst prüfen ob Zeit "VerzAuf" vergangen ist und dann fenster öffnen
{
neuMillis = millis(); // beim allerersten Programmdurchlauf ist altMillis = 0 wegen Deklaration
if ((neuMillis - altMillis) >= VerzAuf) // vor öffnen prüfen ob Verzögrungszeit "VerzAuf" in ms vergangen ist
{ // wenn das der Fall ist...
fenster_oeffnen(); // Routine fenster_oeffnen anspringen
} // sonst zurück zum Hauptprogramm springen aber vorher noch
altMillis = neuMillis; // altMillis auf neuMillis hochsetzen
}
}
// ******** schließen ***************
void fenster_schliessen()
{
digitalWrite(ZylEin_O,LOW);
digitalWrite(ZylAus_O, HIGH);

while(digitalRead(ZylAus_I) == HIGH)
{
digitalWrite(ZylAus_O, HIGH);
}
digitalWrite(ZylAus_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
gradC_I=gradC_I-3; // KORREKTURWERT minus 3 Grad Celsius für Innentemperatur,(Meßaufbau mißt zu hohe Innentemperatur weil nicht direkt am Boden gemessen wird)
//Ende Messung Innentemperatur vom Dallas Temperatursensor. Temperatur nun in der Variable gradC_I

// 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 Feuchtewert 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***********
}

[ch_ris]

Hat schon mal jemand den digispark usb tiny85 benutzt?
ich würde den gern am moped verwenden, jetzt gibt's da unterschiede:
bei reichelt max spannung 12v.
bei ebay clonen werden 16v oder 35v behauptet.
alles lüge?

[Finger]

Hier ist der Schaltplan dazu: https://s3.amazonaws.com/digispark/Digi ... cFinal.pdf
Kommt drauf an, welcher spannungsregler bestückt wurde. Zu dem hier gezeigten gibt es hier das Datenblatt: https://www.mouser.de/datasheet/2/308/M ... 773627.pdf
Da hast du 35V Maximum Rating

[unlock]

Ja, Problem ist Verlustleistung im Linearregler!
Am besten nochmal einen Regler vorschalten.

Achtung auch bei Signale, nicht über 5V!

[ch_ris]

danke.
also das gleiche gemache wie bei nano etc. um den halbwegs automotive zu bekommen.
das macht(e) halt den Formfaktor wieder zunichte
hier gehts mir jetzt konket um eine einzelne rgb led als Ladekontrolle.
wie er hier die anbietet:
https://gammatronixltd.com/epages/bae94 ... /Category1
(für das geld würde ich da jetzt nicht anfangen zu basteln, aber meine anfrage ob er das auch für life anbieten kann, verläuft anscheinend im sand.)

so, es geht ja um nix, daher würde ich hier kein gefatze machen, und mich mit mindestens dem 7805 zufrieden geben.
würde so eine "neopixel" LED sinn machen um den strom für die led nicht von den pwm Pins zu holen sondern direkt vom bordnetz?

edit, geht anscheinend nicht nur mir so:
https://sites.google.com/site/klaasdc/a ... ry-monitor

[unlock]

Grob geschätzt würde mit einer RGB Led schon funktionieren,
denn es herschen im Vehikel ja nie konstant 35V, schlimmer sind Spannungsspitzen.

Wenn z.B. 1W abgeführt werden, dann kann mann P/Ui-Uo = 1W/35V-5V = 33mA,
bei Ub 15V -> 100mA.

Wenn mann aber bei:
1. Layout-> viel Kühlfläche, Metalgehäuse usw.
2. Schaltungsentwurf-> Wärmeerzeuger verteilen, Widerstände vorschalten usw.
sich etwas gedanken macht, sollte es selbst im Kfz(hohe Ambienttemperatur) ohne kritischen Zustand wirken.

[ch_ris]

hab mal bestellt. und schon mal angefangen zu hacken.
ach herje, naiv wie ich bin dachte ich serielle Kommunikation geht wie beim nano.
ich will halt den eeprom zum konfigurieren benutzen. also die Spannungsgrenzen im eeprom ablegen und über die konsole ändern.
jetz ist das bisschen anders
hab ein usb terminal fürs android, das behauptet digispark zu können, ich bin gespannt.

[unlock]

Wenn der Tiny noch keinen Bootloader hat, dann mußt Du über ISP mit einem anderen Controller programmieren.

Bei den anderen Boards sind Anschlüsse für ISP vorhanden, mußt aber den Arduino entfernen,
oder ISP via Arduino.

[ch_ris]

sind heute gekommen. upload geht nicht, fuck, wasn das schon wieder...treiberterror?
verschiedene usb probiert...nix
wenn man ihn allerdings richtig rum reinsteckt, gehts auf einmal

[Finger]

Hat jemand von euch schonmal den Nano auf niedrigeren Takt umgefrickelt? Ich hab ne Anwendung, da muss ich Strom sparen, muss also mit dem Takt runter. Alles kein Thema, aber wie bringe ich da dem Compiler bei, damit meine Timings (millis (), I2C, Uart etc) wieder stimmen? Wo zum Henker muss ich ihm das mitgeben?

[Matt]

avr-gcc oder ähnlich -> makefile anpassen

Code: Alles auswählen

F_CPU = 16000000

= 16Mhz

[Finger]

Weißt du zufällig, wo die liegen?

[Matt]

Bei arduino bin ich einfach überfragt. Ich weiss gar nicht, wie du code complierst.

Bei C-code packe ich immer makefile ins Ordner zusammen mit C Code, da jeder Projekte nicht gleiche µC bzw. Takt nutzt.
Dann starte ich Complimieren per "make all", fertig. Ich nutze avr-gcc.

ich werfe mal makefile.txt rein, da sollst du dann .txt Endung entfernen.
Atmega328p, 16Mhz

[Finger]

Bisher nutze ich da immer die Arduino-IDE, dann muss ich da wohl drin wühlen....

[jodurino]

Hat schon mal jemand den digispark usb tiny85 benutzt?
ich würde den gern am moped verwenden, jetzt gibt's da unterschiede:
bei reichelt max spannung 12v.
bei ebay clonen werden 16v oder 35v behauptet.
alles lüge?

Ja habe den jetzt mehrfach in Autos verwendet,
aber immer mit 7812 1,5A TO220 Gehäuse vor dem VIN
ganz klassisch mit Elko und 2 100nF Kondensatoren
funktioniert tadellos als Türpiepser mit Melodiegenerve

cu
jodurino

[Finger]

Ich hab jetzt stumpf die Boards.txt durch ein eigenes ergänzt, dann rennt das!

[he25rb]

Arduino mini core

https://github.com/MCUdude/MiniCore

sind alle Möglichkeiten von Frequenz und Versorgung drinnen

mfg herb

[ch_ris]

Ja habe den jetzt mehrfach in Autos verwendet,
aber immer mit 7812 1,5A TO220 Gehäuse vor dem VIN
ganz klassisch mit Elko und 2 100nF Kondensatoren
funktioniert tadellos als Türpiepser mit Melodiegenerve

cu
jodurino

ok, danke.
wie ist das mit dem usb wenn vcc schon drauf ist?
der arduino bootet ja neu beim an und abstöpseln.
geht das hier auch oder besser Stromversorgung unterbrechen wenn ich neu booten will nach Änderung am eeprom?
hab da im netz nichts zu gefunden.

[IPv6]

@Finger:
Ich nehme dafür auch den Arduino MiniCore.
Kann man alle möglichen Taktfrequenzen nehmen und der Standardkrams funktioniert.

Zum Stromsparen mit einem Arduino Nano:
Spannungsregler weg und mit einer Brücke den mittleren Pin und das Kühlfahnenpad verbinden, da ist bei den chinesischen Nanos keine Leiterbahn dazwischen, der Strom muss einmal durch den Regler.
LEDs runtermachen und den USB-UART Wandler entfernen. Kann ja nach wie vor per ISP programmiert werden, serieller Monitor geht dann halt nicht mehr.

Problem war bei mir nur, dass bei internem 1 Mhz Oszillator die Arduino IDE, die ja avrdude aufruft, nicht die Programmiergeschwindigkeit runtersetzt, das war dann zu schnell für 1 Mhz. Also mit der Arduink IDE das hex file erzeugen und manuell per avrdude mit angepasstem Tempo hochschieben.

So ein umgebauter Nano liegt jetzt über ein halbes Jahr im Regel und wacht alle 8 Sekunden auf um eine Temperatur zu messen und diese zu verschicken. Das ganze läuft mit zwei AA Batterien aus meiner leere Batterien Kiste. Die Batterien haben immernoch unveränderte Spannung.

[ch_ris]

das mit dem V-USB von dem digispark (<DigiUSB.h>)ist ein bisschen frustrierend.
hab keine Möglichkeit gefunden per PC Terminal zu kommunizieren.
kann nur hoffen das es mit der Handy app klappt sobald ich ein otg adapter hab, meine kabel sind alle verschollen.
edit
treiberproblem mit win10 64
beim einstöpseln wird der digispark bootloader erkannt, wodurch der upload geht.
sobald der sich abmeldet nach 5sec hab ich ein unbekanntes gerät.
die weiteren nötigen treiber werden auch gar nicht im gerätemanager angezeigt.
wenns ein problem mit dem bootloader wäre, sollten doch trotzdem die installierten treiber im GM erscheinen denk ich.
edit2
tut

[sysconsol]

avr-gcc oder ähnlich -> makefile anpassen

Code: Alles auswählen

F_CPU = 16000000

= 16Mhz

Ich dachte, das kann man via Arduino-IDE im Code-Editor mitgeben?

[ferdimh]

Man kann das sogar am Anfang vom "Codefile" (das ja bei Arduino nicht auf .c endet, obwohl es das tun sollte) machen:
#undef F_CPU
#define F_CPU 1E6

und DANACH erst diversen Kram einbinden.

Das ist aber ultimativ hässlich, weil es dann verschiedenen konkurrierende Definitionen hat. Da hasst man sich in der Regel nachträglich dafür.

[Matt]

avr-gcc oder ähnlich -> makefile anpassen

Code: Alles auswählen

F_CPU = 16000000

= 16Mhz

Ich dachte, das kann man via Arduino-IDE im Code-Editor mitgeben?

Ich nutze avr-gcc und nicht diese Arduino-IDE (werde ich auch nie es nutzen)

[ch_ris]

hier mal der Anfang einer terminal eingabe verarbeitung.

Code: Alles auswählen

void comUsb() {

	unsigned char prefix = inputString[0];
	unsigned char kommand = inputString[1];
	unsigned char kommand2 = inputString[2];


	if (prefix == 'v') {

		DigiUSB.print("adc-");
		DigiUSB.println(avgVal, 10);

	} else if (prefix == 'm') {//1==2){       //
		DigiUSB.print("high ");
		DigiUSB.println(vmin_ee11, 10);
		DigiUSB.print("max ");
		DigiUSB.println(vmax_ee10, 10);

	}

Die Eingabe sei stets 'v'. zurückkommen soll also "adc- bla"
Das fliegt mir um die Ohren, bzw. ich erhalte keine Rückgabe.
wenn ich den Inhalt des zweiten else if blocks komplett auskommentiere, gehts.
wenn ich nur eine einzige zeile wieder einkommentiere knallts.
wenn ich die Bedingung austausche (1==2) gehts.

was ist hier los?

[Finger]

Wofür brauchst du an der Stelle das "else"? Was passiert ohne dieses?
Und lass doch mal den Compileroutput sehen (Flash/Ram-Nutzung), irgendwelche Warnings?