Senza conoscere la tua applicazione e la capacità corrente del dispositivo incorporato sarà difficile per me dare un parere definitivo se .NET MF è all'altezza del compito. Se il dispositivo incorporato è una CPU a 8 bit a bassa potenza con 2K di RAM e 32K di ROM, .NET MF non sarebbe adatto a tale progetto.
In un numero elevato di casi, il passaggio a .NET MF comporterebbe modifiche hardware a un chipset preferito da molti fornitori che in genere utilizzano core ARM7 o ARM9. Il motivo principale per questo è sfruttare il lavoro già svolto nel porting dell'HAL e cross-compilare il PAL & TinyCLR con il codice nativo per il processore in questione. Quindi, se l'applicazione si adatta al modello MF .NET, è necessario solo sviluppare codice gestito.
Un confronto di development boards potrebbe aiutare a selezionare una piattaforma per un nuovo design. Il vantaggio dello GHI products consiste nel fatto che è possibile acquistare i chipset nudi con il firmware che hanno sviluppato per integrarsi con la progettazione hardware.
Risposta alla domanda 1: .NET Framework è all'altezza dell'attività?
Spiacente, non posso rispondere a questa domanda senza ulteriori informazioni.
Risposta alla domanda 2: Quali sono alcune delle cose che .NET Micro Framework non può fare?
Il micro-quadro non è in tempo reale come molti dei prodotti concorrenti. Lo scheduler è abbastanza semplice e non ottimizzato per sistemi che richiedono tempi deterministici.
Il TinyCLR interpreta l'IL dal prossimo "thread" in attesa per un 20ms. I thread possono fornire la sezione temporale assegnata chiamando lo Thread.Sleep(0). SOLO tra ogni thread time slice il Runtime Interpreter controlla i flag dagli eventi hardware e di invio al codice gestito o risveglia i thread se sono bloccati in attesa dell'hardware. Per quanto ho capito, non c'è modo per un thread di essere sbloccato da routine di servizio di interrupt di codice nativo (ISR) o per un thread con priorità più alta che interrompe preventivamente un thread con priorità più bassa.
Risposta alla domanda 3: Quali sono alcuni dei trucchi?
Tutto sembra funzionare, avete capito il come il runtime interperter opere di loop (la schedulazione dei thread e reagire agli eventi hardware) e poi si dimentica di raccolta dei rifiuti !!
È consigliabile ridurre al minimo la quantità di thrashing della memoria (rivedere attentamente ogni volta che si esegue il new un oggetto). Invece di creare e distruggere oggetti di uso comune, considera la possibilità di tenere un pool di oggetti solitamente in GC e di riciclarli quando necessario.
Risposta alla domanda 4: Esiste un mercato di terze parti valido per i dispositivi plug-in?
Il coinvolgimento di terze parti è principalmente nelle schede di sviluppo e progetti di riferimento sul lato hardware delle cose. Da un punto di vista del software, questo code-share link potrebbe essere di interesse. Come una questione secondaria, non dimenticare che la maggior parte degli strumenti di sviluppo VS2008 lavorare anche su .NET MF (ad es ReSharper e VisualSVN)
Siamo spiacenti, non avere una risposta alla domanda 5 come io non seguo questo tipo di cose Lo landing page for .NET MF su Microsoft sembra avere immagini di dispositivi commerciali ma non ho mai seguito i collegamenti.
Perché sulla Terra consiglieresti di passare a una piattaforma con cui non hai esperienza? –
@Binary Worrier. Perché la metodologia esistente impiega troppo tempo per arrivare a un mercato. E quindi, sto facendo la domanda qui prima di premere il grilletto. – AngryHacker
Sono curioso di sapere perché stai consultando un'azienda che produce dispositivi embedded quando non hai mai programmato un dispositivo incorporato? Mi sento male per la pessima compagnia ... sembra che abbiano preso la brutta fine del bastone. – jrista