Il mercato embedded è estremamente dinamico e si appoggia a prodotti hardware in continua e rapida evoluzione, microprocessori in testa.
Il mercato embedded è estremamente dinamico e si appoggia a prodotti hardware in continua e rapida evoluzione, microprocessori in testa.
Il mercato embedded è estremamente dinamico e si appoggia a prodotti hardware in continua e rapida evoluzione, microprocessori in testa.
Un RTOS che può essere trasferito su più piattaforme target può fare la differenza sul medio e lungo termine quando l’hard-ware del sistema embedded sarà diventato obsoleto e sarà necessario passare ad un diverso processore. La portabilità è un aspetto correlato ed altrettanto importante: i primi RTOS venivano realizzati direttamente in Assembly al fine di sfruttare al massimo le prestazioni dell’hardware sottostante; ma trasferire il codice su un altro microprocessore poteva significare dover riscrivere buona parte del sistema da zero, oltre che dover investire del tempo nell’apprendimento del nuovo linguaggio macchina. Il passaggio a linguaggi a più alto livello di astrazione ma pur sempre dotati di costrutti vicini allo strato hardware, come il C, ha permesso di incrementare notevolmente la portabilità del software delegandone le difficoltà al compilatore. Questo tipo di approccio ha consentito ai produttori di sviluppare moduli di crescente complessità per l’implementazione di funzionalità di file-system, di connettività in rete e di interfacciamento grafico. Resta comunque prassi comune riscrivere in Assembly quelle porzioni di codice dalla cui ottimizzazione si possono trarre vantaggi consistenti in termini di prestazioni. E se l’applicazione è sufficientemente contenuta può essere vantaggioso realizzare il proprio sistema operativo proprietario senza ricorrere ai prodotti off-the-shelf.
La questione della portabilità può essere vista anche in termini del software che realizza l’applicazione sfruttando i servizi offerti dal sistema operativo.
Non esiste uno standard vero e proprio e lo sviluppatore può generalmente adottare il linguaggio di proprio gradimento tra quelli messi a disposizione dall’ambiente di sviluppo e compatibili con la piattaforma target. Per ovvi motivi il più diffuso è il C, anche se la possibilità di sfruttare la programmazione ad oggetti rende il C++ una valida alternativa.
L’adesione ad uno standard comune come POSIX permette di ridurre la quantità di modifiche da apportare e consente agli sviluppatori di concentrarsi su una sintassi uniforme, appoggiandosi anche ad una API (Application Programming Interface) standard. Sfortunatamente POSIX non è esente da difetti, primo fra tutti quello di non essere stato pensato per la realizzazione di sistemi operativi in tempo reale, onde per cui un RTOS completamente conforme a questo standard vedrebbe compromesse le sue capacità di essere impiegato in sistemi hard real-time.
I tempi di latenza risultano infatti accresciuti dal fatto che routine che richiederebbero due chiamarne ad un RTOS proprietario arriverebbero a chiamarne oltre dieci in un sistema operativo conforme a POSIX.
Per minimizzare questo tipo di inconvenienti certi produttori limitano la conformità allo standard alle sole sezioni che riguardano i servizi in tempo reale, spesso implementandole solo parzialmente in modo da non incidere sulle prestazioni.