Questo topic nasce grazie a questo
Ma anche grazie a @cotestatnt che mi ha dato modo di scoprire il simulatore online.
La questione brevemente la riassumo:
HC12 (non posseggo neanche arduino, quindi tutta teoria) in totale diciamo 5, 1 master e 4 slave.
Tutti possono impegnare il bus e tutti possono ricevere se accadesse tutti riceverebbero cosa? marmellata? bene diciamo che ci organizziamo.
Il link al programmino e qui
Per adesso riconosce di essere interrogato grazie a questa porzione di codice:
result = 0;
// put your main code here, to run repeatedly:
if ((haveQuestionedMe == false) && (Serial.available() == lenCode)) {
for (uint8_t i=0; i<lenCode-1; i++) {
result += (uint8_t)(miAspetto[i] - Serial.read());
Serial.println(result);
}
Nota: available restituisce n+1, cioè se inseriscei abc n vale 3, forse conta anche il CR.
Provate voi a metterlo in difficolta inserendo una sequenza diversa da array miAspetto[].
Quando vi riuscite fatemi sapere come avete fatto.
Per adesso mi balena per la testa di potere entrare in modo sicuro in modo raw e poi uscire.
In modo sicuro significa che in modo raw non si deve potere presentare una sequenza che accidentalmente lo faccia uscire da modo raw. Certe cose si pagano, un byte a 0 ogni 4 byte, la sequenza per entrare e uscire è composta da 5 byte. Che ne pensate?
Mi era sfuggito questo post
Anche io ho scoperto questo simulatore grazie ad un utente del forum inglese!
Ho provato lo sketch e non sono riuscito a trovare il modo di "metterlo in difficoltà"...
Volevo però proporre anche un approccio leggermente diverso: ad esempio io in questi casi preferisco sempre usare un messaggio tipo [START] [ID] Messaggio [STOP] (più eventuale checksum)
Con il simulatore ho dovuto per forza usare dei caratteri stampabili, ma ovviamente è possibile usare lo stesso sistema anche con dei byte "grezzi".
In linea di massima concordo, però devi ammettere che è un ottimo esercizio cercare di "costruire" un protocollo di comunicazione sicuro e funzionante.
... certamente, magari studiando però prima ciò che esiste (... e funziona benissimo) per poi fare qualche cosa di ancora meglio ... altrimenti è del tutto inutile.
A me lo dici, io oltre al forum arduino ero iscritto al forum di Giovanni (gioblu), Ricordo che da un post sul principio di funzionamento di un led lui ne ricavo un modo per comunicare ottico sfruttando come ricevitore un normalissimo led e anzi pubblicò tabelle che mostravano quale led era più efficiente. Di base ricordo che Giovanni si occupava principalmente di siti web.
Comunque, non ho usato PJON perché non ho necessità pratiche, poiché non ho HC12 né arduino, ho tutto in montagna (tranne HC12). Il codice nasce dal fatto che nel topic HC12 datalogger proposi un algoritmo simile ma mi venne fatto notare che con le sequenze abc bac ecc non funzionava, quindi non mi concentrerei sul protocollo ma sull'algoritmo per verificare le sequenze che intuitivamente viene fatto con if annidate o con l'operatore && e sono if interminabili.
C'era un errore e andava in difficoltà se inserivi un byte meno, cioè un falso positivo, ora corretto.
Si in un protocollo quanto meno questo sarebbe il minimo.
Visto, ma me lo guardo meglio. Si il vincolo dei caratteri stampabili è una limitazione anche per me, serve arduino vero ma posso (devo farne ammeno per adesso) provare sul pc nativo. Ho visto che usi il metodo find di Serial per le sequenze, poi me lo studio per bene.
PS: non so quanto vi siete resi conto che anche con le limitazioni che ha quel simulatore è utilissimo specie con gli utenti alle prime armi.
Si, è un metodo della classe Stream (genitore di Serial).
Verissimo! Io da quando l'ho scoperto lo uso tantissimo anche per me stesso. Magari mi viene in mente un possibile algoritmo, apro il browser e lo testo in 5 minuti.
E' un po' meno "fornito" di componenti rispetto a Tinkercad, ma la simulazione è molto più reattiva e non richiede registrazione.
Inoltre supporta più tab, cosa importantissima che consente di caricare anche librerie non ufficialmente supportate.
Occhio al buffer overflow, la prima cosa che ho provato. Altra cosa con le statemachine può capitare che resti nel case START_FRAME troppo tempo in attesa (perché a causa QoS basso si è perso qualcosa) e allora un timeout che rimette tutto a zero e in IDLE.
Peccato che il simulatore non mi permette di inserire raw data, l'avrei voluto vedere a lavorare sugli indirizzi di memoria, in sostanza in raw mode riceve una struct composta da indirizzo e valore, casta l'intero ad indirizzo di memoria e ci scrive su (o legge, ma scrivere su un indirizzo arbitrario mi da un certo fremito.
Sono l autore del post indicato
Avevo visto questo ma non sono così bravo
Un aiuto ad implementarlo?
Questa la stringa completa che voglio memorizzare
11:20:19 28/12/2021,#a,C, 15.36,C, 70.68,%
Questo quello che arriva dagli slave #a,C, 15.36,C, 70.68,%
grazie
Perdona, ma NON è così banale ... bisogna che ti scarichi tutta la documentazione, ti studi bene il prodotto, vedi il tipo di collegamento che più si addice alla tua configurazione e poi guardi i vari esempi da cui prendere spunto.
Meglio continuare dal topic di origine anche perché lo hai aperto tu (questo l'ho aperto io).
PS: hai frainteso, credo, comunque "non riusciamo a comunicare". Se interrogo stefa24x tu NON sei stato interrogato ma lo è stato (se esiste) lo slave che si chiama stefa24x, il quale dovrebbe rispondere stefa24xACK (se risponde vuole dire che è raggiungibile diversamente è guasto, batteria scarica, irrangiungibile fuori campo e.. molti altri raggionamenti potrebbero essere fatti.
bene diciamo che ci organizziamo.
