Linux in Bticino 2000.. 2012+

Linux in Bticino 2000.. 2012+ https://gitorious.org/~bticino Il Sistema MyHome La storia Medium Platform: ciclo di sviluppo di una piattaforma Lo sviluppo distribuito La formazione Lo Stackopen v2 : struttura a plugin Debug sui sistemi embedded in pratica I prodotti e le versioni SDK raffaele.recalcati@bticino.it

SCS BUS Lighting & Shutter example Command SCS L N Loads M M

SCS BUS MY HOME is based on the use of the digital BUS SCS which can be used in any residential or service environment. SCS is a proprietary protocol Twisted pair cable on which power, messages, audio (telephonic band and hi-fi band) and video signals are transported COMMANDS VOICE POWER STEREO HiFi VIDEO f Similar way for configuring and cabling systems / devices

Legrand Group Home Automation Comfort Ligth automation Management of shutters / automations Scenario activation Sound diffusion Remote management Remote access from your laptop Remote access from mobile control (smart phone, ) Safety Burglar alarm Technical alarms Remote assistances Video monitoring system Touch Control & Multimedia RSS Management mediaclient webcam Energy Management Temperature control Air conditioning Load management Consumption display Audio Video communication digital video door entry system integrated telephone system

La storia: 1998-2000 Web Server a stack TCP-IP e Sistema Operativo a memoria non protetta proprietario (acquistati i sorgenti), CPU AMD186 60Mhz, 512KB Flash, 512 KB Ram. Vantaggi: molto efficiente Svantaggi: no riutilizzo di codice, no community, memoria RAM condivisa tra applicazioni, stack tcp ip e sistema operativo. Sistema Operativo e Stack Tcp-Ip: US Robotics

La storia: 2000-2002 Gateway e Webserver con scheda grafica per acquisizione immagini 4fps colori basato su X86 300Mhz, scheda per interfacciamento con bus di campo SCS. Vantaggi: scheda cpu già pronta, community Linux Svantaggi: mancanza di controllo sull'hardware per la scheda cpu Linux Redhat 6.2 (distribuzione ritagliata per "starci" nel piccolo harddisk).

La storia: 2003-2004 Gateway e Webserver (CPU: StrongArm 1110 200Mhz) Vantaggi: controllo completo sull'hardware, community Linux, riutilizzo software precedente tramite cross-compilazione Svantaggi: necessità di ottimizzare gli applicativi per la cpu meno potente Sistema Operativo Linux Bootloader: Ecos redboot Kernel: 2.4.19-rmk7-pxa2 Distribuzione: Etlinux

La storia: 2005-2010 Btweb Platform Gateway, Webserver, Touschscreen 3,5'' e 10'', Interfaccia Voip da SCS a Ethernet, Scheduler scenari programmabile. CPU: PXA255 (fino a 64MB Ram, 32 MB Flash NOR) Kernel: 2.4.19-rmk7-pxa2, 2.6.26 git@gitorious.org:btweb_platform/linux-2_4_19-rmk7- pxa2-btweb.git Distribuzione: Etlinux2. git@gitorious.org:btweb_platform/etlinux2_3-0.git

La storia: 2005-2010 Btweb Platform Singolo Kernel https://gitorious.org/btweb_platform/linux-2_4_19-rmk7-pxa2- btweb/blobs/master/arch/arm/mach-pxa/btweb-flavors.c /* * linux/arch/arm/mach-pxa/btweb-flavors.c * * Management of different hardware flavors for the BTicino devices * * The boot loader should have left the GPIOs as generic as possible, so we fix * them to the needs of the product. * * Adapted to the BTicino device family by Alessandro Rubini in 2006 * * Customizations for new BTicino products made by Raffaele Recalcati in 2006,2007,2008 * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ /*************************************************** GPIO58 GPIO6 GPIO7 GPIO82 GPIO84 RAM SPEED F453 0 0 0 0 0 64 400 // 0x0 F543AV 0 0 0 0 1 64 400 // 0x1 346890 0 0 0 1 0 64 400 // 0x2 PBX-2/8/8/exp 0 0 0 1 1 64 400 // 0x3 PBX-2/8/8 0 0 1 0 0 64 400 // 0x3 PE 0 0 1 0 1 64 400 // 0x3 PI 0 0 1 1 0 64 400 // 0x3 H4684/IP 0 0 1 1 1 64 400 // 0x3 H4684/IP/8 0 1 0 0 0 64 400 // 0x3 CDP/HW 0 1 0 0 1 64 400 // 0x3 INTERFMM 0 1 0 1 0 64 400 // 0x3 BMNE500 F453 MH200N MH200 0 1 0 1 1 64 400 // 0x3 MEGATICKER 0 1 1 0 0 64 400 // 0x3 OLD F453/MH200 0 0 1 x x 64 // 0x4-0x7 H4684 0 1 0 0 0 64 200 // 0x8 PE-monob 0 1 0 0 1 32 200 // 0x9 F453AV-proto 0 1 1 1 1 64 400 // 0xf Moreover: GPIO63, GPIO64, GPIO69 (hw revisions) ***************************************************/

La storia: 2011+ Medium Platform Porting da PXA255 a DM365 degli stessi prodotti CPU: DM365 270Mhz (fino a 256MB Ram, 256MB NAND, 2GB emmc) https://gitorious.org/medium_platform Vedi presentazione FOSDEM 2011 Medium_Platform.pdf file nel repository https://gitorious.org/medium_platform/documentation/trees/master

La storia: ARM MACH number http://www.arm.linux.org.uk/developer/machines/ 670 Btweb pxa255 2567 BTicino PXA270 Multimedia Touch pxa270 2948 BASI dm365 3337 Dingo Board dm365 3982 JUMBO_D dm365 3983 JUMBO_I dm365 3715 Owl Board dm365 4227 Lago pure gateway dm365 4326 amico_i dm365 4327 amico_e dm365 3341 omap3_baia dm3730

Medium Platform: ciclo di sviluppo di un prodotto La progettazione iniziale HwBsp, Middle Layer, Gui è estremamente modulare

Medium Platform: ciclo di sviluppo di un prodotto In base alle necessità si differenzia solo quello che serve

Medium Platform:ciclo di sviluppo di un prodotto Lo Sviluppo Si decidono le peculiarità del dispositivo, ad esempio Web server e il Touchscreen 3.5'' Davinci. Sviluppo hardware Bring-up scheda e verifica HwBsp: tempo ridotto grazie al lavoro precedente sulla piattaforma Utilizzo di bt_test_bsp e bt_test per verifica dell'hardware e dei driver

Medium Platform:ciclo di sviluppo di un prodotto Lo Sviluppo Sviluppo applicativi, interfaccia grafica Qt e libreria HAL (Hardware Abstraction Layer: interfaccia verso il kernel). Si parametrizza il software di configurazione per effettuare l'aggiornamento firmware e modificare la configurazione del dispositivo rispetto all'impianto voluto Test automatici degli applicativi mediante Robot framework

Medium Platform:ciclo di sviluppo di un prodotto Test Lab Test completi effettuati da un altro gruppo di lavoro: Test CE: EMC, sicurezza Internal test: funzionali Eventuali feedback per correzioni hardware e software.

Medium Platform:ciclo di sviluppo di un prodotto Impianti Pilota Test di alcuni mesi effettuati su impianti reali, duranti i quali l'assistenza tecnica monitora il funzionamento e raccoglie osservazioni per lo sviluppo R&D.

Lo sviluppo distribuito No ad eccessive interdipendenze tra i diversi strumenti (posso sostituirne uno di essi senza pregiudicare gli altri)

Lo sviluppo distribuito Introduzione del concetto di Maintainers Rispetto del CodingStyle Altri siti Legrand Fornitori esterni in Vpn Introduzione workflow per accettazione contributi

Lo sviluppo distribuito glossario [A] = Autore (chi effettua lo sviluppo e manda le patch) [M] = Maintainer (chi verifica il CodingStyle e la compatibilità con gli altri dispositivo già stabili, chi ha i diritti per pushare sul git tree presente nella LAN Bticino) [T] = Tester (verifica dopo la ricompilazione complessiva)

Lo sviluppo distribuito Stable TAG device1 [A] Nuovo sviluppo su device2 Develop branch in locale (macchina virtuale backuppata) [A]Valid Send patches [M]Valid [M] commit per avere history pulita Stable TAG device2

Lo sviluppo distribuito Stable TAG device1 [M] Bug fix per dispositivi in produzione [A] Nuovo sviluppo su device2 Develop branch in locale (macchina virtuale backuppata) [A]Valid Send patches [M]Valid [M] commit per avere history pulita Stable TAG device2

Lo sviluppo distribuito Stable TAG device1 [M] Bug fix per dispositivi in produzione [A] Nuovo sviluppo su device2 Develop branch in locale (macchina virtuale backuppata) [A]Valid Send patches [M]Valid [M] commit per avere history pulita Stable TAG device2

Lo sviluppo distribuito Stable TAG device1 [M] Bug fix per dispositivi in produzione [A] Nuovo sviluppo su device2 Develop branch in locale (macchina virtuale backuppata) [A]Valid Send patches [M]Valid [M] commit per avere history pulita Stable TAG device2

Lo sviluppo distribuito miglioramenti Evitare ignore white space Mandare le patch nel body e plain text (consente il commento in linea da parte del maintainer) "[nome_modulo PATCH 1/5 v3] titolo Realizzare test automatici di validazione sui device non in sviluppo...

Lo sviluppo distribuito verifica automatica di integrità (in sviluppo) Stable TAG device1 [M] Bug fix per dispositivi in produzione [A]Valid [A] Nuovo sviluppo su device2 Develop branch in locale (macchina virtuale backuppata) [J] Valid [J] validazione automatica anche su device1 delle periferiche hw e funzionalità sw Send patches [M]Valid [M] commit per avere history pulita Stable TAG device2

Lo sviluppo distribuito validazione automatica (in sviluppo)

La formazione: interna Poco formalizzata, ma quotidiana e tra tutti i gruppi di lavoro. La condivisione del know-how è la vera chiave. Approccio Out4Insourcing, grazie a consulenze mirate che accrescono il know-how del gruppo stesso. No a sviluppi esterni a scatola chiusa, non sono funzionali, nè integrabili, viste le numerose dipendenze con hardware e software sviluppati internamente

La formazione: esterna Corsi organizzati dalle risorse umane su esigenze di sviluppo espresse con un anno di anticipo. Name Date embedded linux conference 2012 05/11/2012 licenze open source 17/05/2012 html5 & css3 02/04/2012 introduzione java e fondamenti di programmazione android 26/03/2012 le reti ip multicast 09/11/2011 embedded linux conference europe 26/10/2011 integrità dei segnali nelle moderne schede elettroniche 20/06/2011 problematiche avanzate di internetworking 07/06/2011 networking ed infrastrutture 13/04/2011 arm linux advanced course - medium platform hardware based 29/03/2011 conoscenza sull'applicazione sistemi arm-linux 16/12/2010 gstreamer conference 2010 + celf embedded linux conference europe 26/10/2010 fosdem 2010 06/02/2010 embedded linux conference europe 2009 15/10/2009 metodologie agili 12/05/2009 ip telephony 05/12/2006

Lo Stackopen v2 : struttura a plugin dalla struttura a IPC (stackopen 2002-2011+)

Lo Stackopen v2 : struttura a plugin dalla struttura a IPC (stackopen) Processi scritti diversamente Interfacce sopra e sotto reimplementate (anche in modo differente) Gli stili di debug possono essere differenti Il test può essere solo ai morsetti esterni e, di solito, sul target Le frame di aggiornamento da scssserver vanno a tutti i processi Il file di configurazione è unico e serve per stabilire chi si connette a chi, quindi i processi sono interdipendenti Context Switch inefficiente

Lo Stackopen v2 : struttura a plugin dalla struttura a IPC poco efficiente (stackopen)

PLUGINS COSO Lo Stackopen v2 : struttura a plugin https://git.gitorious.org/bt_general/coso.git (LGPL)

Lo Stackopen v2 : struttura a plugin soluzioni Processi scritti diversamente OK Interfacce sopra e sotto reimplementate (anche in modo differente) OK Gli stili di debug possono essere differenti OK Il test può essere solo ai morsetti esterni e, di solito, sul target Sviluppo e test sul PC Le frame di aggiornamento da scssserver vanno a tutti i processi no a comunicazioni superflue Il file di configurazione è unico e serve per stabilire chi si connette a chi, quindi i processi sono interdipendenti ciascuno ha il suo file di configurazione Context Switch inefficiente meno scambi di informazione

Debug sui sistemi embedded in pratica Jtag Lauterbach (ETM per off-chip trace) e Peedi DS-5 per analisi colli di bottiglia In realtà tanta esperienza, stampe di trace su seriale, gpio ed un oscilloscopio sono la pratica quotidiana e solo in casi particolari si ricorre alla strumentazione di cui sopra, che richiede spesso setup complicati

I prodotti e le versioni SDK Di solito utilizzate dai system integrator http://www.myopen-legrandgroup.com/devices/default.aspx Ci sono esempi già implementati per i vari prodotti e wiki descrittive