Cos'è ElectroYou | Login Iscriviti

ElectroYou - la comunità dei professionisti del mondo elettrico

Ricerca personalizzata

Come si progetta un programma per RTOS?

Raccolta di codici sorgenti

Moderatore: Foto UtentePaolino

0
voti

[1] Come si progetta un programma per RTOS?

Messaggioda Foto Utentepusillus » 14 lug 2017, 18:05

Premetto che mi reputo un ignorante che si sforza di conoscere cose nuove pur avendo lacune enormi di matematica, informatica, fisica e tutto il resto... perdonatemi se i miei dubbi potrebbero apparire sciocchi.

Da qualche tempo sto leggendo dei tutorial su RTX. Gli esercizi sono molto semplici e ho capito come sevirmi di signals, messaggi, semafori, etc. per far interagire i tasks tra di loro.
Nello sviluppo di un programma quale è il metodo da seguire?
Ci sono dei diagrammi che riescono a rappresentare le varie interazioni tra i processi sui quali basarsi per poi sviluppare il codice ?
Avatar utente
Foto Utentepusillus
630 1 10
Frequentatore
Frequentatore
 
Messaggi: 195
Iscritto il: 5 mar 2016, 14:19

5
voti

[2] Re: Come si progetta un programma per RTOS?

Messaggioda Foto UtenteGuidoB » 15 lug 2017, 1:43

pusillus ha scritto:Nello sviluppo di un programma quale è il metodo da seguire?

Domanda difficile a cui non c'è una risposta univoca.
Di solito si procede top-down, cioè si divide un problema in sottoproblemi più semplici e dettagliati, ogni sottoproblema in sotto-sotto-problemi e così via, finché si arriva a problemi semplici, con un livello di dettaglio tale da poter passare direttamente alla codifica in un linguaggio di programmazione.

Però al giorno d'oggi non è frequente partire da zero. Di solito si tratta di aggiungere qualcosa a un software già funzionante. Per questo lo sviluppo è fortemente influenzato dalla struttura del codice esistente. Se è ben fatta è un piacere lavorarci, se è mal fatta sono dolori e frustrazioni.

pusillus ha scritto:Ci sono dei diagrammi che riescono a rappresentare le varie interazioni tra i processi sui quali basarsi per poi sviluppare il codice ?

È un discorso ampio e in costante evoluzione.
L'Ingegneria del software si occupa anche di questa modellizzazione.
Ci sono stati vari tentativi di modellare e schematizzare in modo chiaro e senza ambiguità il funzionamento del software.

Una volta si usavano i diagrammi di flusso o flow-chart, oggi abbastanza superati.

Altri schemi più recenti (ciascuno applicabile più proficuamente a una categoria specifica di software o a una diversa "vista" del suo funzionamento) sono, per esempio, i diagrammi di sequenza, le macchine a stati e le reti di Petri.

C'è poi l'UML (Linguaggio Unificato di Modellazione) che cerca di mettere insieme molti di questi schemi in diversi tipi di diagrammi grafici non ambigui.
Per esempio, le macchine a stati gerarchiche UML (Statecharts) hanno dei simboli grafici specifici che indicano stati, transizioni, guardie (condizioni), sottostati ecc., e ci sono tool per disegnarle, controllarne la correttezza, simularne il funzionamento e anche generare automaticamente codice in C o C++ (vedi questo per esempio).

È tantissima roba che va studiata con calma e costanza, un pezzo alla volta, su buoni libri (come questo di Miro Samek, di 700 pagine, in inglese, sull'implementazione delle macchine a stati gerarchiche UML in C e C++, scaricabile gratuitamente). Ci vogliono anni, e per capire bene bisogna utilizzare questi concetti sul lavoro, come in un continuo esercizio. Imparare ad utilizzare bene l'UML lo vedo come un necessario completamento all'imparare a programmare bene in C, C++, Java o altri linguaggi.

Poi purtroppo c'è anche da dire che tutte queste belle schematizzazioni richiedono un pensiero ordinato e un'alta specializzazione, mentre oggi il software in tante ditte lo fanno persone con scarsa preparazione, di fretta, in disordine e all'insegna del risparmio a breve termine. Questo software di bassa qualità è pieno di errori che richiedono urgenti e costosi interventi di correzione, è inefficiente, difficile da capire, da correggere e da far evolvere, e crea insoddisfazione nei clienti. I costi di esercizio e manutenzione a lungo termine sono molto elevati. In queste ditte di UML non s'è mai sentito parlare, non c'è la capacità di utilizzarlo e alcune non ne vogliono neanche sapere.

Nonostante questo, conoscere l'UML (almeno un po') aiuta a ragionare e ad applicare i suoi concetti quando si presenta l'occasione, invece di dover "inventare" per necessità schemi primitivi, incompleti e ambigui.
Big fan of ƎlectroYou! \O-<
Avatar utente
Foto UtenteGuidoB
12,7k 5 12 13
G.Master EY
G.Master EY
 
Messaggi: 1866
Iscritto il: 3 mar 2011, 15:48
Località: Madrid

1
voti

[3] Re: Come si progetta un programma per RTOS?

Messaggioda Foto Utentepusillus » 15 lug 2017, 7:27

Ti ringrazio molto per la risposta così articolata. È un argomento che è fuori della mia portata. Magari avere tempo da investire per poter imparare anche un minimo :(
Dato che, nel mio caso, i programmi non saranno così complessi, non mi rimane che scomporre tutto in piccoli problemi. Più o meno è come stavo procedendo:
Sto facendo uno stupido robottino che ha il sensore sonar due ruote con motore ed un lettore mp3. Un task si occupa del sonar ,uno del mp3 e poi c'è il task "Brain" che sincronizza e prende le decisioni su come agire ....

Sono solo contento che la mia domanda non era poi così stupida!
Avatar utente
Foto Utentepusillus
630 1 10
Frequentatore
Frequentatore
 
Messaggi: 195
Iscritto il: 5 mar 2016, 14:19

1
voti

[4] Re: Come si progetta un programma per RTOS?

Messaggioda Foto UtenteWALTERmwp » 3 ago 2017, 15:00

Oltre a quanto riportato da @GuidoB, di estremo interesse, io suggerirei di prendere un RTOS, il più essenziale possibile, se c'è(open), e "studiarlo", magari utilizzarlo per il proprio progetto, apportandovici modifiche, variazioni, così da sperimentare, vedere di conseguenza cosa succede.
Credo sia un modo, anche indiretto, per provare ad assimilare principi e concetti generali, propri d'un RTOS.
Questo approccio potrebbe stare tra il partire dal nulla e utilizzarne uno in modo acritico e consentirebbe, forse, di rendersi conto quali sarebbero le esigenze di un programma dato in pasto a un sistema operativo.

Saluti
Avatar utente
Foto UtenteWALTERmwp
16,6k 4 8 13
G.Master EY
G.Master EY
 
Messaggi: 5143
Iscritto il: 17 lug 2010, 17:42
Località: le 4 del mattino


Torna a Firmware e programmazione

Chi c’è in linea

Visitano il forum: Nessuno e 2 ospiti