DevExperience

.Net Framework, Internet of Things & M2M, Embedded Systems, Design Patterns Paolo Patierno's Blog

MVP Award

I'm Microsoft MVP for Windows Embedded

Recent Posts

Apps & Articles

Progetti

Pubblicazioni

Tags

My Profiles

 

My Embedded101 Blog

My YouTube Channel

Windows Embedded CE 6.0

Building Embedded Devices using Windows Embedded CE 6.0 R2

Archives

Sto leggendo...

Windows Embedded

.Net Micro Framework

.Net Framework & CLR

Email Notifications

Open Source Hardware

RSS Blog Post

dicembre 2011 - Post

Codice Nativo vs Gestito : performance

Affrontando un problema lavorativo riguardo le perfomance grafiche su un target device con processore ARM e Windows CE 6.0 R3 e facendo delle ricerche di approfondimento in rete, mi sono imbattuto in un interessantissimo articolo di Chris Tacke dell’OpenNETCF Communty intitolato “Native vs. Managed Code : GDI Performance”.

L’articolo, attraverso un’applicazione di test, dimostra quanto il codice nativo non possa essere considerato in assoluto molto più veloce del codice gestito ma soltanto per una percentuale relativa che però può talvolta variare da piattaforma a piattaforma. In particolare, il test viene eseguito utilizzando le GDI di Windows.

Un ulteriore interessante risultato è che l’utilizzo di metodi del .Net Compact Framework che fungono da wrapper di corrispondenti metodi nativi (vedi ad esempio Graphics.FillRectangle che è wrapper dell’API FillRect) riducono le performance rispetto all’invocazione diretta delle API di sistema attraverso le P/Invoke. E’ ovvio che il wrapper al suo interno eseguirà sempre una P/Invoke ma aggiunge un carico di lavoro in più, probabilmente legato a dei check che vengono eseguiti prima della chiamata nativa (vedi anche il marshalling dei parametri).

Posted: 23 dic 2011 13:10 da Paolo | con no comments
Inserito sotto: , , , , ,
WCE7 e la BSP Virtual PC : TFTP timeout durante il download dell’immagine sul target “virtuale”

Utilizzando la BSP Virtual PC per Windows Embedded Compact 7, può accadere di trovarsi di fronte al seguente errore nella fase di download dell’immagine sul target “virtuale”…

ERROR : BootTransportPb: TFTP timeout occurred !

… come evidenziato nella seguente figura.

VCEPC_error

Il Platform Builder ha avviato il download ma poco dopo scatta il timeout sul protocollo di trasporto TFTP. Nella finestra di output dell’ambiente di sviluppo, viene visualizzato il seguente errore.

PB_error

Un trucco per poter superare questo problema, che di fatto ci impedisce di scaricare l’immagine del sistema operativo sul target, è quello di disabilitare il controllo della checksum sui pacchetti UDP nella nostra scheda di rete.

net_1

net_2

Se non avete ancora utilizzato la BSP Virtual PC fornita con l’installazione dell’ambiente di sviluppo per Windows Embedded Compact 7, vi consiglio di leggere il seguente post.

Posted: 22 dic 2011 8:45 da Paolo | con no comments
Inserito sotto:
WARNISERROR e l’errore “warning treated as error – no ‘object’ file generated”

Sviluppando su Windows CE ed utilizzando il Platform Builder, può capitare di incorrere nel seguente errore :

error C2220: warning treated as error – no ‘object’ file generated

Ciò vuol dire che il compilatore è stato impostato per trattare i warning come errori e quindi la compilazione non viene completata correttamente ed il file oggetto non viene generato.

Analizzando le opzioni di compilazione al sequente link si evince che è disponibile l’opzione /W per definire il warning level del compilatore stesso. Nel caso in cui venga settato /WX, quest’ultimo tratterà ogni warning come errore.

Per poter modificare questo comportamento in corrispondenza di un singolo modulo (librearia o eseguibile), è necessario settare all’interno del file sources di quest’ultimo, la seguente linea…

WARNISERROR = 0

…oppure ometterla, considerando che questo è il comportamento di default.

Talvolta, alcune BSP settano tale impostazione a livello globale per tutti i moduli impostandola nel file source.cmn che troviamo al percorso $(_WINCEROOT)\PLATFORM\<BSP>.

Attraverso questa impostazione, l’ambiente di build setterà o meno il warning level del compilatore con l’opzione /WX.

Considerando, infatti, un estratto del makefile.def

!IF "$(WARNISERROR)"=="1"
# Turn off WX when running prefast, it throws some warnings.
!  IF "$(PREFAST_ADD_PATH)" == ""
CFLAGS=$(CFLAGS) -WX
!  ENDIF
!ENDIF

…si evince che, abilitanto WARNISERROR, tra le flags del compilatore (CFLAGS) viene impostata anche WX.

Posted: 20 dic 2011 13:21 da Paolo | con no comments
Inserito sotto:
Windows Embedded Compact 7 Online Training

wce7

Con l’obiettivo di continuare a puntare sulle piattaforme embedded, Microsoft ha reso disponibile un nuovo portale per il training online su Windows Embedded Compact 7.

Il contenuto tecnico è notevole :

  • 65 webcasts;
  • Una dozzina di virtual labs;
  • Riferimenti a numerose white papers ed alla documentazione ufficiale MSDN;

Assolutamente da non perdere, sia come punto di partenza nello studio che per gli approfondimenti.

wce7_1

Posted: 14 dic 2011 21:43 da Paolo | con no comments
Inserito sotto: ,
μPLibrary : un esempio di utilizzo del Dynamic Dns client

Dopo aver rilasciato l’ultima versione della μPLibrary, posto il seguente articolo per chiarire l’utilizzo del nuovo componente Dynamic DNS client che ho aggiunto.

In primo luogo, è necessario istanziare un oggetto della classe DdnsAccount attraverso la quale è possibile settare il nome dell’host per il quale vogliamo eseguire la sincronizzazione con l’indirizzo IP corrente, oltre a specificare lo username e la password del nostro account presso il DNS service provider.

   1: DdnsAccount ddnsAccount = new DdnsAccount { 
   2:     Hostname = "hostname", 
   3:     Username = "username", 
   4:     Password = "password" };
 
Dopo aver definito le informazioni che riguardano l’account, è necessario istanziare un oggetto della classe DdnsConfig attraverso il quale settiamo la configurazione del Ddns client, ossia l’account precedente, il periodo di aggiornamento dell’indirizzo IP (in millisecondi) e la possibilità di utilizzare o meno una connessione protetta su SSL.
 
   1: DdnsConfig ddnsConfig = new DdnsConfig { 
   2:     Account = ddnsAccount, 
   3:     Period = 300000, 
   4:     SSL = true };
 
A questo punto, completate tutte le impostazioni di configurazione, è necessario istanziare il client vero e priorio. A tale scopo andiamo ad utilizzare la classe statica DdnsClientFactory (che implementa il pattern Factory Method) ed il relativo metodo GetDdnsClient(). Quest’ultimo riceve in ingresso i due seguenti parametri :
  • DdnsServiceProvider : uno dei possibili valori di tale enumerativo che rappresenta il Dynamic DNS service provider che stiamo utilizzando (es. DynDNS, No-IP, …);
  • DdnsConfig : l’oggetto che contiene tutte le impostazioni di configurazione del client;

Il metodo in questione ritorna un’istanza di una delle possibili classi derivate dalla classe DdnsClient, che dipenderà dal service provider scelto. Scegliendo, ad esempio, No-IP come service provider, la classe istanziata sarà del tipo DdnsNoIpClient (che appunto deriva da DdnsClient e ne implementa i metodi necessari).

   1: DdnsClient ddnsClient = DdnsClientFactory.GetDdnsClient(
   2:     DdnsServiceProvider.NoIp, 
   3:     ddnsConfig);
 
Il passo successivo è quello di registrare un event handler all’evento IpAddressUpdated della classe DdnsClient che verrà sollevato nel momento in cui il client avrà eseguito un aggiornamento dell’indirizzo IP presso il service provider.
 
   1: ddnsClient.IpAddressUpdated += 
   2:     new IpAddressUpdatedHandler(ddnsClient_IpAddressUpdated);
 
L’event handler riceverà un event args del tipo IpAddressUpdatedEventArgs che fornisce le due seguenti informazioni :
  • IpAddress : l’indirizzo IP aggiornato;
  • Response : un’istanza della classe DdnsResponse che contiene il codice e quindi l’esito dell’aggiornamento ritornato dal server;
L’ultima operazione che ci rimane è quella di avviare il client, utilizzando il metodo Start() della classe DdnsClient (è previsto anche il corrispondente metodo Stop() per terminare l’azione del client). Al suo interno, quest’ultimo non fa altro che avviare un timer che sulla base del periodo settato in fase di configurazione, esegue il check e l’update dell’indirizzo IP. Ovviamente, tutte le operazioni vengono eseguite in un thread separato dal main thread dell’applicazione che può così proseguire in altre azioni ed elaborazioni.
Posted: 10 dic 2011 14:53 da Paolo | con no comments
Inserito sotto: ,
TinyCLR.it : la community italiana sul .Net Micro Framework

tinyclrit

E’ finalmente online il sito della community italiana TinyCLR.it dedicata al mondo embedded ed in particolare al .Net Micro Framework e che cercherà di essere il punto di riferimento per questa tecnologia Microsoft in Italia, così come nel mondo è già nota la community TinyCLR.com.

Io sono tra le persone che ha partecitpato alla sua creazione (anche se il portale è tutta opera di Lorenzo Maiorfi) e darò il mio contributo alla sua crescita come ormai già faccio con il mio blog per il DotNetCampania.

Vi aspettiamo !!!

Posted: 9 dic 2011 16:21 da Paolo | con no comments
Inserito sotto: , ,
μPLibrary : componente client per il servizio di Dynamic Dns

La libreria μPLibrary (arrivata alla versione 1.3.0.0) si è arricchita di un nuovo componente software che fornisce la funzionalità di client per il servizio di Dynamic Dns.

Infatti, sappiamo che esistono alcuni service provider (No-IP, DynDns, …) che forniscono il servizio di Dynamic Dns per tutti coloro che hanno un indirizzo IP dinamico ma che vogliono comunque raggiungere il proprio PC dall’esterno utilizzando un nome di dominio (es. pccasa.dyndns.org).

dyndnsno-ip

Gli stessi service provider forniscono anche un  proprio applicativo che va installato sul proprio PC per garantire la sincronizzazione e corrispondenza tra il proprio indirizzo IP (che cambia continuamente) ed il nome host che abbiamo scelto (es. pccasa.dyndns.org). Con questa soluzione è necessario, però, avere il proprio PC sempre acceso. Esistono, comunque, molti router sul mercato che includono tale funzionalità.

Il componente che ho aggiunto alla mia libreria, invece permette di utilizzare la propria board con il .Net Micro Framework a fungere da client per il servizio di Dynamic Dns. Al suo interno è implementato tutto il protocollo necessario per il check del proprio indirizzo IP e la funzionalità di upload dello stesso presso il service provider. Attualmente, i service provider supportati sono No-IP e DynDns, ma è banale estendere il componente per altri service provider.

Nei prossimi giorni, posterò un articolo più esaustivo sul suo funzionamento e sul suo utilizzo, nel frattempo è già disponibile anche su Nuget !

Posted: 4 dic 2011 17:14 da Paolo | con no comments