Ripensare l’approccio alla tecnologia Mcu

microcontrollori costituiscono di fatto la base su cui è costruita la vasta maggioranza dei moderni sistemi embedded e forniscono agli ingegneri una combinazione di flessibilità, convenienza economica e prestazioni ragionevolmente solide. Grazie a tali caratteristiche, essi sono stati in grado di raggiungere vendite unitarie sorprendenti. Con il raggiungimento della maturità, il mercato delle Mcu è diventato sempre più dipendente da un piccolo numero di architetture generiche ampiamente usate. Tuttavia, ciò è pressoché in completo contrasto con le esigenze che stanno ora emergendo all’interno di alcune aree del mercato embedded. Nell’articolo che segue esamineremo il divario che si è creato fra ciò che gli ingegneri vogliono e ciò che essi si possono realmente attendersi. Malgrado le caratteristiche comuni delle serie di prodotti Mcu con la piattaforma di base da cui essi hanno origine siano state chiaramente uno dei principali fattori che hanno contribuito al successo fenomenale di questi dispositivi, queste ultime determinano anche  una restrizione del loro campo d’applicazione. Questo potrebbe lasciare in futuro sempre meno spazio per la differenziazione. L’impegno dell’industria su applicazioni come l’IoT, ad esempio, ha implicato il fatto che è stato introdotto sul mercato un vasto numero di Mcu, in cui gli obiettivi  principali sono di rendere il budget di potenza il più possibile ridotto e di mantenere livelli elevati di sicurezza, con opzioni di connettività supportate unicamente di tipo wireless. Malgrado ciò consenta di concretizzare le opportunità offerte in questo settore, allo stesso tempo altre applicazioni, in cui è previsto un insieme totalmente diverso di caratteristiche, rischiano di essere sottovalutate.

Aspetti da considerare

Un caso emblematico si osserva nei progetti di sistemi in cui sono presenti grandi quantità di dati multimediali che devono essere gestiti. Le moderne Mcu con funzione generica sono scarsamente dotate di risorse per queste funzioni, e spesso riescono a malapena a farvi fronte. Le loro risorse di elaborazione finiscono per essere dirottate improvvisamente in direzioni diverse, nel tentativo di gestire i dati in arrivo, mentre allo steso tempo occorre ancora occuparsi di altre funzioni operative standard. Di conseguenza possono sorgere dei problemi di latenza. Ciò però è in diretto contrasto con scenari applicativi in cui è previsto il funzionamento deterministico, ad esempio i sistemi di visione complessi che ispezionano le saldature sui Pcb non possono essere interrotti dal buffering. La disponibilità di un numero di I/O sufficienti nelle Mcu è un altro aspetto di cui spesso non ci si occupa adeguatamente, malgrado l’ampia varietà di tecnologie di interfaccia diverse che sono ora presenti nei progetti embedded. Ad esempio, l’implementazione di un’interfaccia Usb su Mcu non è normalmente così facile da effettuare, dato che gli aspetti legati allo sviluppo software tendono ad essere non sufficientemente coperti. Di conseguenza, gli ingegneri embedded spesso non hanno il supporto di cui necessitano. Inoltre le Mcu in genere disporranno solo del supporto incorporato alla funzionalità dei dispositivi Usb (non agli host Usb). Si dovrebbe riconoscere che, in generale, le funzionalità I/O di gran parte delle Mcu attualmente presenti sul mercato non si estendono abbastanza oltre. L’offerta di un’ampia varietà di opzioni per la connettività diventerà sempre più importante in futuro. In particolare, ci sarà probabilmente la necessità di gruppi di I/O che renderanno la Mcu più adatta a gestire specifici tipi di applicazioni. Le Mcu non sono naturalmente l’unica strada disponibile agli ingegneri; occorre anche considerare l’opzione system-on-chip. A differenza delle Mcu, questi ultimi offrono una soluzione più ottimizzata, con parametri di prestazione elevati, oltre ad offrire un ingombro minore e vantaggi di costo sul lungo termine. Vi sono tuttavia una moltitudine di altri aspetti che impattano in modo sostanziale sulla loro attrattiva. L’investimento finanziario iniziale richiesto, lo sforzo di ingegnerizzazione e il tempo richiesto per lo sviluppo SoC devono essere tutti considerati. Per giustificare l’adozione di questa opzione occorre essere assolutamente sicuri nella presenza di una domanda di elevati volumi unitari, oppure essere certi che non sarà necessaria alcuna modifica al progetto per un lungo periodo di tempo. Anche in tal caso esistono dei rischi associati. Se si trova un baco, allora potrebbe occorrere del tempo per correggerlo, il che porterebbe a ritardi nel rilascio del prodotto finale. Per questi motivi, è forse ancora preferibile optare per un dispositivo pronto all’uso.

Più risorse su hardware

Mentre la vasta maggioranza dei produttori di Mcu si sono concentrati sull’implementazione di caratteristiche e di funzionalità su software, la tattica di Bridgetek consiste nell’avere molte più risorse realizzate su hardware. Di conseguenza, le serie FT900 e FT930 della società sono in grado di assicurare il funzionamento ottimizzato per le prestazioni che mancano nelle Mcu generiche. La tecnologia avanzata incorporata per l’interfacciamento è la chiave di ciò. Attraverso quest’ultima, queste Mcu sono in grado di fornire bridge dedicati fra I/O veloci, consentendo agli elementi discreti di un progetto di accedere all’hardware più idoneo disponibile. Ciò significa che l’interfacciamento dei vari elementi di elaborazione e degli elementi di I/O sulla Mcu può essere effettuato in modo completamente deterministico (senza alcun pericolo che si produca una latenza). La Fig. 1 descrive un esempio di applicazione significativo. In questo caso è presente un sistema di più display con controllo tattile, che sarebbe adatto per l’installazione in un contesto Point-of-Sale o di cartellonistica digitale. Il contenuto di immagini che deve essere rappresentato dal sistema può essere fatto scorrere su tutti e 4 gli schermi. La manipolazione con tocco può essere applicata a ciascun display in modalità isolata o simultaneamente in tutti - fornendo così un’esperienza utente più avvolgente che attirerà l’attenzione. Questo esempio mette in evidenza la capacità delle Mcu FT930 di Bridgetek di creare un bridge Usb e quindi successivamente di controllare 4 periferiche Spi separate attraverso l’unità proprietaria Usb D2xx. In questo caso particolare, le periferiche sono chip di controllori grafici con funzionalità tattile incorporata. Comunicando attraverso un canale Usb 2.0 D2XX, la Mcu prende i dati di contenuto forniti dal Pc host a li applica ai vari display. Immagini panoramiche di grandi dimensioni sono divise in parti e memorizzate come immagini Jpeg sul Pc host. La Mcu invia i comandi al Pc per prelevare le parti richieste e trasferirle al controllore grafico corrispondente, di modo da poter essere decodificate e visualizzate. Essa è in grado di controllare i 4 controllori grafici FT813 Eve connessi attraverso le sue risorse di interfacciamento integrate di tipo quad Spi. Ciò significa che si comporta in realtà come un hub - distribuendo i dati su più display (piuttosto che essere semplicemente confinata a una disposizione singola di tipo punto-a punto). Allo stesso tempo la Mcu esamina i 4 pannelli con funzionalità tattile alla ricerca di segnali in ingresso da parte dell’utente. Essa registra i tocchi e le strisciate in relazione all’accelerazione, al rallentamento o al congelamento del contenuto dell’immagine. Le immagini possono essere scorse in senso sia orizzontale, sia verticale, a seconda della natura dell’applicazione. In un qualsiasi momento determinato, le 4 porzioni di immagine sono prelevate, scaricate, decodificate e visualizzate, allo scopo di ottenere un aspetto di scorrimento uniforme. Se si tenta di realizzare uno schema così sofisticato usando una Mcu generica, ci sarebbero numerose sfide da superare. Queste sarebbero in primo luogo legate allo sviluppo di codice per il dispositivo Usb. Inoltre, sarebbe probabilmente necessario connettere in sequenza diverse Mcu. In più, questa connessione in sequenza porrebbe potenzialmente serie limitazioni sulla velocità del sistema, per via della mancanza di funzionalità Qspi. La Fig. 2 mostra un altro esempio di applicazione - questa volta in relazione al flusso dei dati. Uno schema di questo tipo potrebbe essere vantaggioso per ottenere ad esempio funzioni di sicurezza domestica. “Campanelli intelligenti” di questo tipo stanno già riscuotendo interesse da parte di una fetta crescente di pubblico. In questo caso, l’immagine visiva catturata da una fotocamera remota è trasmessa attraverso un bus Can (o possibilmente in alcune circostanze attraverso un’interfaccia Ethernet) che si connette a un display con funzionalità tattile, per poter essere controllata. In altri scenari, come nella sorveglianza o nell’ispezione in fabbrica, l’utente avrà bisogno di assicurare che sia mantenuta la visualizzazione del contenuto in tempo reale, senza dover ricorrere al buffering dei dati. Attraverso il controllo tattile, è possibile congelare il display (se si individua un problema potenziale) e quindi è possibile ingrandire una particolare regione di interesse per un esame più approfondito. La Mcu è in grado di utilizzare le funzionalità tattili e audio del relativo controllore grafico Eve per rappresentare i dati video provenienti dalla fotocamera (più un manuale utente su schermo), catturando al contempo anche i tocchi su schermo tattile ed emettendo suoni sintetizzati. La velocità del flusso di dati si adatta alla risoluzione e alla velocità dei fotogrammi della specifica fotocamera. Le funzionalità Can, Camera Link e Ethernet delle Mcu di Bridgetek sono fondamentali per realizzare questo schema, mentre le Mcu più generiche non disporrebbero di una simile gamma di interfacce necessarie, rendendo di conseguenza il sistema molto più difficile da ottenere. Un esempio finale da considerare è la distribuzione dell’audio. Una sala conferenze potrebbe avere più microfoni connessi a diversi altoparlanti in una disposizione complessa. Ciò richiederà con ogni probabilità l’installazione di un’infrastruttura Ethernet. La velocità di trasmissione dei dati e la necessità di evitare i problemi di latenza, implicano che l’interfacciamento con Mcu costituirà ancora una volta l’approccio migliore.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome