ElectroYou

Non parlo come programmatore professionista ma come elettronico tradizionale.
Arduino usa come linguaggio un C semplificato. Ciò vuol dire che un problema modesto può essere risolto anche a distanza di un paio di mesi perché una "ripassata" delle cose essenziali è molto semplice.
Talune volte ci si rende conto che un problema, qualcosa di modesto, diventa un mezzo casino con il linguaggio C
mentre sarebbe facile farlo con il linguaggio LADDER su un PIC.Anche il linguaggio LADDER ha bisogno solo di una veloce ripassata e comunque è intuitivo.
Domanda: esiste un programma, oltre al LD-MICRO che si lavora in LADDER e si salva direttamente o attraverso un passo intermedio in .HEX?

Ciao NinoAL,

NinoAL ha scritto:Non parlo come programmatore professionista ma come elettronico tradizionale.
Arduino usa come linguaggio un C semplificato

Non capisco cosa tu voglia dire con "C semplificato". Alla fine è sempre C.

Talune volte ci si rende conto che un problema, qualcosa di modesto, diventa un mezzo casino con il linguaggio C

Dipende. Se si conosce bene il linguaggio di programmazione, secondo me no.
In più, se non conosci il LADDER, divenat un mezzo casino ugualmente.

Io per esempio non conosco il LADDER.
Non ho mai programmato in LADDER, e se mi metti di fronte un programma scritto in tale linguaggio non lo so interpretare attualmente (perché non l'ho mai studiato) e troverei forse qualche difficoltà al principio, mentre con il C so che posso fare di tutto. Molto probabilmente con il LADDER non farei le stesse cose, altrimenti tutto il mondo programmerebbe i micro in LADDER e non in C.

Per il resto, a parte il programma citato da te, suppongo questo, non ho trovato niente.

Lunga vita al C.

Gli ambienti grafici come il ladder, (molto di moda in certi ambienti), ma anche funzionali, sono molto semplici ed utili per risolvere situazioni booleane, pratici per il debug, e veloci per le modifiche da parte di "altri" che non avevano partecipato al primo sviluppo. Implementarli su un processore medio piccolo, però, risulta difficile. Ne viene fupri un linguaggio macchina "grasso", per risolvere "poco". (Scusate la terminologia poco ortodossa).
In più richiedono un grandissimo sbattimento a livello "ambiente di sviluppo". Se un parser per un linguaggio letterale è già di per se un bel "mattone", un interprete grafico è ancora più "incasinato".
Dannarsi l'anima per implementare un simile ambiente, per piccoli processori, per risolvere poi "poco", porta davvero ad un bilancio "energetico" sfavorevole.

Molto intelligente e utile è il progetto di AOX, che invito a consultare e sviluppare. Il linguaggio grafico è già implementato con CoDeSys, ed il progetto modestamente semplice.

La discussione potrebbe essere lunghissima, eterna se vogliamo. Avete provato a ragionare cosa significhi fare il debug di un programma grafico? In termine di scambio dati tra il processore e l'ambiente di sviluppo. Provate solo ad immaginare cosa può essere la comunicazione utile. Ne viene fuori un processore impegnato al 99% in risorse di comunicazione, ed un 1% in risorse di programma.

Se devi cablare un quadro tradizionale l'uso del LADDER è intuitivo e immediato ma allo stesso tempo usare un PLC è costoso, non ne vale la pena.
E non vale la pena usare il C, utile in tante altre applicazioni.

Programmare in modo semplice e diretto la logica di un processore non è tanto solo una questione del compilatore che riceve le istruzioni che gli dai, ma richiede anche tutta una base di software più nascosto che fa del lavoro dietro le quinte.
Per esempio serve una base tempi (semplice da fare con un interrupt) che almeno ti fornisce un byte con 8 bits che oscillano periodicamente (es 10ms, 20ms, 50ms,...) e magari un altro byte con i valori di fronte di salita.
Poi servono delle funzioni di gestione degli I/O che ti preparano i valori degli ingressi e ti sparano fuori sul mondo esterno i valori delle uscite. Infine una parte di download e monitor.
A questo punto serve un traduttore dal linguaggio ladder o altro che manipoli i valori degli I/O e della memoria ram. I timer e gli altri dispositivi del linguaggio non sono altro che pezzi o funzioni che lavorano su aree (istanze dei dispositivi) della ram.
Io per anni ho lavorato in assembler ma avendo avuto anche a che fare con i PLC, apprezzandone alcuni aspetti, mi ero fatto un preassemblatore che tritava tutto quello che gli davo. Quindi potevo scrivere in assembler ma qualche riga dopo potevo anche spaziare sulla lista istruzioni (simil Omron) oppure usare gli IF THEN ELSE del basic. Se poi le istruzioni dell'assembler erano limitate a 8 bit c'erano anche le versioni a 16 e 32 bits. Poi essendo seguace delle calcolatrici HP si poteva anche scrivere in RPN. Quindi le varie parti potevano fare uso misto di tanti linguaggi più o meno adatti al caso.
Ora tutto questo fa parte solo dei ricordi ma ho potuto fare cose abbastanza complesse con un linguaggio somma di tanti.