La mando sul display perchè ero stufo, avendo un solo cavetto di connessione, di dover staccare il primo PPTEA e collegarmi al secondo per vedere che succedeva... comunque, tutto può essere... dovrei provare cosa succede facendo un loopback sulla seriale dello stesso PPTEA...

ASPE'...HO UN PROBLEMA...E' COLPA MIA....E' COLPA MIA...MA NON SO DOVE E COME...IIIIUUUUUUUU

10 SETIO=&H400FF
30 A=64
35 A++
40 SERIALOUT=CHR(A)&CHR(A+1)
45 WAITMS 250
60 B=SERIALINPSTR
70 IF B ="" THEN 60
130 PRINT "RICEVUTO" & B
135 WAITMS 250
140 GOTO 35
Non avendo 2 pptea ho seguito il tuo suggerimento...chiuso in loopback funge ma solo fino a due caratteri...quando metto il 3 ....se lo perdeeeeeeee!
Devo vedere il firmware e capire dove e quale è il problema ... !

...Evvai! un altro bug trovato!!! (non sto prendendoti in giro, sono felice perchè si migliora il PPTEA!)
Adesso ti spedisco due KSB, non è possibile che il guru abbia solo un esemplare...

Ciao non è che non ho due 'esemplari' ora non ho il tempo per metterne due in configurazione incrociata...

Sto riducendo la superficie del cerchio per centrare il problema...sono partito rifacendo le prove con il RASPBERRY e funge tutto...quindi mettendo due PPTEA in modo incrociato con due programmi MASTER-SLAVE...si testano le comunicazioni. Ho cercato di utilizzare tutto, USB etc...e tutto sembra andare bene.Quindi dove è il problema? Non lo so ...ma piano piano ci arriviamo!

Dalle prove che sto facendo (PPTEA 3.0) sembra che tutto funga...per il momento solo il loopback sembra abbia problemi...il motivo è legato probabilmente alla contemporaneità dei dati...cioè mentre si inviano i dati vengono contemporaneamente ricevuti, il che mi fa pensare che si utilizzi la stessa area di memoria...spero che il problema non sia nelle librerie della microchip...ma anche se fosse si sistema anche quello.

Ho fatto la prova con 2 PPTEA MASTER/SLAVE con tx/rx incrociato e la cosa funge ...questo è il codice:

MASTER

10 'PPTEA-PING PONG DUE PPTEA:PPTEA MASTER
20 SETIO=&H400FF
25 CONSTANT ATTESA_MAX_RISPOSTA=1 ' ASPETTO AL MAX 1 SECONDO
30 USBOUT ="TEST PING/PONG MASTER"
40 CNT++
47 STR="<ping>"
48 PRINT "ERRORI:" & NR &"--> " & STR
50 SERIALOUT=STR
55 RESET_TIMER
60 H=SERIALINPSTR
65 IF TIMER > ATTESA_MAX_RISPOSTA THEN :NO_RESPONCE
70 IF H="" THEN 60
75 IF H="<pong>" THEN 90
77 NR++
80 PRINT "ERRORE:" & H
90 WAITMS 250
100 GOTO 40
150 :NO_RESPONCE
155 PRINT "NESSUNA RISPOSTA"
156 BEEP
157 SERIALCLOSE
160 NR++
170 GOTO 40



SLAVE

10 'PPTEA-PING PONG DUE PPTEA:PPTEA SLAVE
20 SETIO=&H400FF
30 USBOUT ="TEST PING/PONG SLAVE"
60 H=SERIALINPSTR
70 IF LEN(H)=0 THEN 60
72 IF H="<ping>" THEN 80
76 PRINT H
78 GOTO 156
80 RASPSEND="<pong>"
90 CNT++
156 BEEP
157 PRINT "N:"&CNT
170 GOTO 60

24.000 invii senza colpo ferire...
Il cerchio si restringe!

Prova con i dati binari....
Ho preso il tuo ultimo codice e l'ho provato ed ho notato dei problemi inerenti la seriale con:
1.display
2.pause
3.velocità 4800
I 3 eventi potrebbero essere scorrelati...sto stringendo sempre più il cerchio!In effetti il programma di sopra funge perchè non ha le cose sopra segnalate...

Questo codice funzica..ma solo perchè ho commentato alcune linee di codice
Esempio:
MASTER

5 PRAGMA INTERNAL_EEPROM 'MASTER
10 CADS=0
20 SETIO=&H6F7EC
30 'SERIALSPEED=SPEED_4800
40 DTAOUT=Rnd MOD 254+1
45 MSGID=&HA0+SLAVE
50 MRQ=MASTER*16+&HF
60 CHECK=(MRQ+DTAOUT)
70 CHECK=CHECK-((CHECK/256)*256)
80 MSGOUT=CHR(MSGID)&CHR(MRQ)&CHR(DTAOUT)&CHR(CHECK)
90 LCDPOS=17
100 LCDWRITE=MSGID & " " & MRQ & " " & DTAOUT & " " & CHECK & " "
110 SERIALOUT=MSGOUT
115 PRINT "OUT=<" & MSGOUT & ">"
120 'WAITMS 850
122 'LCDPOS=33
123 'LCDWRITE=BLANK16
125 MSGIN=SERIALINPSTR
130 'LCDPOS=33
133 IF LEN(MSGIN)=0 THEN 125
135 USBOUT= "IN=<" & MSGIN &">"
137 IF ASC(MID(MSGIN,4,1))=CHECK THEN 150
140 PRINT "NOK!"
145 BEEP
149 GOTO 40
150 PRINT "OK!"
999 GOTO 40

SLAVE


5 PRAGMA INTERNAL_EEPROM 'SLAVE
10 CADS=0
20 SETIO=&H6F7EC
125 MSGIN=SERIALINPSTR
126 IF LEN(MSGIN)=0 THEN 125
127 MSGID=ASC(MID(MSGIN,1,1))
130 MRQ= ASC(MID(MSGIN,2,1))
140 DTAOUT=ASC(MID(MSGIN,3,1))
150 CHECK= ASC(MID(MSGIN,4,1))
155 CK=MRQ+DTAOUT
156 CK=CK-((CK/256)*256)
160 USBOUT= "MSGID" & MSGID & "-" & MRQ & "-" & DTAOUT & "-" & CHECK
165 IF CK= CHECK THEN 170
167 USBOUT="->NOK!" & CR_LF
168 BEEP
169 GOTO 125
170 USBOUT="->OK!" & CR_LF
180 SERIALOUT=MSGIN
999 GOTO 125


Il cerchio si stringe sempre di più!!!

Penso di essere sulla strada giusta...allora il problema sembrerebbe non legato alle istruzioni che per altro non centrano nulla con la seriale...ma al fatto che per qualche motivo la seriale non memorizza i dati in ricezione se non è arrivato il comando di receive. Quindi ho risolto parzialmente il problema facendo questa cosa:
1.Master invia i dati
2.Il Master si mette in attesa ma deve farlo prima che lo slave gli reinvii i dati

3.Slave riceve i dati
4.Attende un pochino (WAITMS adeguata)
5.Reinvia i dati ( quando invia il master deve aver fatto l'istruzione SERIALINPSTR

Il problema che si verifica nel codice è che commentando nel master la wait e le istruzioni del display (queste possono essere messe dopo la ricezione) tutto funziona.

MArko,ci aggiorniamo quanto prima...
Bolle

...quindi, la ricezione di dati in background dalla seriale non è possibile? Se il master o lo slave fanno dell'altro, non sentono i dati in arrivo? avevo capito che i dati in ricezione dalla seriale, finivano in un buffer e venivano letti con la SERIALINPSTR... non capisco il punto 5... comunque, rimanda le spiegazioni a dopo, ti lascio lavorare...

A dire il vero pensavo anche io che funzionasse in background...
In sintesi uso la seriale della microchip...può darsi che sia halfduplex...oppure manca qualche settaggio.
Se si utilizza un sistema di comunicazione client-server ... dovrebbe funzionare perchè da questa prima analisi sembra che il problema sia solo dovuto alla contemporaneità dei dati...tant'è che non riuscivo a capire come mai con le applicazioni che avevo fatto non era saltato fuori il problema...il loopback è stato un chiaro esempio del problema in corso!
Cmq dammi tempo che sto analizzando la questione, i dati possono essere messi in pericolo dalla sola ricezione (la trasmissione è ok) dei dati provenienti dalla USB... ...purtroppo non ho molto tempo!
Ciao
Bolle

...ricordo che per il modulino RF usavi il bit 15 per la ricezione non bloccante... c'entra qualcosa? Per la domotica, ho previsto che lo slave, nei momenti in cui non fa nulla, monitorizza la seriale in attesa di comandi; quando riceve dei dati, cerca il suo ID e se lo trova esegue il comando inviatogli dal master... anche quando deve comunicare qualcosa, aspetta sempre il via libera del master... quindi dovrebbe funzionare, ma in pratica non lo fa... c'è da dire che per debugging invio al pc via usb delle info su cosa stia facendo il PPTEA... potrebbe dare fastidio? Come sempre, sai che non ho fretta perchè, comunque, il tempo è tiranno anche per me.

Si, si ...hai ragione cerco di sistemare tutto quanto prima!
Ciao
Bolle

Questa sera operazione a cuore aperto sul PPTEA!

L'operazione è riuscita, ma il paziente è morto?