Scheduler ufficiale

e a che serve uno scheduler in un arduino???

vbextreme:
e a che serve uno scheduler in un arduino???

Per servire serve, infatti si crea un surrogato software per supplire alla carenza hardware, però con tutti i limiti del caso.

non ho chiesto se, ma a cosa.

vbextreme:
non ho chiesto se, ma a cosa.

Per gestire vari compiti in "parallelo" oppure attivare un task con ben precisi intervalli, sempre e comunque entro i limiti, abbastanza pesanti, di un AVR.

non ne vedo proprio l'utilità, anzi riesco solo a vederne i problemi che può scaturire.
Bho....Delegare ad un'altro ciò che io posso fare meglio? bha!... quando a volte si cercano complicazioni inutili, stiamo pur sempre parlando di chip a 16mhz.....

vbextreme:
Bho....Delegare ad un'altro ciò che io posso fare meglio? bha!... quando a volte si cercano complicazioni inutili, stiamo pur sempre parlando di chip a 16mhz.....

Pensi davvero di poter gestire in modo ottimale molti diversi compiti, magari qualcuno con temporizzazioni critiche, a manina ?
Io preferisco affidarmi ad un scheduler, seppure minimale e semplice, che mi gestisce le cose in automatico secondo delle regole che imposto io, sopratutto se lo scheduler l'ho scritto io e so esattamente cosa fa.

assolutamente si!
Sui chip single core è sempre da preferire il task singolo per aumentare le performance, la sicurezza e la stabilità.
Dopotutto il parallelismo non esiste su questi core e un qualsiasi scheduler non potrà mai svolgere meglio il compito rispetto ad un cervello allenato, ancor peggio per le sezioni critiche!

vbextreme:
assolutamente si!
Sui chip single core è sempre da preferire il task singolo per aumentare le performance, la sicurezza e la stabilità.

Si come no, infatti io, e tutti quelli come me, che realizzano professionalmente applicazioni su mcu dove girano più task siamo tutti scemi e non abbiamo capito nulla.
Va be' lasciamo perdere che è meglio, tanto io continuo a scrivere software low level e farmi pagare per questo, se mi serve uno scheduler o ne uso uno già pronto, se esiste, oppure me lo scrivo ottimizzato per il caso particolare, non sei certo tu a cambiare lo status delle cose a me a alle migliaia di persone che fanno il mio stesso lavoro.

permalosetto?
non mi pare poi di aver aver affermato che chi usa uno scheduler sia uno scemo o altro, ho semplicemente detto che IO non riesco a capirlo! in tutti i libri che ho letto si parla sempre di come non usare lo scheduler per migliorare il proprio programma e non ho fatto altre che riportarlo.
Invece di scrivere quattro righe di parole inutili di cio che fai te perché non provi a spiegarlo?
O magari un libro dove spiega perché usarlo!

vb stai attaccando la persona sbagliata :slight_smile:

attaccando?
chiedendo!
Mica sono la bocca della verità e se c'è qualcuno che ne sa di più benvenga! ma che dia almeno risposte esaustive magari correlate da libri su cui studiare, a me piace leggere!
Poco mi importa se lui sviluppa space shuttle, a me interessa imparare e se quello che ho letto è sbagliato oppure l'ho appreso male vorrei almeno capire il perché e magari una lettura che possa aiutare.
Se poi questo concetto lo reputi sbagliato amen, sono fatto così!

il concetto e' buono, e' l'approccio che e' sbagliato, se stessimo parlando a voce direi e' il tono di voce sbagliato.
Te lo posso dire da "collega" perche' capita anche a me di fare spesso lo stesso errore.

:slight_smile:

Beh si può dire che qui nessuno è perfetto dal creatore dello space shuttle a colui che vuole imparare ... in ogni caso :
Che utilità può avere uno scheduler su arduino ? Io conosco solo lo scheduler su ia-32 quindi non ne ho la più pallida idea di come funzioni uno scheduler su rtos o su un sistema avr.
Su arduino non ha senso o ha senso lo scheduler ? Se no è perché il salvataggio dei dati su stack è dispendioso se non fatto via hardware ?
Grazie a tutti

oltre al context switch e il suo grosso dispendio di ram che molto probabilmente limita anche a soli5/6 task c'e' anche da considerare la mole di lavoro che deve compiere lo scheduler, potrebbe anche finire che impiega più tempo lo scheduler che il task!
Siamo pur sempre su dei 16mhz con limitatissime risorse RAM, usate per compiere un lavoro e nella stra grande maggioranza dei casi uno scheduler è inutile o almeno alcuni accorgimenti software lo rendono tale.

Magari date un'occhiata al mio qRTOS così capite cosa intendo per uno scheduler minimale, ma molto utile, che può girare su un AVR, o altra piccola mcu 8 bit.

Giusto per la cronaca, gli scheduler e i sistemi multitasking li hanno inventati il giorno prima del primo computer, giusto per rimanere su macchine "piccole", i primissimi personal computer erano basati su Z80 e 6502, un nome per tutti Apple ][, su queste macchina girava un sistema operativo che poteva essere sia monotasking che multitasking, il DOS IBM è derivato dal CPM, il primo sistema operativo veramente efficiente per Z80, del quale esisteva la versione multitasking denominata MPM.
MPM poteva girare, con limitatissime prestazioni, su macchine a singolo processore, lo Z80 non possedeva nessun supporto hardware per il multitasking, sia su macchine multiprocessore, all'epoca i multicore erano ancora fantascienza.

bhe un semplicissimo richiamo di funzioni in maniera sequenziale, non c'è nemmeno una gestione di priorità o altre cose simili, numero task fisso, spreco di memoria sui vari flag booleani mentre si poteva benissimo usare un unico byte, piu che altro sembra un buon punto di partenza su cui poter lavorare e trasformarlo in qualcosa di simile a questo, a riga 113 trovi la definizione di un ADT chiamato WORKER e a riga 890 a 1157 trovi l'implementazione.
Tale mini scheduler è stato progettato per suddividere il processo principale in piu lavori, pensato per i classici eventi del mondo mainstream permette priorità, esecuzioni temporizzate e altre diavolerie simili, se guardi la funzione thr_work_run() si capisce bene quanto possa diventare complesso uno scheduler solo per eseguire un task.
Sarebbe piu interessante vedere un vero context switch su tali architetture.
Hai qualcosa a riguardo?

vbextreme:
bhe un semplicissimo richiamo di funzioni in maniera sequenziale, non c'è nemmeno una gestione di priorità o altre cose simili, numero task fisso, spreco di memoria sui vari flag booleani mentre si poteva benissimo usare un unico byte,

Come si vede che non hai mai lavorato seriamente sulle piccole mcu/micro, non puoi minimamente pensare di usare le stesse tecniche per un PC su una mcu, semplicemente non hai le risorse per farlo.
Intanto il mio qRTOS è a norme MISRA, ammesso che sai cosa sono, non spreca risorse, salvo qualche byte di ram, visto che utilizza il watchdog e il suo interrupt, normalmente non utilizzato su Arduino e anche se lo devi usare per resettare il micro in emergenza la cosa è sempre possibile.
Fin dall'inizio di questo topic ho specificato che gli AVR non hanno nessun supporto hardware per il multitasking, tocca arrangiarsi a software e le possibilità sono limitate, eppure con quel poco che permette un AVR, o altro micro/mcu simile, si possono fare cose molto interessanti, non sempre serve un 32bit superpompato per realizzare una applicazioni, anzi quando si parla di low level le mcu 8 bit si usano spesso e volentieri, magari coordinate da un processore di classe superiore, non a caso la produzione degli otto bit gode di ottima salute, miliardi di pezzi prodotti all'anno tra i vari produttori, e non è in nessun modo minacciata dai 32 bit.
Ci tengo a specificare che il qRTOS è specifico per Arduino, su altri micro mi muovo in modo diverso a seconda di cosa mi mette a disposizione l'hardware, inoltre la quasi totalità del mio lavoro non è certo con gli AVR, uso PIC serie 18 per gli otto bit, dsPIC per il controllo degli attuatori in closed lopp, STM32 per l'high level e sistemi Linux Emdedded, vari modelli, per le GUI locali, gestione di Lan/Wlan, etc.

astrobeed:
... non a caso la produzione degli otto bit gode di ottima salute, miliardi di pezzi prodotti all'anno tra i vari produttori, e non è in nessun modo minacciata dai 32 bit.

ESATTO !!!

Al seminario organizzato da Atmel di qualche settimana fa (... e tu Astro sai di cosa parlo ;)), ci hanno tenuto a specificare che tutta la produzione AVR (ATtiny, ATmega, ecc) è garantita per almeno altri 15 anni (... proprio per l'enorme consumo che se ne fa). :slight_smile:

Guglielmo