Dimenticavo un piccolo dettaglio, dove cavolo lo metti il compilatore C/C++ per AVR, con tutte le librerie e il core di Arduino, te le concedo precompilate, in solo 256k di flash del Mega2560 ? 
La prima cosa che ho detto è stata che serve memoria di massa e codice interpretato.
residente su questa, lo consideravo sottinteso
Poi ho detto che serve un linker
Che il linker legga da memoria di massa e scriva su memoria di massa è parimenti sottinteso
Non dimentichiamoci che qualunque architettura hardware abbiano, sempre di macchine parliamo
Turing ha dato delle dimostrazioni, se ricordo bene
Poi che sia una sega mentale, inutile e complicatissima siamo d'accordo
Ma se lo op comincia con un editor di linea io lo seguo
Personalmente dubito che nemmeno cominci...
Ma tant'è...
Io, oltre quello che ha detto Astro, ribadisco quello che ho detto prima; Arduino e queste MCU sono pensate per fare da controllori di circuiti. Invece di creare un circuito ad-hoc ti permettono di avere un circuito "semplificato" perché controllato da un piccolo cervello. Stop.
Non abbiamo un piccolo PC alla Raspberry con inoltre un Sistema Operativo che permette di gestire i file.
Essere etichettato come il male in persona da parte tua astro non mi stupisce e anzi un po' mi lusinga haha
Parlando seriamente, non volevo di certo creare discussioni o malintesti, semplicemente
Ho trovato interessante immaginare se e' possibile creare uno strumento in grado di programmare e testare un arduino che non fosse un prodotto commerciale basato sulla concurrency, ma qualcosa di piu' basso livello che io potrei costruire in casa. Studiando le vulnerabilita' presenti nella nostra rete e nei nostri computer mi spaventa pensare che potrebbero smettere tutti di funzionare e che avere la casa piena di arduini e pezzi elettronici non mi aiuterebbe a risolvere la situazione o manutenzionare i sistemi che ho gia messo in produzione. A parte gli scherzi, il movimento maker e' basato sul fai da te o DIY, lo stesso che ha creato l'Arduino Boy o qualsivoglia versione di tetris possibile, perche' non anche questo?
Quindi scartando la possibilita' di usare c o c++ ma scegliendo la strada dell'interpreter se non ho capito male andrebbe sviluppato una sorta di bootloader in grado di leggere dalla sd il programma e interpretarlo utilizzando un proprio interpreter.
Quello che non mi e' chiaro architetturalmente e' come e se potrebbe essere possibile includere condizionalmente diverse funzionalita', intendo che la funzionalita' della seriale o dell'i2c non sempre vengono utilizzate ma nel linguaggio da interpretatare possono sempre essere richieste... quindi immagino sarebbe una versione piu' lenta (per colpa dell'interpreter) e con meno funzionalita' dell'arduino, perche' non ci puo' stare tutto soprattutto perche' sull'arduino un sacco di funzionalita' si overlappano nell'uso di timer, interrupt e cosi' via.
Seguendo questo approccio, l'unico programma compilato sarebbe l'interpreter e quindi il bootloader se cosi' si puo' chiamare, che ovviamente e' l'unica cosa che non va perduta per nessun motivo nel caso dell'apocalisse
docsavage:
Turing ha dato delle dimostrazioni, se ricordo bene
E io ti ribadisco il concetto che gli AVR sono ad architettura Harvard, mi spieghi come pensi di caricare nella flash, di volta in volta, come serve, i vari pezzi del compilatore, del linker, le librerie da linkare, etc. ?
Ti rammento che sugli AVR è possibile scrivere la flash solo dalla memoria protetta, quella dove risiede il bootloader e dal normale codice operativo non hai accesso a quell'area per lanciare una tua routine, devi per forza fare un reset, inutile dire cosa succede quando resetti.
Se non te lo ricordi te lo rammento io, sulle macchine ad architettura Harvard non è possibile eseguire del codice dalla ram dati, solo dalla memoria di programma, che può anche essere una RAM ma sugli AVR sarebbe comunque non riscrivibile in nessun caso a run time.
Gli AVR, tutti quanti inclusi gli Xmega, sono piccole mcu progettate per scopi operativi low level, se ti serve di più ci si sposta sulle mcu di fascia media e alta a 32 bit, ma pure con queste ci sono dei limiti invalicabili, per ogni cosa serve il giusto hardware/software, tutto il resto sono solo pippe mentali o fantascienza.
Por lo op: non hai capito il mio discorso
Io parlavo di compilatore intercambiabile con l'attuale
Solo che gira interpretato, è qui nulla di particolare, sul processore di arduino
Tu parli di rifare il linguaggio....
gioscarab:
Quindi scartando la possibilita' di usare c o c++ ma scegliendo la strada dell'interpreter
L'interprete è possibile, ma non sarebbe più Arduino inteso come sistema di programmazione, sopratutto ti scordi la miriade di librerie che hanno fatto il "successo" di Arduino.
In pratica avresti un interprete, linguaggio da definire, residente nella Flash e un programma operativo, molto piccolo residente in RAM sotto forma di token, per occupare il minimo spazio possibile, oppure tutto in flash caricabile da SD all'avvio, magari tramite la pressione di un apposito pulsante, però nel secondo caso tanto vale caricare un normale .hex per Arduino.
Qualcosa di simile esiste per i PIC i picaxe, però serve comunque un pc per editare il codice e trasfomarlo in token.
Mai voluto scrivere la flash
Mi basta processare un file da sd verso sd
E questo si può fare certamente
E questo è esattamente quello che fa un editor di linea
Poi da li si parte
Mai pensato, io, di compilarlo sulla uno il codice per la stessa uno che se lo compila
Quello si che è una sega mentale, incestuosa oltretutto
hahaha da un Uno a un Uno non e' solo incestuosa!!
Cmq trovo, malgrado i toni, molto istruttivo questo post e vi ringrazio in ogni caso per mettere in share la vostra esperienza.
Si sono d'accordo devo dire di essere stato influenzato nel pensare questa cosa da come e' fatto picaxe, anche se credo possa essere possibile fare in modo che non serva un pc per farlo, ma che con il surrogato di cui stiamo parlando o pseudo computer sappia prendere il linguaggio scritto concepibile dagli umani in loco sulla stessa macchina, salvato su sd, e ridurre il suo overhead in loco e risalvarlo in sd in versione ridotta pronta all'uso della macchina target.
ovviamente andrebbe sviluppato:
- Linguaggio human proof
- Step in cui viene ridotto l'overhead, linguaggio "macchina"
- Core o programma operativo / interpreter
E poi ovviamente lo pseudo computer che abbia:
- tv out
- tastiera
- sd
Come dicevo prima l'unica cosa che non va persa e' l'hex originale che contiene il programma operativo e l'interpreter che non puo' essere riprodotto sul surrogato ma serve un vero e proprio computer
Dimmi su quale Arduino vorresti "compilare" il codice per una UNO, sopratutto dimmi dove pensi di mettere tutto il compilatore e il linker, perché non puoi caricarlo da SD, devono essere residenti fin da subito nella di programma di una MCU.
Ovviamente stiamo parlando di mcu, ti concedo l'uso di qualunque modello di qualunque marca, anche di fascia altissima, non di microprocessori e relative s.b.c., come può essere una Raspberry, su questa si che è possibile compilare ed editare qualunque sketch per Arduino, però ci devi mettere sopra Linux, la via facile, volendo sarebbe possibile scrivere un proprio s.o. specializzato per programmare Arduino senza Linux, lavoro immenso e tutto sommato inutile.
Mai pensato di usare compilatore originale
Ho scritto che serve
creare un linguaggio interpretato che risieda su memoria di massa, è questo non è impossibile
Scrivere in questo linguaggio un cross-compilatore per C
E questo è difficile, ma non impossibile
Compilare con questo un sorgente C da memoria di massa a memoria di massa
Questo è il meno
Poi si riparte col linker....
A dir la verità credo sia più semplice partire dal linker
Doc, un conto è se parliamo di compilare uno sketch per Arduino, ovvero del codice C/C++ con annesso il wireframe wiring e tutte le relative librerie, inclusa la avrlibc che è parte integrante del compilatore C per Arduino, farlo su una mcu, qualunque essa sia, è impossibile, mi pare di capire che su questa cosa siamo d'accordo.
Se parliamo di creare una sorta di linguaggio interpretato, o magari usare una versione custom del classico basic interpretato usato su ZX80/81, Spectrum, etc, questo è sicuramente possibile.
Poi se il codice da "eseguire" si mette in ram, in questo è possibile farlo perché non viene eseguito direttamente dal micro, oppure caricarto nella flash assieme all'interprete, soluzione migliore dal punto di vista delle risorse, o eseguirlo dalla SD, soluzione pessima per i tempi di esecuzione in quanto la SD è lenta, è tutto da vedere e decidere in base alle esigenze.
Editare e "compilare" (= trasformare in token) il codice per l'interprete tramite un sistema realizzato con altra mcu, per forza di cose di fascia alta si può fare anche se c'è molto, ma molto, lavoro da fare per realizzare il relativo codice.
Lasciamo perdere cose come la TV out per due semplicissimi motivi, il primo di ordine pratico, tv e monitor con ingresso video composito stanno sparendo, quelli di più recente produzione al massimo hanno l'ingresso VGA, interfaccia si analogica ma di tipo RGB con sincronismi separati, niente a che vedere con il video composito, ma sopratutto per motivi di uso risorse e impegno CPU, generare i sincronismi per un segnale video PAL/NTSC e il relativo dot clock è una cosa che impegna un Arduino per la stragrande maggioranza del tempo, rimane molto difficile fare altre cose, sopratutto impegnative come preparare i token per un interprete.
Soluzione possibile usare una mcu 32/64 bit di fascia alta, ben dotata di ram e flash, con un display lcd da almeno 7" 1280x800 px, cosa che costa di più di un tablet entry level da 7" dove si può fare la stessa cosa più facilmente e meglio.
Ci sono mcu di fascia alta dotate di display controller, p.e. gli F7 di ST, che possono pilotare display ad alta risoluzione senza problemi e gestire porte USB HOST per collegare una normale tastiera e un mouse, però torniamo sempre al fatto che alla fine come hardware, dal punto di vista costi, potenzialità, conviene usare una sbc linux embedded, andrebbe bene pure la Raspberry PI Zero, costa meno di 20E completa di adattatori e SD 4 GB, e permette di usare un qualunque monitor HDMI.
Ok, non siamo poi così distanti, come idee
Andiamo casomai avanti dopo
Adesso collaudo freno
Non vuoi vero che il freno del carro di guasti davanti a casa tua?
Quindi collaudo con calma....
ByPIC, MCU PIC32MX170F256, 256k Flash and 64k RAM operating at 40Mhz con interprete Basic
http://www.bypic.co.uk/
Tiny Basic, interprete, per Arduino (inteso come hardware), supporta la SD per contenere il codice da eseguire.
Vedi che ci avviciniamo?
Adesso basta scrivere in basic il cross-compilatore....
Frena frena...
Ops
Astro, eri tu?
astrobeed:
Tiny Basic, interprete, per Arduino (inteso come hardware), supporta la SD per contenere il codice da eseguire.
Forte !! Ma poi i comandi li dai via Serial Monitor, giusto ?
Vedo nel codice che tutto ciò che è msg richiama outchar, quindi:
static void outchar(unsigned char c)
{
#if ARDUINO
Serial.write(c);
#else
putchar(c);
#endif
}
Ho dato un'occhiata al codice dell'interprete, non usa i token, modo decisamente poco efficiente, interpreta direttamente le stringhe ASCII, pertanto il listato lo carichi direttamente sulla SD e lo crei con un qualunque editor, con tutti i problemi relativi a spazi e tabulazioni indesiderate.
Diciamo che si può sicuramente fare di meglio, però quel codice può essere un ottimo punto di partenza per scrivere un proprio interprete, non necessariamente Basic, per AVR.
Ma allora chi abbiamo centrato????
A proposito di linguaggi alternativi per gli AVR, rammento che Mikroelektronika produce compilatori C, Basic e Pascal per questi micro, il tutto dotato di un ottimo IDE, molto user friendly, e una ricca dotazione di librerie "pappa pronta", purtroppo sono compilatori a pagamento, la versione free compila solo per pochi k di dimensione eseguibile.