Thread per sperimentazione sistema minimo LINUX su Microcontrollore

La Raspberry ha un SOC abbastanza complesso, non è l'ideale per partire con un LOW level.

La board OLIMEX ha un processore classico, sufficientemente veloce, ma allo stesso tempo non troppo complicato per tirare su un sistema minimale, per giocare con GPIO e SPI.

La Raspeberry va bene per giocare al piccolo Linux, ma lato riga di comando o cmq ad alto livello.

Infatti, la penso anche io come Mauro Laurenti: ocio, eh!

Per Windows ? Sai cosa, hai bisogno del retaggio GNU per compilare il kernel, non solo di GCC ma di tanti altri tools, per cui … tecnicamente potresti usare un supporto UNIX per Windows (Cywin o simile, io pero' mai usato), e sbolognartela da li, pero' … a me sa tanto di pantano.

ARM ha diversi profili Target (come le mie MIPS, ho anche le MIPS64, con o senza estensioni SIMP) , dipende anche dalla libc che andrai ad usare poi sul target (glibc vs uclibc, a un impatto di profilo anche sul cross compiler, oltre che su tutti i linker script), per cui … vero che la rasp e' una ARM che compila nativo per ARM, bisogna vedere se la ISA della cadrega e' dello stesso tipo, della stessa classe, ecc, insomma dello stesso profilo, altrimenti … ti tocca comunque crearti un cross compiler.

Stai facendo un grosso errore, ovvero stai mettendo sullo stesso piano linux con p.e. freeRTOS: le differenza tra i due sono numerose ed abissali. In particolare c'e' un fatto che non vorrei sfuggisse: linux ha strati e strati di codice tra l'hw e lo userspace, e sei OBBLIGATO a separare i due perche' linux funziona a processi (oltre al fatto che linux separa kernel space da userspace a MUST), freeRTOS non separa kernel space da userspace e funziona a task, compilati statici, gia' solo questo impatta su tutti gli oggetti che servono alle applicazioni per interfacciarsi ai driver, infine all'hw.

Insomma, lassa sta quel discorso entry-level, e' sbagliato a priori, e comunque con linux la App l'hw lo gestiesce dallo userspace attraverso i punti "caldi" con il kernel (p.e. i devname, oppure le interfacce lan)

Beh ma la cadrega che hanno in Laboratorio, il ColdFire a 200 MHz, non credo che ci voglia tutta questa scienza per farlo andare (smazza un pò di servizi I/O, un piccolo Display OLED e fornisce un pò di supporto a una FPGA). Tra l'altro i 2 Ingegneri che ci lavorano, non mi sembrano dotati di "impressionanti conoscenze", tuttaltro! In qualche modo avranno fatto anche loro. In realtà ho capito che hanno dei moduli che loro usano come "Black box", ossia li prendono così-come-sono, senza farsi troppe domande, e poi li mettono insieme.

A questo punto che approccio mi consigli? Smanettare installando qualcosa di già pronto?

Il discorso di mettere il naso nei driver per SPI e I2C, senza integrarli nel kernel, ma come moduli separati, e poi smanettarci dentro, non mi sembra una cattiva idea giusto per "aprire la scatola".

Perche' hanno preso il kernel support gia' fatto e/o simile (tradotto quando fornisce freescale) e lo hanno adattato, ovvero il consiglio che ti ho dato in prima pagina. Tu volevi fare LOW level, e questo e' ben diverso, per l'appunto.