SO VS Hardware puro .. chi è a mediare?

[Desartstudio]

MA chi mi spiega quale il layer che divide un SO dall'hardware puro?

Quali interfacce vanno implementate sul fw della board ?
oppure è il SO che implementa le istruzioni per gestire l'hw?
se si .. quali sono le linee guida a quel punto sull'hardware ?

Scusate le domande ignoranti ma mi incuriosisce molto e non ho ben capito cosa cercare per avere risposte.

grazie

[GuidoB]

Domanda tosta.

Io la vedo così: l'interfaccia del sistema operativo con l'hardware è parte del sistema operativo.

Se il S.O. è fatto bene, questa interfaccia è organizzata come uno "strato" (layer).
Se si vuole portare il S.O. su un altro HW, basta (in teoria) cambiare questo strato. Questo è uno dei benefici di confinare l'interfaccia in uno strato (e non sparpagliarla dentro tutto il S.O.).

Se esiste un "porting" di quel S.O. a una certa piattaforma HW, allora lo strato di interfaccia è già stato adattato a quell'hardware.

Che cosa c'è dentro lo strato di interfaccia? Bè, in generale ci saranno funzioni che "nascondono" le particolarità dell'hardware e permettono di accedervi con comode funzioni dai parametri standardizzati (esempio: far uscire un certo livello logico da un piedino, o un byte da una porta seriale, far partire un timer). Dovranno esserci anche funzioni che permettono la "subscription" (abbonamento) di altre funzioni (generalmente gestori di interruzione) agli eventi segnalati dall'hardware (esempio: è cambiato un livello logico su un piedino di ingresso, è arrivato un byte su una porta seriale, è terminata la scrittura su una EEPROM, è scaduto un timer). Oppure si salta a piè pari la subscription e si implementano i gestori di interrupt direttamente come parte del layer di interfaccia.
Molte di queste funzioni si considerano parti di "device drivers".
Il tema non è per nulla banale, non lo conosco nei dettagli e spero di non aver scritto qualche castroneria.

Per i dettagli dovresti andarti a studiare gli strati bassi del porting di qualche sistema operativo (per esempio freeRTOS) su qualche piattaforma HW che ti interessa.

Buono studio.

[TardoFreak]

Diciamo che progettare qualsiasi programma prevedendo un layer di astrazione hardware dovrebbe essere la regola, indipendentemente che si usi un sistema operativo o meno.

[Desartstudio]

Grazie guidoB mille sei stato molto gentile, credevo anche io qualcosa di simile ma come ipotesi :)
Ora allora approfondisco..
Quello che vorrei fare è far girare una debian, per essere precisi la versione per raspberry, quindi già per ARM, sull'STM32 che è sempre un cortex M3 montato su una scheda custom .. ma credo che per ora rimanga nel cassetto fin quando non finisco di studiare bene l'architettura dei micro in questione...

TardoFreak, certamente, io non mi intendo di elettronica, ci "spippolo" ma delle volte vado avanti per tutorial senza cognizione di causa :), software invece lavoro come senior/architetto, quindi non vedo l'ora di capire dove e come mettere mano, o meglio codice :) sul micro per provare a fare qualcosa di concreto .. ho sempre lavorato in .Net ma da un paio di anni avevo la scimmia di capire cosa c'era sotto .. e di abbassarmi a un layer inferiore per capire realmente le cose .. sembra sia venuto il suo tempo ;)

grazie a entrambi.. mi dispiace solo non valutare i vostri post che ho una reputation troppo bassa essendo nuovo

[TardoFreak]

.Net, per quel poco che conosco, implementa un layer per l' astrazione hardware ma non mi sono mai interessato all' argomento perché si, lavoro principalmente con i Cortex-M3 ma in modo, diciamo tradizionale per massimizzare le prestazioni e poter scegliere il taglio più conveniente in termini di costi.
Ho anche usato sistemi operativi real time ma rimanendo "sul leggero" sempre per motivi di prestazioni.

[Desartstudio]

io stò cercando di sviluppare una soluzione custom, l'hw è stato realizzato da un mio amico, ma non ha tempo di realizzarmi anche il sw... quindi me lo stò studiano io .. anche se la vedo una cosa lunga...

Anzi se può interessarti ti scrivo in privato, abbiamo utilizzato il stm32f103rb (questo esclude il fatto SO è solo acquisizione)

[TardoFreak]

Lo conosco molto bene. E' un bellissimo micro.

[xyz]

Quello che vorrei fare è far girare una debian, per essere precisi la versione per raspberry, quindi già per ARM, sull'STM32 che è sempre un cortex M3 montato su una scheda custom

La Debian è una distribuzione Linux, contiene il sistema operativo Linux. Tra gli innumerevoli compiti del sistema operativo c'è quello di astrarre hardware e di fornire un sistema di interscambio tra il kernel space e lo user space per permettere a chi ha i permessi di accedere nel modo consentito al hadrware presente.

Ti stai confondendo sulle architetture ARM e famiglie. STM32 è un ARM Cortex-M3 (gli ultimissimi modelli sono Cortex-M4F) mentre la Raspberry-Pi usa un chip della Broadcom un BCM2835 famiglia ARM11 architettura ARMv6 (la cosa più difficile degli ARM non è hardware ma sono i nomi ). Tra STM32 e BCM2835 c'è un abisso, il primo ha una architettura Harvard il secondo Von Neumann, solo col secondo puoi farci girare un Linux vaniglia, il primo non ha abbastanza risorse per contenere tutto il sistema operativo.

[Desartstudio]

Ti stai confondendo sulle architetture ARM e famiglie.

No no non mi confondo .. è che sono proprio ignorante in materia!

Grazie chiarissimo ..
ora guardo anche vaniglia... in rete ho trovato anche altre 2 versioni .. bho!
Comunque non era un bisogno, volevo solo capire l'effettiva fattibilità :)

[xyz]

Scusa volevo scrivere "Linux vanilla" e mi è scappato il nome in italiano E' la versione originale del Kernel di Linux senza nessuna modifica, è quella che si scarica direttamente dal sito https://www.kernel.org o dal repository via GIT.

Ho cercato in giro, utilizzando una versione ridotta di Linux, la uCLinux è possibile far girare Linux ridotto in un Cortex-M3 ma devi per forza espandere la memoria:

http://www.linux-arm.org/LinuxKernel/LinuxM3
http://www.uschema.com/uclinux-na-stm32/ (sito Russo)