Protocollo CAN

12 Anni 7 Mesi fa - 12 Anni 7 Mesi fa #1 da Joe
Protocollo CAN è stato creato da Joe
La libreria can per pic Laurtec "CANlib.h" e' stata creata per il C18 quindi non direttamente funzionante sul C della hi-tech questo perche' alcune definizioni per le chiamate alle SFR hanno diverse denominazioni.
Ho dovuto modificare la libreria per adeguarla a funzionare anche sul C hi-tech, senza modificarne la funzionalita' ma solo rinominando i nomi delle definizioni e le funzioni sono rimaste identiche.

Ho solo riscontrato alcuni "problemi" nel segnale e volevo una tua conferma.
Usando un PIC 18F4580 con una frequenza da 8 mhz senza prescaler (prova eseguita sia con clock interno da 8 mhz sia con un quarzo esterno sempre da 8Mhz),
scegliendo di usare la frequenza minima di 125Kb/s e 16 Quanti Temporali (quindi un Tq di 0,5 uS come nel tuo esempio) ho dovuto impostare il BRP a 1.

CANInitialize (2,7,6,1,1,
CAN_CONFIG_LINE_FILTER_OFF &
CAN_CONFIG_SAMPLE_ONCE &
CAN_CONFIG_ALL_VALID_MSG &
CAN_CONFIG_DBL_BUFFER_ON);

Bene, come calcolo teorico e' ok , ma in pratica tramite un analizzatore di segnali un USBee SX ho notato che il Tbit varia da 9,083 uS a 9,167 uS invece che di 8 uS , differenza di 2 Tq circa che posso correggere manualmente con i phaseseg1 e 2 nel CANInitialize,
e' possibile che la variazione sia causata dal il mio analizzatore da PC,
ma ho notato che c'e' anche una differenza tra il Tbit a livello alto circa 9 uS e il Tbit a livello basso 9,85 uS e per questo volevo una tua conferma, anche se ho capito che il Tbit da prendere in considerazione quando il segnale e' a liv alto.


File allegato:

Nome del file: CANlib.zip
Dimensione del file:5 KB
Allegati:
Ultima Modifica 12 Anni 7 Mesi fa da Joe.

Si prega Accedi o Crea un account a partecipare alla conversazione.

  • Joe
  • Visitatori
  • Visitatori
12 Anni 7 Mesi fa #2 da Mauro Laurenti
Risposta da Mauro Laurenti al topic Re: Protocollo CAN
Ciao Joe,

devo dire che è da un po' che non modifico o scrivo programmi con la libreria CAN anche se mi sono ripromesso di sviluppare nuove schede.

La libreria ha un bug che mi venne segnalato e non ho ancora avuto modo di correggere.
Il bug porta un problema tra la frequenza impostata e quella attuale, per cui le differenze di tempi che hai notato potrebbero essere legate a questo bug.
Riporto la segnalazione dell'utente che mi ha contattato:

ho pensato ad un piccolo progettino che mostrasse su un dispaly LCD (controller hitachi) le informazioni che viaggiano sulla presa OBD della mia autovettura.
Ho proceduto per passi cominciando dalla modalità loop e non riscontrondando alcun problema. I messaggi inviati erano perfettamente presenti sul buffer di ricezione e mostrati correttamente sul display. Il problemi sono venuti con le prove in auto :). Entrando prima nella modalità LISTEN e successivamente nella modalità NORMAL. Nel primo caso non riuscivo ad ottenere alcun tipo di messaggio e nel secondo caso mandavo in tilt le centraline della vettura :). Durante la fase di debug, mi sono accorto che nei registri BRGCON non venivano scritti i valori che mi aspettavo e per questo motivo ho pensato che i problemi di comunicazione erano proprio i settaggi errati relativi al bit timing.
Ho aperto la libreria è ho notato una inesattezza proprio nel settare i valori di SJW, propSeg, phaseSeg1 e phaseSeg2.
Prendiamo come esempio il parametro SJW che può variare da 1 a 4, ma lo stesso discorso si può applicare anche agli altri tre parametri.
Attualmente se passo SJW come 1, questo viene scritto direttamente nel registro BRGCON1, ma se vediamo il datasheet, se imposto 1 per SJW, nel registro dovrei scrivere 00. Per questo motivo, ho pensato di inserire (modificando la libreria), l'istruzione "SJW = SJW -1" prima della sua scrittura nel registro.
Provato nuovamente in macchina, il dispositivo prima in modalità ascolto e successivamente in modalità normale, ha funzionato regolarmente mostrando i dati richiesti con la funzione CanSendmessage.
Questa ovviamente è una soluzione adottata da un novello in programmazione :) e siceramente non saprei se ci sono soluzioni...come dire...più professionali.
Volevo segnalare inoltre che nel PDF che descrive la libreria CAN, i primi due flag segnati nella tabella della funzione CANSendMessage, diveramente dalla libreria, non sono "CAN_CONFIG_STD_MSG" e "CAN_CONFIG_XTD_MSG", ma "CAN_TX_STD_FRAME" e "CAN_TX_XTD_FRAME".


La libreria CAN è per altro rimasta nel suo layout originale composto del solo file .h mentre le altre librerie sono tutte divise in file .h e.c.
Spero di correggere il bug quando aggiornerò il file. Fammi sapere se il problema da te riscontrato è relativo a questo bug altrimenti credo ci sia qualche problema che dovrò investigare meglio.

Per quanto detto sopra escluderei in primo luogo che la strumentazione da te utilizzata abbia problemi.

Saluti,

Mauro

Si prega Accedi o Crea un account a partecipare alla conversazione.

  • Mauro Laurenti
  • Avatar di Mauro Laurenti
  • Moderator
  • Moderator
Di più
Moderatori: Mauro Laurenti

Registrati al sito

Accedi a tutte le risorse e articoli non visibili pubblicamente, puoi registrarti con pochi passi.

Registrati al sito LaurTec.

Login