Chaser + TFT parallel

Goeiedag allen.

ik ben Emile b uit noord-holland en ben 28jaar Arduino/c/c++/html/php/css is een hobby die ik heb zins me eeste 386.

momenteel ben ik bezig met een Chaser(lichttafel), 512 kanalen die ieder een waarde van 0 tot 255 kunnen hebben. met een arduino DUE!

momenteel heb ik een aantal dingen gaande.
de Engine , het gene dat informatie uit een array haald en zo doende de 512 kanelen kan aansturen.
IO/analog , wat code om 8/8/8, buttons/led/analog informatie teverwerkt. via 165,595,4051
TFT + touchscreen, HX8357D 8bit mode

voorheen had ik de Engine is een ISR gestopt doormiddel van Duetimer library.
dit werkte Perfect! was ook erg makkeliijk met de rest van de programma schrijven.
maar ik heb op menigt topic gelezen dat een ISR zo kort mogelijk moest zijn.
via de Engelse forum ben ik er achter gekomen dat de ISR veelst groot/lang was, en ik alles parallel moest gaan draaien.

naja mijn moeder taal is nederlands dus dacht van ik vraag het hier omdat de engelse forum wat moeilijk tebegrijpen is met moeilijke woorden en begrippen.

nu de vraag is hoe kan ik alles zo goed mogelijk parallel laten werken.

momenteel heb ik een ISR die een flag true zet en als hij true staat moet hij Alles vergeten en zo Snel!! mogelijk naar het stuk gaan waar de Engine staat. en als hij dat heeft gedaan dan moet hij verder gaan waar hij gebleven was en de flag staat dan weer op false. en ik vind dit moeilijk om te combineren met de TFT. want die gebrijkt heel veel procces power om alles te updaten.

de code die ik nu heb voor de TFT werkt opzig wel goed maar ik vind het niet echt netjes.

meschien hebben jullie een goed idee hoe ik de engine/tft netje parallel kan laten lopen.

en om een idee tekrijgen van mij skecth
tab _100_Playback staat de engine.
tab _800_Menu_F staan de lcd functions uitgewerkt.
tab _999_loop staat de loop

SequencerArray_v3.1.zip (7.35 KB)

Ja een ISR moet zo snel mogelijk gedaan zijn, want anders lopen timers in het honderd, wat je wel kunt doen zoals je al doet is, een interuptvlag aanzetten in de interupt routine, of een teller ophogen etc.
parallel lopen kun je zeker, door geen for loops te gebruiken, de analoge waarde ophalen, dan telkens 1 ophogen en terug naar de loop, dan bijv een regel naar de tft schrijven, en de volgende analoge waarde ophalen,
dan spring je dus telkens heen en weer, voordelen zijn dat de analoge waarden stabieler zijn, en bijvoorbeeld een serieel uit heeft dan tijd om te verspringen, je hoeft dan niet telkens een delay te gberuiken om op het clocksignaal te wachten.

naja wat ik nu doe is 44x per seconde de falg true zetten en ALLES!!! wat in de engine zit updaten.
daarbuiten mag de DUE gewoon de loop draaien als normaal.
maar ik vind het moeilijk om een goeie manier tevinden om de TFT elemeten opzijn buurt te updaten zonder de Flag te storen.

ik wil uiteraard zo een hoog mogelijke FPS op de TFT bepalen zonder de Engine lastig tevallen want dat is het belangrijks in de hele sketch.

Maar effe een duidelijk andtwoord over ISR's wil ik ook hebben. want hoe defineer je nouw of een ISR te groot is.

zo als ik al zij had ik de totale Engine in een ISR.
hier door hoefde ik niet moeilijk na tedenken om alles parallel te laten draaien.
het draaide gewoon precies zo als ik wouw.

iedereen zecht dat als je ISR tegroot is dat er onverwachte dingen kunnen gebeuren.
maar ik heb me sketch op deze manier wel 1week NON-STOP laten draaien en het werkte allemaal nog perfect!

en de normale run time voor het project wat ik heb is 8 uur achterelkaar en uit gekkigheid meschien 12 uur achter elkaar.

hoe defineer je nouw of een ISR tegroot is?

Als je echt wilt weten of een ISR te groot is, dan heb je nog wel wat huiswerk uit te voeren.
Op het moment dat een ISR wordt uitgevoerd blokkeren de anderen interrupts. Dus zoals Paul al aangaf dat evt. timers stilstaan en mogelijk een "tick" gaan missen. Dit soort controllers heeft niet een of andere priorisering van de interrupts.
Als je wilt weten hoelang de ISR duurt, zul je naar de assembly moeten van de code en per instructie de duur bepalen in cycles (mogelijk zijn hier programma's voor). Zolang de duur korter is dan bijvoorbeeld het aantal ticks in millis() ed. gaat het nog altijd goed. Maar er zijn nog meerdere ISR's aan het werk als je gebruik maakt van diverse libraries.
Een ISR is een onderbreking van de "normale" flow van het programma. Reden om deze dus zo kort mogelijk te houden. Op het moment dat je een belangrijk stuk code gaat opnemen in een ISR kun je jezelf afvragen of je wel "handig" bezig bent.
Ik heb al eens meer gezegd dat een "werkend" programma een goed programma is. Dat het nu toevallig goed gaat zou je de volgende keer wel eens kunnen opbreken omdat je dan je het apelazerus zoekt in een programma die er op eerste gezicht goed uit ziet meer toch niet doet wat je wilt. Je hebt dan een "slechte" gewoonte aangeleerd en die is moeilijker af te leren dan aan te leren.

spirit:
Maar effe een duidelijk andtwoord over ISR's wil ik ook hebben. want hoe defineer je nouw of een ISR te groot is.

Mijn visie:
ISR als sensor: Als je meer doet dan registreren dat de ISR zich heeft voorgedaan doe je teveel.
ISR als sturing: als je meer doet dan een paar pinnen verzetten doe je teveel. (dit kan inclusief berekeningen van de nieuwe pin waarden als ze simpel zijn. Dus geen cosinus en sinus ...)

Met vriendelijke groet
Jantje

zowel de chaser als de tft hoeven alleen herschreven te worden als er iets verandert, en zelfs dan alleen de waarde veranderen die nodig is.

Dit soort controllers heeft niet een of andere priorisering van de interrupts.

ik heb volgens mij wel eens gelezen dat het gewoon in een wacht rij komt.
Dus als ISR 1 bezig is en ISR 2 word opgeroppen, dat ISR 2 wacht tot dat ISR 1 klaar is. en dat zijn ding doet.

Zolang de duur korter is dan bijvoorbeeld het aantal ticks in millis() ed

om precies te zijn de Engine duurt ±700Micros dus 0.7 millis.

Een ISR is een onderbreking van de “normale” flow van het programma. Reden om deze dus zo kort mogelijk te houden.

DAAROM!! gebruikte ik het juist. de Engine moet!!! optijd geupdate worden. anders zie (met je ogen) vertragingen, als je BV een pagina op de TFT verandert.

maar ik denk nu wel dat ik begrijp waarom ik geen ISR moet gebruiken. ook al werkte het wel lekker en was de rest van de skecth programmeren daardoor heel makkelijk.

momenteel heb ik de ISR flag.
deze zorg er voor dat IF FLAG==TRUE dan STOPT ALLES. tot dat hij bij de Engine is en speel dat af, daarna staat FLAG=FALSE.
en als FLAG==FALSE dan update LCD.
En lcd functies hebben een ID en als IDno == true/1 && ISRTIME < 1000 (ISRTIME = de hoeveel tijd hij heeft om LCD functies teupdaten) tot dat de volgende ISR flag moglelijk komt.
Anders is hij meschien iets heel complext naar de LCD aan het sturen. en word de Engine telaat gedraait zo dat je Delay ziet.
en variable hebben een aparte ID en als hij bij MAX id is dan word alles weer op “0” gezet zo dat hij blijft updaten.
Dus als ID[0] == 0 Updaten!!!
en als ID[0] == 1 Oke heb ik al gedaan op naar de volgende.

maar deze manier voelt gewoon niet goed.

zowel de chaser als de tft hoeven alleen herschreven te worden als er iets verandert, en zelfs dan alleen de waarde veranderen die nodig is.

werkt al op de TFT. behalfe Variable.
alleen de Chaser heeft dat niet, ik werkt nu nog met “worst case scenario”. het moet namalijk altijd goed werken. of ik nouw 3 kanalen verander OF alle 512. daarom update ik alle 512 ALTIJD!
en voor de test gebruik ik 6 PWM kanalen.

Maar ik heb ook zo veel mogelijk ISR’s uitgezet.
ISR (0) A0 = Milis, micros, Deze staat aan.
ISR (3) B0 = Engine/chaser
ISR (7,8)C1,C2 = en een andere weet effe niet welke (A0 of B0) gebruik ik voor bedug PWM 13 tot 8

ISR A1, A2, B1, B2, C0 staan allemaal uit.
maar meschien zijn er wel meer waar ik de bestaan niet van afweet.

maar voor de duidelijkheid ik waardeer het enorm dat jullie allemaal mee denken.
en antwoorden geven :slight_smile: