Piattaforma a microcontrollore di EY.

[Paolino]

Al solo pensiero di dover saldare i 96 pin del connettore inizio ad aver caldo

Caldo? No, non è colpa dei 96 poli ma dei 44 gradi

Paolo.

[TardoFreak]

Saldare il connettore non è un problema, sono 3 file passo 2.54 e poi si possono saldare solo i contatti che interessano.

Ho ragionato sopra il micro e mi è sorto qualche dubbio sul PIC24.
Tutto vero quello che ha menzionato Paolino, tuttavia lo vedo incasinato da programmare in assembly. Le strutture microchip non sono il massimo in termini di semplicità.
E visto che questa piattaforma vorrebbe essere anche uno strumento didattico la scelta del PIC24 mi pare un po' azzardata per un neofita.

La butto lì e vada come si vuole.
Sto valutando la possibilità di far qualcosa su gli 8051 anche perché il core è diffusissimo, lo si trova anche nelle CPLD e FPGA, nel vari System On Chip, in pratica ovunque.
Sto anche valutando l' idea di superare il micro realizzando una macchina a stack, con poche istruzioni semi-interpretate (ovviamente da un micro più veloce della luce )
Una macchina basata su operazioni su stack (tipo il linguaggio RPN delle calcolatrici) è ottima per sviluppare compilatori di qualsiasi linguaggio. Se poi la macchina esegue questo assembly semplificato a notevole velocità diventerebbe un ottimo strumento didattico ed un buono strumento per applicazioni a sviluppo rapido.

[TardoFreak]

Ne butto lì un' altra,così, per parlare.
Nel neolitico c' erano i programmi "monitor". In pratica era una EPROM (o addirittura una ROM) che faceva da sistema operativo. Vabbè, parlare di sistema operativo oggi sarebbe una bestemmia. Tuttavia era un programma che collegava il microprocessore con relativo sistema costruito intorno, ad un terminale tramite RS232 e che permetteva di:
- Leggere la memoria visualizzandola in formato esadecimale ed ASCII,la stessa cosa che faceva l' HEXDUMP.
- Disassemblare a partire da un indirizzo
- Caricare in RAM un programma in formato Motorola-S o Hex o che dir si voglia.
- Lanciare un programma.
- Inserire dei breakpoint (in pratica delle software interrupt,le SWI del 6800) per interrompere l' esecuzione del programma.
- Eseguire il programma passo per passo.
- Visualizzare i registri.

[GuidoB]

Ottima, magnifica, grandissima idea, TardoFreak !!!
Non sono espertissimo, ma un STM32F1xx mi sembra una buona scelta, rivolta al futuro (e anche perché sto studiando gli ARM Cortex ). Eviterei un micro troppo semplice e limitato, si rischia un doppione di arduino.
Poi per le parti più ostiche (inizializzazione periferiche et similia) per chi non vuole studiarsele subito si può pensare a funzioni che semplifichino la vita.

Il monitor: ottima idea!

Penso anche a una base di codice riutilizzabile anche per programmi professionali, una specie di mini sistema operativo con multitasking cooperativo, modelli di procedure di interrupt e polling da prendere come base, che mettano tutti gli eventi in una coda FIFO di eventi con i relativi timestamp, una soluzione ben conosciuta e collaudata.

Poi un dispatcher che prenda gli eventi dalla coda e chiami gli event handler opportuni, implementati dall'utente come macchine a stati.
Anche un generatore di eventi di timeout (programmati chiamando opportune procedure tipo "setTimeout", "setPeriodicTimeout", "setAbsoluteTimeout" ecc.)...
Il tutto scritto in C o C++.
Penso sia opportuno usare un IDE già esistente o un insieme di strumenti free (penso a Eclipse + gcc + gdb).

Vado un po' a ruota libera, sono in vacanza... spero di concretizzare meglio più avanti.

Scrivo da un PC prestato... tra due settimane sarò ancora "autonomo", ma fino ad allora non so se potrò continuare a partecipare a questa interessante discussione... a risentirci!

[GuidoB]

Rieccomi ragazzi, mi sono venute in mente un po' di cose.
Partiamo dall'hardware.

1) E' necessario un RTC? Non si può implementare nel software? Lo dico perché non vedo molto senso nell'avere due quarzi, uno per il micro e uno per l'RTC, più il chip dell'RTC. Ho pensato che se il micro può generare degli interrupt o "tick", per esempio ogni circa 10 ms, si può tararne digitalmente la durata per far avanzare un orologio una volta al secondo. Questo orologio si userebbe per le temporizzazioni a lungo termine, mentre per quelle a breve o che non ammettono jitter si userebbero i "tick".

Esempio: ho dei "tick" di durata pari a 10,1234 ms. Ogni volta che c'è un "tick" sommo 43479672 a un contatore a 32 bit. A ogni overflow di questo contatore a 32 bit aggiungo 1 secondo all'orologio.
Questo numero (43479672) non rappresenta altro che la durata del "tick" espressa in unità di . Posso cambiare questo numero (taratura digitale) a passi di una unità alla volta. Ogni passo di una unità su 43 milioni corrisponde a una correzione di 23 parti per miliardo. 23 parti per miliardo corrispondono a 0,73 s l'anno, errore ben inferiore a quello dovuto a tolleranze e derive del quarzo.

Quindi, a meno che il chip dell'RTC incorpori un termometro e riesca a compensare le derive termiche del quarzo, o abbia qualche altra sofisticazione che renda comodo averlo (tipo alimentazione separata con pila al litio), io lo risparmierei.

Che ne dite? So di essere un neofita, e magari mi sfugge qualcosa e l'RTC hardware serve, ma mi sembra una buona idea, anche se su un aspetto tutto sommato secondario.

2)

Per l' eventuale espansione/prototipazione direi di usare connettori DIN a 96 poli. Costano poco. si possono montare sulle millefori formato eurocard ed una schedina di bus per montare le femmine.
Invece di usare quei connettori stupidi di arduino che limitano lo spazio ed hanno pochi pin.

Ottimo, si possono ottenere sistemi complessi e con tante espansioni.
Visto che come dici il connettore ha 3 file saldabili passo 2,54 mm, magari non costa tanto mantenere il profilo dei componenti basso, e così permettere a chi volesse di saldare, al posto del connettore DIN, 1 o 2 o 3 file di connettori "tipo arduino"... Boh, anche qui sono un neofita, ma mi sembra che potrebbe essere una possibilità utile a qualcuno.

Per il software, sarebbe bello avere un mini kernel con multi-tasking collaborativo (non-preemptive), base comune a cui ciascuno può attaccare degli event handler realizzati come macchine a stati. Sto scrivendo un articolo sulla programmazione a eventi, ecco come vorrei fare questo kernel, basato sullo schema "extended handlers":

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Che ve ne pare? E' un lavoro che può valere la pena? O magari sapete se c'è già fatta una soluzione open-source?

Poi per le macchine a stati voglio provare "The state machine compiler".

mi sarebbe piaciuto ... poterlo programmare tramite un terminale (quindi con un linguaggio interpretato o semi-compilato) collegato al PC tramite una seriale virtuale , provando il programma passo per passo e modificarlo tutte le volte che mi viene un' idea per migliorare il ciclo di collaudo.

Mi vengono in mente Lua, Python e Java. La macchina virtuale Java forse è un po' pesante, ma chissà... Android usa una cosa simile. Forse Python è meglio, ma ne so ancora troppo poco. Lua assomiglia più al C e ha un interprete molto leggero. Bisogna studiare e provare, provare, provare... Qualcuno ha qualche consiglio?

A me questo progetto sembra una bellissima idea.

[DarwinNE]

Mi ero perso questa bella discussione. Io è da un po' che non smanetto con i micro anche per una semplice ragione: lavoro solo su MacOSX e la più parte dei programmi di sviluppo sono disponibili solo su Windows (o almeno lo erano qualche anno fa, non so se la situazione sia cambiata). Sono riuscito ad usare un PicKit 2 da Mac per programmare in assembler con un po' di salti mortali, ma se ci fosse qualcosa di comodo usando il C non nego che la cosa mi interesserebbe.
Non so se se n'è già parlato sopra, non ho riletto proprio tutti i messaggi, ma mi piacerebbe anche poter far comunicare la scheda con una rete (Ethernet o WiFi), oppure poter leggere e scrivere da una schedina di memoria, per esempio per fare un datalogger.

[TardoFreak]

Inizialmente bisogna decidere l' hardware, il micro, su cui far girare il tutto e su cui si possano implementare poi eventuali idee.
Per fare una cosa ben fatta bisognerebbe avere un micro potente ma non troppo incasinato e che, almeno inizialmente, si potesse programmare con un IDE ed avere un compilatore C gratuito. Gli ARM sono troppo complicati per un neofita quindi direi di andare su un PIC32 per diversi motivi.
- Non ostante sia potentissimo e ricco di periferiche furbe, non è più complesso di un PIC24. Con un semplice progetto di base contenente le opportune inizializzazioni ed un punto "place your code here!" anche un principiante dovrebbe farcela senza troppi casini.
- Si programma e si debugga con il PicKit 3 che molti hanno già e che comunque costa poco.
- L' IDE è gratuito nella versione Lite. Non è un mostro di ottimizzazione ma il micro è talmente veloce e con talmente tanta memoria che i programmi realizzati con questa versione sono ottimi.
- Nessuno vieta di realizzare delle librerie precompilate ottenute con una versione commerciale. Forse un' anima pia con licenza commerciale potrebbe farlo, cambio infinita riconoscenza.
- Se si hanno voglia e capacità il micro offre molto, tantissimo! USB OTG, linee seriali in quantità industriale, Ethernet, flash e ram a volontà e chi più ne ha più ne metta.

In questo modo, avendo il tempo di scrivere funzioni e cose varie per arricchire il sistema, si avrebbe già una base hardware a basso costo, espandibile ed in grado di permettere di iniziare il lavoro supportati da un compilatore C. Per molti sarebbe già sufficiente ed ognuno potrebbe partecipare iniziando a tirar giù funzioni di uso comune, tutorials per principianti e qualche applicazione appetitosa/educativa/divertente.

Che ne dite?

[TardoFreak]

Aggiornamento:
I connettori DIN41612 a 96 pin (sia maschio che femmina) si comprano a 3 euro l' uno. Con 96 pin si possono portare tutti i segnali utili del micro e alimentazioni e qualcos' altro di sfizioso. L' espansione sarebbe garantita e lo si monta su millefori senza problemi.
Il PIC32MX795F512L costa 8,64 euro a comprarne 10 ed ha tutto a bordo, proprio tutto.

Attendo pareri.

[simo85]

Ragazzi, appena ho tempo mi leggo la discussione e spero di partecipare e dare quale aiuto al progetto che, come si dice dalle mie parti (ed anche quelle di GuidoB), mola un huevo..

[simo85]

Non sono esperto sull'argomento perché ancora non ho usato un SO su un micro, ma visto che si è parlato di kernel e SO, se si potesse usare FreeRTOS non penso sia una cattiva idea.

Non l'ho ancora mai usato, ma ci si potrebbe "sporcare le mani" secondo il micro ad usare, già che supporta 31 architetture.

http://www.freertos.org/

Cosa ne pensate?