Bravo Marko,
forse ho trovato il problema, è una questione molto sofisticata, per ora verificami se ti funge il codice eabasic...poi vedrò di trovare una soluzione. Non sono certo ma apparentemente il controllo con una variabile (NULL) al posto di una costante sembra non creare problemi...ma è tutto da capire...il problema è confinato in uno spazio molto ristretto...quanto prima lo uccido...spero
Ciao
Bolle

CODICE PPTEA MASTER:

Nel frattempo ho rifatto le prove su cavo lungo, mettendo in serie i vari doppini, con tre PPTEA sparsi per casa ho coperto una lunghezza di bus di circa 120mt...
in giornata provo il codice che hai postato, mi dici al volo in cosa lo hai modificato?

Ho inserito la variabile NULL (linea 15= ed ho fatto il confronto con la variabile invece che con la costante...tutto qui...ma è solo una pezza in attesa di risolvere.
Ciao
Bolle
PS:Vedo che procedi alla grande...ho anche pensato perchè il wifi non funge...è tarato su una certa velocità per i moduli aurel...manca il setting della velocità!

XMarko,
trovato il problema a livello di firmware...era più tosto del previsto...ma alla fine ha soccombuto...Firmware 2.16u provalo con qualsiasi tipo di codice.

X Pino,
se c'è spazio provo a metterlo nella prossima versione...provo a fare la consegna 2.16u.

Ok...
riguardo al wifi, io ho provato il CAN-BUS con la seriale su tutte le velocità possibili, e non ho mai avuto problemi... non ho indagato più di tanto, ma mi pare che gli stati logici dei pin di TX ed RX a riposo siano diversi quando la porta è impostata come WIFI piuttosto che come RS232. Sarebbe bello riuscire a far funzionare i transceiver con il protocollo wifi, in maniera da avere un unico modo di trasmissione per poter trasmettere anche a slave non raggiungibili con il rame.
Adesso provo il firmware nuovo (ma non doveva essere "t" ?) , e poi semmai mi metto d'impegno su questa cosa...

...stai bravo e pensa ad altro, per quanto mi interessa, funziona anche in rs232, io farò i test del caso e poi ne riparliamo... sarebbe interessante fare la prova contraria, porta RS232 su modulo Aurel... credo che almeno in un punto dovrò usarlo (a meno di magie con le sonde e lo scivolante... )

Avevo scritto un messaggio ma probabilmente non l'ho inviato...
Chiedevo quali differenze ci sono fra la RS232 (TTL) e il "WiFi", e se fosse il caso di mantenere o meno quest'ultima, mi ricordo che parlavi qualcosa riguardo alla codifica manchester, ma non mi è molto chiaro il tutto, non basterebbe avere la RS232 e poi uno ci collega ciò che vuole? Mi rendo conto che non c'é una UART a gestirlo, il problema, penso da profano/praticone, e quello di gestire entrambi i buffer, sia di input che di output....sempre che ci siano...

Ciao Pino e Marko

il motivo è legato al segnale che deve 'ballare' ed avere una certa frequenza...facciamo un esempio, se inviamo tutti 0...il segnale è quasi sempre basso...la codifica serve cmq a far oscillare i dati costanti....quindi se mandi un segnale seriale ad un modulino aurel (od altro) che non è predisposto per la seriale...questo non funzica...la codifica oscilla e invia un segnale oscillante anche se questo è costante...e poi la decodifica risistema tutto.
Il PPTEA gestisce sia la codifica WIFI che i dati seriali...ora occorre capire come mai a marko non funge...quando ho tempo faccio vedere le differenze.
Quindi se provate la seriale su un modulo generico wireless non funzica...quelli che gestiscono la seriale costano di più.
Ciao
Bolle

...ho capito che devo prendere a prestito l'oscilloscopio in azienda...

Credo di aver capito che il segnale che "balla" in pratica è un clock che serve a tenere sincronizzato il ricevitore in attesa dei dati, ogni tanto mi sovvengono vecchi ricordi...

@bolle: stavo pensando ad una cosa del genere, per rendere il progetto fruibile a tutti e non limitato al mio uso:
allocare una parte della memoria esterna per una tabella; l'indirizzo della cella di memoria lo ricavo dallo stato dalla linea di input attivata e dal tempo di pressione del pulsante, a questopunto leggo il contenuto della cella che mi riporta lo stato da assegnare alle uscite; prevedo un ciclo di "programmazione" del pptea slave per caricare/aggiornare la tabella, e la tabella di assegnazione stato ingressi/stato uscite la creo con un sw ad hoc su PC... in questo modo, una volta inserito il codice nel pptea slave, ogni modifica di funzione all'impianto la faccio via comunicazione seriale, senza riprogrammare ogni slave...
che ne dici?
Il problema è: come faccio a sapere con certezza il "base address" dal quale la eeprom esterna non è usata per il codice?

Direi soluzione ottima ed elegante. Per risolvere il tuo problema ,che problema non è, è molto semplice:
prendere nota della lunghezza del codice compilato (numerello presente nella fase 7 ) . Se si usa l'exp di memoria quel valore può arrivare al max a 2047...ciò vuol dire che da quel valore in poi la memoria è libera. Quindi puoi utilizzare i valori partendo dal fondo.

Esempio: se ti servono 60 Byte...la parte dati la metti da 1980 a 2040. In questo caso il valore del compilato deve essere inferiore a 1980!!!
Sono stato chiaro?

Ciao
Bolle