[OT] Altri mondi... altri Arduino...

Apro questo post in quanto ci sentiamo un pò orfani del vecchio post sulle MCU. L'argomento portante saranno, si altre MCU, ma inquadrate nell'Universo Arduino, ovvero tutte le alternative Arduino-like. Questo sarà sufficiente per non essere completamente OT e tirare a campare nella sezione più frequentata dagli Harwaristi.

Vedremo i limiti, i vantaggi e i problemi di tutte le soluzioni che offre il mercato.

Innanzitutto facciamo una carrellata, credo abbastanza esaustiva, di tutte le board Arduinesche, poi le analizzeremo nel dettaglio, con pregi e difetti.

Microchip:

MAX32

UNO

STM32:

Maple

Nucleo

MBED: (NPX, Freescale, vari)

NPX Freescale Nordic

Renesas:

Sakura

Microchip:

Pinguino

Texas Instruments:

MSP430 Launchpad

Stellaris

Esistono poi ulteriori rivisitazioni della piattaforma Arduino, ma veramente poco riuscite o di scarso successo.

BaBBuino: Apro questo post in quanto ci sentiamo un pò orfani del vecchio post sulle MCU.

Il thread sulle MCU mica è stato cancellato, è stato solo spostato in Bar Sport perché nato con un fine e divenuto contenitore per lo spam.

E per non dimenticarlo: :grin: http://forum.arduino.cc/index.php?topic=190930.0

Pensavo fosse morto di morte naturale! :D

Cmq questo è diverso. Vediamo se diventa interessante come quell'altro ai tempi d'oro.

Appena ho tempo inizio con la descrizione delle Board Microchip, a mio avviso le migliori in assoluto.

Possiamo commentare? Ho una Maple, carina, piccola come formato, ma... IDE fermo allo 0.0.12 (beta) librerie... solo parziali e sono ferme da un bel pò. In pratico, poco supporto. Questa: Maple Cortex M3

P.S. mi attizza la Nucleo.

Infatti Maple è stato un semi-pacco, nonostante le potenzialità eccelse degli STM.

La forza di questi sistemi è l'IDE ed il supporto around. Non è l'Hardware da 30 GHZ, con 400 periferiche super-evolute, a fare la differenza.

Tutt'altra storia è NUCLEO, che sfrutta l'ottimo Hardware STM32, con diversi core tra cui il Cortex-M4 che ha il supporto FPU e DSP. Penso che di più non si possa pretendere come Hardware per questi sistemi (oltre c'è un confine con gli embedded PC Linux) . Il sistema si appoggia alla piattaforma MBED, matura e molto articolata. In pratica perfino un Progettista professionista potrebbe concepire un sistema complesso, in molto meno tempo che con gli strumenti professionali che ha a disposizione. Solo il pregiudizio gli impedirebbe di utilizzare detto sistema, non le prestazioni in se.

@BaBBuino, per quanto riguarda i futuri dettagli, verrà analizzato anche l'hw/sw per lo sviluppo, sempre in ottica smanettoni squattrinati XD? Grazie

BaBBuino: 1.Tutt'altra storia è NUCLEO, che sfrutta l'ottimo Hardware STM32, con diversi core tra cui il Cortex-M4 che ha il supporto FPU e DSP. Penso che di più non si possa pretendere come Hardware per questi sistemi (oltre c'è un confine con gli embedded PC Linux) . 2.Il sistema si appoggia alla piattaforma MBED, matura e molto articolata. In pratica perfino un Progettista professionista potrebbe concepire un sistema complesso, in molto meno tempo che con gli strumenti professionali che ha a disposizione. Solo il pregiudizio gli impedirebbe di utilizzare detto sistema, non le prestazioni in se.

  1. scusa DSP stà per ?

  2. mi interessa questo discorso. Mi spiego. Arduino ha di bello la semplicità, per me che sono un neofita delle MCU. La stessa idea mi pare la vogliano applicare per chipKit e Maple (con però MCU a 32 bit e non 8 bit). Però, chipKit è PIC e mi pare che programmare "professionalmente" PIC (soprattutto standalone) sia molto più complesso rispetto a quello che l'IDE proposto nasconde. Anche la Maple (STM32) ha un IDE che "scimmiotta" quello di Arduino, tutto per semplificare. Ma provando la STM32F4discovery con altri IDE le cose mi sembrano più complesse. Però con Arduino e gli Atmel si può passare a sviluppare a più basso livello scavalcando l'IDE, e si può passare a fare degli standalone. Mi pare arduo con PIC e STM32 passando da quelle schede simi-Arduino. La Nucleo invece se usa la piattaforma MBED (che non conosco ho solo letto poche cose) permetterebbe di partire da quella scheda e poi andare su qualcosa di più avanzato ? (un pò lunghino come punto 2 !!! )

Il senso di questi Hardware è l’ambiente di sviluppo: scrivi tre cazzate, e hai un software funzionante.

Tutte le piattaforme menzionate, TUTTE, hanno un’intefaccia Arduino Like, Linguaggio compreso. Salvo qualche piccola variante poco significativa, il C di questi oggetti è BaBBEo-level, ovvero il punto di forza cui facevamo riferimento prima.

Quindi il ChipKit è identico ad Arduino come programmazione, pur disponendo di circa 8-10 volte la potenza di calcolo, molta più Flash, molta più RAM, e di periferiche molto più performanti.

Nel momento che vuoi uscire dall’ambiente “domestico” dell’IDE, entri nelle nebbie, nel pantano della vera programmazione, non esiste una via di mezzo.

E poi con queste piattaforme particolarmente evolute (Freescale, STM, Microchip) si possono fare cose da turchi, pur senza conoscere gli aspetti complessi di questi oggetti. Non vedo il senso di andarsi ad impelagare in situazioni extra-IDE.

Per i PIC, non è poi così vero che sono difficili da programmare, anzi. ma alla fine nemmeno gli STM32. Bisogna solo mettersi dietro e studiare.

Ora faccio un esempio “tangibile”…

Con una Ambiente Arduinesco (qualsiasi) grosso modo un Hello world sarà così:

/*
int led = 13;

void setup()
 {                
  pinMode(led, OUTPUT);     
}

void loop()
 {
  digitalWrite(led, HIGH);   
  delay(1000);               
  digitalWrite(led, LOW);   
  delay(1000);              
}

Per far lampeggiare un Led con un STM32 in maniera “grezza”:

#include "stm32f10x.h"


void delay(uint32_t cnt) {
	while (cnt) {
		cnt--;
	}
}

void clock_init(void) {
	RCC->CR |= RCC_CR_HSEON;

	while (!(RCC->CR & RCC_CR_HSERDY));

	RCC->CFGR |= RCC_CFGR_PLLMULL9 | RCC_CFGR_PLLXTPRE_HSE | RCC_CFGR_PLLSRC_HSE;

	RCC->CR   |= RCC_CR_PLLON;

	while (!(RCC->CR & RCC_CR_PLLRDY));

	RCC->CFGR |= RCC_CFGR_HPRE_DIV1 | RCC_CFGR_PPRE1_DIV2 | RCC_CFGR_PPRE2_DIV1;

	FLASH->ACR |= FLASH_ACR_LATENCY_2;

	RCC->CFGR |= RCC_CFGR_SW_PLL;

	while (!(RCC->CFGR & RCC_CFGR_SWS_PLL ));
}


int main(void) {

	clock_init();

	RCC->APB2ENR |= RCC_APB2ENR_IOPCEN | RCC_APB2ENR_IOPEEN;

	GPIOC->CRL = (0x03 << (7 * 4)) | (0x03 << (6 * 4));

	GPIOE->CRL = (0x04 << (5 * 4)) | (0x04 << (4 * 4));

	while (1) {
		if((GPIOE->IDR & (1 << 4)) == 0) {
			GPIOC->BSRR |= GPIO_BSRR_BR7 | GPIO_BSRR_BS6;

			delay(0xFFFFF);

			GPIOC->BSRR |= GPIO_BSRR_BR6 | GPIO_BSRR_BS7;
		}

		delay(0xFFFFF);
	}

	return 0;
}

I due programmi sono perfettamente equivalenti, fanno le stesse cose, ma nel caso del secondo listato, Immagino che qualcuno, alla fine della 3a riga, abbia già lanciato dalla finestra la scheda STM32…

Eppure, sapendo cosa sono quelle righe (volendo possiamo anche vedere il significato insieme), non è affatto difficile scrivere del codice. ma ovviamente lo sforzo e il tempo saranno diversi.

BaBBuino:
Per i PIC, non è poi così vero che sono difficili da programmare, anzi. ma alla fine nemmeno gli STM32. Bisogna solo mettersi dietro e studiare.

Quello che mi mette in difficoltà è il grande numero di MCU e la loro variabilità.
Ovvero di PIC c’e’ ne sono una marea, ogn’uno con le sue peculiarità e nei IDE professionali devi indicare il processore giusto, anche per STM32, il tuo esempio credo sia per “stm32f10x.h” io ho la stm32f407vg, penso quel codice devo cambiarlo.
L’ide di Arduino mi semplifica, secondo me, non tanto i comandi, ma la “variabilità” tra MCU e un’altra (nei limiti, ovvio).
Anche la questione dei fuse, affogati nell’IDE, mi mette in difficoltà sui pic. Sui alcuni pic 16 ci sono pochi fuse da conoscere, già su un pic18f ho visto una marea di fuse (intendo bit con significato)

L'IDE di Microchip (MPLAB X) ti crea un file di default per il chip che hai scelto per i settaggi, che poi tu puoi andare ad editare e modificare solo nei punti in cui vuoi cambiare qualcosa. E' ovvio che l'IDE di Arduino semplifica, ma semplifica perché hai un clock fisso, un settaggio del micro fisso e tante altre cose preimpostate che non puoi cambiare.

1) I fuse te li devi dimenticare. Devi considerarli come normali variabili di configurazione. Inoltre si! Sono tanti... ma alla fine, quando muovi quei soliti 3 o 4, il resto ti rimane identico nei secoli dei secoli.

2) Ci vuole tempo. Vi siete abituati con Arduino che in 10 minuti avete capito tutto, e si pretende che anche il resto "del mondo" debba essere così.

3) Bisogna concentrarsi su una piattaforma, una famiglia, alla volta. Non si può essere tuttologi di tutto. Nel momento che scegli i PIC32, ti butti a capofitto su di loro. Se scegli ARM, ti butti per qualche mese su ARM (non due giorni al mese! )

4) DSP, genericamente, significa Processore Digitale di Segnali. In sostanza si tratta di Microcontrollori che hanno al loro interno un Core moltiplicatore e divisore Hardware. Mi spiego: Per fare una moltiplicazione, chessò, 12 x 11, la MCU non lo fa direttamente, ma somma 11 volte il numero 12., e come minimo ci vogliono 11 cicli di clock:

Assembler per Babbuini: 1: somma 12 a 12 e salva il risultato nel registro R10 2: somma 12 al registro R10 e salva il risultato in R10 3: somma 12 al registro R10 e salva il risultato in R10 4: somma 12 al registro R10 e salva il risultato in R10 5: somma 12 al registro R10 e salva il risultato in R10 6: somma 12 al registro R10 e salva il risultato in R10 7: somma 12 al registro R10 e salva il risultato in R10 8: somma 12 al registro R10 e salva il risultato in R10 9: somma 12 al registro R10 e salva il risultato in R10 10: somma 12 al registro R10 e salva il risultato in R10 11: somma 12 al registro R10 e salva il risultato in R10

Alla fine, nel registro R10 c'è il risultato della moltiplicazione, e ci ho messo 11 (in realtà molti di più per vari overhead) cicli di clock.

Figurati per moltiplicare 117x769... ci vuole un miliardo di cicli!!!

Ora il moltiplicatore Hardware, di solito a 16 bit, può moltiplicare IN UN SOLO CICLO di clock un numero di 16 bit con un altro di 16 bit (65535 x 65535 nel caso di Unsigned), per un numero finale di 32 bit (circa 4 miliardi), salvato in due registri da 16 bit. Idem per la divisione!

Assembler per babbuini: 1: moltiplica 12354x34657 2: salva il risultato in R10(LSB) e R11(MSB - Fine! - Già finito? - Si! :grin:

Quindi con delle singole istruzioni si eseguono calcoli che implementati in una normale unità ALU richiederebbero innumerevoli istruzioni più semplici Questo è detto semplificando molto.

Riassumendo: Un DSP ha di solito nella sua ISA delle singole istruzioni per eseguire rapidamente calcoli molto complessi (es. grafica vettoriale).

A questo si aggiunge la FPU, ovvero l'unità in virgola mobile. Che significa? Significa che di fianco alla ALU (che gestisce interi) c'è un coprocessore matematico che esegue calcoli, in pochi cicli di clock, che utilizzano numeri con la virgola (Es. Seno, Coseno, Pi greco ecc.). Senza la FPU, i calcoli in virgola mobile vengono emulati via Software (qualche funzione, libreria etc.) ma naturalmente, come per le funzioni DSP, in questo modo l'esecuzione è molto moooolto più lenta!

Circa il DSP c'è da dire che negli ultimi anni il confine tra MCU con e senza, è diventato abbastanza labile, perchè molte MCU convenzionali cominciano ad integrare anche qualche funzione (istruzione) tipica del DSP (tipo la MAC = multiplay an accumulate, in singolo ciclo di clock) Quindi? Quindi... boh? Certe MCU sono anche mezzi DSP. Esempio, il Cortex-M3 ha qualche funzione DSP, mentre il Cortex-M4 ha un vero e proprio Core DSP completo.

Infatti la Board che hai tu, con il STM32F4xx, è un M4, e differisce dalla mia STMF10x, che ha Core M3, proprio perchè in più (ma non solo) una unità DSP e FPU integrate.

BaBBuino: ma ovviamente lo sforzo e il tempo saranno diversi.

... ed anche la soddisfazione :D

PS: la Freedom della Freescale (quella chiamata Freescale all'inizio) la reputo una bomba se consideri il suo costo irrisorio (metà di un Arduino Uno). Ce l'ha un mio amico, personalmente però non l'ho mai provata. Anche se i Freescale mi piacciono perché sono fatti in modo più intelligente.. ricordo di una gestione di un pwm, fatto al politecnico, che è stato molto più semplice rispetto ad Atmel e Microchip che invece avevo in casa. Parlo ovviamente del codice in versione "brutta e lunga".

Il problema di quelle schede è che colpiscono l’immaginario per l’Hardware ultrapotente: Convertitore AD a 400 bit, Comparatore con demodulatore DELTA-SIGMA, Modulo crypto-engine a supersimmetria, Encoder in quadratura al quadrato, con triangolazione del cerchio, 10 giga di Flash, 800 mega di Ram, antani alla massima potenza.

E poi… quando ce l’hai davanti e ci devi fare qualcosa… cominci… beh… adesso… ehm… ci faccio… poi coso il coso… flaggo il flag, ci collego la cosa là e… e… e se c’è un LED sulla Board… LO FACCIO LAMPEGGIARE; ECCO!
Alla fine poi si risolve in questo modo. Si fa lampeggiare un LED!

Suggerisco Hardware meno esagerati, anche semplici, ma compresi a fondo!

Mi iscrivo ... iscrivendomi X iscrizione :)

BaBBuino: Il problema di quelle schede è che colpiscono l'immaginario per l'Hardware ultrapotente: Convertitore AD a 400 bit, Comparatore con demodulatore DELTA-SIGMA, Modulo crypto-engine a supersimmetria, Encoder in quadratura al quadrato, con triangolazione del cerchio, 10 giga di Flash, 800 mega di Ram, antani alla massima potenza.

E poi.. quando ce l'hai davanti e ci devi fare qualcosa.. cominci... beh... adesso... ehm... ci faccio... poi coso il coso.. flaggo il flag, ci collego la cosa là e.. e... e se c'è un LED sulla Board... LO FACCIO LAMPEGGIARE; ECCO! Alla fine poi si risolve in questo modo. Si fa lampeggiare un LED!

Suggerisco Hardware meno esagerati, anche semplici, ma compresi a fondo!

Straquoto! Io ho cominciato con gli 8 bit e sto ancora su quelli. Il freescale che avevo provato era su 16bit, e qualche differenza si era notata. Ma di fatto, anche un dsPIC a 32bit funziona (SUPPONGO! visto che non ce l'ho) in modo simile ad un PIC18F, ma permette molta più capacità di elaborazione che, io, ora non so sfruttare. A sua volta, il PIC18F47J53 che ho è incredibilmente più potente dell'Atmega328. Ma come punto di partenza è stato proprio quest'ultimo.

x iscirzione...

BaBBuino: LO FACCIO LAMPEGGIARE; ECCO! Alla fine poi si risolve in questo modo. Si fa lampeggiare un LED!

ROTFL!!!

A riuscirci.... :~

Riccardo

Azz, la chipKit Uno (penso anche la Max32) sono 3.3V =(

E quindi? :drooling_face:

Preferisco pin a 5V, un pochettino meno di problemi (dai, su sonon pur sempre un softwerista :blush: )