EMBEDDED
52 • MAGGIO • 2014
62
SOFTWARE
C LANGUAGE
• Come utilizzare le funzionalità specifiche del com-
pilatore, come ad esempio le funzioni intrinseche o le
estensioni del linguaggi.
• Come utilizzare la verifica del range, le affermazioni,
le condizioni iniziali e finali (pre e post-condition) e
altri costrutti simili utilizzati per individuare gli errori.
• Organizzazione dell’interfaccia e dell’accesso tra i
moduli.
• Requisiti in termini di documentazione.
In sintesi, lo standard di codifica dovrebbe fornire
suggerimenti sulle modalità da adottare per risolvere i
problemi che influenzano la qualità del codice e la sua
integrità ma non sono esplicitamente affrontati dal lin-
guaggio o dal sottoinsieme.
Suggerimenti pratici
Di seguito saranno descritti alcuni approcci da utilizza-
re relativamente ai temi trattati in precedenza.
MISRA-C
Nel caso si decida di utilizzare
MISRA-C, l’approccio può essere leg-
germente differente a secondo che si
avvii lo sviluppo a partire da zero o si
stia riutilizzando codice legacy. Nel
primo caso è buona norma tener conto
dei seguenti suggerimenti:
• Non cercare di supportare “in modo
cieco” ogni singola regola. Per alcune
parti del codice non è probabilmente
possibile essere conformi a uno a o
più regole. Questa affermazione è vera
soprattutto per il codice sviluppato per
l’interfacciamento con la parte hardwa-
re. In questo caso è necessario prendere decisioni con
cognizione di causa e documentare tali decisioni.
• Cercare di garantire la conformità, in ogni momento,
con le regole relative ai tipi base, oltre che con l’arit-
metica e con le conversioni eseguite su tipi suddetti.
I problemi in questo ambito sono insidiosi, e il codice
che sembra funzionare perfettamente su una piattafor-
ma potrebbe non funzionare affatto su un’altra..
• Se si sta utilizzando una procedura non conforme
per la stessa regola più volte su parti di codice simile, è
bene considerare questo fatto come una sorta di avver-
timento. Quindi è lecito chiedersi:
• L’interpretazione della regola è corretta?
• Il pattern del codice è realmente necessario? In
caso affermativo è necessario considerare la possibi-
lità di scomporre il codice non conforme sotto forma
di funzione isolata o insieme di funzioni.
• Utilizzare un checker statico in grado di verifi-
care la conformità in maniera interattiva durante lo
sviluppo.
Nel caso si stia applicando un insieme di regole
MISRA-C a codice legacy può essere utile eseguire le
seguenti operazioni:
• Lavorare su una regola alla volta.
• Selezionare in prima istanza le regole semplici, come
ad esempio quella di includere anche singole istruzioni
che formano il nucleo di un costrutto condizionale con
‘{‘ and ‘}’. (MISRA-C:2004 rule 14.8)
• Tener conto delle regole che affermano che i tipi
base come short, int e char non dovreb-
bero essere usati e si tenga in con-
siderazione l’opportunità di cambiare
un modulo alla volta per utilizzare tipi
dimensionati in maniera esplicita come
ad esempio uint16_t.
• Dopo un po’ di esercizio con qualche
modulo più semplice, si può passare
a esaminare moduli affetti da errori o
difficili da manutenere.
La variabile volatile
Adesso è utile concentrare l’attenzio-
ne su uno degli aspetti del linguaggio
C che crea la maggior confusione: la
variabile volatile. L’uso scorretto di questa variabile è
molto spesso la causa dei malfunzionamento dei siste-
mi embedded. La principale ragione per dichiarare un
oggetto come volatile è informare il compilatore che il
valore dell’oggetto può cambiare in maniera sconosciu-
ta al compilatore stesso per cui tutti gli accessi all’og-
getto devono essere mantenuti. La necessità di avere
oggetti cariabili è dovuta a:
• Accesso condiviso: l’oggetto è condiviso tra parecchi
task in un ambiente multitasking oppure un singolo
Tabella 2 – Tabella contenuta nello standard IEC61508, parte 7, appendice C
L’uso
scorretto
della variabile
volatile è spesso
la causa dei mal-
funzionamenti
dei sistemi
embedded
