Arduino, programera fördröjning.

[bearing]

Blir lite nyfiken bara.

Är det tryckvakten som är signalen?
Vad är det som gör att signalen inte är helt stadig, d.v.s måste vara obruten 15 sekunder?

[mri]

SeniorLemuren: Absolut är det prestige!

[pinch]

Blir lite nyfiken bara.

Är det tryckvakten som är signalen?
Vad är det som gör att signalen inte är helt stadig, d.v.s måste vara obruten 15 sekunder?

Det är faktiskt till luftfjädringen på min bil, orginal styrenhet har en prislapp på ca: 4000kr och en förmåga att ge upp.
15 sekunder är för att slippa höjdjusteringar hela tiden när bilen fjädrar vid färd.

[bearing]

Ah, intressant, låter ju som ett kul projekt.

Ja du lär väl inte ha igång bilen mer än 49 dagar i sträck=)

[mri]

pinch: OK. Såhär skulle jag skriva det. Notera att jag bara har med styrning av kompressor eftersom den där andra paralella funktionen bara gjorde programmet grötigare att läsa. Principed torde framgå dock.
"up_enabled" gör att vi inte kollar den där delayen om och om igen efter att den löpt ut, och det var kanske den här detaljen som Herr Almqvist hakade upp sig på.

Med reservation för skrivfel:

Kod: Markera allt

unsigned long up_time;
const int upin = 7;     // height sensor low input
const int upout =  13;  // compressor     

bool up_enabled;   // remember if comressor has been started


void setup() 
{
  // initialize pin output:
  pinMode(upout, OUTPUT);
  // initialize pin input:
  pinMode(upin, INPUT);
  delay(10000); // startup delay
  digitalWrite(upout, HIGH);  // start compressor
  delay(5000);                // wait 5 sec
  digitalWrite(upout, LOW);   // stop compressor
  up_enabled = false;

  up_time = millis();         // initial value needed in case upin is initially high
}

void loop() 
{
  if (digitalRead(upin) == LOW) 
  {
    // ALWAYS stop compressor when upin is LOW
    digitalWrite(upout, LOW);  // stop compressor
    up_enabled = false;        // ...

    up_time = millis();        // push delay start forward
  }
  else
  {
    if (!up_enabled && ((millis() - up_time) >= 15000))
    {
      digitalWrite(upout, HIGH);  // start compressor
      up_enabled = true;         // remember that we have started
    }
  }

}

[Icecap]

Jag kan förstå att uppgiften måste lösas på det minst logiska sättet. Men OK, det går att göra utan glitches ändå.

Jag kan fint fatta att det kan bli problem vid overflow av räknaren med den nyss föreslagna metod och ja, det kanske är av minimal betydelse men samtidig får jag ont i hjärtat av att man kan rekommendera en icke-perfekt lösning och säga att "nåja, det är ju bara sällan att det blir fel...".

Då det inte verkar intressant med en "riktig" lösning kan man faktisk göra likadan fast på ett annat sätt. I Main-loop kan man göra som följer:

Kod: Markera allt

Time_Now = millis();
if(Time_Now != Time_Before)
  {
  if(Input == Active) 
    {
    if(Active_Counter < Activate_Level) Active_Counter++;
    else Output = true;
    }
  else
    {
    Active_Counter = 0;
    Output = false;
    }
  }
Time_Before = Time_Now;

I essens kolla det om tiden är "en annan" än förra gång, är det så kollar den om input är aktivt osv. Man kan såklart börja räkna på om det är en viss minimum tid mellan tiden nu och förra tiden men är main-loop "short & sharp" ska det inte behövs.

Men man kan såklart göra exakt samma sak med en timer-interrupt, skillnaden är att man kan veta timingen exakt medan man på detta vis bara har ett ungefär.

[mri]

Och den uppenbara bristen i Icecaps förslag ovan är ju (som han själv nämner om) att om man sätter in annan kod i main-loopen (eller sätter in interrupt handlers) som gör att main-loopen updateras mer sällan än varje ms, kommer delayen att bli annan längd än den tänkta.

Det samma händer också fast systemet flyttas in i en timer interrupt. Om någon annan, måhända dåligt programmerad, interrupt handler med högre prioritet blockerar för timer interrupten för länge, kommer delayen också att påverkas.

Kan hända att lösningen är helt ok i det tänkta fallet; ett tidsfördröjt relä som troligen endast kommer att vara just det.

Generellt; om man försöker mäta tid själv genom att inkrementera en variabel bygger man in begränsningar på ett eller annat sätt. Det är bättre att använda en hårdvarutimer, och i Arduino finns millis().


Hursomhelst (och nu riktar jag mig inte specifikt till dig Icecap), är jag förvånad över att jag behöver argumentera för metoden jag föreslår, dvs att "mäta tiden" direkt med millis(). Det här är ju fundamentalt hur 2-komplement och modulo matte fungerar. Att det blir overflow i millis() är inget problem. Det här liknar mycket hur man hanterar en ringbuffer med endast head och tail pekare (ingen separat "count" variabel). millis() motsvarar "head" och starttiden för delayen motsvaras av "tail". Ringbufferns storlek är 2^32....

[pinch]

Jag har nu monterat och kopplat allt i bilen, provkört både långa och korta sträckor.
Allt fungerar som det är tänkt och jag är jätte nöjd.

Vill tacka alla som har varit med och skrivit i tråden, då detta var mitt första Arduino äventyr så har jag lärt mig massor

[sodjan]

Det är ju jättekul att det fungerar och att du är nöjd, men jag
skulle gissa att många är intresserade av hur det löstes till slut.