Arduino quizsysteem stuurt leds niet goed aan, data mist?

[MistW]

Mijn jongere broer en ik zijn bezig met een quizsysteem in C# in combinatie met Arduino Uno.
Dit werkte aldoor prima.
-Knop werd ingedrukt
-Arduino stuurt data naar pc
-Pc verstuurd data Arduino

Daar we één poort te kort kwamen hebben we een shifter gebruikt, deze stuurt nu alle "status leds" aan, de leds waaraan je kan zien wie op een knop heeft gedrukt.
Ook zit er aan de Arduino een rgb ledstrip.

Zoals ik al zei, dit werkte aldoor prima, totdat de shifter er bij kwam. Het lijkt er nu sterk op dat Arduino soms de data niet kan verwerken. I.p.v. I/O/I/O/I/O bij de leds, doet deze ineens I/O/I/I/I/O/I en dat soort fratsen.

Hieronder de data die de pc naar Arduino stuurt:

code:

@0+ 
#240000000
@0- 
#000000000
@0+ 
#240000000
@0- 
#000000000
@0+ 
#240000000
@0- 
#000000000
@0+ 
#240000000
@0- 
#000000000
@0+ 
#240000000
@0- 
#000000000

En hieronder de Arduino code:

C:

const int amountButtons = 8;

// set the first pin of the row of buttons
const int PinButton[] = {A0, A1, A2, A3, A4, A5, 12, 13};    // *

// what are the pins the leds are in, has to be the size of the buttons *
const int PinLed[] = {0, 1, 2, 3, 4, 5, 6, 7};
// what character corresponds with what led (led 0 -> 0, led 1 -> 1 etc) *
const char LedByte[] = {'0', '1', '2', '3', '4', '5', '6', '7'};
// the pins that the rgp strip is connected to (Red = 1st, Green = 2nd, Blue = 3rd)
const int PinRGBStrip[] = {10, 9, 11};



//Pin connected to latch pin (ST_CP) of 74HC595
const int latchPin = 2;
////Pin connected to Data in (DS) of 74HC595
const int dataPin = 3;
//Pin connected to clock pin (SH_CP) of 74HC595
const int clockPin = 4;

// set the standalone mode, whether it needs a computer to operate
const int PinStandalone = 8;

// after how many miliseconds can someone press the button again
const int buttonPressDelay = 2000;

const int ledBlinkDelay = 500;
const int ledBlinkTimes = 5;

// this is the first symbol that is defining the message is a color
const char colorSign = '#';
// this is the character that determines that the next bytes are for leds
const char ledSign = '@';

// dont fiddle with these
boolean appendreceive = false;
String receiveMessage;
boolean buttonPressed[] = {false, false, false, false};    // *
long previousMillisButton[] = {0,0,0,0,0,0,0,0};       // *
long previousMillisLed[] = {0,0,0,0,0,0,0,0};          // *
boolean nextIsLed = false;
int ledNum = -1;
boolean nextIsLedState = false;
boolean standalone = true;

////////////////////////////////////////////////////////////////////
// * = array has to be the same length as amount of buttons
////////////////////////////////////////////////////////////////////


// the setup routine runs once when you press reset:
void setup() 
{
  // loop #buttonAmount times to set some stuff
  for(int i=0; i<amountButtons; i++)
  {
    // set all the leds as output
    //pinMode(PinLed[i], OUTPUT);    // removed since we use a shifter now
    // set all the buttons as input
    pinMode(PinButton[i], INPUT);
    // set all the button state's to high
    digitalWrite(PinButton[i], HIGH);
  }
  
  pinMode(latchPin, OUTPUT);
  pinMode(dataPin, OUTPUT);  
  pinMode(clockPin, OUTPUT);
  
  if(false)    // just so we are able so skipy the startup test sequence
  {
    // turn all the lights on at the start, this way we can check if all the lights are connected properly
    for(int n=0; n<amountButtons; n++)
    {
      SetLedState(PinLed[n], true);
      delay(1000);
      SetLedState(PinLed[n], false);
      delay(100);
    }
    
    for(int m=0; m<5; m++)
    {
      switch (m)
      {
        case 0:
          SetLedStripColor(255, 255, 255);
          break;
        case 1:
          SetLedStripColor(255, 0, 0);
          break;
        case 2:
          SetLedStripColor(0, 255, 0);
          break;
        case 3:
          SetLedStripColor(0, 0, 255);
          break;
        case 4:
          SetLedStripColor(0, 0, 0);
          break;
      }
      
      delay(1000);
    }
  }
}

// the loop routine runs over and over again forever:
void loop() 
{
  // Loop through buttons to get if they are pressed
  for(int i=0; i<amountButtons; i++)
  {
    // if button pressed
    if(digitalRead(PinButton[i]) == LOW && buttonPressed[i] == false)
    {
      // send the button number over serial
      if(!standalone)
        Serial.println(i);
      else
        FlashLights(PinLed[i], 500, 500, 5);
        
      buttonPressed[i] = true;
      
      // set the time for the button press delay
      previousMillisButton[i] = millis();
    }
  }
  
  if(!standalone)
  {
    // check if there is a message to receive
    if (Serial.available() > 0) 
    {
      char incomingByte = (char)Serial.read();
      
      // check if the character is the colorSign OR if we want to collect the characters
      if(incomingByte == colorSign || appendreceive)
      {
        if(incomingByte == colorSign)
          appendreceive = true;
        else
        {
          if(receiveMessage.length() < 9)
            receiveMessage += incomingByte;
            
          if(receiveMessage.length() >= 9)
          {
            SetLedStripColor(receiveMessage.substring(0, 3).toInt(), receiveMessage.substring(3, 6).toInt(), receiveMessage.substring(6, 9).toInt());
            receiveMessage = "";
            appendreceive = false;
          }
        } 
      }
      
      if(incomingByte == ledSign || nextIsLed || nextIsLedState)
      {
        if(incomingByte == ledSign)
        {
          nextIsLed = true;
        }
          
        if(nextIsLed)
        {
          if(nextIsLedState)
          {
            SetLedState(ledNum, (incomingByte == '+' ? true : false));
            nextIsLed = false;
            nextIsLedState = false;
          }
          
          if(!nextIsLedState)
          {
            // loop # amount of times to check if there is a led linked to the received byte
            for(int n=0; n<amountButtons; n++)
            {
              // check the byte to the current led
              if(incomingByte == LedByte[n])
              {
                ledNum = n;
                nextIsLedState = true;
              }
            }
          }
        }
      }
    }
  }
  // BUTTONS STATE SET
  for(int a=0; a<amountButtons; a++)
  {
    // check if the current button is pressed
    if(buttonPressed[a] == true)
    {
      unsigned long currentMillis = millis();
      
      // check if enough time has passed to set the buttonpressed to false
      if(currentMillis - previousMillisButton[a] > buttonPressDelay)
      {
        buttonPressed[a] = false;
        previousMillisButton[a] = 0;
      }
    }
  }
  
  if(digitalRead(PinStandalone) == HIGH)
  {
    if(standalone)
    {
      Serial.begin(57600);
      standalone = false;
    }
  }
  else if(digitalRead(PinStandalone) == LOW)
  {
    if(!standalone)
    {
      Serial.end();
      standalone = true;
    }
  }
}

void FlashLights(int led, int onTime, int offTime, int amount)
{
  for(int i=0; i<amount; i++)
  {
    SetLedState(led, true);
    SetLedStripColor(255, 255, 255);
    delay(onTime);
    SetLedState(led, false);
    SetLedStripColor(0, 0, 0);
    delay(offTime);
  }
}

void SetLedState(int led, boolean on)
{
  if(on)
  {
    //digitalWrite(PinLed[led], HIGH);    // Removed since we use a shifter now
    registerWrite(PinLed[led], HIGH);
  }
  else
  {
    //digitalWrite(PinLed[led], LOW);    // Removed since we use a shifter now
    registerWrite(PinLed[led], LOW);
  }
}

void SetLedStripColor(int red, int green, int blue)
{
  analogWrite(PinRGBStrip[0], red);
  analogWrite(PinRGBStrip[1], green);
  analogWrite(PinRGBStrip[2], blue);
}



// This method sends bits to the shift register:     (Origional arduino code)

void registerWrite(int whichPin, int whichState) {
// the bits you want to send
  byte bitsToSend = 0;

  // turn off the output so the pins don't light up
  // while you're shifting bits:
  digitalWrite(latchPin, LOW);

  // turn on the next highest bit in bitsToSend:
  bitWrite(bitsToSend, whichPin, whichState);

  // shift the bits out:
  shiftOut(dataPin, clockPin, MSBFIRST, bitsToSend);

    // turn on the output so the LEDs can light up:
  digitalWrite(latchPin, HIGH);
}

Kunnen jullie vinden waar het hem in zit? Eventueel kan ik ook wel een filmpje laten zien van het probleem, mocht het niet duidelijk zijn.

Alvast bedankt.

[kitao]

Ik heb geen idee eigenlijk waar het aan ligt maar ik wou zelf ook eens een shift (die in bestelling is) aan een uno haken dus ik lees met je mee. Programma's schrijven en lezen heb ik nog niet veel verstand van.
Wel valt dit me op :

C++:

// what are the pins the leds are in, has to be the size of the buttons * 
const int PinLed[] = {0, 1, 2, 3, 4, 5, 6, 7}; 
// what character corresponds with what led (led 0 -> 0, led 1 -> 1 etc) * 
const char LedByte[] = {'0', '1', '2', '3', '4', '5', '6', '7'}; 
// the pins that the rgp strip is connected to (Red = 1st, Green = 2nd, Blue = 3rd) 
const int PinRGBStrip[] = {10, 9, 11}; 


//Pin connected to latch pin (ST_CP) of 74HC595 
const int latchPin = 2; 
////Pin connected to Data in (DS) of 74HC595 
const int dataPin = 3; 
//Pin connected to clock pin (SH_CP) of 74HC595 
const int clockPin = 4; 

Hier begrijp ik het al niet goed meer. Voor PinLed gebruik je dezelfde uitgangen als latch-, data- en clockPin ?
En als je een shiftregister gebruikt dan hoef je via de arduino toch geen aparte led-pinnen meer te definiëren ?

edit:
Misschien kun je het ook eens met een port expander proberen ?
http://tronixstuff.com/20...g-your-arduinos-io-ports/

[ Voor 6% gewijzigd door kitao op 21-12-2013 01:39 . Reden: toevoeging ]

[mad_max234]

Als ik je goed berijp gaat het fout met data wat verstuurd word via usart(serial poort)?

Denk dat usart soms wat bits verliest, niet ongebruikelijk. Check inbouwen kan dit oplossen en helpen debuggen. iets van crc sum of xor sum meesturen zodat je data kan controleren. Door even simpele check in te bouwen sluit je in slechtste geval hoogstens uit dat usart niet het probleem is, in beste geval los je het probleem op. We moeten ergens beginnen met debuggen.

Edit/
@kitao
Die PinLed array is voor shift register functie iets verder op in de code, heeft dus niks met pinnen van arduino te maken.

[ Voor 38% gewijzigd door mad_max234 op 21-12-2013 10:30 ]

[Verwijderd]

en als je Serial.begin(57600); is iets lager zet..

[mad_max234]

Ben ik nu nog niet wakker of zie ik helemaal geen Serial.begin() in setup staan?

Edit/
Gevonden, staat verder op in de code.

[ Voor 24% gewijzigd door mad_max234 op 21-12-2013 10:41 ]

[kitao]

Naar zoiets was ik gisterenook aan het kijken. Of er een library nodig was of iets dergelijks.
Maar ja, nogmaals, ik weet er zelf te weinig vanaf. Wel zag ik dat in onderstaand voorbeeld er verder niks extra's wordt gebruikt maar dat is slechts een klein onderdeel van het programma :
http://arduino.cc/en/Tutorial/ShftOut11

Daarnaast kwam nog even de mogelijkheid van contactdender bij me op of is dit softwarematig opgevangen met een delay ?

[MistW]

Misschien handig om even te vermelden, er zit ook een standalone knop op. Dan werkt Arduino gewoon in z'n eentje, zonder de pc. Dan werkt alles prima.
Zo ver ik weet zit er een delay wel in, hebben we ook al wel mee geschoven zeg maar.
Ik kan niet echt alles beantwoorden, want het codebrein ligt nog te slapen helaas.

[alexandersamson]

Hoe lang zijn je kabels? Lijkt wel of de data niet lekker overkomt. Is de Ground ook goed doorverbonden met alles?

Dat leds random aan/uit gaan en niet volgens patroon lijkt op zwevende ingangen, te lange kabels of slechte verbindingen.

[kitao]

Er was ook sprake van een filmpje, hoe meer info hoe beter lijkt me.
En is dit eigen ontwerp of heb je iets van een voorbeeld gebruikt met een schema erbij ?

[MistW]

alexandersamson schreef op zaterdag 21 december 2013 @ 11:08:
Hoe lang zijn je kabels? Lijkt wel of de data niet lekker overkomt. Is de Ground ook goed doorverbonden met alles?

Dat leds random aan/uit gaan en niet volgens patroon lijkt op zwevende ingangen, te lange kabels of slechte verbindingen.

Kijk hier kan ik dus makkelijk antwoord op geven
De USB kabel die we gebruiken is nu de standaard usbkabel voor de Arduino. Echt geen lange. Deze gaat dan in de behuizing, waarachter er dan weer een usbkabel loopt, dit keer naar de Arduino zelf.
In eerste instantie dachten wij ook dat het aan de kabels lag. Maar zelfs met 1 kabel doet het probleem zich voor. PC-----Behuizing-----Arduino PC----Arduino maakt dus geen verschil.

Ground moet eigenlijk wel goed doorverbonden zijn, anders zou de boel niet eens werken toch?

[alexandersamson]

Ik had het eigenlijk over de verbinding tussen de arduino en de shifters, niet de pc, of begrijp ik nu iets niet?


Zet die Serial.begin(57600); eens in de void Setup() bovenaan ergens, en niet in je loop via die standalone functie.
Serial moet je inprincipe maar 1 keer aanroepen in het begin.

Heb je anders een foto van het geheel (liefst met open behuizing als het in een kastje zit)

[ Voor 24% gewijzigd door alexandersamson op 21-12-2013 11:21 ]

[MistW]

alexandersamson schreef op zaterdag 21 december 2013 @ 11:18:
Ik had het eigenlijk over de verbinding tussen de arduino en de shifters, niet de pc, of begrijp ik nu iets niet?


Zet die Serial.begin(57600); eens in de void Setup() bovenaan ergens, en niet in je loop via die standalone functie.

Heb je anders een foto van het geheel (liefst met open behuizing als het in een kastje zit)

Ah zo, sorry.

Tussen de Arduino en de shifter zitten kabeltjes van 10 cm ongeveer. Dat zou het echt niet mogen zijn lijkt mij. Wat betreft de code, moet ik dus even wachten op het codebrein.....

http://i.imgur.com/ti6RZQ7.jpg

Misschien dat dit wat helpt? Het is niet af, maar geeft wel een idee.

[ Voor 8% gewijzigd door MistW op 21-12-2013 11:25 ]

[alexandersamson]

Is een kleine test, Je knipt 'Serial.begin(57600);' weg en je plakt het direct onder void setup(){

(even opslaan onder andere bestandsnaam, omdat de slaper de coder is blijkbaar).

Die functie is dan even leeg, maar maakt niets uit.
Als dit niet werkt, kan je slaper er altijd nog naar kijken

[ Voor 6% gewijzigd door alexandersamson op 21-12-2013 11:24 ]

[MistW]

Het brein is wakker, moment alstublieft.

[kitao]

Bedankt voor het schema.
Netjes gedaan en ik wist niet dat je ook geblokte lijnen kon maken op Fritz, ook eens proberen.

[mad_max234]

alexandersamson schreef op zaterdag 21 december 2013 @ 11:18:
Ik had het eigenlijk over de verbinding tussen de arduino en de shifters, niet de pc, of begrijp ik nu iets niet?


Zet die Serial.begin(57600); eens in de void Setup() bovenaan ergens, en niet in je loop via die standalone functie.
Serial moet je inprincipe maar 1 keer aanroepen in het begin.

Heb je anders een foto van het geheel (liefst met open behuizing als het in een kastje zit)

Nee hoor, mag je overal aanroepen, mag ook in je code stoppen en weer opnieuw beginnen, etc.
En meerder keren aanroepen zal geen probleem moeten geven, je mag usart gewoon zovaak instellen als je wilt ook veranderen naar andere instellingen, etc

[MistW]

alexandersamson schreef op zaterdag 21 december 2013 @ 11:24:
Is een kleine test, Je knipt 'Serial.begin(57600);' weg en je plakt het direct onder void setup(){

(even opslaan onder andere bestandsnaam, omdat de slaper de coder is blijkbaar).

Die functie is dan even leeg, maar maakt niets uit.
Als dit niet werkt, kan je slaper er altijd nog naar kijken

Het lijkt tot nu toe te werken eigenlijk, nu even de delaytime korter zetten en stresstesten.

kitao schreef op zaterdag 21 december 2013 @ 11:39:
Bedankt voor het schema.
Netjes gedaan en ik wist niet dat je ook geblokte lijnen kon maken op Fritz, ook eens proberen.

Als je een draad selecteert kun je bij de Inspector naast de kleur kiezen voor Banded. Vink je die aan dan heb je mooi gestreepte draden. Maakt het soms wel zo overzichtelijk.

[ Voor 28% gewijzigd door MistW op 21-12-2013 11:55 ]

[Ploink]

Vroeger zag een quizmaster circuitje er gewoon zo uit.....

[alexandersamson]

mad_max234 schreef op zaterdag 21 december 2013 @ 11:43:
[...]


Nee hoor, mag je overal aanroepen, mag ook in je code stoppen en weer opnieuw beginnen, etc.
En meerder keren aanroepen zal geen probleem moeten geven, je mag usart gewoon zovaak instellen als je wilt ook veranderen naar andere instellingen, etc

Toch is het good practice om -als je toch al serial gaat gebruiken- deze bij je setup al te laten starten. Zo vang je veel problemen af als je per ongeluk dingen wil lezen of sturen naar/van serial, zonder deze te hebben gestart, omdat deze in een of andere functie staat die nog niet is gestart.

[ Voor 5% gewijzigd door alexandersamson op 21-12-2013 11:54 ]

[MistW]

Hierbij een filmpje van de proefopstelling, toen alles nog prima werktte.
http://youtu.be/-7XDDu2CJ8k

Alexandersamson, bedankt voor je oplossing, tot nu toe werkt het nog steeds.
Wel raar, maar een oplossing is een oplossing haha.

Ik zal t.z.t. wel even een filmpje posten denk ik van het resultaat.

[mad_max234]

alexandersamson schreef op zaterdag 21 december 2013 @ 11:53:
[...]


Toch is het good practice om -als je toch al serial gaat gebruiken- deze bij je setup al te laten starten. Zo vang je veel problemen af als je per ongeluk dingen wil lezen of sturen naar/van serial, zonder deze te hebben gestart, omdat deze in een of andere functie staat die nog niet is gestart.

Dat is toch echt iets heel anders dan je eerder beweerde en waar ik antwoord op gaf.

Dat het menselijk fouten of code fouten kan voorkomen is iets heel anders dan wat je eerder beweerde dat maar eenmalig behoort aan te roepen en dat het in setup loop moet staan.

[mad_max234]

MistW schreef op zaterdag 21 december 2013 @ 11:59:
Hierbij een filmpje van de proefopstelling, toen alles nog prima werktte.
http://youtu.be/-7XDDu2CJ8k

Alexandersamson, bedankt voor je oplossing, tot nu toe werkt het nog steeds.
Wel raar, maar een oplossing is een oplossing haha.

Ik zal t.z.t. wel even een filmpje posten denk ik van het resultaat.

Als nu wel werkt dan zit er een foutje in de stand alone functie die de serial.begin en end aanriep. Die functie omzeil je nu dus en ook de code fout. maar je mis nu dus ook die functie. Al is die stand alone functie beetje overbodig, serial mag je gewoon altijd starten en ongebruikt aan laten, heeft in jou geval niet echt nadelig gevolgen, die maar uA meer verbruik is in jou geval niet van belang, draait niet op batterijen of zo. Dus wat mij betreft heb je die stand alone functie helemaal niet nodig, gewoon serial altijd starten.

[MistW]

mad_max234 schreef op zaterdag 21 december 2013 @ 12:41:
[...]


Als nu wel werkt dan zit er een foutje in de stand alone functie die de serial.begin en end aanriep. Die functie omzeil je nu dus en ook de code fout. maar je mis nu dus ook die functie. Al is die stand alone functie beetje overbodig, serial mag je gewoon altijd starten en ongebruikt aan laten, heeft in jou geval niet echt nadelig gevolgen, die maar uA meer verbruik is in jou geval niet van belang, draait niet op batterijen of zo. Dus wat mij betreft heb je die stand alone functie helemaal niet nodig, gewoon serial altijd starten.

Inderdaad zo gedaan, en nee, hangt niet aan batterijen . Hij start nu gewoon, zoals je zegt, de serial. Ook in standalone. Heel erg bedankt allemaal!

[mad_max234]

Je hebt de fout gevonden? En heb nu dus de oude situatie werkende zeg maar, dus met stand alone functie waarmee je serial in en uit schakelt?

[kitao]

En nog bedankt voor de tip over die lijnen. Ben blij dat je eruit gekomen ben; ik dacht gisteren even dat dit topic geen reacties zou krijgen maar dat valt vandaag ruimschoots mee.
Serial.begin aan het begin dus om fouten te voorkomen, altijd handig om te weten

[alexandersamson]

mad_max234 schreef op zaterdag 21 december 2013 @ 12:33:
[...]


Dat is toch echt iets heel anders dan je eerder beweerde en waar ik antwoord op gaf.

Dat het menselijk fouten of code fouten kan voorkomen is iets heel anders dan wat je eerder beweerde dat maar eenmalig behoort aan te roepen en dat het in setup loop moet staan.

Nah.. Ik vind het in der mate zo erg good practice dat een ieder die Serial ook maar denkt te gaan gebruiken een functie via de Setup moet aanroepen en niet ergens halverwege de loop. Ik vind zelf dan ook dat je het eenmalig hoort aan te roepen in de setup, al dan niet conditional met een if/then/else lusje.
Of het in de loop wel werkt, weet ik niet, want daar gebruik ik het nooit en nog nooit nodig gehad ook

Ben blij dat TS is geholpen in ieder geval

[MistW]

mad_max234 schreef op zaterdag 21 december 2013 @ 13:18:
Je hebt de fout gevonden? En heb nu dus de oude situatie werkende zeg maar, dus met stand alone functie waarmee je serial in en uit schakelt?

De fout is opgelost, het zat hem inderdaad ergens in de standalone functie. Hij start nu nog wel gewoon de serial, ook in standalone. Ietsje minder netjes maar werkt wel zo goed haha.

kitao schreef op zaterdag 21 december 2013 @ 13:19:
En nog bedankt voor de tip over die lijnen. Ben blij dat je eruit gekomen ben; ik dacht gisteren even dat dit topic geen reacties zou krijgen maar dat valt vandaag ruimschoots mee.
Serial.begin aan het begin dus om fouten te voorkomen, altijd handig om te weten

Ik ben ook erg blij dat ik er uit gekomen ben. Had ook nog op het Arduino forum gepost omdat ik dacht dat daar misschien wat meer kennis aanwezig zou zijn, daar slechts één slechte forum post gekregen, dat hielp dus weinig. Vertrouwen in Tweakers is dus niet beschaamd. Het filmpje gaat me nu even niet lukken. Heb zo een verjaardag. Maar echt heel erg bedankt allemaal!

[kitao]

Prettige verjaardag.
Overigens ben ik er nog niet uit, ik zie bij Fritzing alleen maar kleurkeuze in inspector of onder rechtermuisknop en geen blokjesdraad.
Misschien heb ik nog een oude versie.

edit:
was idd oude versie, ik heb nu 085 eropstaan en dan heb je wel gestreepte lijnen

[ Voor 18% gewijzigd door kitao op 21-12-2013 14:23 ]

[mad_max234]

alexandersamson schreef op zaterdag 21 december 2013 @ 13:56:
[...]


Nah.. Ik vind het in der mate zo erg good practice dat een ieder die Serial ook maar denkt te gaan gebruiken een functie via de Setup moet aanroepen en niet ergens halverwege de loop.

Ben blij dat TS is geholpen in ieder geval

Dat mag je vinden, of het waar is is een tweede.
Als je code gewoon goed werkt is er geen enkele rede waarom je setup zou verkiezen boven void loop!

En wat nu als je in je code serial bandbreedte wilt aanpassen, dus via serial monitor nieuwe bandbreedte opgeven en on the fly veranderen? Juist ja dat kan niet eens in de setup loop.
En wil misschien juist helemaal geen serial verbinding actief hebben vanaf setup loop, kan zelfs ongewenst zijn voor andere, dat het in jou situaties op die manier beste is uitgekomen zegt helemaal niks natuurlijk.

Ik vind zelf dan ook dat je het eenmalig hoort aan te roepen in de setup, al dan niet conditional met een if/then/else lusje.
Of het in de loop wel werkt, weet ik niet, want daar gebruik ik het nooit en nog nooit nodig gehad ook

Zoals ik al zei mag je dat vinden, is dat voor jou wellicht beste oplossing steeds geweest, maar dat hoeft voor andere helemaal niet. De C code achter serial.begin heeft gewoon juist init volgorde om overal in code ten alle tijde opnieuw aangeroepen te mogen worden zonder dat het problemen geeft.

[alexandersamson]

mad_max234 schreef op zaterdag 21 december 2013 @ 14:59:
[...]

Als je code gewoon goed werkt is er geen enkele rede waarom je setup zou verkiezen boven void loop!

[...]

Daar is dus het probleem met deze discussie: De code werkte niet goed.
Als je je code goed schrijft, zet je Serial.begin(baudRate); in je setup neer neer en niet in je loop.
De code van TS heeft geen enkele eigenschappen in gebruik waarom de Serial.begin in de loop zou moeten beginnen.
Het is een stukje netheid en overzicht, zodat je minder fouten maakt. Je gooit je #Defines die je in het begin nodig hebt ook niet ergens tussen je code neer.
Je kan nu wel allemaal weerwoorden geven en net doen of ik weinig sense maak, maar kijk eens voor de grap naar de meeste voorbeeldcodes en codes voor Arduino over het algemeen. Serial wordt gewoon gestart in de Setup, waarom, vraag je je af? Omdat het een init is en daar gewoon hoort in de meeste gevallen en goed is voor het overzicht :-) period

over excessen en poortconflicten waarbij je niet wil dat Serial wordt gestart in het begin kunnen we heel lang doorpraten, maar valt compleet buiten de scope van TS zijn, nu opgeloste, probleem

[MistW]

Dit is zo ongeveer wat het is geworden.
http://youtu.be/ynO3Et3OOF8

[Verwijderd]

stevige kast en knoppen

[Ploink]

Ja mooi robuuste constructie. Het ziet er professioneel uit. Is het voor een televisie quiz of voor in de lokale kroeg ofzo?

[alexandersamson]

Dat ziet er allerbest uit. Is dit iets wat je aan het bouwen bent voor een opdrachtgever? Ik bedoel maar, Neutrik connectoren enzo en professionele kabels en switches.

[mad_max234]

Ziet er netjes uit en degelijk uit. Led onder die knop is dat ook RGB?
Waar ga je het systeem voor gebruiken, ben altijd beetje nieuwsgierig?

@alexandersamson
Nee serial initial mag overal plaatsvinden ook in de while loop(void loop in arduino), init van serial mag overal(main loop en while loop) plaatsvinden, zie datasheet van atmega328p of app notes van atmel over usart.

Ik vind het juist bad practice, door serial te verplaatsen doet je code het wellicht, maar niet zoals je eigenlijk zou willen. Vind net zoiets als mensen die zinnen anders gaan schrijven omdat ze bepaalde woorden niet kunnen schrijven. Je lost je probleem niet op maar ontloopt het probleem, leer er dus niks van maar ontloopt het juist, it is a bad practice!

Nogmaals is geen good practice, en er is geen rede om serial.begin in setup te zetten of boven void loop te verkiezen, ook in setup kan er code fouten zitten, waar ga je serial.begin dan heen plaatsen?

En soms kan serial.begin niet eens in setup loop, moet perse in de void loop voor bepaalde handelingen.

Edit
Defines staan wel degelijk door codes heen, wat als je nu meerder soorten uC wilt ondersteunen in je code, dan zal je code vol staan met if defines met daarbij de juist defines voor de uC en de functie. Dat jij het niet zo gebruikt wilt niet zeggen dat het ongebruikelijk is, is namelijk heel gebruikelijk. En ja word er niet duidelijker op, dat is waar, maar helaas is dit toch echt de makkelijkste manier die we kennen om dit voor elkaar te krijgen, grootste voordeel is nog dat we allemaal hetzelfde blijven doen zodat we weten waar we wat mogen verwachten, oop is daar onder andere een middel voor.

En defines die je nodig hebt zullen natuurlijk eerst gedefinieerd moeten worden voordat je ze gebruikt, logisch lijkt me, maar defines staan echt niet altijd bovenaan of in .h file of zo. Staan vaak bij de functies zelf. Vaak zijn delen van functie die anders geschreven moeten worden voor bepaald uC, bijvoorbeeld atmel software framework voorbeelden staan files vol met defines, die voorbeelden zijn voor zowel de atmel SAM's en atmel AVR's(mega en xmega's) uC's.

[ Voor 50% gewijzigd door mad_max234 op 23-12-2013 21:17 ]

[alexandersamson]

mad_max, ik snap je hele verhaal wel, maar je vergeet wat ik zeg: de code van TS heeft geen kwaliteiten die het nodig maken om de Serial via de loop te laten lopen. Net als de defines. Global defines (al dan niet met ifdef) zet je ook gewoon bovenaan. Uitzonderingen daargelaten en dat zeg ik ook steeds. Uitzonderingen zijn voor TS nu niet van toepassing, want zijn code zal net zo efficient werken met alles tussen de loop als alles netjes op volgorde. Alleen waarom zou je alles tussen je loop gooien en het onoverzichtelijk maken als je het simpel kan houden?
Het zal er ook van afhangen of je bepaalde zaken globaal of lokaal gebruikt. En daar botsen onze meningen denk ik een beetje. Het heeft geen zin om er excesvoorbeelden bij te halen, want daar gaat dit helemaal niet over in TS zijn probleem. Misschien is het wat duidelijker als ik er duidelijk bij zeg dat ik code bedoel zoals TS zijn code en niet allerlei voorbeeldcodes en situaties die je nu tevoorschijn haalt.

dat stuk over bad practice als je serial gaat verplaatsen en woorden schrijven is bullshit, want in een simpel stuk code als TS had Serial gewoon in de setup gestart kunnen worden vanaf begin af aan en had er niets verplaatst hoeven worden (en vica versa). Let op:

code:

void setup(){
  if(connected ==  true){
    Serial.begin(9600);
  }
}
void loop(){
  //Do things here
}

of:

code:

void setup(){
  // Y u no use me? :(
}
void loop(){
  if(triggerThisOneTimeOnly == false){
    triggerThisOneTimeOnly = true;
    if(connected ==  true){
      Serial.begin(9600);
    }
  }
}

Waarom dus dingen in simpele code moeilijk maken voor jezelf, anderen... Omdat je een bepaalde standaard wil gebruiken die 'ook gebruikelijk' is. Heb je gelijk in, maar daarmee ook zeggen dat ik het minder juist heb of dat al die voorbeeldcode geschreven en te vinden zijn op het internet voor code van het zelfde simpelheidslevel als die van TS, minder juist zijn dan jouw mening hierover, geloof ik dus geen ene zak van

[kitao]

Interessant deze polemiek.
Nu ben ik zelf bezig met een beetje C door te nemen en wat ik me dus afvraag als het in dit geval toch niet uitmaakt waar Serial.begin wordt geschreven, hoe kan het dan dat toen TS het verplaatste naar Setup het probleem in ene keer was opgelost ????

[alexandersamson]

Omdat er door een overzichtsfoutje waarschijnlijk eerst een Read/Write werd gedaan voordat Serial was begonnen. Of door een fout dat de lus zich blijft herhalen, steeds Serial initialiseerd, wat misschien een interrupt is, die dus er voor zorgt dat de data naar de RGB leds werd onderbroken en corrupt raakte.
Daarom blijf ik zeggen: Als je code simpel is, houd het simpel en zet de dingen gewoon op plekken zoals ze bedoelt zijn. Als je code ingewikkelder is, dan heeft mad_max gelijk met al zijn punten, maar moet je dus goed opletten dat je geen foutjes maakt
Ik heb het zelf allemaal getest en het maakt inderdaad geen ene drol uit waar je Serial.begin zet. Alleen als deze in een ongecontroleerde loop raakt, krijg je rare verhalen en klopt millis(); enzo niet meer. Paar keer liep de Arduino zelfs vast en draaide helemaal geen code meer. Dus qua functionaliteit heeft mad_max helemaal gelijk, maar qua overzicht is het beter Serial gewoon lekker bij je setup te zetten, dan weet je dat hij precies 1 keer wordt geinitialiseerd, niet meer en dat hij wordt geinitialiseerd voordat je loop begint.
Bij meer ingewikkeldere code, waarbij je Serial steeds wil aanpassen of verlaat wil inschakelen zal je deze wel naar de loop moeten verplaatsen. Maar dan moet je dus opletten dat je deze niet in een freefall laat lopen of dat je requests doet voordat je Serial.begin() hebt gebruikt.

[ Voor 42% gewijzigd door alexandersamson op 24-12-2013 10:54 ]

[Verwijderd]

Dus qua functionaliteit heeft mad_max helemaal gelijk, maar qua overzicht is het beter Serial gewoon lekker bij je setup te zetten, dan weet je dat hij precies 1 keer wordt geinitialiseerd, niet meer en dat hij wordt geinitialiseerd voordat je loop begint.

100 %

[Sissors]

Laat ik dan maar degene zijn die verteld wie er gelijk heeft van de twee ruziemakertjes . Allebei . En geen van beide .

Ja je mag baudrate wijzigen buiten je setup, anders zou je dat inderdaad nooit on-the-fly kunnen doen. Maar Serial.init mag zeker niet overal plaatsvinden. Enkel en alleen als je zeker bent dat er op dat moment niks wordt ontvangen of verstuurd.

En de algemene 'regels': inits doe je in de setup. Het is zonde van je processing om ze meerdere keren te doen. Wijzigen van je settings kan (soms doe je dat zelfs continue, als je bijvoorbeeld op 1 SPI bus twee devices met verschillende eisen hebt die je om en om gebruikt), maar dan moet je zeker zijn dat het op dat moment mag.

Bijvoorbeeld voor de UART van de datasheet:

Before doing a re-initialization with changed baud rate or frame format, be sure that there are no
ongoing transmissions during the period the registers are changed

Oftewel, niet kloten met baudrate als hij bezig kan zijn.

"Maar Sissors, als je hem instelt op de waarde waar hij al op stond verandert er eigenlijk toch niks?"

Niet dus, stukje eerder in diezelfde datasheet:

The USART Baud Rate Register (UBRRn) and the down-counter connected to it function as a
programmable prescaler or baud rate generator. The down-counter, running at system clock
(fosc), is loaded with the UBRRn value each time the counter has counted down to zero or when
the UBRRnL Register is written.

Oftewel een clock divider wordt gebruikt om de juiste baudrate te maken (een tellertje). Elke keer dat jij een nieuwe baudrate instelt wordt dat tellertje gereset, en klopt er dus geen drol meer van hetgene waar hij mee bezig was, afhankelijk van het exacte moment waarop het gebeurd.

[ Voor 5% gewijzigd door Sissors op 24-12-2013 11:09 ]

[kitao]

Bedankt voor de toelichting iedereen.
Iets dergelijks was ik net aan het doorlezen en dat ging over een 'statement block scope level'.
Zo zal dit programma niet gaan werken :

C++:

#define MAXVAL 1000
int k = 0;
void setup()
{
Serial.begin(9600);
}
void loop()
{
int x = 5;
if (x < MAXVAL) {
int temp;
temp = x * 100;
}
Serial.print("The value of temp is: ");
Serial.println(temp);
if (k++ > 10)
exit(0);
}

[Verwijderd]

kitao schreef op dinsdag 24 december 2013 @ 11:26:
Bedankt voor de toelichting iedereen.
Iets dergelijks was ik net aan het doorlezen en dat ging over een 'statement block scope level'.
Zo zal dit programma niet gaan werken :

C++:

#define MAXVAL 1000
int k = 0;
void setup()
{
Serial.begin(9600);
}
void loop()
{
int x = 5;
if (x < MAXVAL) {
int temp;
temp = x * 100;
}
Serial.print("The value of temp is: ");
Serial.println(temp);
if (k++ > 10)
exit(0);
}

en snap jij ook waarom niet ..

[kitao]

Als je het nog verder wil toelichten dan is dat altijd welkom natuurlijk

[Verwijderd]

kitao schreef op dinsdag 24 december 2013 @ 12:07:
Als je het nog verder wil toelichten dan is dat altijd welkom natuurlijk

dat is een vraag met een wedervraag beantwoorden
_{kom er straks even op terug}

[ Voor 7% gewijzigd door Verwijderd op 24-12-2013 12:11 ]

[Harrie]

Ik vermoed dat hij bedoelt dat de integer temp, welke gedeclareerd wordt binnen de if, niet meer beschikbaar is na de sluitende accolade van regel 13.
De Serial.println(temp); op regel 15 zou dus een compiler error moeten geven vermoed ik?
(Ik heb wel nog nooit code geschreven voor een Arduino..)

[ Voor 10% gewijzigd door Harrie op 24-12-2013 12:17 ]

[kitao]

Harrie schreef op dinsdag 24 december 2013 @ 12:16:
Ik vermoed dat hij bedoelt dat de integer temp, welke gedeclareerd wordt binnen de if, niet meer beschikbaar is na de sluitende accolade van regel 13.
De Serial.println(temp); op regel 15 zou dus een compiler error moeten geven vermoed ik?
(Ik heb wel nog nooit code geschreven voor een Arduino..)

exact
dit komt in beeld :

_klikbaar
De overeenkomst met dit topic is dus de plaatsgeving van 'iets' binnen een programma en de mogelijke invloed daarop.
Goed gezien trouwens als je zelf nooit met arduino bezig bent. Maar dit fenomeen komt ook in andere talen voor zag ik.

_{edit:
grotere afbeelding neergezet, was niet te lezen}

[ Voor 6% gewijzigd door kitao op 24-12-2013 12:36 ]

[Verwijderd]

goed bezig kitao !

[alexandersamson]

Sissors schreef op dinsdag 24 december 2013 @ 11:07:
...Verhaal...

Duidelijke taal en duidelijke sense Weer wat geleerd

[MistW]

Verwijderd schreef op maandag 23 december 2013 @ 15:34:
stevige kast en knoppen

Ploink schreef op maandag 23 december 2013 @ 15:57:
Ja mooi robuuste constructie. Het ziet er professioneel uit. Is het voor een televisie quiz of voor in de lokale kroeg ofzo?

alexandersamson schreef op maandag 23 december 2013 @ 15:58:
Dat ziet er allerbest uit. Is dit iets wat je aan het bouwen bent voor een opdrachtgever? Ik bedoel maar, Neutrik connectoren enzo en professionele kabels en switches.

mad_max234 schreef op maandag 23 december 2013 @ 20:52:
Ziet er netjes uit en degelijk uit. Led onder die knop is dat ook RGB?
Waar ga je het systeem voor gebruiken, ben altijd beetje nieuwsgierig?

Eigenlijk, is het voor de leuk. Ik organiseer mede een quiz in de lokale jeugdsoos, het leek me een leuk projectje. Alles is een beetje op basis van "al doende leert men". Er zitten wat meetfoutjes in, denkfoutjes gemaakt, dingen die volgende keer anders zou doen maar al met al is het heel aardig gelukt.
Het zijn niet echte Neutriks hoor, enkel de USB en UTP voor de rgbLEDstrip zijn Neutrik.

Je bedenkt onderweg welke kabels waar geschikt voor zouden kunnen zijn, wat handig is. Rubuust.
Tevens kan je niet iets bedenken qua aansluitingen wat je niet kent, je zoekt dus tussen wat je bekend is. Ik ben inmiddels wel meerdere aansluitingen tegen gekomen die ook wel zouden kunnen. De XLR kabels zijn mij erg bekend, ik wou eerst voor Jackpluggen gaan maar XLRs locken mooier. (Achteraf zijn de geboorde cirkels ietsje te klein, daardoor werkt de lock nog niet haha, je kan de pushknopjes wel indrukken maar ze veren niet terug.. foutje moet kunnen)
Wat betreft de schakelaartjes, tsja, ze zijn goedkoop hoor, stelt niet veel voor opzich. Ik vond het vervelend dat de relais aldoor mee staan te schakelen, dus heb er een switch tussen gezet. Dat zul je lang niet aldoor gebruiken in de praktijk.

De ledstrip onder de knop is geen RGB, gewoon witte led. Anders zouden er 5 aders door de kabel moeten lopen, r,g,b,12v,ground,knop. Ze zijn er wel, maar wit is prima. Ik wil alleen nog even dat de witte leds altijd branden en gaan knipperen wanneer er gedrukt is. Dus moet nog even wat transistortjes hebben. Verder is binnenin nog niet alles aangesloten, de print met 4 relais moet nog komen uit China. De laatste 4 XLR's zijn ook nog niet aangesloten. Werk genoeg dus.

De behuizing is een lang verhaal, heb heel lang zitten zoeken. Het is mijn eerste projectje, dus er moest wel voldoende ruimte zijn om alles in te bouwen. Verder zitten er in de kast 2 voedingen, 1 gewone 12v adapter voor de rgbledstrip (laptop adapter grootte) en 1 12v voeding voor de witte LEDstripjes onder de knop en voor de Arduino.
Gaandeweg krijg je al meer een beeld van hoeveel ruimte alles in beslag neemt, maar je blijft aldoor wachten op dat éne pakketje enzovoorts. Bij Conrad zag ik door alle behuizingen echt het bos niet meer, daar komt bij dat de site niet heel snel is en daardoor het zoeken nog ergernisvoller werd. Toen bedacht ik mij dat een flightcase of iets dergelijks misschien ook wel iets zou zijn, nou ja, zo kom je dus uiteindelijk bij dit uit. Een mooie PVC behuizing die ook nog in een kastje is in te bouwen. Voorbereid op een onbekende toekomst zeg maar.

Trouwens het idee van de knoppen kwam van R.U.B.E.N. Daar zitten ook mooie knoppen in die ik vervolgens ook ergens op het www vond: http://www.yellowspot.nl/...ten/speltechniek/knoppen/
Zij hebben dus gaatjes geboord in de zwarte knop, daarvoor was de knop mij toch ietsje te duur. Komt bij, als je het fout doet blijf je het altijd zien. Nu waren twee kleine gaatjes voor de draadjes aan de binnenzijde voldoende.

Bedankt allemaal voor de positieve reacties. De binnenzijde is trouwens wel een breadboardje nog. Ik was begonnen op een gaatjesprint, maar mijn precieze soldeerskills waren nog niet echt je van het. Toen bleek dat we ook nog een shifter nodig hadden vond ik het wel goed hoor. Die connectoren solderen toch allemaal een stuk makkelijker dan de pootjes van een shifter...

[kitao]

Voor die shifter kan je een ic-voetje pakken.
Insteken, vastzetten met plakband, printje omdraaien en solderen met scherp puntje.
Mooi project trouwens en behoorlijk uitgebreid voor de eerste.

ps, misschien is dit makkelijker als een eilandprintje, heb je wat meer aansluitingen

[ Voor 29% gewijzigd door kitao op 25-12-2013 15:57 ]