Arduino e ricezione seriale

Ad ogni modo l'evento di ricezione viene già realizzato in automatico su un thread diverso dal principale

L'evento DataReceived viene generato su un thread secondario quando dall'oggetto SerialPort vengono ricevuti i dati. Poiché questo evento viene generato in un thread secondario e non in quello principale, il tentativo di modificare alcuni elementi del thread principale, come gli elementi di interfaccia, potrebbe generare un'eccezione thread. Se è necessario modificare alcuni elementi nelle classi principali Form o Control, eseguire il postback delle richieste di modifica utilizzando il metodo Invoke, che eseguirà il lavoro nel thread appropriato.

(msdn.microsoft.com/it-it/library/system....d%28v=vs.110%29.aspx)

Ma ripensandoci... non può essere la questione del thread, perchè io il contatore che mi serve a controllare l'inattività, lo azzero proprio dentro l'evento datareceived... quindi se si incrementa fino ad arrivare al valore di controllo... vuol dire che non viene mai azzerato... il che vuol dire che l'evento datareceived non scatta...

Ho controllato. I due sistemi sono equivalenti (methodInvoker o l'altro con il delegate). Il MethodInvoker è piu semplice e si usa quando non bisogna passare/aspettarsi parametri. Ad ogni modo non vengono eseguiti su un thread separato.

aspetta Gianni, ora sono un pò confuso... mi stai dicendo forse che quando invoco il delegate per la ricezione sulla seiale sono sul thread principale mentre l'evento data received viene eseguito su un thread separato? ho dei dubbi sul fatto che thread secondario e thread separato siano la stessa cosa. Questo perchè avrei potuto interromperlo in ogni istante... Invece no!!! Nel caso del pilotaggio otto servi ho dovuto creare un thread esterno...:

Dim ExtThread As System.Threading.Thread

nel main ho dovuto disabilitare il controllo incrociato delle chiamate ai threads...:

'DON'T REMOVE THE FOLLOWING LINE: in this way, CheckForIllegalCrossThreadCalls is not performed
Control.CheckForIllegalCrossThreadCalls = False


nel pulsante di avvio del loop ho delegato il nuovo thread alla private sub servos_loop_on...:

Private Sub btnOn_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnOn.Click
'External thread for loop routine. Loop will never stop without it
ExtThread = New Threading.Thread(AddressOf Me.Servos_Loop_On)
ExtThread.Start()
End Sub


infine, per terminare il loop ho usato il pulsante btnOff con l'istruzione...:

ExtThread.Abort()


Solo così riuscivo a stare nel thread principale senza che mi si impallasse il pc, mentre i dati in arrivo sulla seriale continuavano ad arrivare all'infinito.....


Comunque, sotto certi aspetti, vb net è veramente deludente...


Marcello

Su MSDN viene detto così:

"L'evento DataReceived viene generato su un thread secondario quando dall'oggetto SerialPort vengono ricevuti i dati." e questo è evidente anche dal fatto che se metti, ad esempio, la scrittura di una label dentro l'evento datareceived, viene sollevata un'eccezione, per questo motivo i vari esempi utilizzano un delegato che fa da tramite tra quel thread e il thread principale.

Non ho capito il tuo programma cosa fa: premi il pulsante e viene avviato un nuovo thread in cui viene richiamata la funzione servos_loop_on ... e cosa fa? prende i dati dalla seriale? nell'evento datareceived che ci hai messo?

Ad ogni modo sto pensando che è qualche problema dei pc. Ho notato che la ricezione mi si interrompe dalle 4 alle 5 del mattino: non ricevo piu dati e la porta USB in pratica è presente ma impossibile da aprire da qualsiasi programma fino a che non la scollego. Questo comportamento è proprio anomalo.