Free Software User Group Italia :: Forum

cancellato quanto scritto da hapWaisse, un troll, che ha imbrattato anche la ses hardware con suo particolare senso dell'umorismo

Se puoi cambia il topic, che sennò ci entra nei search engine

fatto

e cosi' recuperiamo il thread x parlare di un kernel x sistemi embedded: qualcuno lo usa ?

No, non lo conoscevo, tu hai info in merito???

MicroC/OS-II (molto spesso scritto "µC/OS-II" o "uC/OS-II") e' un kernel orientato ad hw mmu-less per obiettivi embedded; si colloca tra i kernel (soft)-realtime che consumano poche risorse e cercano di essere quanto + deterministici possibile

piu' in dettaglio:

* low-cost
* priority-based
* pre-emptive
* (soft)-real time
* multitasking kernel
* linear memory mapping
* mmu less
* scritto al 95% in C, BSP in asm SOLO quando none' possibile diversamente
* orientato agli embedded systems.

Fece la prima comparsa circa nel 1992, in un aricocolo pubblicato su "Embedded Systems Programming magazine", oggi, rivisto e corretto nella major version 2, poi, visto l'interesse, da allora viene documentato nel libro "µC/OS The Real-Time Kernel" Jean J. Labrosse ISBN 0-87930-444-8. Fin da subito ucos/2 fu concepito ed inteso con l'intento di essere semplice, ben documentato negli algoritmi interni, ed altamente portabile su hw a basso costo, addirittura mmu-less.

Di commit in commit le promesse sono state mantenute, di ucos/2 ne esiste dunque un libro che ne racconta in dettaglio i sorgenti, gli stessi sono aperti se per uso didattico, vanno pagati diritti alla Micrium Inc. se per uso commerciale

Con il passare degli anni Labrosse giro' parte del supporto a Micrium.inc, la quale fornisce anche supporto aggiuntivo

* uC/OS-View
* uC/CAN
* uC/TCP-IP
* uC/FS
* uC/GUI
* uC/MOD-BUS
* uC/LCD
* uC/USB (Mass Storage Device and Bulk)
* uC/TCP-IP apps[]={[DHCP, POP3, SNTP, FTP, TFTP, DNS, SMTP, TTCP}, {HTTP, FTP, TFTP, PPP}}


una lista dei port disponibili: http://www.micrium.com/products/rtos/kernel/ports.html


io ne sto studiando i sorgenti nell'eventualita' di un porting

* target = 68hc11
* platform = tinyboard-proto-68hc11
* toolchain= gcc-m6800-3.4.6

Di che tipo di hardware parliamo indicativamente....?

Ti dispiace se ripubblichiamo la tua presentazione sul nostro wiki (o se vuoi fallo tu che almeno si vede che è opera tua)?

no problema fai pure


parliamo di hw
* senza necessita' di avere mmu (puo' anche averla, non verra' minimamente usata)
* tanto (semplificando al max) lo scheduling passa per task statici
* niente memoria protetta, niente memoria virtuale
* hw di ridotte risorse, principalmente poca ram
* noMMU, poca ram -> ucLinux fa MOLTA fatica a girare, in ogni caso sbrodelando quelle poche risorse x niente
* richieste (soft)-realtime nelle constraints, scheduling deterministico (e nuovamente uclinux NON va bene)
* quindi parliamo di hw tipo microcontrollori, cpu embedded (core + periferiche integrate)
* di un kenrel disegnato x app custom
* avere un kernel che permette il porting di app dal mondo *NIX non ha troppo senso
* le app in commessa solitamente vanno ridisegnate da capo, appunto xke' custom


68hc11 e' un core 6800 (con 2 zeri, 68000 con 3 zeri e' una altra arch, parente ma diversa)
un microcontrollore con pochi registri interni tutti ad 8 bit e con 32Kbyte di ram indirizzabile linearmente ... seriale uart interna e una manciata di GPI/O su cui implementare un bus i2c, spi, e LCD


ultimamente si punta ad hw a 32bit, sempre in taglio embedded

fra questi va ricordato che si sta puntanto massivamente ad arm di classe strongarm, xscale, cortex .... tutte arch che volendo potrebbero supportare anche linux (linux, non uclinux, cioe' hanno MMU, magari leggerotta con poca cache ma cmq costa orami "poco' fornirla) ... ma che per risicare i costi di ram &C (in cerci casi anche il piccolo costo della MMU, che tanto non serve) e rientrare nelle constraints si preferisce nuovamente usare kernel RTOS (opensource) oppure .... ucos/2 con supporto Microrium

Io l'ho provato nell'ambito del corso di "Tecniche d'acquisizione dati 1"... Il prof. aveva portato un paio di libroni di Labrosse, uno riguardante questo kernel e l'altro su una libreria di funzioni che ci si può usare. Comunque l'ho guardato soltanto a scopo didattico (i sorgenti si leggono bene ed il librone di Labrosse è chiaro) e "operativamente parlando" non ho fatto più di far girare qualche demo sotto Linux.

penso che non sarebbe male portarlo -in pratica- su qualche hw embedded, tipo questa homemade 68hc11tinyboard =P

sotto linux ... compilato come app, umm che demo hai/avete visto ? (non nascondo che essente stato citato a "Tecniche d'acquisizione dati 1" la cosa ingolosisca =P c'e' qualche url supp didattico di quel corso ? curiosita' )

Non mi ricordo di preciso ma erano delle demo incluse nel porting, robette sceme con qualche task del tipo "hola mundo". Purtroppo il prof non ha messo online alcun materiale (ed io non ho preso appunti!); l'unica cosa tangibile di quel corso era proprio il libro di Labrosse che gli ho scippato per qualche giorno.

il vero problema di un kernel come questo e' sviluppare app (o meglio i tasks di cui e' composta), perche' non e' cosi' facile e scontato come sembra. Ecco xke' chiedevo circa le demo/promo/esempi

c'e' anche un problema di dev-chain, basarsi su gcc/gnu non e' cosi' scontato: spesso i port di ucos/2 sono basati su altre toolchain (spesso colossi come TI-codecomposer, o CodeWarrior, Sierra, DIAB, ecc) e spesso queste introducono fastidiose direttive dilettali (o forse son dialettali le direttive asm gnu, punti di vista)

ho preso un port esistente e ne ho adattato progressivamente le direttive alla toolchain (confezionata per host=ppc, target=68hc11-unknown-platform) disegnando il memory map specifico per la mia platform (la board finale), quindi confezionando il memorylayer script per il linker che andra' cosi' a sfornare il formato binario giusto mappando nel modo e nel posto giusto giusto (giusto per quella platform) i vari segmenti di codice

ora provo a portare quel kernel sulla 68hc11-tinyboard andando a sviluppare progressivamente i task e i (pochi) driver della app finale: nodo di acquisizione ed pre-elaborazione dati microsismici

in progetto avrei anche, come accennavo qua e la in thread come quello di haiku o aros, in progetto avrei anche, a tempo perso, una board 68060 con poche e stringate risorse ... solo 8Mb di ram, 2 seriali, 1 parallela ... e c'e' da sviluppare l'hw aggiuntivo (fra l'altro su un bus motorola particolare): ethernet, linear non volatile memory storage (4x8Mb) ... forse anche una interfaccia ATA: nel caso bisognerebbe sviluppare codice VHDL per le CPLD che implementerebbero l'hw aggiundo, infine sviluppare il kernel (quale? va scelto un kernel, forse ucos/2 va bene), sviluppare i driver ... infine i tasks di una app finale che in questo caso non e' ben disegnata nelle specifiche essendo questa una "commessa hobbistica"




ultimo passo: confezionare anche un case che renda che renda ragione di un design hobbistico sperimentale