Go Down

Topic: [C] Inviare dati ad Arduino (Read 2012 times) previous topic - next topic

dally

#30
Dec 29, 2016, 04:01 pm Last Edit: Dec 29, 2016, 07:37 pm by dally
In effetti non c'è nessuna garanzia che la seriale sia gestibile tramite file, non viene citata nel documento, però tutti i compilatori C, per pc, che ho visto/usato, e sono tanti, hanno sempre permesso l'accesso alla seriale come file.
Probabilmente non ne hai visti abbastanza :D

Amiga classic si era inventata altri modi bislacchi simili a quelli dell'esempio DOS, con pero' la periferica mappata in ram, e Pure OS9 ha un modo bislacco, con primitive serial_putc, e serial_getc, dentro alle quali ci sono due trap dirette al kernel

arduinopro44

@arduinopro: forse ora funziona perché in qualche modo hai cambiato la velocità della porta. Prova a riavviare :D.
Intendi la velocità della porta definita in C? Purtroppo non ho cambiato nulla lì quindi se è questo, o qualsiasi altra cosa, si è modificato da solo.


Non so come sia il tuo codice, pero' considera anche che se non chiudi gli stream alla fine del tuo programma (fclose), la cosa potrebbe bloccare la porta. In teoria se succede la fopen restituisce NULL.
Si si, finché non "sblocco" la porta con flcose il meccanismo rimane in attesa. E' un po' fastidioso ma l'importante è che funzioni.

nid69ita

#32
Dec 30, 2016, 10:09 am Last Edit: Dec 30, 2016, 10:18 am by nid69ita
E' quindi possibile inviare dati ad Arduino tramite C?
Possibile che nessuno abbia mai utilizzato il C per comunicare con Arduino?? (Su internet di fatto non ho trovato assolutamente nulla!)
Grazie!
Scusa, ma i link che ti ho fornito ?  Ci sono esempi C e C.Net
Logicamente su C.NET usi le librerie del framework net.   

In C puro lo fai come hai fatto tu (la seriale E' uno stream come un file !! ), il difficile è fare i settaggi della velocità/parità/etc. che DIPENDONO dal S.O.
Su Windows in C puro vedi dai link che ti ho dato l'esempio in C puro apre un file ma usando API del Windows perchè così può fare i settaggi.     

Quindi SI in C fai come hai scritto tu e quello è portabile su altri S.O.   ma i settaggi NO !! Dipendono dal S.O.
Anche perchè, la seriale è un file ma di un file mica "setti" cose tipo la velocità.

Poi ci sono anche altre cose che dipendono dal S.O. e quindi la "portabilità" va a farsi friggere,
una tra tutti è in nome della seriale,  COMx su windows,   ttyACMx su Linux  LINK
my name is IGOR, not AIGOR

dally

#33
Dec 30, 2016, 11:21 am Last Edit: Dec 30, 2016, 11:30 am by dally
finché non "sblocco" la porta con fclose il meccanismo rimane in attesa
Senza un sistema operativo accedi alle risorse direttamente. Su un sistema operativo gestire le periferiche come oggetti o come file implica invece che la risorsa sia assegnata ad un processo, il che ha delle conseguenze importanti.

La fopen fa proprio questo. Dice al kernel che si vuole utilizzare una risorsa, ne alloca un descrittore. File, o oggetto che sia, il concetto e' sempre lo stesso: quando hai finito di usare la risorsa la devi rilasciare! file close, socket close. Quello che e'.

Per tua fortuna i sistemi operativi moderni hanno un gestore di risorse smaliziato, codice OS che si fa un giro infinito a bassa priorità alla ricerca di risorse USR ancora allocate ma di fatto non utilizzate ne associate ad alcun processo.

Quando se ne accorge, tipicamente dopo qualche manciata di secondi dopo che e' terminato il processo che la usava, la risorsa viene nuovamente rilasciata, e puoi riaprire la seriale, o un file, senza che fallisca la open.

dally

#34
Dec 30, 2016, 12:00 pm Last Edit: Dec 30, 2016, 01:55 pm by dally
ttyACMx
Su UNIX le seriali sono per tradizione ttyS*. Tutti gli UNIX commerciali chiamano in quel modo le seriali, e pure linux su x86 con seriali cablate.

E' la roba ARM che si e' inventata un modo di chiamare le seriali built-in nel SoC, questo perche' ha riciclato del codice adattandolo alle proprie esigenze. ACM indica "acm modem", ovvero altra roba ancora ormai desueta ma che resta li a fare legacy, antichi ricordi … mentre per la roba usb-serial (trasporto bulk) il nome tipico e' ttyUSB*. Il motivo e' semplice e' proprio codice nuovo, scritto appoggiandosi al core usb, per altro plug-and-play quindi e' utile chiamare cosi' le seriali, distinguendole da quelle built-in, perche' cosi' UDEV fa prima a gestirle al volo.

Plugga Arduino p.e. su Ubuntu, vedrai comparire una /dev/ttyUSB*

Accedi alla console di certe altre machine linux e troverai la seriale chiamata /dev/cua0 per motivi ancora piu' bislacchi dei tempi dei kernel <= 2.0. La roba "Cua" era un driver seriale alleggerito di tutto il polpettone a supporto della tty, in modo che fosse piu' semplice configurarlo ed usarlo per applicazioni dialout. Altri tempi, ben altri kernel, oggi e' considerato deprecato, pero' qualcuno chiama ancora cosi' la seriale per motivi suoi. Puo' capitare. Niente paura.

Insomma non c'e' un vero modo univoco di chiamare il devname della seriale. *Dipende*

In ogni caso il nome, il devname, e' solo una stringa scritta del kernel-module (il driver) che gestisce l'appendice della risorsa. Se vuoi puoi anche chiamarla "cicciolina", basta crearsi un devname apposito, che rispetti il tipo (c=dispositivo a caratteri, byte), major e minor (questi due sono specifici del kernel module, ed identificano il device)

una roba tipo

Code: [Select]

mkdev /dev/cicciolina0 c 4 64


Questo e' l'approccio "static", classico. Se si usa UDEV bisogna dargli regole. Il discorso di base non cambia: su UNIX il devname e' solo una stringa a piacere, per convenzioni.

Windows gestisce invece le risorse per oggetti. Non so come e se sia possibile cambiare il devname della seriale.

La cosa bella dell'oggetto COM usato da Delphi e VisualC e' che cliccavi su una icona, ti compariva un quadratino, lo piazzavi nel form del progetto, e ci potevi cliccare sopra per settare comodamente tutti i dettagli nelle propieta', e per identificare la seriale desiderata (COM1, COM2, … COM18)  ti compariva un elenco di risorse disponibili comprensivo di descrizione presa da resource manager. Vedevi proprio il vendor, il modello della seriale. P.e. COM18, affianco "Arduino2009" (stringa scritta nel chip FTDI232, FTDI2232, e simili).

Ecco perche' molta gente la usava nei progetti personali nel 2005. Era maledettamente intuitivo e stra-comodo :D

astrobeed

La cosa bella dell'oggetto COM usato da Delphi e VisualC
In Visual C Microsoft e RAD di Embarcadero (ex Borland), da notare che sotto RAD Delphi e Cbuilder condividono le stesse librerie, sono disponibili ottime librerie per gestire le comunicazioni lan, usb nativa e seriale hardware/virtuale.

Scientia potentia est

dally

Fantastica questa cosa dei RAD. Fai conto che dal 2005 in poi mi sono occupato solo di un paio di UNIX commerciali e di linux. Prima ho sviluppato parecchio su Delphi 2.0, con qualche porting verso VisualC.

Ma toglimi una coriosita': si configura ancora tutto per propieta' trascinando l'oggetto sul form per poi spulciare le varie voci? O c'e' una megawizard che ti fa domande ed in base alle risposte istanzia il codice?

SukkoPera

Il nome della seriale dipende anche dal driver, su Linux. Quando pluggo la mia Uno, o alcune altre schede, mi ritrovo /dev/ttyACMx, mentre con altre che usano chip USB-Seriale diversi (CP210x? Vado a memoria) mi ritrovo /dev/ttyUSBx.
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

dally

#38
Dec 30, 2016, 01:03 pm Last Edit: Dec 30, 2016, 01:56 pm by dally
Il nome della seriale dipende anche dal driver, su Linux.
ho spiegato per bene che su linux il "devname" e' solo una convezione che dipende o dalle regole di UDEV(1) o da come si e' creato il file in /dev. Vedi esempio cicciolina. Il driver non fa altro che rapportarsi al kernel per major e minor, la stringa del filename e' un file speciale che rilascia proprio queste informazioni identificando il device nella tabella dei devs. Ovvero puoi rinominare la seriale come ti pare. Sempre e comunque.


(1) UDEV si spazzola la lista dei devs in probe, e crea dinamicamente il devname popolando la directory /dev/*

SukkoPera

So benissimo come funzionano i device e udev. Quello che volevo dire è solo che, senza farsi tante seghe mentali, all'atto pratico ho due Arduino simili che quando li collego danno origine a device diversi. Per cui è bene che nessuno faccia particolari assunzioni sul nome con cui dovrà accedere alla seriale!
"Code is read much more often than it is written, so plan accordingly. Design for readability."

Guida rapida a ESP8266: https://goo.gl/kzh62E

nid69ita

@sukko, @dally   non esageriamo con l'OT
Troppe spiegazioni, per una domanda fatta da @arduinopro44  alla fine gli confondiamo le idee :)
my name is IGOR, not AIGOR

nid69ita

#41
Dec 30, 2016, 01:53 pm Last Edit: Dec 30, 2016, 01:57 pm by nid69ita
ho spiegato per bene che su linux il "devname" e' solo una convezione che dipende o dalle regole di UDEV(1) o da come si e' creato il file in /dev. Vedi esempio cicciolina.
Continuo l'OT  ...   :smiley-mr-green:

Ma chi stabilisce allora questo nome ?
Come dice @Sukko "Quando pluggo la mia Uno, o alcune altre schede, mi ritrovo /dev/ttyACMx, mentre con altre che usano chip USB-Seriale diversi (CP210x? Vado a memoria) mi ritrovo /dev/ttyUSBx." anche io ho notato questa cosa. 
Ripeto, ma chi stabilisce questo nome ? Il costruttore nel driver ? Ma da dove viene preso/scaricato il driver ?  In Linux (ho ubuntu) mi pare quasi automatico lo scarico del driver rispetto a Windzoz
my name is IGOR, not AIGOR

astrobeed

Ma toglimi una coriosita': si configura ancora tutto per propieta' trascinando l'oggetto sul form per poi spulciare le varie voci? O c'e' una megawizard che ti fa domande ed in base alle risposte istanzia il codice?
Con l'ambiente RAD lavori quasi esclusivamente con oggetti sotto forma di icone grafiche dotate di metodi, proprietà, eventi, settabili tramite apposito menù, in pratica tutto ciò che compone il form è un attimo crearlo, poi tocca scrivere il relativo codice per gestire gli eventi che attivi, vale sia per Delphi che per Cbuilder.
C'è anche un comodo wizard che ti crea il progetto con tutto quello che serve a seconda di cosa devi fare, p.e. un normale programma, sia totalmente stand alone che tramite run time varie, oppure un servizio o una dll.
Personalmente preferisco da sempre l'ambiente di lavoro Borland rispetto a quello Microsoft, l'attuale RAD studio XE 10, Berlin in codice, ha una grafica molto simile ai vecchi ambienti Delphi 7 e Cbuilder 6, che uso ancora per il codice che deve girare su hardware molto datato.
Recentemente RAD Studio gestisce anche il mondo mobile, posso generare codice per IoS e Android, però servono i realtivi sdk installati, meglio ancora adesso, tramite l'addon UNIGUI, è possibile scrivere codice in Delphi o C che poi viene trasformato in codice per server Apache, tutto gira sotto forma di pagina web su qualunque dispositivo, ovviamente occorre un server dedicato in rete oppure si usa un apposito server standalone installato sul pc dove gira il codice.
Scientia potentia est

dally

Ma chi stabilisce allora questo nome ?
Di solito, da quanto ho osservato sin dai kernel linux 2.0 in poi, viene proposta una soluzione, se piace, la cosa prosegue, se non piace qualcuno la modifica, e si itera fino ad una condizione stabile.

Tieni anche presente che a nessuno piace scrivere kernel-module da zero, la tendenza e' prendere qualcosa di gia' fatto ad adattarlo di volta in volta. Si vede anche dai commenti in testa al codice. Ispirato da. Originariamente scritto da. Tratto da. Migrato da. etc

Ma da dove viene preso/scaricato il driver ? 
Non ho capito la domanda. I driver sono inclusi nel kernel tree di linux, approvati da Linus Torvalds e staff. Altrimenti sono esterni, e come tali sono gestiti. Progetti autonomi, dei vari utenti o vendor.

A rigore, se si parla di kernel, nessuno sceglie i devname.

I devname sono una questione del rootfs, a cui il kernel presta servizi. Quindi arriviamo a chi? confeziona una distribuzione linux, ovvero prende un kernel, popola il rootfs, fa scelte coerenti, e decide che devname usare.

p.e. Debian ho notato piu' volte che ha fatto scelte diverse da Slackware.

dally

Poi c'e' UNIX, quello da cui Linux ha preso le distanze.

Tutti gli UNIX commerciali che ho supportato discendono dal System V BSD, tutti rispettano le regole scritte inizialmente, comprese le scelte per i devname, come scrivere interfacce, etc.

Ci sono tomi di libri vari, e ci sono anche dei fork OpenSource.

Pero' sono passati anni dalle prime bozze, quindi qualche piccola evoluzione qui, qualche piccola mutazione la', l'intero ecosistema si modifica.

Go Up