Ho trovato in rete alcuni link interessanti che dimostrano la possibilità di programmare una board Arduino (o altra mcu atmel) in linguaggi come fortran, scheme. Entrambe sono degli interpreti, il loro funzionamento non l'ho approfondito.
Ricordo di aver letto che si può usare anche il linguaggio ADA, ma non riesco a trovarlo più.
Sapete di altri linguaggi con i quali potere programmare arduino?
Ciao.
Basic.....
assembler
Ciao Uwe
Ops che sbadato ho dimenticato i link?
Fortran http://amforth.sourceforge.net/
Scheme scrying download | SourceForge.net
Entrambi trovati qui http://1010.co.uk/org/avr_resources.html#sec-1
Ciao.
Ruby http://rad.rubyforge.org/
Occam http://www.concurrency.cc/book/
Java (Atmega8) http://www.harbaum.org/till/nanovm/index.shtml
Aggiungo anche Bitlash. L'avete mai provato? Molto interessante. E' un altro linguaggio interpretato, l'interprete risiede nell'Atmega ed i programmi possono risiedere in EEPROM.
Con l'ultima versione 2.0RC3 è stato introdotto il supporto ai programmi residenti su SD, in questo modo non c'è virtualmente limite alle dimensioni di uno sketch se non quelle dettate dal filesystem.
Sintatticamente richiama il C/Wiring usato per l'Arduino ma si possono anche integrare funzioni scritte direttamente in C puro.
Cavolo... non pensavo ci fosse tutta questa roba...... 
Figo anche RAD, a me il Ruby piace, e poter programmare l'Arduino in Ruby può essere divertente. Resta da capire che "potenza" hanno questi linguaggi, ossia che livello di possibilità riescono ad offrire. Se si tratta di sketch "normali" penso non abbiano problemi (tipo leggere dei pin, effettuare dei calcoli, attivare delle uscite) ma quando si tratta di manipolare cose complesse, come sono messi? Per l'IDE di Arduino trovi un sacco di lib, e per questi linguaggi? Se devo mettermi a scrivere a mano una libreria per usare un display LCD con Ruby allora uso l'IDE di Arduino e vado di #include <LiquidCrystal.h> 
da amante di java posso dire: che obbrobrio!
leo72:
Aggiungo anche Bitlash. L'avete mai provato? Molto interessante. E' un altro linguaggio interpretato, l'interprete risiede nell'Atmega ed i programmi possono risiedere in EEPROM.
Con l'ultima versione 2.0RC3 è stato introdotto il supporto ai programmi residenti su SD, in questo modo non c'è virtualmente limite alle dimensioni di uno sketch se non quelle dettate dal filesystem.
Sintatticamente richiama il C/Wiring usato per l'Arduino ma si possono anche integrare funzioni scritte direttamente in C puro.
questo è molto interessante e utile. Ma è un compilato o un interpretato quello che risiede in SD?
Bitlash è un interprete e risiede direttamente nell'Atmega.
Esso può funzionare sia interattivamente (apri un terminale e comunichi direttamente con l'interprete, che esegue all'istante i comandi che gli passi) oppure eseguire programmi e/o funzioni prescritte. Questi possono risiedere sia su EEPROM sia su SD esterne.
Queste funzioni altro non sono che sketch scritti in Bitlash che l'interprete legge ed esegue, un comando alla volta. Quindi su SD risiedono file di testo contenenti le tue funzioni.
Esiste una funzione particolare di autostart che puoi memorizzare su EEPROM e che viene eseguita ogni volta che viene avviato l'Atmega. Se questa funzione esiste, Bitlash la esegue per prima. Al suo interno puoi ad esempio mettere di eseguire un'altra funzione presente su EEPROM oppure andare a cercare una certa funzione sull'SD. Da una funzione puoi richiamarne un'altra e così via... all'infinito. Quindi puoi riempire virtualmente una SD di funzioni collegate le une alle altre, creando uno sketch immenso.
Occam http://www.concurrency.cc/book/
Ada http://avr-ada.sourceforge.net/
Questi sono quelli che mi interessano maggiormente. Del linguaggio ADA so che è compilato tramite avr-gcc che deve essere patchato per abilitare il linguaggio ADA.
Mentre di Occam non so proprio nulla, ma vedo che c'è un libro on-line, ed è un peccato non leggerlo. Che sapete di Occam di preliminare tanto per scegliere con quale dei due cominciare.
da amante di java posso dire: che obbrobrio! smiley-grin
Da "odiante" di java (attacco di orticaria improvvisa) non riuscirei a distinguere tra entrambe gli obbrobri.
Ciao.
@leo72: quindi è un linguaggio interpretato... perdi di velocità in cambio di spazio teoricamente infinito.
@MauroTec: java e flash, sono le uniche 2 alternative al paradigma "compile once, run everywhere". magari non ti piace java ma dovrai ammettere che tra le due la migliore è java, anche se per ora fatica ancora ad inserirsi nel contesto giochi. Il punto è che far girare java su un micro perdi il paradigma iniziale, rendendo java una versione pesante del c++
Eviterei linguaggi interpretati... i tempi di esecuzione aumentano di diverse decine di volte e con 1-2k di RAM e 20MHz si sente parecchio la differenza.
Anche i linguaggi a livello più alto e debolmente tipizzati producono eseguibili meno performanti.
PS. si dice "assembly", assembler è il programma che trasforma il codice testuale in eseguibile.
Ciao
beh per la ram si può fare una swap su SD, e la velocità di esecuzione che "muore".. però può essere utile
MGuruDC:
Eviterei linguaggi interpretati... i tempi di esecuzione aumentano di diverse decine di volte e con 1-2k di RAM e 20MHz si sente parecchio la differenza.
Anche i linguaggi a livello più alto e debolmente tipizzati producono eseguibili meno performanti.
PS. si dice "assembly", assembler è il programma che trasforma il codice testuale in eseguibile.
Ciao
Concorto con te sul fatto che sono meglio i linguaggi compilati, proprio perchè riducono di molto il tempo che gli interpretati impiegherebbero per tradurre la singola istruzione ed eseguirla.
PS. Hai detto bene, però ormai i vari assemblatori inseriscono del codice proprietario all'interno di essi e questo fa si che ad esempio un linguaggio assembly utilizzato con un assemblatore (ad esempio TASM) non funzioni per un' altro (FASM, i due assemblatori sono presi a caso =D).
I linguaggi interpretati hanno la loro forza nella possibilità appunto di poter eseguire del codice scritto con un semplice editor di testo. Adesso che Bitlash supporta anche le SD, le potenzialità sono enormi: pensate ad un Atmega che deve eseguire sketch di media complessità (tipo letture e scritture di pin) residente su SD. Per aggiornare lo sketch basta salvare su una SD la versione aggiornata, cambiare la schedina e riavviare il micro! In pratica un'operazione che può essere eseguita con semplicità anche dall'utilizzatore finale ed anche se questo è un totale incapace in elettronica XD
Diamond39:
PS. Hai detto bene, però ormai i vari assemblatori inseriscono del codice proprietario all'interno di essi e questo fa si che ad esempio un linguaggio assembly utilizzato con un assemblatore (ad esempio TASM) non funzioni per un' altro (FASM, i due assemblatori sono presi a caso =D).
Non diciamo bischerate di questo genere, un assemblatore non aggiunge nessun codice proprietario a meno che non utilizzi espressamente qualche macro, o libreria, fornita col compilatore stesso.
Un sorgente assembly, che utilizza solo istruzioni native, per il micro xyz funziona sempre e comunque sia che lo compili con l'assemblatore A oppure con quello B.
Stessa cosa vale per il C ANSI se utilizzi solo le librerie standard.
Attenzione a non confondere i compilatori veri e propri con i programmi accessori quali gestori di librerie e linker, questi si che sono specifici e non si possono utilizzare con file di libreria e file oggetto generati da suite diverse.
@MauroTec: java e flash, sono le uniche 2 alternative al paradigma "compile once, run everywhere". magari non ti piace java ma dovrai ammettere che tra le due la migliore è java, anche se per ora fatica ancora ad inserirsi nel contesto giochi. Il punto è che far girare java su un micro perdi il paradigma iniziale, rendendo java una versione pesante del c++
Si diciamo che java persegue l'obbiettivo che ogni programmatore vuole raggiungere, e cioè più o meno; scrivo una volta riuso tante volte, eseguo il programma su ogni piattaforma conosciuta; sempre che ci sia la macchina virtuale per quella piattaforma o architettura. C'è di buono però che non è un'interpretato a tutti gli effetti ma una vera è proprio macchina virtuale che esegue byte code precompilato.
PS. Hai detto bene, però ormai i vari assemblatori inseriscono del codice proprietario all'interno di essi e questo fa si che ad esempio un linguaggio assembly utilizzato con un assemblatore (ad esempio TASM) non funzioni per un' altro (FASM, i due assemblatori sono presi a caso =D).
Forse ti riferisci che ognuno fa di testa sua e introduce qualcosa di non standard tra le direttive di asm, se così questo accada anche con il c, c++ e qualsiasi altro linguaggio. Ma se un dato assembler viene descritto come fedele allo standard xx.xx, e va in palla durante l'asseblaggio di codice standard allora è da considarare un'errore.
il problema di ada e' che per compilare il compilatore ada serve un compilatore ada
gcc da solo non ce la fa
Cioè, non ho capito cosa vuole dire questa frase. Tu hai provato a compilare avr-gcc patchato per abilitare il linguaggio ADA? Io non l'ho ancora fatto, se ha info in merito spara.
(il che per me e' una scocciatura, perche' esistono bootstrapper per x86, per ppc, per arm, ma non per mips devo risolvere il problema dell'uovo e della gallina chi e' venuto per primo ?)
Ancora più confuso, tra i mips ci sono anche i PIC giusto?
notare i demo sono per avr32
Quali demo? link please.
Da recente ho dato uno sguardo alla toolchain per pic messa su da digilent, non è per niente chiara e lineare come per gli avr. La cosa mi ha dato pure qualche problema con il programma che sto sviluppando che analizza i file headers di un sorgente alla ricerca dei micro compatibili con quel codice sorgente soprattuto utile quando sviluppi una libreria e vuoi automatizzare la creazione di un file che descrive la libreria. Per avr basta cercare la stringhe AVR e __ rispettivamente prefix e suffix ciò che sta in mezzo è il nome del microcontrollore con PIC il prefix e suffix sono entrambi "_".
Ciao.
@leo72
Approfitto della tua conoscenza di Bitlash per porti una domanda...
ma le istruzioni che l'interprete bitlash receve in input, vengono momentaneamente scritte su flash/eeprom ?? oppure sono dei semplici token che chiamato delle funzioni già compilate? nel primo caso prima o poi andrebbe cambiato microcontrollore...
seppe
non credo, è un passaggio inutile. Vengono lette (e quindi caricate "in ram") ed eseguite. le uniche cose salvate saranno le variabili, ma cmq in ram. Poi magari esplicitamente puoi leggere/scrivere la eeprom