Vi posto il link su Channel9 ad un interessantissimo video introduttivo di Pete Brown sul .Net Micro Framework e sulla disponibilità delle numerose piattaforme hardware per lo sviluppo quali Netduino e Netduino GO della Secret Labs ed ovviamente tutte le board compatibili con .Net Gadgeteer, tra cui le principali sono la Fez Spider e la Fez Hydra della GHI.
Per chi vuole avvicinarsi a questo fantastico mondo, consiglio di darci uno sguardo…
Anche questo mese su “ioProgrammo” (n. 178, Settembre 2012) c’è un mio articolo dedicato all’utilizzo dell’accelerometro in Windows Phone.
Si parte dalla teoria del funzionamento di un accelerometro fino ad arrivare alla realizzazione di una semplice applicazione di tilt sensing.
Purtroppo, c’è stato da parte mia un errore nel fornire due figure (precisamente la fig. 3 e la fig. 6) all’editore che nella rivista appaiono completamente nere. Di seguito vi riporto il loro contenuto reale.
 Fig. 3 calcolo accelerazione rispetto asse X |
 Fig. 6 calcolo accelerazioni rispetto assi X e Y |
Anche questa volta…mi raccomando…non perdetevelo !
A seguito del rilascio ufficiale e della disponibilità del download del .Net Micro Framework 4.2, è stato ufficialmente rilasciato dalla Secret Labs anche il firmware 4.2.0 per il Netduino basato appunto sulla nuova versione del .Net Micro Framework.
Porta con se le seguenti novità :
Potete trovare tutte le informazioni a questo link e l’annuncio ufficiale qui, sul forum dedicato al Netduino.
Come già annunciato nei giorni scorsi ed a seguito di un blocco temporaneo dei sistemi, Microsoft ha sostituito il vecchio App Hub con il Windows Phone Dev Center.
Sul Windows Phone Developer Blog possiamo leggere qui tutto ciò che riguarda le innovazioni, tra cui :
Speriamo che si sia ridotto anche il tempo di certificazione delle app !
Molto spesso può essere utile riuscire ad accendere il nostro PC da remoto, sia che si tratti della rete locale di casa o aziendale sia che si tratti di utilizzare Internet per farlo. Sappiamo che è fondamentalmente semplice fare l’operazione inversa di spegnimento una volta che abbiamo il controllo del PC … ma come fare ad accenderlo ?
Per questo scopo, ci viene in aiuto una funzionalità di cui oggi sono dotati tutti i PC moderni sulla propria scheda di rete che è la Wake On LAN (nota come WOL). Abilitandola opportunamente nel BIOS ed attivandola anche nelle impostazioni della scheda di rete dal sistema operativo, si fa in modo che allo shutdown la scheda di rete rimanga alimentata (PC con alimentazione ATX) e quindi in ascolto del traffico che c’è sulla rete. Ovviamente, nell’ambito del modello ISO-OSI ci troviamo nel livello Data Link Layer (livello 2), quindi dobbiamo ragionare in termini di MAC address, in quanto lo stack TCP/IP è uno strato software che viene gestito dal sistema operativo, che ovviamente non abbiamo a disposizione a PC spento.
La “magia” che permette l’accensione del PC è proprio dovuta ad uno pacchetto di byte che va trasmesso in rete e che prende appunto il nome di “Magic Packet”.
Esso è caratterizzato da 102 bytes complessivi di cui, i primi 6 sono tutti 0xFF seguiti dal MAC address del PC che vogliamo far accendere e ripetuto 16 volte. Come mai così tante ripetizioni del MAC address ? Basti pensare che una scheda di rete è in ascolto di tutti i pacchetti che passano ma li scarta quando non è il destinatario. Se il MAC address fosse inserito una sola volta nel pacchetto, sicuramente avremmo la possibilità che un normale pacchetto di traffico (download di un file, email, …) abbia una sequenza di byte al suo interno molto simile ad essa ed a quel punto il PC lo interpreterebbe erroneamente come un “Magic Packet” e si avvierebbe. Ripetendo 16 volte il MAC address si riduce drasticamente (fondamentalmente a zero) questa possibilità.
La migliore modalità per trasferire il pacchetto è quella di utilizzare il protocollo UDP in broadcast, in quanto non abbiamo alcun bisogno dell’handshake del TCP e non potremmo nemmeno utilizzarlo correttamente considerando che il PC destinazione è spento. Nel momento in cui, il PC “ascolta” questa sequenza di 102 byte e riconosce al suo interno il suo MAC address ecco che … la magia si avvera … il PC si accende !
Prendendo spunto da questo articolo di Marco Lai, “Wake on Lan accendere il computer con Arduino ethernet”, non poteva ovviamente mancare la mia implementazione per il .Net Micro Framework all’interno della libreria uPLibrary (arrivata alla versione 1.7.0.0).
All’interno del namespace relativo al Networking, uPLibrary.Networking, ho aggiunto la classe statica Wol che espone l’unico metodo statico Wake(), il quale prevede come unico parametro un array di byte che rappresenta il MAC address della scheda di rete del PC da avviare.
Utilizzando una scheda Netduino, possiamo realizzare una semplice applicazione che avvia il PC alla pressione dello switch presente sulla board stessa.
public class Program
{
private static InterruptPort sw;
public static void Main()
{
// write your code here
sw = new InterruptPort(Pins.ONBOARD_SW1, true,
Port.ResistorMode.Disabled,
Port.InterruptMode.InterruptEdgeHigh);
sw.OnInterrupt += new NativeEventHandler(sw_OnInterrupt);
Thread.Sleep(Timeout.Infinite);
}
static void sw_OnInterrupt(uint data1, uint data2, DateTime time)
{
Wol.Wake(new byte[] { 0x00, 0x26, 0x22, 0xA2, 0xF2, 0xD3 });
}
}
Ovviamente, il tutto è disponibile su Codeplex ed è stato anche aggiornato nella Nuget Gallery!
Ricordo che per il corretto funzionamento, è necessario il supporto del Wake On LAN da parte della scheda di rete del vostro PC ed una relativa opportuna configurazione nel BIOS (in alcuni casi anche alcune impostazioni nel driver del sistema operativo).
Vi segnalo questo interessantissimo articolo “.Net Development for ARM processors” di Andrew Pardoe (Program Manager nel CLR team) su MSDN Magazine che esplora l’evoluzione dello sviluppo in .Net dal processore x86 al processore ARM, con l’introduzione del .Net Compact Framework ed il .Net Micro Framework fino all’avvento della piattaforma in Windows 8.
Sono evidenziate le notevoli differenza tra le due architetture di cui deve tener conto il team che sviluppa il CLR in modo che il passaggio da un’architettura all’altra sia trasparente per noi sviluppatori.
L’ho trovato molto…molto…interessante….leggere per credere !
DEVEXPERIENCE 