Come strutturi grandi progetti incorporati? [chiuso]

Contesto :

Ingegnere elettronico junior R&D ( l'unico EE in azienda ): l'hardware e la codifica non sono il problema. Il mio problema più grande è ottenere una panoramica adeguata del progetto e da dove iniziare.

Finora ho realizzato solo progetti software minori (sotto 500 righe di codice), ma non riesco a immaginarmi di fare progetti più grandi senza perdere la visione d'insieme della funzionalità o la mancanza di funzionalità.

Come struttura migliore / quali strumenti utilizzate per strutturare sistemi software embedded di grandi dimensioni?

Cosa sto facendo attualmente :

Di solito inizio, abbozzando la funzionalità del progetto. Potrebbe essere uno o più diagrammi di flusso a strati o diagrammi correlati (diagrammi a blocchi, ecc.) E fare alcune ricerche sui componenti / chip. Quindi passo subito alla codifica (immagino che fallisca velocemente) facendo riferimento ai fogli dati / Internet, codificando una funzionalità alla volta e testandola con dati fittizi o test simili. Potrebbe scrivere dati su un chip MEM, e quindi se funziona potrebbe essere un driver SPI tra il chip principale e il chip MEM.

Quale risposta sto cercando :

Qualcosa di veramente. Risolverò ciò che trovo sensato. Potrebbe essere un libro, un articolo, esperienza personale, raccomandazioni, ecc.

Sono molto interessato a sapere come gli anziani affrontano questo.

modificare

Prima di tutto, grazie per aver condiviso i tuoi anni di esperienza! Tutte le risposte sono molto apprezzate. La mia opinione su questo è;

• Crea un documento di specifica chiaro e preciso.
• Creare un documento di progettazione software. (Qualcosa che aggiungerò ora) Progetta modelli di documenti
• Pensa in moduli quanto possa sembrare ridondante. (Qualcosa su cui devo concentrarmi maggiormente)
• Seguire uno standard di codifica per strutturare i file di intestazione / sorgente. (Non l'ho mai fatto) Barr Group C standard
• Concentrati innanzitutto sulla creazione di implementazioni di basso livello. (Comunicazione ecc.)
• Implementare modelli di progettazione ove possibile / sensato. Modelli di progettazione
• Imposta qualcosa per il controllo delle revisioni (Github ecc. - mai usato così tanto)
• Ricerca integrazione continua / implementazione continua (Qualcosa di nuovo su cui mi sono imbattuto) Nozioni di base su CI e CD

Esistono diversi aspetti che influenzano il grado di dettaglio necessario alla strutturazione di un progetto. Per me uno dei fattori principali è se sono l'unico codificatore (quello che sembra essere il tuo caso mentre scrivi che sei l'unico EE) o se ci sono altri coinvolti. Quindi c'è la domanda su cosa significhi "grande". Di solito divido il processo di progettazione nei seguenti passaggi:

Definizione dei requisiti Se si ottiene una specifica software adeguata per lavorare con molta pianificazione, è già stata eseguita. Se hai solo requisiti vaghi, la prima cosa che devi fare è risolvere ciò che il cliente vuole effettivamente (a volte non lo sanno davvero in primo luogo). So che è allettante entrare subito nel codice, ma ciò comporta il rischio di perdere una caratteristica importante che potrebbe non essere ovvia in primo luogo e che non può essere semplicemente inserita nel codice proprio da qualche parte nel mezzo dello sviluppo.

Confini del sistema e manutenibilità Nei sistemi embedded spesso si hanno alcune interfacce di sistema, alcune all'esterno (operatore) ma anche all'interno. Definiscili bene e cerca di mantenere le dipendenze più basse possibili, questo semplificherà la progettazione e la manutenibilità continue. Inoltre commenta / documenta il codice dove necessario, non sai mai chi altro dovrà lavorarci, sarà felice di non dover scavare attraverso una dozzina di strati di codice prima di sapere effettivamente cosa fa una funzione.

Definire attività verificabili Soprattutto se altri sviluppatori stanno lavorando sulla stessa base di codice è inevitabile definire attività (funzionalità) chiare e le interfacce richieste tra di loro. Ogni volta che è possibile, le singole funzionalità devono essere testate / verificate indipendentemente dalle altre, è lì che sono necessarie interfacce ben definite in modo da poter definire i casi di test.

Una caratteristica dopo l'altra Alla gente piacciono i progressi, quindi se hai una varietà di compiti di solito lavorano su qualunque cosa prometta il maggior progresso. Di solito cerco di completare un'attività e portarla a uno stato verificato e testato prima di iniziare con quella successiva. Questo consente al tuo codice di essere testato da altri e non finisci per dimenticare qualcosa.

Controllo delle revisioni Durante la vita di un progetto a volte hai bisogno di versioni precedenti, forse per identificare un bug introdotto con qualche nuova versione o semplicemente per costruire un dispositivo che si comporta esattamente allo stesso modo di quello che hai spedito 3 anni fa. Assicurati di avere chiare revisioni di build e tag nel codice. Git è sicuramente tuo amico qui.

Humpawumpa ha scritto un'ottima risposta ! Voglio solo integrare alcuni dei suoi punti, ma poiché questo è troppo lungo per essere un commento, scriverò una risposta separata.

Una volta ero nella posizione del PO - non l'unico EE, ma l'unico EE che aveva fatto qualsiasi sviluppo MCU in una piccola azienda.

Non posso sottolineare abbastanza l'importanza della modularità , anche se sei l'unico sviluppatore. È l'unico modo per rimanere sani man mano che il progetto cresce. Devi essere severo nello scrivere moduli che gestiscono solo un concetto funzionale ciascuno e mantenere le loro interfacce esterne il più minimali possibile. I moduli di alto livello corrisponderanno ai requisiti funzionali, mentre i moduli di basso livello avranno stretti legami con le risorse hardware (ad esempio, i driver di dispositivo).

Ho trascorso molto tempo a mantenere un diagramma dettagliato del flusso di dati ¹ , che mostrava esattamente come i vari moduli condividessero le informazioni. Alcune funzionalità avranno requisiti molto diversi in termini di prestazioni in tempo reale; assicurati di sapere come influenza la condivisione delle informazioni. Il diagramma aveva tracciato dei confini che separavano il codice non-interrupt dai vari domini guidati da interrupt.

¹ Molto diverso da un diagramma di flusso, focalizzato sul flusso di controllo .

Per qualsiasi grande progetto, lo pianifico come se fossero coinvolti più sviluppatori, anche se ho intenzione di fare tutto da solo.

I motivi sono semplici:

1 Complessità. Un grande progetto avrà sempre implicazioni complesse. Avere pianificato il progetto come se fossero coinvolti più team significa che la complessità è stata considerata e documentata . Il numero di volte in cui ho visto grandi progetti incorrere in problemi è elevato e di solito perché qualcosa "è scivolato attraverso le fessure". Non dimenticare che anche l'assemblaggio meccanico deve essere considerato e non semplicemente per le dimensioni della scatola: ci saranno bisogno di dissipatori di calore? La scatola deve essere collegata a terra per sicurezza? Ci sono molte domande solo in questa categoria.

2 requisiti. Supponendo che siano coinvolte più persone, i requisiti di livello superiore (che spesso sfido poiché possono comportare costi e complessità non necessari) devono essere suddivisi in vari compiti più piccoli richiesti e realizzabili (che potrebbero essere inviati a un'altra squadra in un'organizzazione più grande ) piuttosto che guardare solo un singolo blob.

3 Partizionamento. Esistono due tipi principali di partizionamento; funzionalità hardware e hardware / software. Il primo tipo è determinare quali blocchi funzionali separati (ma comunicanti) devono essere presenti. Il secondo è un compromesso tra hardware e software più semplici (a volte), ma tieni presente che semplicemente spostare più cose sul software non risolverà necessariamente un problema hardware. Passare di più al software può effettivamente aumentare notevolmente la complessità dell'hardware in alcune circostanze (maggiore potenza di elaborazione, interfacce più complesse e altro).

4 interfacce. Il processo di partizionamento aiuterà a definire le interfacce interne; le interfacce esterne di solito fanno parte dei requisiti generali (sebbene non sempre). Esistono molti modi per cooperare tra le diverse parti di un sistema che possono essere un protocollo di comunicazione complesso o semplicemente una segnalazione buona / cattiva.

5 Verifica. Questa è una miscela di test a basso livello (per hardware e driver) e livello di sistema. Avere eseguito il progetto in blocchi ben definiti consente una verifica robusta (che può essere mediante analisi o test effettivi e di solito è una combinazione dei due; gli aggiornamenti dei progetti possono utilizzare argomenti di somiglianza).

6 standard. Uso gli standard di codifica e disegno come se fosse una squadra più numerosa. Uso gli standard di codifica del gruppo Barr in quanto non sono troppo onerosi ma impediscono che nel codice siano presenti molte classi di bug. Per la documentazione di output PCB seguo IPC-D-326 (che richiama IPC-D-325) in quanto è un metodo collaudato per comunicare il mio intento ai produttori e agli assemblatori di PCB. Questo può sembrare strano ma avere la disciplina per seguire una serie di standard significa che la qualità è coerente.

7 Controllo versione. Uso il controllo di revisione per tutte le parti del progetto (sistema, hardware, software. Meccanico, requisiti di prova - tutto). Gli strumenti CAD che utilizzo supportano il controllo delle versioni così come tutto il software e gli strumenti di costruzione FPGA.

Ho lavorato su molti progetti incorporati (così come molte delle persone con esperienza qui intorno) e le dimensioni del team sono variate da 1 (me stesso) a dozzine (o centinaia su un determinato insieme di progetti) sparsi tra più discipline e talvolta altre aree geografiche remote siti. Utilizzando lo stesso approccio over-arching (che è noto per funzionare) significa che posso raccogliere un particolare compito in relativo isolamento e completarlo e testarlo a fondo come parte autonoma del progetto più ampio. Significa anche che posso sottoporre alcune cose occasionalmente, se necessario.

Fare tutte queste cose aggiunge un po 'di tempo in anticipo, ma alla fine è un percorso più veloce per sistemi embedded complessi.

Le altre risposte danno molti ottimi consigli. Qui ci sono due che ho trovato il più importante nella mia carriera di sviluppo embedded:

1. Trasforma la maggior parte del codice in moduli separati e ben definiti possibili.
2. Rendi i moduli automaticamente testabili su PC.

Questo è ciò di cui hai bisogno per fare lo sviluppo dello stile di "integrazione continua" sui sistemi embedded. Ci sarà sempre una quantità di codice troppo strettamente legata all'hardware per i test automatici, ma cerca di minimizzarlo. Puoi andare abbastanza lontano usando dati simulati o acquisizioni di dati dall'hardware reale, che poi inserisci nel sistema di test.

Per aggiungere alle risposte esistenti ...

Comincio sempre dal basso verso l'alto. Dal tuo design hardware, sai qual è il tuo I / O. Inizia costruendo moduli driver che incapsulino quell'I / O, in modo che il tuo codice di alto livello non debba conoscere troppo le cose di basso livello.

Quando si creano interfacce di basso livello, ovviamente è necessario un cablaggio di prova. Se si progetta questo per collegarsi al PC dall'inizio (forse con una porta RS-232, forse USB, forse telnet su Ethernet), è possibile mantenere questa interfaccia del cablaggio di test in posizione durante la creazione dell'applicazione. Puoi continuare ad aggiungere più hook di cablaggio di test man mano che l'applicazione prende forma e ciò ti consentirà di testare la regressione del codice mentre prosegui.

Tendo a pensare in quattro domande. I primi due appartengono all'inizio di un progetto di sistemi, i due successivi verso la fine.

1. Vogliono davvero il sistema? Il sistema risolverà il problema dei clienti, in una scala temporale e di costo che accetteranno? Un problema comune è la creazione di sistemi che il cliente non utilizzerà.

2. Possiamo davvero costruire quel sistema? Sarà possibile fornire le prestazioni, la precisione, l'utilizzo di energia necessari, ...?

La creazione dei primi prototipi è un buon modo per rispondere a queste due prime domande. La mitigazione del rischio è estremamente importante nelle prime fasi.

Le prossime due domande sono più mirate alle fasi successive del progetto:

3. abbiamo davvero finito? Tutto progettato, codificato, testato, consegnato

4. Usano davvero il sistema?