Strani comportamenti di Bascom AVR

[pier]

Condivido il giudizio sull'help con esempi spesso errati o quantomeno poco curati e commentati.
Per il tuo problema purtroppo io mi arrendo.
Interrupts abilitati? variabili correttamente dimensionate? provare a leggere il buffer rx con ASM?
E se il problema fosse il tx?
Sicuro che non ci siano problemi di cavi, adattatori, Baud?
Prova a spedire valori da te fissati senza leggerli dall'rx e vedi se sul PC li vedi corretti e, ancora, puoi attaccare un lcd al micro e vedere cosa dice di ricevere mandandogli solo caratteri ascii rappresentabili (qualche cosa forse lo puoi fare anche solo in simulazione escludendo Arduino e comandando manualmente l'interrupt ma il problema sarebbe inviargli i dati credo scrivendo direttamente nel buffer).
Puoi forse anche testare il solo lato PC (cavi e adattatori compresi) collegando TX e RX degli adattatori...

[suibaf]

Ho quasi risolto, mi manca ancora una piccola cosa. Magari dopo se interessa posto tutto il codice (che poi 4 righe sono).

Il problema che ho adesso è:

Code: Select all

Printbin #2 , Rcv_buff(1) ; Num_byte 

Num_byte vale 7, quindi mi dovrebbe mandare sulla seriale 7 byte a iniziare da Rcv_buff(1) e invece mi manda sulla seriale tutto l'array Rcv_buff() che l'ho dimensionato a 30 elementi. E sono sicuro che Num_byte vale 7 nel momento in cui viene passato a Printbin.
Se a printbin non gli passo una variabile, ma gli dò 7 allora funziona. Cioè non posso passare a Printbin una variabile, vuole per forza una costante? Non ci posso credere!
Grazie

[deluca]

molto semplicemente lo risolvi così:

Code: Select all

num_byte=7
for i = 1 to num_byte
      printbin rcv_buff(i) ; 1
next i


uno dei metodi.... ma ce ne stanno altri

[suibaf]

Si è proprio come ho fatto. Ma come mai printbin non accetta una variabile dove specifico il numero dei byte? Ma non ti da neanche una segnalazione di errore

[pier]

Alla fine mi interesserà capire...
Per il problema residuo, se sei certo che num_byte è = 7 e costante, hai provato semplicemente a dimensionare rcv_buff a 6?
Concordo anche che il non accettare una variabile sulla lunghezza è un limite scomodo.

[suibaf]

Pier non ho capito la domanda.

[pier]

Scusa, ti suggerivo solo di provare ad inizio codice con dim rcv_buff(6) invece di 30 ma ho capito che era una sciocchezza.
La mia età, decisamente maggiore della tua, a volte gioca brutti scherzi!
Mi interesserebbero però anche le altre soluzioni accennate da Deluca perchè mi ci sto appassionando

[deluca]

Si è proprio come ho fatto. Ma come mai printbin non accetta una variabile dove specifico il numero dei byte? Ma non ti da neanche una segnalazione di errore

Bene, il fatto è che il compilatore non può gestire tutto quello di cui gli utenti hanno bisogno. Cmq segnalerò a Mark questa possibile fix. Inoltre per il compilatore scrivere

Code: Select all

Printbin variabile(i);seconda_variabile

è lecito e quindi non c'è nessuna ragione per segnalare un errore.
Come avete potuto constatare, il printbin trasmetterebbe tutto il vettore(i) accodando la seconda varibile.

[pier]

Bene! Allora per ora tutto risolto.
Se ho ben capito si trattava solo di un modo errato di spedire indietro al PC i dati.
Comunque sarei curioso di vedere tutta la parte relativa al codice di comunicazione RX/TX funzionante.
Nella vita non si sa mai...

[deluca]

Chiediamo allora a suibaf di postare l'intero codice in modo da valutarne eventuali miglioramenti.

[suibaf]

Giovanni,
sono daccordo con te che il compilatore non può fare tutto quello che viene in mente all'utente, ed è anche vero che la sintassi era corretta per cui non andava in errore. Secondo il mio giudizio è l'approccio che andrebbe cambiato, non tanto per utenti esperti che una volta che conoscono sanno come fare. Ma comunque problema superato.

Pier in questo momento il mio 2560 è in grado di riconoscere la presenza/assenza di un rfid nei pressi del reader. Ed è anche grazie a voi oltre che al mio impegno. Per cui ovviamente ti posto lo stralcio di codice, che non è detto che sia scritto bene in quanto funziona!

Code: Select all

'-----------------------------------------------------------------------------------------

'purpose                  : test for M2560 support

'micro                    : Mega2560

'-----------------------------------------------------------------------------------------



$regfile = "m2560def.dat"                                   ' used micro
$crystal = 16000000                                         ' used xtal
$hwstack = 40
$swstack = 40
$framesize = 40

Dim Num_byte As Byte
Dim A As Byte
Dim B As Long
Dim Receive_idcard(7) As Byte

Dim Rcv_length As Byte
Rcv_length = 0
Dim Rcv_buff(30) As Byte
Rcv_buff = ""
Dim Ch As Byte




'                              33             32             31               30           34             35
Config Lcdpin = Pin , Db4 = Portc.4 , Db5 = Portc.5 , Db6 = Portc.6 , Db7 = Portc.7 , E = Portc.3 , Rs = Portc.2
Config Lcd = 20 * 4


Config Com2 = 19200 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0

Config Print1 = Portc.1 , Mode = Set
Config Pinc.1 = Output

Config Serialin1 = Buffered , Size = 100 , Bytematch = All

Open "Com2:" For Binary As #2


Enable Interrupts

Clear Serialin1

Locate 1 , 1

Dim I As Byte


Do


   If Num_byte <> 0 Then

      Lcd Num_byte

      For I = 1 To Num_byte

         Printbin #2 , Rcv_buff(i) ; 1

      Next
      Num_byte = 0

   End If

   Waitms 50

Loop


'Label called when UART receives a char

Serial1bytereceived:


   Do

      Num_byte = Num_byte + 1
      Inputbin #2 , Ch
      Rcv_buff(num_byte) = Ch

   Loop Until Ischarwaiting() = 0


Return

End


[pier]

Grazie Suibaf del codice. Qualche osservazione:
1) Ok per l'azzeramento iniziale "di sicurezza" delle variabili ma credo che se intendevi svuotare tutti gli elementi dell'array Rcv_buff(30) avresti dovuto fare un loop per scansionarli tutti e sarebbe errato l'azzeramento con "" essendo questo di tipo byte (se è un'altra variabile qui inutilizzata come non detto)
2) aggiornando l'lcd nel loop principale corri il rischio di vedere un numero di caratteri inferiore al reale ricevuto e ritrasmesso nel caso in cui l'interrupt di ricezione avvenisse tra l'aggiornamento lcd e la ritrasmissione. Forse meglio metterlo nell'ISR dell'interrupt magari mediante un flag da settare nell'ISR e resettare poi nel loop principale onde non rallentare l'ISR stessa (tieni anche presente che non stai gestendo la posizione sull'lcd che shifterebbe)
3) forse il loop nell'ISR è inutile in quanto (a meno non temi dati a velocità folle) l'interrupt arriva ad ogni carattere ricevuto e quindi la lettura del buffer lo svuota anche se non fa male.....
4) per semplicità invece di Num_byte = Num_byte + 1 puoi scrivere incr Num_byte
5) mi risulta che l'end vada posto prima della label dell'ISR

[suibaf]

Grazie mille Pier! Tienimi d'occhio, non perdermi di vista perchè sicuramente avrò bisogno del vostro aiuto.

[suibaf]

Deluca ecco il link del lettore scrittore RFID che stò usando:

https://dl.dropboxusercontent.com/u/152 ... 0%20en.pdf

Io ho implementato con succeso la funzione GET_CARD_ID (0x13).

Dopo di chè devo implemntare la funzione LINEAR_READ (0x14), ma non ci sono riuscito e adesso non funziona piu' nulla! E' come se i byte in ricezione si mescolassero e non riesco piu' a fare la selezione corretta. Non mi funziona neanche il cecksum!

Ho fatto un interrogazione a tempo: faccio la richiesta GET_CARD_ID, aspetto 500 ms, faccio la richiesta LINEAR_READ e ricomincio. Ma non mi ha dato buoni risultati!
Mi date qualche dritta?
Grazie

[deluca]

Se utilizzi il terminale PC, funziona la comunicazione con il modulo?

[suibaf]

il terminale pc lo utilizzo come sniffer in modo da vedere i segnali che si scambiano il 2560 con il reader. Posso dire che la comunicazione è completa. Ma dovendo visualizzare le risposte del reader sul display lcd 4x20 devo selezionare i byte che mi servono ed i conti non tornano! Una domenica sprecata.....menomale che ha piovuto tutto il giorno.