ARM annuncia mbed OS: un nuovo sistema operativo per l'internet delle cose

ARM annuncia mbed OS: un nuovo sistema operativo per l'internet delle cose

mbed OS è un sistema operativo per i microcontroller installati nei dispositivi connessi ad internet

di pubblicata il , alle 08:34 nel canale Sistemi Operativi
ARM
 

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

15 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
nist#04 Ottobre 2014, 23:45 #11
Originariamente inviato da: joethefox
allora bocciato. Gli ultimi eventi dovrebbero farci riflettere sul fatto che la vera sicurezza non puo' prescindere dalla possibilità di visionare il codice sorgente, piuttosto e anzichenò.


Se con "ultimi eventi" ti riferisci a Heartbleed e CVE-2014-6277 (peraltro vulnerabilità ampiamente gonfiate a dismisura dai media generalisti, visto che l'intervallo di minaccia di entrambe era molto ma molto stretto) ti faccio solo notare che erano (sono) due vulnerabilità di due software FOSS (uno era un bug di OpenSSL, l'altro di Bash). Sei caduto in un diffuso luogo comune, il software bug-free non esiste, né closed-source né, evidentemente, open.
La testa è il solo strumento in grado di proteggere gli utenti, un idiota su Linux è solo un idiota con un buon sistema operativo. Vice versa, un utente intelligente, anche con un OS di mxxxa, rimane abbastanza sgamato da non farsi fregare
massimo79m05 Ottobre 2014, 20:26 #12
Originariamente inviato da: WarDuck
Embedded spesso è sinonimo di real-time, quindi a meno di versioni particolari, la risposta di cui parli sarebbe decisamente sbagliata.


non e' cosi'. l'internet of things e' rivolto al 90% a elettrodomestici, tv, lettori blueray e roba del genere, dove non serve il real time. i miei vecchi decoder dtt sono java based, per dirne una, e un decoder dtt che registra che ho comprato da pochi mesi, e' java.
controlla bene, moltissimi dispositivi sono java based.

forse confondi "embedded" con "industriale", e in quel caso java non va bene, ma e' una frazione di tutto.

Originariamente inviato da: Unrealizer
il mondo IoT (e in generale quello embedded) è caratterizzato da dispositivi poco potenti e in cui le risorse computazionali e di memoria sono sempre risicate (e si fa i tirchi pure con quelle)... java invece è avido di risorse, soprattutto di ram


java non e' cosi' avido come si crede, ne' lento.
ho visto decine di benchmark (sviluppando in c++ e java mi sono voluto informare), e la differenza e' minima.
LMCH05 Ottobre 2014, 21:17 #13
Originariamente inviato da: WarDuck
Embedded spesso è sinonimo di real-time, quindi a meno di versioni particolari, la risposta di cui parli sarebbe decisamente sbagliata.


mbed OS è event driven, non real-time.

Se si ha bisogno di prestazioni realtime serve ben altro.

Ma d'altra parte in un sacco di applicazioni IoT non servono prestazioni realtime ma connettività (supporto di stack dei comunicazione, protocolli ed interfacce di vario tipo).
LMCH06 Ottobre 2014, 13:32 #14
Originariamente inviato da: Antonio23
real-time non c'entra nulla con le prestazioni. è solo questione di vincoli da rispettare sulla schedulabilità dei processi.


Non confondere le prestazioni in generale con la sola potenza di calcolo.
LMCH07 Ottobre 2014, 01:05 #15
Originariamente inviato da: Antonio23
veramente non li sto confondendo, o forse non ho capito il senso del tuo commento originale, cosa intendi con prestazioni. ho visto microcontrollori ad otto bit in ambienti real time...


Se è per questo ce ne sono anche a 4bit se i task/thread critici sono sufficientemente leggeri o se i vincoli tipo WCET sono sufficientemente ampi.

I vincoli di un applicazione specifica non sono noti a priori ad un S.O. realtime "generico", per questo di solito si danno specifiche di riferimento tipo WCET per la gestione degli interrupt (da cui ricavare la capacità di calcolo "utilizzabile" con interrupt che arrivano con una certa frequenza), massima risoluzione (e precisione) temporale dei timer, overhead legato alla gestione di funzionalità specifiche ecc.
in modo da avere un idea di quale hardware utilizzare abbinato al S.O. prescelto.
Ed in tal senso più che di vincoli è il caso di parlare di prestazioni
(nel senso di prestazioni dell'accoppiata hardware+software realtime "di base" che devono essere tali poter rientrare nei vincoli associati invece all'applicazione/i specifica/che).

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^