ElectroYou - la comunità dei professionisti del mondo elettrico

da **TardoFreak** » 6 giu 2014, 16:40

Allora, in pratica, è già fatto!
Mi basta implementare la classe CDC e farci uno straccio di interprete di comandi.

Pensavo fosse più incasinato.

Bene!

da **DanteCpp** » 6 giu 2014, 16:41

Per far quel che mi sembra voglia fare @TardoFreak, bisognerebbe compilare i sorgenti matlab nel set di istruzioni pic18. Trovare i sorgenti di matlab la vedo grigia, pero c'è Octave scritto per gran parte in c++, il lavoro(non da nulla) sarebbe quello di creare un makefile che compili tutti i sorgenti per PIC, e ci potrebbe essere anche da modificare un po il codice affinché sia commestibile dal compilatore microchip.

Tutto questo se il PIC ha risorse adeguate per far girare un tale programma! :mrgreen:

Se invece si vuol interfacciare il pierin con matlab che gira su PC, come mi pare che stia dicendo @BietroBaima, la cosa mi sembra decisamente più semplice. Qui su linux si potrebbe fare semplicemente anche in bash...

da **TardoFreak** » 6 giu 2014, 16:45

Cerco di spiegarmi meglio.
Non voglio integrare il Pierin in uno di questi software ma di poterlo collegare ad una USB e poterlo comandare con i software.
Insomma, diventerebbe un' interfaccia di I/O per acquisizione dati/ingressi digitali o attivazione di uscite digitali e PWM.
Volendo gli potrei far pilotare anche uno stepper e tante altre cose.
Il mio problema sono i comandi ma se, a quanto pare, i comandi si mandano come testo su seriale il set di comandi lo scelgo io.

da **PietroBaima** » 6 giu 2014, 16:48

Sì, credo che voglia fare una cosa del genere.
Una volta che si è stabilito un colloquio tra Pierin e Mathematica/Matlab poi si ha a disposizione tutta la (immensa!) potenza di calcolo di questi ultimi, si possono fare grafici ed elaborazioni complicate che la potenza di calcolo del Pierin non può certo permettersi.

Per migliorare ulteriormente si potrebbero fare dei comandi ad hoc mathematica/matlab, per usare direttamente il pierin come un internal device. Entrambi i software permettono di scrivere delle estensioni al toolset di comandi.

In questo caso basterebbe regalare l'add-on a mathematica/matlab per renderlo pierin-friendly, in pratica.

E' però un lavoro diverso da quello dell'interazione tramite seriale. Piuttosto diverso.

da **PietroBaima** » 6 giu 2014, 16:49

TardoFreak ha scritto:se, a quanto pare, i comandi si mandano come testo su seriale il set di comandi lo scelgo io.

precisamente. Basta stabilire un protocollo/set di comandi

da **DanteCpp** » 6 giu 2014, 16:54

Ho capito, la cosa è figa! :ok:

Se si creerà un repo, mi farebbe piacere partecipare al codice, tempo permettendo!

da **TardoFreak** » 6 giu 2014, 16:58

Alura,
Se avrò tempo per prima cosa implementerò la comunicazione CDC con le varie funzioni per vedere se c'è un carattere in ricezione, per inviare una stringa etc etc.
Quando l' avrò fatto riaprirò questa discussione.

Da questo all' interprete dei comandi il passo non è breve, è meno che breve. :mrgreen:

da **TardoFreak** » 7 giu 2014, 17:27

Aggiornamento:
Ho tirato giù la base per l' implementazione della seriale virtuale.

Ulteriori info e download del progetto da questo articolo:
http://www.electroyou.it/mediawiki/inde ... rtuale-usb

Potrebbe servire a chi si vuole cimentare con l' USB.

Prossimo passo un interprete di semplici comandi.

da **TardoFreak** » 8 giu 2014, 17:12

Sto scrivendo l' interprete ma mi sono bloccato sul tipo di risposta che deve dare perché non so quale è la maniera più facile per trattare queste risposte.
Questi sono i punti oscuri:
- Se il comando va a buon fine inviare o no una risposta? Se si è meglio una risposta tipo "OK" o un singolo carattere tipo "*"?
- Se il comando è errato mandare o no una risposta tipo "E01" che identifica anche il tipo di errore?
- il/i caratteri della risposta devono essere seguiti da un CR/LF?

Per i comandi in ingresso ho previsto che siano terminati da un carattere di CR ma posso cambiarlo.

da **DirtyDeeds** » 8 giu 2014, 22:41

TardoFreak ha scritto:Questi sono i punti oscuri:
- Se il comando va a buon fine inviare o no una risposta? Se si è meglio una risposta tipo "OK" o un singolo carattere tipo "*"?
- Se il comando è errato mandare o no una risposta tipo "E01" che identifica anche il tipo di errore?
- il/i caratteri della risposta devono essere seguiti da un CR/LF?

Non ho seguito bene il discorso, ma quello che potresti fare è: non inviare nessuna risposta, qualunque cosa capiti, ma crea un registro con dei flag che vengono alzati in caso di errori. Sarà poi facoltà dell'utente, se interessato, andare a leggere il registro per verificare l'esito di un'operazione e verificare quali errori possano essersi verificati.