Porting (o cambio strategico)
da un embedded proprietario
a un Linux Embedded
problemi, soluzioni...
ed esperienze in evoluzione
commitsoftware
mobile apps
& mobile web
embedded
transport
back-end services
field-force
rich-client & web
cross-media
consulting, engineering, project delivery
background
■ sviluppo in C/C++
■
STL, templates, boost...
■ integrazione componenti nativi
■
■ COM, DLL,LIB, SO...
cross-compiling
■ x86, ARM,...
■ protocolli su socket
■
■ ASIO, winsocket
state-machines, vincoli temporali
esperienze embedded
Automazione e sistemi di controllo
■
distribuzione carburanti
■
■
componente outdoor per vendita
prodotti e accettazione pagamenti
trasporto pubblico
■
componente di scrittura e
validazione titoli di viaggio
Sistemi real-time per controllo remoto
■
tele-laboratorio
■
librerie protocollo RTAI su linux
summary
descrizione architettura
evoluzione dell'ambiente di sviluppo
nuovi componenti
nuovi strumenti
problemi incontrati, soluzioni adottate...
futuri miglioramenti
diagramma architetturale
spostamento funzionalità
su Linux (nuovo hardware)
comunicazione
seriale
prima
GPRS
GPS
TERMINALE
PROPRIETARIO
Back-end Server
Interface
dopo
GPRS
GPS
TERMINALE
LINUX
WLAN
RS 485 utente
RS 485 operatore
TERMINALE
PROPRIETARIO
Back-end Server
Interface
deploy componenti software
app monolitica
>>
comps distribuiti
GUI
APP FRAMEWORK
STATE
MACHINE
CONNECTION
MANAGER
BACKEND I/O
CARD I/O
porting elementi
su nuovo sistema
prima
dopo
CARD I/O
CONNECTION
MANAGER
GATEWAY
STATE
MACHINE
RS 485 utente
RS 485 operatore
BACKEND I/O
GUI
funzionalità sviluppate
■ creazione GUI e StateMachine (SM)
■ protocollo livello Sessione
■ comunicazione delle due applicazioni
■ solo su Linux
■ protocollo di livello Presentazione
■ gestione dei comandi SM >> GUI
■ gateway seriale
■ per regolare l'accesso alla seriale per comunicazione
Back-end da parte di più applicazioni
■ remotizzazione libreria Back-end I/O
modalità di programmazione
■ Prima:
■
■
■
■
Applicazione monolitica sviluppata su
Framework proprietario
maggiore attenzione alle risorse perchè più limitate
necessità di gestire la sincronizzazione fra i diversi
task all'interno dell'applicazione
no librerie di terze parti, incluse STL.
■ Dopo:
■
■
■
Applicazione distribuita su più componenti:
divisione dei compiti fra binari separati
unico e completo ambiente di sviluppo
■ debug non simulato
"...one of the most highly
regarded and expertly designed
C++ library projects in the
world."
"We aim to establish "existing
practice" and provide reference
implementations so that Boost
libraries are suitable for eventual
standardization."
1. Boost.Accumulators
2. Boost.Any
3. Boost.Array
4. Boost.Chrono 1.2.3
5. Boost.Concept_Check
6. Boost.Container
7. Boost.Date_Time
8. Boost.Foreach
9. Boost.Function
10. Boost.Functional/Hash
11. Boost.Heap
12. Boost.Interprocess
13. Boost.Intrusive
14. Boost.Lambda
15. Boost.Lexical_Cast 1.0
16. Boost.Move
17. Boost.MPI
18. Boost.Program_options
19. Boost.PropertyTree
20. Boost.Proto
21. Boost.Random
22. Boost.Ratio 1.0.1
23. Boost.Ref
24. Boost.Signals
25. Boost.Signals2
26. Boost.StaticAssert
27. Boost String
Algorithms Library
28. Thread 3.0.1
29. Boost.TR1
30. Boost.Tribool
31. Boost.Typeof
32. Boost.Units 1.1.0
33. Boost.Unordered
34. Boost.Variant
35. Boost.Xpressive
StateMachine Framework
■ framework descrittivo alto livello
■ definizione di stati e transizioni
■ con relative guardie ed azioni
■ conseguente pulizia del codice
■ nessun if di transizione
■ il framework ti "obbliga"
■ a creare più state machine
■ a definire stati "veri", non assimilabili a
funzioni o ad aggregati di stati
nuova State Machine
■ gerarchica
■ device adapter unica interfaccia
■
con primitive sul dispositivo
Boot SM
Device
Adapter
Serial SM
Back-end interface
SM
Main SM
Operator SM
Shift Management
SM
dettagli StateMachine (1/2)
MainSM espone verso le altre SM una serie di
metodi:
■ per l'interazione delle SM fra di loro, quali raise di eventi
template <class Evt>
boost::msm::back::execute_return SM_main_wrapper::process_event(Evt& ev)
{
return boost::static_pointer_cast<SM_Main>(fsm_)->process_event(ev);
}
■ per l'interazione con il DeviceAdapter
dettagli StateMachine (2/2)
esempio di dichiarazione di SM
// front-end: define the FSM structure
struct sm_main_: public msm::front::state_machine_def<sm_main_>
esempio di tabella di transizione
struct transition_table: mpl::vector<
//
Start
Event
Next Action
//+-----------------------------------------------------+----------------+------------+-----------+
a_row< st_start
, ev_init_start, SM_Boot, &v::Init > ,
_row< SM_Boot::exit_pt<acme::st_ini_exit>, none
, st_ini
>,
1. transizione con azione su base evento fra SM diverse
2. transizione senza azione su uscita da metodo nella stessa SM
compilazione del codice
■ compilazione in debug
■ tempi lunghi: alcune decine di minuti.
■ utilizzo di CLang invece di GCC
■ dimensioni elevate: circa 40Mb
■ in release non verificato inaccettabile
distribuzione binari di tali dimensioni
■ notevole utilizzo risorse (e.g. memoria RAM)
■ durante la compilazione
■ non sufficenti PC con 4Gb RAM
ambienti di sviluppo
■ GUI (sistema proprietario)
■ macchina Windows
■ Visual Studio 2008
■ simulatore del terminale proprietario
■ StateMachine
■ macchina Linux Ubuntu
■ CodeBlocks
■ Back-end Server Interface
■ non testabile in modalità debug (causa time-out)
■ "printf" logging su entrambi i terminali
improvements
■ StateMachine
■ Unit Test alcune funzionalità
■ uso librerie GTest e GMock
■ con GMock verifica transizioni SM
■ estendere test a tutte le funzionalità
■ su Linux possibililtà di usare Valgrind
■ individuare e risolvere eventuali
problemi di "memory leaks"
domande? commenti?
Grazie per la vostra attenzione...