Pret met Arduino

[RudyB]

In de zesde video gaan we een automatische dag-nacht sequencer maken, met een aan/uit schakelaar en een indicator LED op ons schakelpaneel. De dag en nacht tijden willen we kunnen instellen in seconden.

Link naar Fun with Arduino 06 Automatic Day & Night Cycle with on/off Switch

[RudyB]

Onze dag / nacht module van de vorige video werkt perfect, maar hij schakelt maar 1 lichtgroep. Op onze layout hebben we waarschijnlijk meerdere lichtgroepen ... huisjes, straatverlichting, een station of industrie. In deze video kijken we hoe we deze kunnen schakelen in een dag / nacht cyclus, maar natuurlijk niet allemaal tegelijk en ook zonder dat het eentonig wordt.

Link naar Pret met Arduino 07 Dag / Nacht Cyclus met Meerdere Lichtgroepen, met Variatie

[tuurtje]

Hallo Rudy,

Kom dit nu pas tegen, echt real fun en goed uitgelegd voor de ouderen zoals ik 


Groetjes


Arthur

[RudyB]

Dank voor je feedback Arthur, dat is fijn om te horen.

[Haas67]

Leuke serie Rudy!
Hopelijk gaat de serie nog verder de DCC richting op. Ben benieuwd!

[RudyB]

Bedankt voor de feedback 'haas67’. Waarschijnljk gaat in deze serie DCC niet aan bod komen, dat is qua code toch meer 'advanced'. Arduino software voor een DCC decoder (servo en/of accessory), voor een 'DCC sniffer' en voor een S88 bus is te downloaden op de software pagina van mijn blog (rudysmodelrailway). En natuurlijk bij Nico's arcomora.

[bask185]

Rudy,

Ik zit zo ff te lezen en te kijken. Het ziet er wel leuk uit voor d'n beginner.

Het was ook al opgemerkt, maar ik zie nogal veel delay() voorkomen. Ik snap dat het voor dummies wel handig is voor een simpel dingetje maar ik vroeg me af. Ga je ook een aflevering maken waar je iets gaat multitasken? 3 functies ofzo parallel laten lopen, elk met een eigen interval zonder delay maar met millis()? En een simpel state machine'tje met een switch case ofzo?

Wat misschien voor jou ook welk leuk is, om voor deze doeleinden je eigen timer library te maken. De code in de lirary laat je dan weg voor de lezers. Maar het gebruik er van is misschien wel grappig. Ik programmeer voor m'n werk complexe machines in C en daarvoor had ik een simpele library gemaakt. Ik gebruik alleen maar een struct en een array en ik kan zo x aantal functies laten uitvoeren met een willekeurige interval.

Ik roep dan bijvoorbeeld aan:

start(TIMER_1,foo,500);

En functie foo() wordt elke 500ms uitgevoerd.

Aanvullend kon ik dan de interval veranderen en natuurlijk de timer stoppen. Het kan allemaal heel simpel gehouden worden zodat de dummies (no offense) onder ons ook makkelijk kunnen multi tasken en dingen automatiseren.

Met 13 + 6 I/O pinnen en een modeltreinbaan, is het denk ik goed mogelijk dat iemand misschien wel 3 afzonderlijke lichtcircuits wilt bedienen met verschillende tijden en dan nog bedenkt, goh een spoorweg overgang kan er ook nog wel bij.

Bas.

[RudyB]

Ja, natuurlijk gaan we binnenkort van de delay() afstappen. Voor de huidige sequencer was het gewoon lekker gemakkkelijk, maar zodra we een spoorwegovergang gaan maken, met knipperende LED's, een servo en sensors om de trein te detecteren, dan kan het knipperen van de LEDs niet meer met een delay(), omdat we dan meer te doen hebben.

[RudyB]

Onze manier van de dag/nacht tijd veranderen leek wel handig, met de #define helemaal bovenaan de code, maar je moet wel elke keer als je een andere cycle time wilt de code aanpassen en opnieuw uploaden. Kan dat misschien gemakkelijker?

Ja ... dat kan. We gaan een User Interface maken waarmee de cycle time 'on the fly' aangepast kan worden. Dat kan via hardware of via software. We gaan ze alletwee proberen. In deze video de eerste werkzaamheden ... text en variabelen naar het beeldscherm schrijven via Serial.print().

Link naar Fun with Arduino 08 User Interface met Serial.print()

[Timo]

Hoi RudyB,

Je hebt er nogal een dikke vette bug in geschreven Preistertjes moeten nu 49,7 dagen wachten voor het weer licht is Rekenen met literals kan een beetje tricky zijn.

Twee andere dingen,

- als je toch variabelen introduceert kunnen de macros ook weg. Krijg je eindelijk minder cryptische errors.
- je breekt nogal met de normale "Arduino stijl" door niet gebruik te maken van camelCaseVariabelen


Timo

[bask185]

@Timo
Die bug? Ik zie hem niet.

Als DAY_NIGHT_CYCLE_ON_OFF_PIN is ingedrukt (en dus LOW is) dan wordt  LIGHTS_PIN elke 180 seconde van state getoggled en LED_PIN gaat uit nadat je die knop uitzet en die delays zijn verlopen.

En er wordt niet gerekend met de literals. Die #defines geven alleen I/O namen aan en die int 'cycle_time is desondanks hij niet gewijzigd wordt, technisch gezien geen literal omdat het noch een const noch een #define is. Hij is veranderlijk.

En het is heel gebruikelijk om #defines te gebruiken om I/O pinnen aan te duiden. Dit vreet namelijk geen extra geheugen. En er kan niks mee gebeuren. De pre compiler vervangt al die #define namen door de constantes. Als je variabelen gaat toewijzen aan I/O dan gebruik je minimaal 1 byte per I/O pin.

@RubyB
Ik vind het opvallend dat je eigenlijk nu pas met variabelen komt. Ik zou dit zelf in les #1 behandelen en misschien ook alle logic operators en anders zou ik die in les #2 behandelen.

En waarom? Nu heb je net Serial.print() uitgelegd en delay() is ook al aan bod gekomen. Deze functies kunnen allemaal variabelen meenemen als argumenten. Vooral voor de print() die verscheidene soorten aan variabelen kan hebben, zou het handig te zijn om een string of een integer te kunnen manipuleren. En dan kan je ook andere dingen gaan doen zoals een potmeter uitlezen en diens waarde in een delay of print gooien.

Een goede arduino/C oefening zou zijn om met je arduino te rekenen en waardes op het scherm te dumpen zodat je ziet wat de arduino uitspuugt, zo kan je ook heel goed overflows en unsigned/signed waardes demonstreren.

Vooral als je straks Serial.Read() gaat behandelen, is het noodzakelijk dat je goed kan rekenen, want stel nou dat je cycle_time nu wilt instellen met de terminal? Dan moet je '1', '8' en '0' apart inlezen, er 48 of '0' van aftrekken, vermenigvuldigen met 100 of 10 en dan de boel bij elkaar optellen.

En dan zou ik voor les #3 dus functies in het algemeen behandelen zodat je ook meteen snapt wat print, read en delay zijn en wat ze doen en waar die () voor zijn en wat ze kunnen returnen.

[Cees Baarda]

En er wordt niet gerekend met de literals. Die #defines geven alleen I/O namen aan en die int 'cycle_time is desondanks hij niet gewijzigd wordt, technisch gezien geen literal omdat het noch een const noch een #define is. Hij is veranderlijk.

En het is heel gebruikelijk om #defines te gebruiken om I/O pinnen aan te duiden. Dit vreet namelijk geen extra geheugen. En er kan niks mee gebeuren. De pre compiler vervangt al die #define namen door de constantes. Als je variabelen gaat toewijzen aan I/O dan gebruik je minimaal 1 byte per I/O pin.

Een stukje code:

Code: [Selecteer]

#define ledPin 4
.
// allerlei andere statements
.
#define ledPin 13
Is volledig legale code. Echter na de laatste regel  wordt LedPin voortaan vertaald door 13.
Het gevolg kan dan zijn dat je programma totaal niet doet wat je verwacht. Het zoeken naar zo'n "fout" is beslist niet gemakkelijk.

Nog een stukje code:

Code: [Selecteer]

const int ledPin = 4;
.
// allerlei andere statements
.
const int ledPin = 13;
Levert een foutmelding op van de compiler, omdat je een const niet mag veranderen. Je bent daarmee gewaarschuwd, dat je iets doet wat mogelijk niet wenselijk is.
Als je beide stukjes compileert, levert dat dezelfde hoeveelheid bytes in programmageheugen en geen ruimtegebruik bij de variabelen op in je microcontroller.
Daarom wordt er al geruime tijd in de Arduino-wereld aangeraden bij dit soort toekenningen const te gebruiken i.p.v. #define.

groet Cees

[RudyB]

@Timo @Bas

Het plan is om in de volgende video iets te vertellen over (unsigned) int en long variabelen en hoe we de delay(cycle_time * 1000) , die nu niet doet wat je zou verwachten, aan de praat krijgen.

[bask185]

Als je beide stukjes compileert, levert dat dezelfde hoeveelheid bytes in programmageheugen en geen ruimtegebruik bij de variabelen op in je microcontroller.

Oe dat wist ik niet, excuus.

Ik heb ff gecheckt met arduino, maar je kan een defined waarde ook geen waarde toewijzen. Als je doet #define x 5  en later x = 7; dan krijg je ook een compiler fout. Dus daarvoor maakt het niet uit wat je kiest.

Maar dan alsnog. Als je gewoon de syntax aanhoudt en hoofdletters gebruikt voor constantes dan zou je zeggen dat het bijna niet mis kan gaan. Als ik een regel code tik, heeft die regel een rede, een doel. Ik kan me nooit geen rede bedenken om ooit te tikken

#define LED_PIN 13
LED_PIN = 12; // wat moet dit nu doen?
Je ziet aan de syntax alleen al dat je een waarde in een constante probeert te proppen. Als je je bedenkt: "wat doet deze regel", dan moet je tot de conclusie komen dat je iets nutteloos doet. Maar goed, het maakt in dit voorbeeld niet uit of je een #define of een const int gebruikt, je krijgt in beide gevallen een compiler fout.

dit:

Code: [Selecteer]

const int ledPin = 4;
.
// allerlei andere statements
.
const int ledPin = 13;
is trouwens een slecht voorbeeld omdat de compiler eerst al struikelt over het feit dat je 2x een variabele declareert met dezelfde naam dan dat je een const probeert te wijzigen. Als je hier geen const tikt, wordt de compiler ook al boos

Code: [Selecteer]

const int ledPin = 4;
.
// allerlei andere statements
.
ledPin = 13;
illustreert het probleem beter. Maar er is een maar....

Ik had nog iets geprobeerd en daarmee een argument gevonden om geen const te gebruiken.
Wat zonder fouten compileert is de volgende code. Een lokale variabele, const of geen const, kan dezelfde naam hebben als een globale variabele.

Code: [Selecteer]

const int x = 5;

void setup()
{
  const int x = 6; // compileert prima
}

void loop()
{

}

zodoende

Code: [Selecteer]

const int x = 5;

void setup()
{
  int x = 6;

  x = 10; // kan gewoon
}

void loop()
{

}
compileert dit ook prima.

Ik heb nog een 2e argument om geen const te gebruiken.
In C++ weet ik het niet, maar bij ansi C heeft const bij lokaal gebruik in een functie body een compleet andere functie dan als een globale variabele. In Keil's C compiler kan je const in een functie gebruiken. Dit is dan een variabele die bij het 1e keer aanroepen van de functie een waarde krijgt, die je kan wijzigen en die zijn waarde niet verliest als de functie opnieuw wordt uitgevoerd.

voorbeeld:

Code: [Selecteer]

void foobar()
{
  const int x = 5;

  x++;
  Serial.println(x); // 6,7,....16
}
Als je deze functie in je programma 10x aanroept, dan heeft x een waarde van 16. De eerste keer krijgt x 5 aangewezen en wordt opgehoogd met 1 en alle andere keren wordt hij alleen opgehoogd.

Dus daarom zie ik geen voordelen in het gebruik van const tov #define en wel nadelen.[/code]

[Timo]

Even korte reactie want zit in België alleen op een mobiel

@Timo
En er wordt niet gerekend met de literals. Die #defines geven alleen I/O namen aan en die int 'cycle_time is desondanks hij niet gewijzigd wordt, technisch gezien geen literal omdat het noch een const noch een #define is. Hij is veranderlijk.

De macro en de int's inderdaad niet, maar 1000 is wel een literal. En aangezien het in een int past is het een signed int literal. De compiler pakt voor het rekenwerk altijd het grootste gebruikte type, niet groter! Voor int maal int literal een signed int dus. Maar de vermenigvuldiging past niet in een signed int! Overflow is het gevolg. En pas daarna vind de impliciete cast naar unsigned long plaats voor delay(). Waarna je dus een delay hebt van 47 dag....


Timo