... io ero sottocapo nocchiere di porto a naja

Bolleeee!!!! Viaggia come un trenoooo!!!! il sistema domotico master/slave ha girato tutta la notte, il master inviava comandi allo slave ogni 2 secondi, e stamattina girava ancora tutto. Ora ho implementato la versione che conta eventuali failure di risposta dallo slave, e siamo a >1900 rtx con 0 fails!!!! Favoloso!!! Nel PPTEA/DOMO ho rimosso la SERIALCLOSE che inviavo alla fine di ogni ciclo di polling della seriale... La versione del fw che hai postato è "beta" o "release"? Ho una richiesta per una KSB, quale uso?

Bene bene...sono contento...mucho contento.
Però considera che la SERIALCLOSE o meglio la SERIALRESTART ( disponibile nella prossima versione del compilatore come macro ) devi comunque gestirla...per il semplice fatto che se ti arriva un forte campo elettromagnetico (vedi fulmini) ...la seriale si potrebbe impallare.Cmq un reset sistema tutto.
Per quanto riguardava la nuova release...aspettavo un tuo riscontro.
Ciao
Bolle

P.S. Mi sto documentando un pochino sul Can-bus, e sto scoprendo che è nato per l'automotive... già immagino il prossimo progetto: il PPTEA in auto, che si interfaccia con il computer di bordo e i vari sensori collegati tra di loro proprio con questo protocollo!!!

In realtà, del CAN io utilizzo solo i transceiver (transmitter-receiver) che portano la comunicazione seriale bifilare punto-punto del PPTEA su di un bus bilanciato punto-multipunto, permettendo di collegare n PPTEA in parallelo. Il protocollo CAN non lo conosco e non lo uso; praticamente è come se comunicassi via radio, quando uno trasmette, gli altri ascoltano, e parlano solo a canale libero. Il vantaggio è che non ho problemi di lunghezza del bus, ed isolo le seriali dei PPTEA dalla linea di trasmissione. Il tutto (PPTEA/DOMO) funzionerebbe anche collegando il TX del master all'RX di tutti gli slave, e viceversa, ma un eventuale problema sui cavi "fumerebbe" tutte le porte collegate.
Come già detto, bisogna mettersi li, chi fosse in grado, per realizzare il software di programmazione della tabella del nodo, ed in seguito la gestione delle azioni "evolute", l'applet java per usare il cellulare con bluetooth come telecomando, l'interfaccia web per comandare da fuori casa l'impianto.... etc... etc.... salute!

Ok, ho solo un dubbio sui transceiver: quanti ne servono? Una coppia per bus oppure una coppia per ogni PPTEA collegato al bus stesso?
Hai uno schemino di come hai fatto questi collegamenti? Hai seguito questo schema di Grix.it che era stato postato?
www.grix.it/UserFiles/shsjk59456/Image/GBaseNet.GIF
Quindi non si capisce bene la storia dei transceiver...

Chiariti per tutti questi dettagli, poi possiamo passare alla parte PC

Lo schema che indichi è infatti quello che mi ha "ispirato"; come si vede li, serve un transceiver per ogni PIC collegato al bus; il transceiver MCP2551 come i MAX usati li, contiene sia il ricevitore che il trasmettitore, viene collegato ai pin TX ed RX del PPTEA ed alla alimentazione, ma la sua presenza è assolutamente "trasparente" per quanto ci riguarda (fatta salvo una "echo" della trasmissione che rientra nel buffer di ricezione, che è banalmente dovuto al full-duplex della porta seriale del PPTEA, e al quale il PPTEA/DOMO è fisiologicamente immune visto come ho strutturato la comunicazione...). Dal punto di vista del software, quindi, non è fondamentale la sua presenza: puoi fare delle prove anche senza utilizzarlo, semplicemente collegando il TX del master all'RX del(i) nodo(i) e viceversa. E' invece fondamentale usare il MAX232 per adattare i livelli logici della seriale RS232 del PC (-12V/+12V) ai livelli TTL del PPTEA (0V/5V); con questo accorgimento è possibile inviare dal PC sia la programmazione che i comandi di gestione ai nodi PPTEA/DOMO; in alternativa, bisogna usare un'altro PPTEA che riceva via USB i dati dal PC e li invii sulla sua porta seriale, e viceversa (che è quello che sto facendo io perchè non ho ancora avuto il tempo di saldare i 4 condensatori 4 ed i 6 fili 6 al MAX232...confido nelle nevicate previste in liguria). Appena riesco faccio comunque uno schema e posto il file excel aggiornato della programmazione... ciao!

... Fatte oggi le prime prove di comando di 2 PPTEA/DOMO collegati via serialCAN attraverso comandi inviati da PC con hyperterminal e interfaccia rs232/max232/CAN... funziona tutto (programmazione, comandi indirizzati, comandi globali)... ho solo un problema nella programmazione, incidentalmente per un comando destinato all'CAN_ID 2, il checksum viene 0, ed è male dice Bolle, in quanto il chr(0) chiude la stringa.
Ci lavoro un pò, poi avrò seriamente bisogno di qualcuno che faccia il sw di programmazione e controllo, perchè se mi ci metto io, a parte che lavorerei con VBA x excel, lo vediamo tra 2 anni...

Avrei bisogno di aiuto; per testare il protocollo di comunicazione mi servirebbe un semplice programma che invii ciclicamente via seriale una sequenza di singole stringhe di caratteri da 4 bytes, da me specificate, e che, alla ricezione di una stringa (sempre da 4 bytes, eventualmente risponda con un'altra, tutte da me specificate. I ritardi tra l'invio di una stringa e la successiva, tra la ricezione della risposta e la seguente trasmissione, dovrebbero essere specificabili indipendentemente.
Sarebbe anche utile avere una misura del tempo trascorso tra la trasmissione e la ricezione di una risposta. Dato che ad ogni trasmissione deve corrispondere una risposta, in caso di mancata risposta si dovrebbe ripetere la trasmissione allo scadere di un timeout... specificabile, ovviamente. Per ora, mi basterebbe poter specificare al massimo una decina di trasmissioni, risposte corrispondenti ed eventuali stringhe di risposta.
Grazie in anticipo a chi vorrà aiutarmi.
Ciao!

Domani ti faccio il sw...cerca di specificare le cose il più possibile.
Ciao
Bolle

Per ora, ben poche specifiche... mi bastano tre colonne di dieci caselle, la prima colonna contiene le stringhe da inviare (comandi per il/i nodo/i PPTEA/DOMO)
la seconda, la risposta attesa dal nodo; se la ricezione corrisponde alla stringa nella seconda casella, se specificata si invia la stringa nella terza casella (la quale avrà anch'essa una risposta, ma mi basta solo visualizzarla); se non è specificata una terza stringa, si passa alla riga successiva. Se non si riceve risposta ad uno degli invii, si ripete sino alla ricezione di una risposta. Dovrei poter specificare i timeout tra le varie operazioni, in msec. giunti alla decima riga, si riparte dalla prima.
Una futura esigenza (così ti prepari già ) sarà quella di estrarre i dati dalle stringhe ricevute, elaborarli e generare una nuova stringa di comando da inviare, ma questo dipenderà dai risultati dei test che farò, e dalla futura presenza di un calcolo CRC nativo nel PPTEA-IV, che mi eliminerebbe la necessità di calcolare un banale checksum dei byte della stringa.
Grazie per la disponibilità, ma se ci fosse qualcun'altro ad applicarsi, sarebbe meglio, visto quanto stai facendo... mica sei il famoso barbiere

Nessuno che si offre, oltre a Bolle di Siviglia? (tutti LO chiedono... tutti LO vogliono...)

aaaahahahhahaahaahahahahhahaaaa...mi sento molto marinaio.....