Arduino issues, randomnumber game

[cagXZ]

Hallo allen!

Ik loop wat probleempjes tegemoet met mijn arduino uno!
Mijn uno heeft een MFS

(multi function shield)

Op de board zie je 4 leds staan, D1 tot en met D4, zij zijn geprogrammeerd om er voor te zorgen dat er een random binair nummer wordt afgespeeld, de nummer wordt gegenereerd met een random number generator.

Nu moet de gebruiker de juiste aantal malen op knop A1 drukken om de goede binaire nummer op te geven, als de juiste aantal malen de knop is ingedrukt, zal op de display verschijnen "G0ED", zo niet of heb je het niet binnen 2 seconden een input gegeven? "You L0SE".

De tijd wordt gemeten door middel van millis(); maar waar ik nu tegen aan loop is de feit dat wanneer ik de knop indruk, pas na een flinke delay 1,2,3,4,5,6 etc. op de display te zien krijg, het loopt niet synchroon...

Hebben de devs hier een tip voor?

Alvast bedankt!

Relevante software en hardware die ik gebruik:
Arduino Uno, MFS, Arduino IDE
...

Wat ik al gevonden of geprobeerd heb:
Delays weghalen en kijken of dat hielp, heeft niet geholpen
...

[TommyboyNL]

Hoe zouden wij jouw vraag moeten kunnen beantwoorden zonder dat jij jouw broncode hier neerzet?
Verder verwacht ik toch dat je nog ergens delays gebruiktm die dit veroorzaken. Delays zouden eigenlijk net als "goto" op de zwarte lijkt van commando's moeten staan.

[cagXZ]

TommyboyNL schreef op zondag 17 december 2017 @ 11:30:
Hoe zouden wij jouw vraag moeten kunnen beantwoorden zonder dat jij jouw broncode hier neerzet?
Verder verwacht ik toch dat je nog ergens delays gebruiktm die dit veroorzaken. Delays zouden eigenlijk net als "goto" op de zwarte lijkt van commando's moeten staan.

Dat vind ik dus ook zeer lastig, ik ga er van uit dat wanneer je je code in de loop sectie zet, alles tegelijkertijd uitgevoerd hoort te worden, maar dat bleek dus in praktijk totaal niet zo te zijn. Anderen wie dit ook gedaan hebben, hebben weer wel de juiste resultaat.

Flabbergasted

[TommyboyNL]

Een microcontroller voert nooit dingen tegelijkertijd uit, alles gebeurt achter elkaar. Als je gelijktijdige acties wilt, zal je je moeten vergrijpen aan een FPGA of CPLD.
Maar nogmaals: Post je broncode eens.

[cagXZ]

TommyboyNL schreef op zondag 17 december 2017 @ 15:20:
Een microcontroller voert nooit dingen tegelijkertijd uit, alles gebeurt achter elkaar. Als je gelijktijdige acties wilt, zal je je moeten vergrijpen aan een FPGA of CPLD.
Maar nogmaals: Post je broncode eens.

Als ik het goed begrepen heb, is dat niet toegestaan, ik zal het privé delen in een vorm van een gist,
My thanks!

[TommyboyNL]

Wissel regel 57 en 58 eens om, zoals ik je code interpreteer, zijn die omgewisseld.
Verder doen je variabelen "teller" en "n" vrijwel exact het zelfde, op de overflow detectie (regel 61 en 62) na.
Verder doen de curly brackets op regel 79 en 94 volgens mij niks, waarom staan die daar?

[farlane]

Lekker duidelijk .... Waarom kun je (relevante) stukken code niet hier plaatsen?

[cagXZ]

farlane schreef op zondag 17 december 2017 @ 17:31:
Lekker duidelijk .... Waarom kun je (relevante) stukken code niet hier plaatsen?

Klinkt zeer omstreden, is het ook maar hier heb ik het bewijs:

[raptorix]

Uh, je mag gewoon je code plaatsen, het is alleen niet de bedoeling dat wij hier hele lappen gaan programmeren, daarnaast is algemene stelregel dat je zelf enigzins moeite hebt gedaan, en daarbij houden we uiteraard rekening met jouw niveau, en dan maakt het echt niet uit of dat je eerste middag programmeren is, of dat je bij Google werkt, geloof me niemand zal je daar op beoordelen, ik ken verschillende mensen uit dit topic die hier als hobbyist kwamen en nu op het allerhoogste niveau programmeren.

[Creepy]

Alle code plaatsen is heel iets anders dan alleen relevante code plaatsen. Je screenshot bewijst dan ok niks.

Nu is dit een topic waar niemand in de toekomst wat aan gaat hebben omdat niet duidelijk is wat je probleem nu precies is. Code via DM maar gaan delen is dus ook weer niet de bedoeling. Dus post de code waar het om draait (probeer je probleem te repduceren met zo weinig mogelijk code) en dan kunnen we je prima helpen,

[ Voor 5% gewijzigd door Creepy op 17-12-2017 19:33 ]

[Sissors]

TommyboyNL schreef op zondag 17 december 2017 @ 11:30:
Hoe zouden wij jouw vraag moeten kunnen beantwoorden zonder dat jij jouw broncode hier neerzet?
Verder verwacht ik toch dat je nog ergens delays gebruiktm die dit veroorzaken. Delays zouden eigenlijk net als "goto" op de zwarte lijkt van commando's moeten staan.

En dan alles maar interrupt based gaan doen? Dat is zware overkill voor veel toepassingen, en niet realistisch voor andere (zoals OneWire gaan bitbangen, succes dat te doen met timer interrupts voor de delays).

[TommyboyNL]

Sissors schreef op maandag 18 december 2017 @ 08:58:
[...]

En dan alles maar interrupt based gaan doen? Dat is zware overkill voor veel toepassingen, en niet realistisch voor andere (zoals OneWire gaan bitbangen, succes dat te doen met timer interrupts voor de delays).

Daar zijn interrupts inderdaad precies voor bedoeld. Een alternatief is de timestamp opslaan wanneer iets moet gebeuren en in je main loop checken of het al tijd is, en op dat moment je routine uitvoeren.

[Sissors]

Je interrupt overhead is veel te groot om bijvoorbeeld een OneWire te bitbangen. Zelfs als het snel genoeg is, ben je nog zo ongeveer 100% van de tijd bezig, en levert het geen enkel voordeel op.

Zolang je maar één proces hebt in je main lus, of meerdere maar die totaal niet tijd kritisch zijn (bijvoorbeeld je wil als de temperatuur van je kamer onder de 15 graden een lampje laten knipperen, dan maakt het echt niks uit als de temperatuur 100us te laat wordt uitgelezen door een andere delay), dan zie ik echt geen probleem van delays. Om het nog niet te hebben over initialisatie bijvoorbeeld. Als jij bij power-on één keer een commando naar een sensor moet sturen, 10ms moet wachten, en dan een ander commando, dan ga je dat toch niet serieus met interrupts doen? Als je je echt daar druk over maakt, pak dan een MCU die fatsoenlijk een RTOS kan draaien.

[farlane]

Sissors schreef op maandag 18 december 2017 @ 17:04:
Als jij bij power-on één keer een commando naar een sensor moet sturen, 10ms moet wachten, en dan een ander commando, dan ga je dat toch niet serieus met interrupts doen?

Waarom niet? Voor dit soort soft-delays gebruik ik meestal de Cortex system timer die in zijn interrupt de system tick ophoogt. Als het strakker moet neem ik een hardware timer. Ik zie het probleem niet.

[Sissors]

Omdat het onnodig moeilijk doen is, en je code wordt er onduidelijker van als je alles via interrupt handlers gaat doen als het ook prima met een reguliere delay kan.

Maar als je dat graag wil doen, prima hoor. Maar dat betekend niet dat er iets mis is met delays gebruiken. Uiteraard hebben ze hun plaatsen waar ze niet horen te zijn, maar er zijn zat plaatsen waar er niks mis is met een delay.

[farlane]

Sissors schreef op maandag 18 december 2017 @ 21:02:
Omdat het onnodig moeilijk doen is, en je code wordt er onduidelijker van als je alles via interrupt handlers gaat doen als het ook prima met een reguliere delay kan.

Hoezo onnodig moeilijk doen? Van een delay die aan een timer hangt weet ik iig dattie in optimized code net zo lang duurt.

[Sissors]

Van een inline delay die aan een timer hangt weet je dat ook (eg, while(timer_value < initial_value + delay)). Alleen hij zit gewoon inline ipv dat je rond gaat springen met interrupt handlers en state machines voor elke basis taak.

En hoewel dat de voorkeur heeft tov een for( ...) nop(); nop(); nop(); delay, vind ik het dus onnodig moeilijk doen als je gewoon ergens een basis vertraging waar het niks uitmaakt dat je hele main code stopt gaat vervangen door een interrupt handler met state machine.

Wat mij betreft hebben zowel interrupt based timings en inline delays gewoon hun plaats. En natuurlijk, als je de timers beschikbaar hebt is een inline delay op basis van een hardware timer het netste, maar als je die niet beschikbaar hebt, of als die niet voldoet, dan is een delay op basis van NOPs voor genoeg situaties ook acceptabel. Heb er zelf nog een keertje eentje gemaakt die zichzelf eerst kalibreert tegen een hardware timer.

[ Voor 30% gewijzigd door Sissors op 19-12-2017 07:51 ]

[farlane]

Sissors schreef op dinsdag 19 december 2017 @ 07:46:
Van een inline delay die aan een timer hangt weet je dat ook (eg, while(timer_value < initial_value + delay)). Alleen hij zit gewoon inline ipv dat je rond gaat springen met interrupt handlers en state machines voor elke basis taak.

Ok, je buigt nu volgens mij enigzins af; nu geef je aan een timer te gebruiken voor een delay waar je het volgens mij eerst had over een delay loop ( dus een for (..) met nops erin oid ) . Dat of ik begrijp je verkeerd.

Wachten op een hardware timer voor een delay is hetzelfde als ik aangeef, echter soms kan het zijn dat je langer moet wachten en dan is een timer tick + statemachine op zijn plaats. Delay loops met nopjes heb ik maar een paar keer nodig gehad, vnl "vroeger" op kreupele 8051/AVR hardware.

[Sissors]

Mijn reactie was oorspronkelijk richting @TommyboyNL, en daar ging het zoals ik het begrijp erover dat het probleem was dat een delay blocking is, en een check in de main loop of een interrupt is dat niet. Maar daar wordt je code onduidelijker van doordat je een statemachine nodig hebt. En soms is dat gewoon de juiste optie, maar soms vind ik dat overkill.

Of een delay met een Timer of met nopjes wordt gedaan is een volgende discussie, en daar is dus de verwarring tussen ons . Timer is uiteraard netter, en als er een interrupt gebeurd dan blijft die delay redelijk correct (afhankelijk wanneer die precies gebeurd). Tegelijk zijn er ook situaties waar NOPjes goed genoeg zijn, of er simpelweg geen losse hardware timer meer beschikbaar is omdat ze allemaal al voor iets gebruikt worden (of omdat het een stuk generieke code is waar je geen timer voor wil gebruiken, al heb je dan weer wat meer risico dat compiler instellingen je delay gaan aanpassen).