Come ottenere più di un'interfaccia uart

Ok, ho un'interfaccia uart (TXD GPIO 14, RXD GPIO 15). Voglio almeno un'altra interfaccia uart.

Possibili soluzioni:

• Bit banging: utilizzare due GPIO di riserva non correlati. Capisco che il tempismo è un problema su un Linux standard. Sarebbe affidabile con un baudrate molto basso?

• Commutazione: RPI decide quando parlare con quale dispositivo. Utilizzando ad es . CD4066BC .

• spi to 2 x uart bridge: non ho trovato una parte adatta (disponibilità, prezzo, pacchetto dil)

• usb to uart: costoso

Ci sono altre opzioni? Sono propenso a cambiare, se può essere fatto. Cosa consiglieresti?

Un UART USB, come FTDI, non è molto costoso. Tutte le altre opzioni sembrano che ti costeranno di più in parti e in tempo rispetto ai ~ $ 13 che potrebbero costarti ed essere inaffidabili o lenti. Scegli l'opzione veloce e senza problemi, come ad esempio:

http://www.dfrobot.com/index.php?route=product/product&product_id=147#.UOamLG-sh8E

Sparkfun ne vende anche uno. In effetti, forse puoi semplicemente estrarne uno da un vecchio dispositivo USB o acquistarne uno da un negozio di spazzatura che non sa cosa fa.

Ho pasticciato con un adattatore da SPI a UART per un progetto Arduino, non esisteva alcuna libreria, quindi ho scritto il mio. Alla fine ha funzionato bene, ma se avessi potuto cadere in una parte di $ 15 avrei. In effetti, dato il tempo che mi è costato, avrei dovuto ottenere un mega con 4 porte seriali.

In alternativa, se desideri molte porte seriali, puoi guardare RS485 seriale, che è simile a 232 (anche se non compatibile), che supporta il multi-drop, ovvero diverse interfacce su un'unica linea.

Se decidi di saltare l'aggiunta di hardware aggiuntivo e segui la strada del bit-bang, questo non è così difficile come immaginalo.

Prima di tutto, il tuo thread di comunicazione deve andare in tempo reale:

#include<sched.h>

struct sched_param param;               
param.sched_priority = sched_get_priority_max(SCHED_FIFO);
if( sched_setscheduler( 0, SCHED_FIFO, &param ) == -1 )
{
        perror("sched_setscheduler");
        return -1;
}

D'ora in poi, il tuo thread non verrà anticipato per 950ms ogni secondo ^* , a meno che non restituisca il controllo volontariamente (attraverso sched_yield()o usleep()) in modo tempestivo, il che non lo renderà mai prevenuto. Con la CPU a 850 MHz il tuo loop di bit banging resterà inattivo per la maggior parte del tempo anche a velocità più elevate.

Ora, purtroppo, l'obbligo di ripristinare il controllo di volta in volta significa che mentre il tuo thread è inattivo, qualunque cosa invii la tua "parte avversaria", sarebbe perso per sempre. Ma a tale scopo potresti usare il controllo della trasmissione. O alloca un altro po 'di GPIO per la linea CTS che abbassi prima di cedere e esegui il backup al ripristino del controllo:

  bcm2835_gpio_write(CTS_PIN, LOW);
  usleep(10);
  bcm2835_gpio_write(CTS_PIN, HIGH);

oppure (preferibilmente IMHO) utilizzare il controllo di trasmissione XON / XOFF - inviare il carattere XOFF su RS232 prima di dormire, XON dopo aver ripreso l'operazione. I codici ASCII predefiniti per questi sono '\x13'per XOFF / "stop invio" e '\x11'per XON / "riprendi invio".

Ovviamente il tuo dispositivo remoto deve obbedire a questi. In caso contrario, alcuni dati andranno persi.

Ho trovato quello che cercavi: uno slave I2C / SPI sul ponte UART / IrDA / GPIO.

Sono disponibili in versione singola e doppia (quindi 1 o 2 UART extra). Anche loro (NXP) (per l'altro lato in caso di necessità) hanno un master I2C / SPI su ponti UART / IrDA / GPIO.

Maggiori informazioni su questi chip sono disponibili qui e sulla controparte principale .

Maxim ha anche chip che fanno esattamente la stessa cosa.

I bridge da USB a UART sono economici e prontamente disponibili, ma hanno caratteristiche di tempismo davvero scadenti. Newark vende una scheda "Embedded Pi" che ha un processore ARM STM32F su cui puoi scrivere codice bare metal. Quel chip ha tre UART e penso che possano andare abbastanza veloci; se dovessi usarne uno per comunicare con il Raspberry Pi che ne lascerebbe due disponibili per altri scopi. Dichiarazione di non responsabilità: ho acquistato una di queste schede, ma non ho ancora utilizzato il Raspberry Pi per gestire direttamente le esigenze di I / O.

Se vuoi molti UART più lenti, l'STM32F sulla scheda Embedded Pi potrebbe probabilmente gestire un numero discreto, specialmente se sei disposto a scrivere un linguaggio di assemblaggio Arm. Se ci sono due gruppi di 16 pin I / O disponibili su una singola scheda, potrebbe essere possibile avere 16 UART software simultanei che lavorano tutti in una volta con una velocità di trasmissione piuttosto decente (avere un interruzione periodica a 3x o 5x della velocità di trasmissione che memorizza Valori a 16 bit bloccati dalla porta di ricezione a un buffer e genera valori precalcolati a 16 bit da un buffer alla porta di trasmissione; in tal caso, il tempo medio di manutenzione per gli UART del software non è eccessivo, ma non importa se si verifica un hit occasionale nel caso peggiore (ad es. tutte e sedici le porte che ricevono un byte contemporaneamente).

Questo approccio può effettivamente funzionare in modo straordinariamente efficiente per la ricezione, dal momento che il codice "caso comune" non deve nemmeno esaminare i singoli UART. Supponiamo di campionare i dati a 5x e che gli ultimi 47 byte del buffer siano duplicati immediatamente prima di esso. Supponendo che i dati vengano scritti nel buffer in ordine crescente, è quindi possibile verificare se un byte è stato ricevuto completamente su uno dei 16 canali semplicemente dicendo:

bytes_ready = (armed_flag & data[rxptr] & ~data[rxptr-47] & ~data[rxptr-46] & ~data[rxptr-45] & ~data[rx_ptr-44]);

Se bytes_readyè zero, nessun dato è stato ricevuto. Altrimenti, se per esempio bytes_readyè impostato il bit 2 di , ciò significa che un bit di dati ricevuto può essere trovato nel bit 2 di dati [rx_ptr-40], dati [rx_ptr-35], dati [rx_ptr-30], ecc. i dati, cancellare il bit 2 di armed_flag e predisporre il ripristino dopo circa 44 campioni.

Questo approccio richiederà un po 'di lavoro su quei campioni in cui un byte di dati è completamente ricevuto (e potenzialmente molto lavoro se tutti e 16 i canali hanno un byte di dati in arrivo contemporaneamente) ma sulla maggior parte dei campioni la quantità di lavoro sarà molto leggera. Se uno avesse 64 pin I / O, si potrebbe gestire fino a 32 UART usando questo approccio senza aggiungere ulteriore lavoro al caso "comune".

Un microcontrollore come un Picaxe potrebbe acquisire i dati seriali su un pin ed emettere i dati seriali su un determinato pin in modo appropriato. Ciò darebbe effettivamente più uscite seriali se si fosse pronti a dire al Picaxe su quale pin eseguire l'output. Potrebbe anche fare lo stesso, ma al contrario, quindi potrebbe ricevere dati seriali da più dispositivi e inviarli a Raspberry Pi. Un'altra opzione potrebbe essere quella di fare in modo che i dispositivi collegati richiedano un qualificatore . Ciò significa che il dispositivo 1 dovrebbe ricevere i dati 'd1', ad esempio prima di ascoltare ulteriori dati sulla linea seriale. Il dispositivo 2 potrebbe avere 'd2' come qualificatore. Ciò significherebbe che per dire 'ciao' al dispositivo 1, dovresti semplicemente inviare 'd1hello' sulla linea UART.

I picax sono abbastanza economici, puoi trovarli su http://www.techsupplies.co.uk/ e sono disponibili in numerose dimensioni con diversi numeri di pin e così via.

Se la comunicazione con i vari dispositivi slave UART non deve avvenire in parallelo, è possibile condividere tra loro una delle porte UART disponibili. È possibile utilizzare i transistor per abilitare solo le connessioni RxD / TxD al dispositivo con cui si desidera attualmente parlare. Questi transistor possono essere controllati da altri pin GPIO Raspberry Pi.

Raspberry Pi 4 supporta ora fino a 4 interfacce UART che devono essere abilitate mediante un overlay dell'albero dei dispositivi. Puoi trovare come fare e quali Pin sono usati qui per ora:

https://www.raspberrypi.org/forums/viewtopic.php?t=244827

La fondazione RPi sta ancora preparando la documentazione per questo.

Ho avuto lo stesso problema. Ho bisogno di collegarmi a 2-4 moduli GSM e ho trovato una soluzione hardware: http://www.instructables.com/id/SPI-to-4-x-UART-Bridge-MULTIUART/

Questa soluzione è basata su PIC24FJ64GA306. È possibile sostituire PIC con Atmel mcu, ma è necessario creare un nuovo PCB :)

Sto usando SC16IS752 IC che è convertitore da SPI a 2xUART. Funziona bene con Raspbian Stretch.

È un po 'più costoso del chip FTDI, ma ci sono due uart e non devo usare la preziosa porta USB.

Dai un'occhiata a https://www.kickstarter.com/projects/1915118535/uart-hat-for-raspberry-pi spero che possa risolvere il tuo problema