È molto confuso, ma non devi preoccuparti. Prima di tutto, pensa a un UART che di per sé è un termine generico, ma pensa a uno che produce un protocollo con un bit iniziale, uno o due bit di stop, 7 o 8 bit di dati di solito, e talvolta parità che è pari o dispari; può variare da lì, il che lo rende molto peggio.
L'UART è ai livelli TTL, qualunque cosa significhi. Una volta era 5 V e ora 3,3 V, 1,8 V o altro; forse TTL è il termine sbagliato. ALLORA hai avuto / hai RS-232, RS-422, ecc. Questi sono gli standard TENSIONE E PIN, non standard di protocollo. Non è corretto mescolare i termini e dire RS-232 quando si intende una sorta di UART.
In passato il tuo UART era sulle tue schede madri e desideravi una sorta di connettore verso il mondo esterno con livelli di tensione che all'epoca avevano senso e una sorta di pinout / cavo standard. Quindi un popolare standard a 25 e 9 pin è stato spesso trovato per varie periferiche, e nel mondo dei PC Wintel questa era chiamata porta COM o talvolta porta seriale.
Certo, una porta che trasporta dati seriali può essere chiamata porta seriale, SPI, I²C, MDIO, UART, HDLC, SDLC, ecc. E forse anche USB e SCSI; potresti impazzire con questo. Di solito una porta seriale indica alcuni pin che puoi ottenere su una UART.
Il mondo Unix / Linux dice ttyinvece di com/ serial/ uart, ma è la stessa cosa.
Ora c'è l'ATTUAZIONE. Puoi acquistare un chip UART con qualche interfaccia su di esso (sì, puoi avere un UART SPI, che è seriale su entrambe le estremità, o U² I²C o un bus dedicato o USB, ecc.). Già nel giorno in cui l'UART aveva un bus su un lato attraverso il quale la CPU stava comunicando. Oggi abbiamo FTDI e altri fornitori che realizzano piacevoli soluzioni USB UART, non rendono diversi alcuni strati di interfaccia tra il software e l'UART e quindi l'altro lato di UART ha qualche interfaccia, sia esso a livello di TTL / chip o RS-232C o RS-422, ecc.
I primi Arduinos utilizzavano spesso una scheda FTDI da USB a UART che forniva anche alimentazione all'Arduino. Alcuni hanno quell'alimentazione USB e seriale / UART sulla scheda Arduino stessa e quindi sono collegati attraverso la scheda all'UART sul chip AVR (stesso affare alcuni processori con alcuni strati di bus per consentire al software di comunicare con un UART che ha qualche interfaccia dall'altra parte, in questo caso i pin sul bordo dell'AVR, a livelli di tensione del chip, TTL).
Poiché la funzionalità UART non è cambiata da decenni, perché la terminologia del software o persino le applicazioni software dovrebbero cambiare a livello di applicazione? Scrivi un'applicazione TTY Linux / Unix 10-15 anni fa contro un chip UART sulla tua scheda madre e ci sono buone probabilità che funzioni ancora oggi con un livello da USB a TTL o da USB a RS-232C o RS-422 o qualunque altro pin / definizione di livello. Lo stesso vale per Windows e ho un codice così vecchio che funziona ancora su entrambi. Nel mondo Windows viene usato il termine COM.
Non uso la sandbox di Arduino da un po 'e se così fosse su Linux, ma non sarei sorpreso se quel programma che è Java, se ricordo bene, è generico e usa il nome di sistema ttyS2su Linux e COM2 Su Windows.
Rileggere la tua domanda può andare molto oltre, sfruttando la quantità già esistente di software che utilizza queste chiamate API. Ancora una volta per decenni non c'è motivo per cui non è possibile creare una porta virtuale nel software che trasporta questi dati bidirezionali praticamente qualsiasi cosa si possa pensare. UART to Ethernet è molto comune e nelle sale server in cui i server utilizzano ancora le porte COM / TTY / RS-232, è possibile disporre di un server terminal con un numero di interfacce che è possibile collegare a un numero di server, quindi Ethernet dall'altro lato, quindi se si sceglie di non effettuare il telnet in, è possibile installare un driver di porta COM virtuale.
Quindi l'applicazione sul tuo computer pensa che stia parlando a una porta COM, ma in realtà quel flusso di byte passa su Ethernet quindi colpisce il terminal server, POI, su un UART a livello RS-232C (ma non necessariamente pinout) cavi a il server e ritorno allo stesso modo.
A volte non vi è alcun motivo per passare effettivamente a un UART reale, per qualsiasi motivo virtualizzare una porta COM in modo che il software scritto per quelle chiamate API possa ancora funzionare. Potresti forse pensare all'antico software bancario che usiamo ancora che ha un terminale stupido a un'interfaccia UART che forse in passato era cablato o è andato in un modem per eventualmente un server. Puoi farlo in modo che il software funzioni ancora, attraverso varie quantità di emulazione inclusa una porta COM virtuale che oggi probabilmente passa Ethernet al server come un flusso seriale (ad esempio TCP / IP).
