GNU/Linux >> Linux Esercitazione >  >> Linux

4 strumenti per la creazione di sistemi Linux embedded

Linux viene distribuito in una gamma di dispositivi molto più ampia di quanto Linus Torvalds avesse previsto quando ci stava lavorando nella sua stanza del dormitorio. La varietà di architetture di chip supportate è sbalorditiva e ha portato a Linux in dispositivi grandi e piccoli; da enormi mainframe IBM a minuscoli dispositivi non più grandi delle loro porte di connessione e tutto il resto. Viene utilizzato nei data center di grandi dimensioni, nei dispositivi dell'infrastruttura Internet e nei sistemi di sviluppo personale. Alimenta anche elettronica di consumo, telefoni cellulari e molti dispositivi Internet of Things.

Quando creano software Linux per dispositivi desktop e di classe enterprise, gli sviluppatori in genere utilizzano una distribuzione desktop come Ubuntu sulle loro macchine di build per avere un ambiente il più vicino possibile a quello in cui verrà distribuito il software. Strumenti come VirtualBox e Docker consentono un allineamento ancora migliore tra gli ambienti di sviluppo, test e produzione.

Cos'è un sistema integrato?

Wikipedia definisce un sistema embedded come:"Un sistema informatico con una funzione dedicata all'interno di un più ampio sistema meccanico o elettrico, spesso con vincoli di calcolo in tempo reale".

Trovo abbastanza semplice dire che un sistema embedded è un computer che la maggior parte delle persone non considera un computer. Il suo ruolo principale è quello di fungere da dispositivo di qualche tipo e non è considerata una piattaforma informatica generica.

Più risorse Linux

  • Comandi Linux cheat sheet
  • Cheat sheet sui comandi avanzati di Linux
  • Corso online gratuito:Panoramica tecnica RHEL
  • Cheat sheet della rete Linux
  • Cheat sheet di SELinux
  • Cheat sheet dei comandi comuni di Linux
  • Cosa sono i container Linux?
  • I nostri ultimi articoli su Linux

L'ambiente di sviluppo nella programmazione dei sistemi embedded di solito è molto diverso dagli ambienti di test e produzione. Possono utilizzare diverse architetture di chip, stack software e persino sistemi operativi. I flussi di lavoro di sviluppo sono molto diversi per gli sviluppatori embedded rispetto agli sviluppatori desktop e web. In genere, l'output della build consisterà in un'intera immagine software per il dispositivo di destinazione, inclusi il kernel, i driver del dispositivo, le librerie e il software applicativo (e talvolta il bootloader).

In questo articolo presenterò un'analisi di quattro opzioni comunemente disponibili per la creazione di sistemi Linux embedded. Darò un'idea di com'è lavorare con ciascuno di essi e fornirò informazioni sufficienti per aiutare i lettori a decidere quale strumento utilizzare per il loro design. Non ti insegnerò come usarne nessuno; ci sono molte risorse di apprendimento online approfondite una volta che hai ristretto le tue scelte. Nessuna opzione è adatta a tutti i casi d'uso e spero di presentare dettagli sufficienti per indirizzare la tua decisione.

Yocto

Il progetto Yocto è definito come "un progetto di collaborazione open source che fornisce modelli, strumenti e metodi per aiutarti a creare sistemi personalizzati basati su Linux per prodotti embedded indipendentemente dall'architettura hardware". È una raccolta di ricette, valori di configurazione e dipendenze utilizzate per creare un'immagine runtime Linux personalizzata su misura per le tue esigenze specifiche.

Divulgazione completa:la maggior parte del mio lavoro su Linux embedded si è concentrato sul progetto Yocto e la mia conoscenza e la mia predilezione per questo sistema saranno probabilmente evidenti.

Yocto utilizza Openembedded come sistema di compilazione. Tecnicamente i due sono progetti separati; in pratica, tuttavia, non è necessario che gli utenti comprendano la distinzione e i nomi dei progetti sono spesso usati in modo intercambiabile.

L'output di una build di un progetto Yocto consiste sostanzialmente di tre componenti:

  • Binari di runtime di destinazione: Questi includono il bootloader, il kernel, i moduli del kernel, l'immagine del filesystem di root. e qualsiasi altro file ausiliario necessario per distribuire Linux sulla piattaforma di destinazione.
  • Feed del pacchetto: Questa è la raccolta di pacchetti software disponibili per essere installati sul tuo target. Puoi selezionare il formato del pacchetto (ad es. deb, rpm, ipk) in base alle tue esigenze. Alcuni di essi possono essere preinstallati nei binari di runtime di destinazione, tuttavia è possibile creare pacchetti per l'installazione in un sistema distribuito.
  • SDK di destinazione: Si tratta della raccolta di librerie e file di intestazione che rappresentano il software installato sulla destinazione. Vengono utilizzati dagli sviluppatori di applicazioni durante la creazione del codice per assicurarsi che siano collegati alle librerie appropriate

Vantaggi

Il progetto Yocto è ampiamente utilizzato nel settore e ha il sostegno di molte aziende influenti. Inoltre, ha una vasta e vivace comunità di sviluppatori e un ecosistema che contribuisce a questo. La combinazione di appassionati di open source e sponsor aziendali aiuta a guidare il progetto Yocto.

Ci sono molte opzioni per ottenere supporto con Yocto. Ci sono libri e altro materiale di formazione se desideri fare da te. Molti ingegneri con esperienza in Yocto sono disponibili se desideri assumere competenze. E molte organizzazioni commerciali forniscono prodotti chiavi in ​​mano basati su Yocto o implementazione basata su servizi e personalizzazione per il tuo design.

Il progetto Yocto è facilmente espandibile attraverso livelli, che possono essere pubblicati indipendentemente per aggiungere funzionalità aggiuntive, a piattaforme target non disponibili nelle versioni del progetto o per archiviare personalizzazioni uniche per il tuo sistema. I livelli possono essere aggiunti alla tua configurazione per aggiungere funzionalità uniche che non sono specificamente incluse nelle versioni stock; ad esempio, il livello "meta-browser" contiene ricette per browser Web, che possono essere facilmente create per il tuo sistema. Poiché sono gestiti in modo indipendente, i livelli possono avere una pianificazione di rilascio diversa (sintonizzata sulla velocità di sviluppo dei livelli) rispetto alle versioni standard di Yocto.

Yocto ha probabilmente il più ampio supporto per dispositivi tra tutte le opzioni discusse in questo articolo. Grazie al supporto di molti produttori di semiconduttori e schede, è probabile che Yocto supporterà qualsiasi piattaforma di destinazione scelta. Le versioni dirette di Yocto supportano solo poche schede (per consentire prove e cicli di rilascio adeguati), tuttavia, un modello di lavoro standard prevede l'utilizzo di livelli di supporto delle schede esterni.

Yocto, infine, è estremamente flessibile e personalizzabile. Le personalizzazioni per l'applicazione specifica possono essere archiviate in un livello per l'incapsulamento e l'isolamento. Le personalizzazioni esclusive di un livello di funzionalità vengono generalmente archiviate come parte del livello stesso, il che consente di applicare le stesse impostazioni contemporaneamente a più configurazioni di sistema. Yocto fornisce anche una priorità di livello ben definita e una capacità di override. Ciò consente di definire l'ordine in cui i livelli vengono applicati e ricercati per i metadati. Ti consente anche di ignorare le impostazioni nei livelli con priorità più alta; ad esempio, molte personalizzazioni alle ricette esistenti verranno aggiunte nei tuoi livelli privati, con l'ordine controllato con precisione dalle priorità.

Svantaggi

Il più grande svantaggio del progetto Yocto è la curva di apprendimento. Ci vuole molto tempo e impegno per imparare il sistema e comprenderlo veramente. A seconda delle vostre esigenze, questo potrebbe essere un investimento troppo grande in tecnologie e competenze che non sono centrali per la vostra applicazione. In questi casi, lavorare con uno dei fornitori commerciali potrebbe essere una buona opzione.

I tempi e le risorse di sviluppo dello sviluppo sono piuttosto elevati per i progetti Yocto. Il numero di pacchetti che devono essere compilati, inclusi toolchain, kernel e tutti i componenti di runtime di destinazione, è significativo. Le workstation di sviluppo per gli sviluppatori Yocto tendono ad essere sistemi di grandi dimensioni. Si sconsiglia l'uso di un notebook compatto. Questo può essere mitigato utilizzando server di build basati su cloud disponibili da molti provider. Inoltre, Yocto ha un meccanismo di memorizzazione nella cache integrato che gli consente di riutilizzare i componenti creati in precedenza quando determina che i parametri per la creazione di un particolare pacchetto non sono cambiati.

Raccomandamento

L'uso del progetto Yocto per il tuo prossimo progetto Linux embedded è una scelta forte. Delle opzioni presentate qui, è la più ampiamente applicabile indipendentemente dal caso d'uso di destinazione. L'ampio supporto del settore, la comunità attiva e l'ampio supporto della piattaforma fanno di questa una buona scelta per i designer imperdibili.

Buildroot

Il progetto Buildroot è definito come "uno strumento semplice, efficiente e facile da usare per generare sistemi Linux embedded attraverso la compilazione incrociata". Condivide molti degli stessi obiettivi del progetto Yocto, tuttavia è incentrato sulla semplicità e sul minimalismo. In generale, Buildroot disabiliterà tutte le impostazioni facoltative in fase di compilazione per tutti i pacchetti (con poche eccezioni degne di nota), risultando nel sistema più piccolo possibile. Spetterà al progettista del sistema abilitare le impostazioni appropriate per un determinato dispositivo.

Buildroot compila tutti i componenti dall'origine ma non supporta la gestione dei pacchetti sulla destinazione. In quanto tale, a volte viene chiamato generatore di firmware poiché le immagini sono in gran parte corrette in fase di compilazione. Le applicazioni possono aggiornare il filesystem di destinazione, ma non esiste alcun meccanismo per installare nuovi pacchetti in un sistema in esecuzione.

L'output di Buildroot è costituito sostanzialmente da tre componenti:

  • L'immagine del filesystem radice e qualsiasi altro file ausiliario necessario per distribuire Linux sulla piattaforma di destinazione
  • Il kernel, il bootloader e i moduli del kernel appropriati per l'hardware di destinazione
  • La toolchain utilizzata per creare tutti i binari di destinazione.

Vantaggi

L'attenzione di Buildroot sulla semplicità significa che, in generale, è più facile da imparare rispetto a Yocto. Il sistema di build di base è scritto in Make ed è abbastanza breve da consentire a uno sviluppatore di comprendere l'intero sistema pur essendo sufficientemente espandibile per soddisfare le esigenze degli sviluppatori Linux embedded. Il core Buildroot generalmente gestisce solo casi d'uso comuni, ma è espandibile tramite script.

Il sistema Buildroot utilizza i normali Makefile e il linguaggio Kconfig per la sua configurazione. Kconfig è stato sviluppato dalla comunità del kernel Linux ed è ampiamente utilizzato nei progetti open source, rendendolo familiare a molti sviluppatori.

A causa dell'obiettivo di progettazione di disabilitare tutte le impostazioni di build-time opzionali, Buildroot generalmente produrrà le immagini più piccole possibili utilizzando la configurazione predefinita. Allo stesso modo, i tempi di costruzione e le risorse dell'host di costruzione saranno inferiori, in generale, rispetto a quelli del progetto Yocto.

Svantaggi

L'attenzione alla semplicità e alle opzioni di compilazione abilitate minime implicano che potrebbe essere necessario eseguire una personalizzazione significativa per configurare una build Buildroot per la propria applicazione. Inoltre, tutte le opzioni di configurazione sono archiviate in un unico file, il che significa che se disponi di più piattaforme hardware, dovrai apportare tutte le modifiche alla personalizzazione per ciascuna piattaforma.

Qualsiasi modifica al file di configurazione del sistema richiede una ricostruzione completa di tutti i pacchetti. Ciò è in qualche modo mitigato dalle dimensioni minime dell'immagine e dai tempi di costruzione rispetto a Yocto, ma può comportare build lunghe mentre modifichi la tua configurazione.

La memorizzazione nella cache dello stato del pacchetto intermedio non è abilitata per impostazione predefinita e non è completa come l'implementazione di Yocto. Ciò significa che, mentre la prima build può essere più breve di una build Yocto equivalente, le build successive potrebbero richiedere la ricostruzione di molti componenti.

Raccomandamento

L'uso di Buildroot per il tuo prossimo progetto Linux embedded è una buona scelta per la maggior parte delle applicazioni. Se il tuo progetto richiede più tipi di hardware o altre differenze, potresti voler riconsiderare a causa della complessità della sincronizzazione di più configurazioni, tuttavia, per un sistema costituito da un'unica configurazione, Buildroot probabilmente funzionerà bene per te.

OpenWRT/LEDE

È stato avviato il progetto OpenWRT per lo sviluppo di firmware personalizzato per router consumer. Molti dei router a basso costo disponibili presso il tuo rivenditore locale sono in grado di eseguire un sistema Linux, ma forse non pronto all'uso. I produttori di questi router potrebbero non fornire aggiornamenti frequenti per affrontare le nuove minacce e, anche se lo fanno, i meccanismi per installare le immagini aggiornate sono difficili e soggetti a errori. Il progetto OpenWRT produce immagini firmware aggiornate per molti dispositivi che sono stati abbandonati dai loro produttori e dà a questi dispositivi una nuova prospettiva di vita.

I risultati principali del progetto OpenWRT sono immagini binarie per un gran numero di dispositivi commerciali. Esistono repository di pacchetti accessibili in rete che consentono agli utenti finali del dispositivo di aggiungere nuovo software ai propri sistemi. Il sistema di build OpenWRT è un sistema di build generico, che consente agli sviluppatori di creare versioni personalizzate per soddisfare i propri requisiti e aggiungere nuovi pacchetti, ma il suo obiettivo principale sono i binari di destinazione.

Vantaggi

Se stai cercando un firmware sostitutivo per un dispositivo commerciale, OpenWRT dovrebbe essere nel tuo elenco di opzioni. È ben mantenuto e potrebbe proteggerti da problemi che il firmware del produttore non può. Puoi anche aggiungere funzionalità extra, rendendo i tuoi dispositivi più utili.

Se il tuo design embedded è incentrato sulla rete, OpenWRT è una buona scelta. Le applicazioni di rete sono il caso d'uso principale di OpenWRT e probabilmente troverai molti di quei pacchetti software disponibili al suo interno.

Svantaggi

OpenWRT impone decisioni politiche significative sul tuo design (rispetto a Yocto e Buildroot). Se queste decisioni non soddisfano i tuoi obiettivi di progettazione, potresti dover apportare modifiche non banali.

È difficile gestire gli aggiornamenti basati sui pacchetti in un parco di dispositivi distribuiti. Questo, per definizione, si traduce in un carico software diverso da quello testato dal team di controllo qualità. Inoltre, è difficile garantire installazioni atomiche con la maggior parte dei gestori di pacchetti e un ciclo di spegnimento intempestivo può lasciare il dispositivo in uno stato imprevedibile.

Raccomandamento

OpenWRT è una buona scelta per progetti hobbisti o per riutilizzare hardware commerciale. È anche una buona scelta per le applicazioni di rete. Se hai bisogno di una personalizzazione significativa dalla configurazione predefinita, potresti preferire Buildroot o Yocto.

Distribuzioni desktop

Un approccio comune alla progettazione di sistemi Linux embedded consiste nell'iniziare con una distribuzione desktop, come Debian o Red Hat, e rimuovere i componenti non necessari finché l'immagine installata non si adatta all'ingombro del dispositivo di destinazione. Questo è l'approccio adottato per la popolare distribuzione Raspbian per la piattaforma Raspberry Pi.

Vantaggi

Il vantaggio principale di questo approccio è la familiarità. Spesso, gli sviluppatori Linux embedded sono anche utenti Linux desktop e sono esperti nella loro distribuzione preferita. L'utilizzo di un ambiente simile sulla destinazione può consentire agli sviluppatori di iniziare più rapidamente. A seconda della distribuzione scelta, è possibile installare molti strumenti aggiuntivi utilizzando strumenti di packaging standard come apt e yum.

Potrebbe essere possibile collegare un display e una tastiera al dispositivo di destinazione ed eseguire tutto lo sviluppo direttamente lì. Per gli sviluppatori che non conoscono lo spazio incorporato, è probabile che questo sia un ambiente più familiare ed elimina la necessità di configurare e utilizzare una configurazione complicata per lo sviluppo incrociato.

Il numero di pacchetti disponibili per la maggior parte delle distribuzioni desktop è generalmente maggiore di quello disponibile per i builder embedded specifici discussi in precedenza. A causa della più ampia base di utenti e della più ampia varietà di casi d'uso, potresti essere in grado di trovare tutti i pacchetti di runtime necessari per la tua applicazione già compilati e pronti per l'uso.

Svantaggi

È probabile che l'utilizzo del target come ambiente di sviluppo principale sia lento. L'esecuzione degli strumenti del compilatore è un'operazione che richiede molte risorse e, a seconda della quantità di codice che stai compilando, potrebbe ostacolare le tue prestazioni.

Con alcune eccezioni, le distribuzioni desktop non sono progettate per ospitare sistemi con risorse limitate e potrebbe essere difficile ritagliare adeguatamente le immagini di destinazione. Allo stesso modo, il flusso di lavoro previsto in un ambiente desktop non è l'ideale per la maggior parte dei progetti incorporati. Ottenere un ambiente riproducibile in questo modo è difficile. L'aggiunta e l'eliminazione manuale di pacchetti è soggetta a errori. Questo può essere script utilizzando strumenti specifici della distribuzione, come debootstrap per i sistemi basati su Debian. Per migliorare ulteriormente la riproducibilità, puoi utilizzare uno strumento di gestione della configurazione, come CFEngine (che, in piena informativa, è realizzato dal mio datore di lavoro, Mender.io). Tuttavia, sei ancora alla mercé del fornitore di distribuzione, che aggiornerà i pacchetti per soddisfare le sue esigenze, non le tue.

Raccomandamento

Diffida di questo approccio per un prodotto che intendi portare sul mercato. Questo è un ottimo modello per applicazioni hobbistiche; tuttavia, per i prodotti che necessitano di supporto, è probabile che questo approccio crei problemi. Sebbene tu possa essere in grado di iniziare più velocemente, a lungo termine potrebbe costarti tempo e fatica.

Altre considerazioni

Questa discussione si è concentrata sulla funzionalità dei sistemi di compilazione, ma in genere ci sono requisiti non funzionali che possono influenzare la tua decisione. Se hai già selezionato il tuo system-on-chip (SoC) o la tua scheda, è probabile che la tua scelta sarà dettata dal fornitore. Se il tuo fornitore fornisce un pacchetto di supporto della scheda (BSP) per un determinato sistema, il suo utilizzo normalmente farà risparmiare un bel po' di tempo, ma ti preghiamo di ricercare la qualità del BSP per evitare problemi più avanti nel ciclo di sviluppo.

Se il tuo budget lo consente, puoi prendere in considerazione l'utilizzo di un fornitore commerciale per il tuo sistema operativo di destinazione. Ci sono aziende che forniranno una configurazione convalidata e supportata di molte delle opzioni discusse qui e, a meno che tu non abbia esperienza nei sistemi di build Linux embedded, questa è una buona scelta e ti consentirà di concentrarti sulle tue competenze principali.

In alternativa, potresti prendere in considerazione una formazione commerciale per il tuo personale addetto allo sviluppo. È probabile che sia più economico di un provider di sistemi operativi commerciali e ti consentirà di essere più autosufficiente. Questo è un modo rapido per superare la curva di apprendimento per le basi del sistema di build che scegli.

Infine, potresti già avere alcuni sviluppatori con esperienza con uno o più sistemi. Se hai ingegneri che hanno una preferenza, vale sicuramente la pena tenerne conto mentre prendi la tua decisione.

Riepilogo

Ci sono molte scelte disponibili per la creazione di sistemi Linux embedded, ognuna con vantaggi e svantaggi. È fondamentale dare la priorità a questa parte del progetto, poiché è estremamente costoso cambiare sistema in un secondo momento nel processo. Oltre a queste opzioni, vengono continuamente sviluppati nuovi sistemi. Si spera che questa discussione fornisca un contesto per la revisione di nuovi sistemi (e quelli menzionati qui) e ti aiuti a prendere una decisione solida per il tuo prossimo progetto.


Linux
  1. Utilizzo di AppImage per la gestione dei pacchetti Linux

  2. 4 strumenti di scansione per il desktop Linux

  3. I migliori strumenti Linux per scrittori

  4. I 5 migliori strumenti di migrazione dei dati per Linux

  5. 8 fantastici strumenti di selezione del colore per Linux

I 12 migliori strumenti di backup open source per sistemi Linux

Alcuni strumenti utili per gli amministratori di sistema Linux

Strumenti Linux:du vs. df

I 20 migliori strumenti di bioinformatica per il sistema Linux

I 15 migliori bootloader Linux per sistemi domestici e integrati

I 15 migliori strumenti di biologia per il sistema Linux