Porting (o cambio strategico) da un embedded proprietario a un Linux Embedded. problemi, soluzioni... ed esperienze in evoluzione

Transcript

1 Porting (o cambio strategico) da un embedded proprietario a un Linux Embedded problemi, soluzioni... ed esperienze in evoluzione

2 commitsoftware consulting, engineering, project delivery rich-client & web back-end services mobile apps & mobile web field-force transport cross-media embedded

3 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

4 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

5 summary descrizione architettura evoluzione dell'ambiente di sviluppo nuovi componenti nuovi strumenti problemi incontrati, soluzioni adottate... futuri miglioramenti

6 diagramma architetturale spostamento funzionalità su Linux (nuovo hardware) comunicazione seriale prima GPRS TERMINALE PROPRIETARIO GPS Back-end Server Interface GPRS GPS TERMINALE LINUX WLAN dopo RS 485 utente RS 485 operatore TERMINALE PROPRIETARIO Back-end Server Interface

7 deploy componenti software app monolitica >> comps distribuiti porting elementi su nuovo sistema GUI STATE MACHINE CARD I/O prima APP FRAMEWORK CONNECTION MANAGER BACKEND I/O dopo CARD I/O GATEWAY RS 485 utente BACKEND I/O CONNECTION MANAGER STATE MACHINE RS 485 operatore GUI

8 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

9 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

10 "...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 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 Boost.Move 17. Boost.MPI 18. Boost.Program_options 19. Boost.PropertyTree 20. Boost.Proto 21. Boost.Random 22. Boost.Ratio Boost.Ref 24. Boost.Signals 25. Boost.Signals2 26. Boost.StaticAssert 27. Boost String Algorithms Library 28. Thread Boost.TR1 30. Boost.Tribool 31. Boost.Typeof 32. Boost.Units Boost.Unordered 34. Boost.Variant 35. Boost.Xpressive

11 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

12 nuova State Machine gerarchica device adapter unica interfaccia con primitive sul dispositivo Boot SM Serial SM Device Adapter Main SM Operator SM Back-end interface SM Shift Management SM

13 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

14 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

15 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

16 ambienti di sviluppo GUI (sistema proprietario) macchina Windows Visual Studio 2008 StateMachine macchina Linux Ubuntu CodeBlocks Back-end Server Interface simulatore del terminale proprietario non testabile in modalità debug (causa time-out) "printf" logging su entrambi i terminali

17 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"

18 domande? commenti? Grazie per la vostra attenzione...