Salve,
ho necessità di comunicare con uno strumento che usa caratteri formati con 7 bit più il bit di start/stop...
Ho necessità di usare una seriale emulata perché la principale (ArduinoUNO) la uso per comunicare con il pc.
Non ho idea di come aggirare il problema...Sapete se qualcuno ha fatto una libreria più evoluta che permetta di settare la composizione del carattere come nella seriale cablata nel micro?
Grazie a tutti
Alex
Che parità usa ? 7 E 1 ? Se si prova a leggerti QUESTO thread e, comunque, li trovi parecchie informazioni 
Guglielmo
P.S. : E cerca anche su Google per Arduino SoftwareSerial 7E1
Beh, 7N1 direi che non usa la parità :).
Raga,
vi metto in allegato la descrizione di come comporre il carattere da inviare. A me sembra un 7bit per il codice ascii...ma mi posso sbagliare, non sono molto pratico...
800comms.pdf (56 KB)
7E1 va benone.
Quel documento dice che il bit di parità può essere Odd, Even, o ignorato (ma comunque c'è) e 1, 1 1/2 o 2 bit di stop.
Guglielmo
Quindi è giusto voler modificare la SerialSoftware.
Ad essere onesto mi funziona anche con 8 bit.
Ho un documento fatto sniffando la comunicazione tra questo strumento, un PID per la regolazione termica, e un programma fatto con labview... Questo documento mi è stato passato...
Analizzando il codice ho visto che ad esempio il primo carattere che dovrebbe essere il classico EOT (ASCII 04) viene rappresentato con il carattere ASCII 132. Sembra ci sia un offset di 128... ho verificato anche altri caratteri e tutti hanno sta cosa...
Sapete illuminarmi sul motivo?
La SoftwareSerial lavora 8N1 (... ovvero, in tutto, 10 bit), se tu programmi lo strumento per lavorare in 7N2 hai la stessa lunghezza del dato (... sempre 10 bit sono) solo che, quando ricevi un byte, ne fai l'AND con 0x7F e lo trasformi in un 7 bit con parità sempre a 0 ... altrimenti leggi come dato anche il bit di parità.
Guglielmo
gpb01:
La SoftwareSerial lavora 8N1 (... ovvero, in tutto, 10 bit), se tu programmi lo strumento per lavorare in 7N2 hai la stessa lunghezza del dato (... sempre 10 bit sono) solo che, quando ricevi un byte, ne fai l'AND con 0x7F e lo trasformi in un 7 bit con parità sempre a 0 ... altrimenti leggi come dato anche il bit di parità.Guglielmo
Capito, il mio problema è trasmettere..io trasmetteri con una seriale 8N2 (softserial non modificata) ma vorrei invare la stringa utilizzando i caratteri ascii standard. C'è qualche "magheggio" che posso fare per costruire il carattere interpretabile correttamente dallo strumento che legge una seriale 7N?
Non so se mi sono spiegato, non so neanche se mi sono capito! 
Tu trasmetti con un 8N1 (non 8N2 che sarebbero 11 bit) ... prima di inviare il carattere fai anche li una AND con 0x7F e metti a 0 il bit che lo strumento interpreta come parità. Però potresti avere problemi con gli stopbit ... :
Da provare ...
Guglielmo
gpb01:
Tu trasmetti con un 8N1 (non 8N2 che sarebbero 11 bit) ... prima di inviare il carattere fai anche li una AND con 0x7F e metti a 0 il bit che lo strumento interpreta come parità. Però potresti avere problemi con gli stopbit ... :Da provare ...
Guglielmo
Capito, dopo mi leggo il link che mi hai passato per modificare la seriale. Se ci capisco qualcosa (ne dubito) mi tolgo il dente e modifico la seriale e faccio una nuova lib da usare per le applicazioni con queste specifiche di seriale. Chissà se aggiorneranno mai la softserial inserendo anche la modifica della lunghezza dei bit...
La seriale HW del ATmega328P presenta la possibilità di impostare il data frame da 5, 6, 7, 8 o 9 bit, il bit di parità assente, even o odd e 1 o 2 bit di stop. La selezione non è possibile direttamente dalla libreria Serial, in quanto 5, 6, 7 hanno poco senso nelle applicazioni comuni, se devo inviare meno bit il frame lo mantengo da 8 e aggiungo del padding nei bit che non trasportano informazione. 9 bit invece sono scomodi da maneggiare, il microcontrollore è a 8 bit, vuol dire usare due registri per contenere solo 9 bit.
La selezione invece dei bit di stop è anche essa superflua nei casi piu comuni, con 2bit vai sul sicuro ma poco cambia(Il canale quando è in idle è come se fosse composto da una serie di caratteri di stop, il/i bit di stop serve/ono a dividere trame indipendenti).
L'unica modifica che effettivamente è apprezzabile anche nel caso comune è l'abilitazione del parity bit.
Per la SW serial il discorso è simile, e se non sono stati implementati nella HW serial è provabile che non verranno implementati nemmeno nella SW serial. Quelle modifiche come hai visto te sono utili solo in casi particolari.
Edit:
Ma voi siete sicuri che la SoftwareSerial preveda l'uso del bit di parità? Dando un rapido sguardo al prototipo non ho visto niente che facesse pensare ad un parity.
In caso non presenti parity potresti provare usare la software serial e generare tu il parity bit da posizionare direttamente nel byte da inviare e inviare cosi trame da 1+7+1 bit(Forse una scelta più semplice che modificare la softserial che renderebbe il tuo codice meno portabile e perdere la possibilità di aggiornamenti automatici).
@RobertoBochet ... me sa che ti devi rilegge tutto il thread ... 
Abbiamo detto che:
Guglielmo
gpb01:
@RobertoBochet ... me sa che ti devi rilegge tutto il thread ...Abbiamo detto che:
- deve usare la SoftwareSerial per sue esigenze
- la SoftwareSerial NON usa la parità ma 8N1 (... comunque esistono dei thread con le modifiche per il 7E1)
- e abbiamo visto come azzera il parity bit in TX ed RX per trasmissione in cui il parity può essere ignorato
Guglielmo
La mia era una risposta a questa frase
Chissà se aggiorneranno mai la softserial inserendo anche la modifica della lunghezza dei bit...
Se non lo fanno per la HW è difficile pensare che verrà implementato per la SW.
Per rispondere al resto, ho letto bene il thread, ma il bit parity fa comunque parte del frame, se l'applicazione se lo aspetta bisogna fornirlo, l'unica cosa che mi era sfuggita era che avevate già determinato l'assenza di bit parity nella SW serial. Ho sottolineato come il 7N1 non sia troppo vantaggioso rispetto al 8N1, e che il frame da lui proposto prendesse in considerazione un bit di parità, che poteva accettare diverse configurazioni.
Il problema è che lui ha uno strumento che, dalla documentazione, sembra accettare : 7bit, E/O/N parity e 1, 1 1/2 e 2 stop bit.
Per evitare di incasinarsi, l'unica è spedire gli 8bit tenendo fisso l'ottavo e quindi simulare un 7N e poi però c'è da verificare il comportamento con gli stop bit (2 ... che in realtà sarebbero il N degli 8 bit del SoftwareSerial e lo stop bit vero del SoftwareSerial).
Guglielmo
Per quel punto sarebbe da capire la quantità e velocità di trasmissione delle trame, se deve inviare singoli caratteri ascii il problema non si pone, ma sarebbe un caso troppo comodo XD
Direi che non rimane da aspettare aggiornamenti dai test e se si verificano errori si sa gia la prima possibile causa su cui puntare il dito.