E' possibile Invertire il segnale TXD della uart via sw?

[flipper]

salve a tutti,
volevo sapere se con i comandi bascom (quindi via sw) è possibile invertire il segnale di uscita TXD della uart di un atmega32 senza aggiungere componenti esterni.

ciao

[legacy]

credo che non si possa, poi non so, non conosco il tuo hw, ancora prima di parlare del sw

te lo dico perche' che io sappia il solo modo di poter swappare rx con tx, se e' questo che chiedi
e' far uso di softuart implementate con gpio: in questo caso basta invertire il datadir di due GPIO.pin
ed invertire gli handler associati ai quei due GPIO.pin
si puo' fare via software

ma se la uart e' hw, micro cablata nella MPU, "mi sa" che fisicamente una uscita ed un ingresso non sono reversibili

[flipper]

se è possibile con la softuart mi potresti spiegare passo passo con qualche riga di codice bascom come fare?
ti ringrazio molto.

[legacy]

purtroppo non conosco bascom, non ancora, e nemmeno avr8 perche' non li uso
uso altre MPU, pero' il principio dovrebbe essere lo stesso

[deluca]

@legacy la questione è diversa:
secondo me flipper ha necessità di invertire il livello logico dello zero e dell'uno (ovvero la polarità di TXD) e non RXD con TXD.

ciao flipper,
la perierica uart che si trova sulla famiglia mega di atmel non prevede la possibilità di configurare la polarità del TXD.

ma volendo utilizzare la uart (in modalità hw) potresti collegare l'uscita TXD all'ingresso INT0 del m32 configurandolo sul fronte di discesa e gestire con l'isr dell'int0 una uscita ausiliaria (sincronizzando opportunamente i dati).
andando su altro chip ad esempio mega168 o similari dotati di pcint (pin-change interrupt) potresti banalmente invertire il segnale TXD realizzando lo stesso collegamento che ho descritto sopra.

Tuttavia, la soluzione ottimale è quella di configurare una uart virtuale software definendo un pin dedicato TXD supplementare e usando PRINT #1,"1234" per spedire sulla nuova seriale i dati in modalità INVERTED.

Code: Select all

Open "COMD.1:9600,8,N,1,INVERTED" For Output As #1
Print #1,"1234"

per chiudere la com puoi usare "Close #1"



in questo esempio definiamo una com sul portd.1, con baud=9600, no-parity, 1bit-stop, modalità invertita
possiamo definire molte di queste com, diciamo quanti sono i pin di I/O

ciao

[legacy]

ah, ok, il risultato che si cercava e' quindi invertire la polarita'?
cioe' cio' che si ottiene con una porta not, insomma

mai fatto in vita mia, mentre mi capita spesso di dover swappare rx con tx
sopratutto perche' mi invertono i segnali sui connettori
quando mi cambiano o aggiornano le schedine, e capita spesso
(anzi capita spesso anche con kit sparkfun da una revision all'altra )
se c'e' un cablaggio a filo e' un attimo, se la scheda va su connettore
mi scoccia modificare il pcb, quindi adotto da un bel po' la soluzione softuart
cosi' se invertono rx con tx io mi adatto via software: easy, no ?

ma per curiosita', il motivo di cio' ?
c'e' proprio a valle un dispositivo seriale uart che ha polarita' invertita ?

[flipper]

grazie deluca, sei un mito, mi hai salvato !!!

devo trasmettere dati seriali con un modulino rf che vuole in ingresso un segnale rs232-ttl inverted.
il baud-rate è di 2400 quindi banalmente posso cambiare il 9600 riportato sul config con 2400?

provo e ti faccio sapere, speriamo bene.

comunque grazie

[flipper]

ciao,
deluca, ho provato tutto, il trasmettitore adesso funziona bene ma mi succede una cosa:
ogni tanto ricevo dei dati non corretti, cioè ad esempio se trasmetto "1234567890" ricevo ad esempio "#234567890" o "^234567890" o simile.

sto inviando i dati a 4800bps ma ho provato anche con altri baud.
quale potrebbe essere il problema?

nel modo non inverted(normale) non funziona completamente come avevo già detto.

grazie tante per l'aiuto.

[legacy]

eh, le softuart non sono tanto belle per un aspetto: soffrono di drift!
non so se e' il tuo caso, nel mio caso con i PIC devo necessariamente calibrarli(1) altrimenti non trasmetto/ricevo bene
ed incorro in problemi simili a quelli che racconti tu

(1) alcuni vengono calibrati in fabbrica, direttamente da Microchip

si ha lo stesso problema anche sulle vecchie PCMCIA/16bit UART stra economiche (tipicamente cinesi)
che si montano su portatili muletto da laboratorio dove per forza di cose non hai porte usb libere per le usb-uart
la soluzione pcmcia uart poi a me piace di +, anche se spesso succede che nella cinesata di turno
per risparmiare le volpi hanno messo su softuart, tipicamente usando micro stra economici
e ancora una volta poi tocca calibrare altrimenti non funzionano correttamente

boh, qui lo dico e qui mi fermo, sono curioso di leggere quale e' la questione del tuo specifico problema
a spanne mi sembra drift issue, ma purtroppo non usando avr8 altro non posso fare e dire


pero' il tifo si

[deluca]

@flipper,
stai usando dei modulini wireless 433 TX e RX per trasmettere e ricevere dati (giusto?)
il problema è che se questi modulini modulano i segnali(dati) in AM - OOK (On Off Keying) hai necessità di codificare(TX) e decodificare(RX) i dati utilizzando il codice-manchester.

A proposito di questo era stato aperto un topic:
viewtopic.php?f=9&t=361

qui puoi trovare anche una porzione di codice per codificare e decodificare i dati in codice manchester.

@legacy,
il "drift issue clock" degli atmega anche utilizzando il clock interno è bassissimo e in ogni chip è il valore del clock è garantito con un valore di calibrazione fin dalla fabbrica.
con questi baud-rate bassi anche con un error% di qualche percento la ricetrasmissione continua ad essere efficiente.

Ancor di più se codifichiamo in manchester.

ciao

[legacy]

@flipper
posso chiederti che modulini hai preso e dove li hai presi ?
quasi quasi una coppia li prendo anche io =P



@deluca, certo manchester e' migliorativo, sopratutto per questo genere di cose
ma direi anche: ottimo! significa che AVR8 per fare softuart e' meglio dei PIC

perche' l'accrocchio di cui parlavo, usando un pic con clock interno (tanto per risparmiare anche su quello)
ha delle rognette di drift, e guarda un po' cosa mi tocca fare

Code: Select all

(sotto linux) myuart-pcmcia-config /dev/ttyS0 uart 16550A port 0x400  irq 58 baud_base 921600 caldrift 0xa3


in pratica i furbastri per farti pagare solo $10 un modulino pcmcia (che da Manathan come minimo paghi 60 euro)
usano un pic molto economico sprovvisto di seriale fisica implementano softuart
e spacciano ai driver di linux il modulino come se fosse "16550A"
mappato (nel mio caso, su portatile Apple/PPC) all'indirizzo 0x400 usando interrupt 58
poi come vedi tocca settare il baud base dell'oscillatore locale, ma anche dargli un valore di correzione pari ad 0xa3
in pratica 0xa3 viene caricato nei registri del pic preposti alla compensazione, e come se fosse calibrazione da fabbrica
e ogni tanto mi tocca ri calibrarlo, specialmente per baud rate o troppo bassi (p.e. 300bps) o troppo alti (p.e. 115200bps)
i valori di fabbrica mi funzionano bene da 4800bps a 38400bps, praticamente i bitrate di maggior uso
sopra o sotto questi bitrate devo ricalibrare, cosa che faccio richiamando lo scriptino con caldrift diversi

dopo tutto funziona, e per quello che costa funziona anche bene; geniali i cinesi, no ?

e ora che lo so, quasi quasi copio i cinesi, tolgo il pic e metto un avr8, poi metto tutto in rete
cosi' al prossimo giro di iterazione su chi copia meglio loro migliorano il loro lavoro