- Messaggi: 131
- Ringraziamenti ricevuti 0
ROVER
Si prega Accedi o Crea un account a partecipare alla conversazione.
- luongo
- Autore della discussione
- Premium Member
il progetto è indubbiamente interessante, e tutt'altro che banale
La comunicazione radio tra i due pic hai già pensato a come implementarla? Noto che hai l'usart della ricevente occupata dal driver motori, usi quindi un pic con doppia seriale?
seguo interessato
saluti,
Matteo
Si prega Accedi o Crea un account a partecipare alla conversazione.
- Matteo Garia
- Moderator
- Messaggi: 376
- Ringraziamenti ricevuti 38
Matteo Garia ha scritto: Ciao!
il progetto è indubbiamente interessante, e tutt'altro che banale
La comunicazione radio tra i due pic hai già pensato a come implementarla? Noto che hai l'usart della ricevente occupata dal driver motori, usi quindi un pic con doppia seriale?
seguo interessato
saluti,
Matteo
Allora di seguito spiego a parole i due codici:
-TX: il firmware del TX al termine dell'inizializzazione visualizza su un display LCD 16x2 la scritta "ATSS READY", (ATSS = All Terrain Surveillance System è il nome che ho dato al mio roverino), mantenendola visibile per 1,5 secondi. Per poi visualizzare la scritta "NV_OFF" (NV = Night Vision) a sinistra e a destra verrà visualizzato lo stato della batteria tramite una piccola batteria stilizzata (ottenuta con la CGRAM). Fatto ciò il uC acquisirà due dati analogici da un joystick (quello della PS2) i dati ottenuti a 8 bit verranno processati e inviati all'MDSMC ma di questo ne parlerò dopo. Seguentemente farà un'altra acquisizione sul livello della batteria che se risulterà ingferiore a un dato valore aggiornerà quanto visualizzato sull'LCD. Infine controlla se è stato premuto un pulsante normalmente aperto, non appena rilevata la pressione del pulsante, procederà con il controllare se i LED IR a bordo del rover sono già accesi (per mezzo di una variabile temporanea complementata opportunamente) o meno e in caso di variazione aggiornerà quanto visualizzato sull'LCD. L'MDSMC (il driver dei motori) ha bisogno di quattro byte per funzionare: start byte 0x80, device byte 0x00, motor number and direction byte (oppurtunamente mappati in variabili a otto bit a seconda della direzione) e uno speed byte. Lo speed byte è dato dall'acquisizione sui due assi. Le acquisizioni a otto bit sono 0 a 255 mentre l'MDSMC accetta valori da 0 a 127. Ho pensato di usare 128 come valore (in realtà i valori di quete sono da 132 a 122 così ho un offset di un decimo di volt visto che condizionerò il segnale del joystick in maniera tale da avere 2,5V in stato di quiete) di quiete e a seconda della direzione del joystick sottrarre a 128 il valore dell'acquisizione oppure sottrarre dal valore dell'acquisizione 128 per ottenere il valore di velocità e decodificarne la direzione. Seguentemente una funzione conterà i byte inviati, raggiunti i quattro byte terminerà la trasmissione. In altri casi seguirà un codice da me ideato per l'occasione che non specifico.
-RX: il firmware dell'RX non fa altro che interpretare quanto mandato dal TX e controllare i LED IR e pilotare il driver motori. Quindi in fase di ricezione uso l'USART sul piedino RX e invece quando il uC deve comunicare con l'MDSMC lo uso sul pin TX.
Si prega Accedi o Crea un account a partecipare alla conversazione.
- luongo
- Autore della discussione
- Premium Member
- Messaggi: 131
- Ringraziamenti ricevuti 0
Si prega Accedi o Crea un account a partecipare alla conversazione.
- luongo
- Autore della discussione
- Premium Member
- Messaggi: 131
- Ringraziamenti ricevuti 0
...magari anche qualche foto!
Anche l'occhio vuole la sua parte!
Saluti,
Mauro
Si prega Accedi o Crea un account a partecipare alla conversazione.
Registrati al sito
Accedi a tutte le risorse e articoli non visibili pubblicamente, puoi registrarti con pochi passi.