Software di test per adattatori VAGCOM?

Ciao a tutti.

Le mie recenti esperienze con VAGCOM hanno rivelato che la qualità di un adattatore è legata, tra le altre cose, al ritardo dei segnali all'interno dell'adattatore stesso (tempo di risposta).
Pertanto, un adattatore dovrebbe essere ottimizzato per avere tempi di funzionamento il più brevi possibile durante la fase di sviluppo o di regolazione.
Questo può essere realizzato, ad esempio, con l'ausilio di un generatore di forme d'onda rettangolari e di un oscilloscopio, ma probabilmente non è disponibile a tutti gli utenti di VAGCOM o a coloro che costruiscono i propri adattatori.

Un'alternativa sarebbe utilizzare il computer già disponibile come strumento di misurazione.
Ogni segnale inviato dal PC alla linea K viene ricevuto come eco sul pin RXD. La misurazione di questo ritardo potrebbe essere utilizzata direttamente come criterio di qualità per l'adattatore e la sua interazione con il computer, e, nel caso di adattatori regolabili, potrebbe essere utilizzata come guida per la regolazione.
Inoltre, in questo modo si potrebbero anche valutare la qualità degli adattatori già pronti disponibili in commercio.

Il test dell'adattatore nel menu VAGCOM sembra controllare la funzionalità dell'adattatore in modo troppo superficiale, tanto che anche adattatori molto lenti vengono riconosciuti come funzionanti, ma che potrebbero comunque non funzionare correttamente durante l'utilizzo reale.

Per un'analisi più precisa, sarebbe necessario disporre di un software appropriato che fosse in grado di svolgere le seguenti funzioni.
Stato iniziale: RTS = basso, DTR = alto (gli altri pin della porta COM sono irrilevanti).
Misurazione: il segnale TXD viene commutato da livello basso a livello alto e viceversa ogni circa 0,5 secondi. Durante il processo, i tempi tra ogni impulso di trasmissione (TXD) e il successivo fronte di segnale dello stesso segno ricevuto (RXD) vengono misurati e visualizzati in tempo reale sul monitor.

Poiché i tempi di salita e di discesa possono essere diversi, entrambi i tempi devono essere indicati contemporaneamente.
Come intervallo di misurazione, dovrebbero essere sufficienti circa 1-100 microsecondi, e come risoluzione, circa 1 microsecondo.

Dove posso trovare un software del genere, oppure chi potrebbe svilupparlo e, eventualmente, renderlo disponibile per il download sul sito di Rainer?

Dopo una breve corrispondenza via email con Ulf, e ora anche qui nel forum, desidero esprimere la mia opinione su questo argomento, perché la tematica rientra in buona parte nel mio ambito di lavoro.

Un programma del genere, utilizzato come strumento di calibrazione, sarebbe senza dubbio utile, ma ritengo che non sia realizzabile, e ciò per una serie di motivi.

Risoluzione del timer: Per ottenere misurazioni precise, è necessario un timer di qualità almeno altrettanto buona, e la maggior parte dei PC non offre questo. Non è possibile ottenere una precisione superiore a 10 microsecondi, anche se alcune interfacce di sistema suggeriscono il contrario. L'unica alternativa sarebbe utilizzare i contatori di prestazioni della CPU (a partire dal Pentium 1, le CPU contano internamente i propri cicli), il che permetterebbe di ottenere una precisione molto elevata, ma a costo di una forte dipendenza da specifiche CPU e schede madri. I prossimi due problemi non saranno risolti con questo.

Interruzioni: Quando si lavora a livello "alto", tra il programma e l'hardware si trova il sistema operativo con diversi gestori di interrupt che possono intervenire in modo imprevedibile, a partire dal servizio di timer del sistema operativo, passando per processi interni di pulizia, fino ad altri dispositivi a cui vengono inviati dati, come dischi fissi o CD-ROM. Tali influenze possono causare ritardi imprevedibili che rendono impossibili le misurazioni pianificate. È difficile disabilitarle completamente, nemmeno quando si utilizza un sistema operativo DOS rudimentale. Una possibile soluzione sarebbe l'utilizzo di un kernel in tempo reale molto piccolo e prevedibile (ad esempio, rtlinux, QNX o Lynx), ma ciò porterebbe nuovamente a una soluzione specializzata che comporterebbe un notevole sforzo. E... risolto così, si presenta il prossimo problema.

Hardware per PC: L'hardware per PC è imprevedibile. Ad esempio, i dispositivi PCI, come le schede grafiche (anche l'AGP è, in realtà, solo una variante di PCI), possono bloccare il bus PCI per periodi di tempo IMPREVEDIBILI, il che alla fine porta al fatto che non possiamo ricevere dati dalle porte seriali con un ritardo noto, poiché nella maggior parte dei casi queste sono collegate al bus PCI tramite un bridge PCI/ISA. Questo non compromette la funzionalità, ma ne riduce la prevedibilità. Questo problema è molto serio: le aziende che utilizzano hardware per PC per sistemi in tempo reale devono selezionare con molta cura tutti i componenti e valutare attentamente questo comportamento, perché nessuno lo specifica nelle schede tecniche. Pertanto, dovremmo fare la stessa cosa, ma questo non è possibile per molte ragioni, dato che i nostri computer sono tutti molto diversi.

Questi tre argomenti evidenziano uno degli aspetti più importanti dei sistemi real-time: essi non devono necessariamente essere VELOCI (è un errore comune), ma devono essere PREVEDIBILI (il che include anche prestazioni prevedibili e sufficienti).

Pertanto, ritengo che un programma di misurazione di questo tipo, SENZA l'aggiunta di hardware supplementare, sia purtroppo non realizzabile.

Con hardware aggiuntivo, è relativamente semplice, ad esempio, utilizzare FIFO di grandi dimensioni per leggere flussi di dati e memorizzare in parallelo i timestamp di un oscillatore al quarzo, e poi renderli accessibili tramite ISA o PCI. Questo disaccoppia tutto dal punto di vista temporale, ma allo stesso tempo non è giustificato in termini di sforzo richiesto.

In generale, potrebbe anche essere che le ragioni sopra esposte siano responsabili del fatto che VAGCOM non funzioni su alcuni computer.

E... c'è ancora un'altra (opzionale) limitazione: le moderne schede di comunicazione (COM) hanno delle FIFO (First-In, First-Out) che utilizzano per bufferizzare i dati. La CPU, quindi, non riceve più informazioni precise sul momento in cui qualcosa arriva, ma solo quando il buffer FIFO ha superato un determinato livello di riempimento. Anche questa funzione dovrebbe essere disattivata, il che a sua volta rallenterebbe notevolmente le comunicazioni, rendendo illusorie le elevate risoluzioni di misurazione.

Cordiali saluti,

Jan.

Ciao Jan,

Se ho capito correttamente l'affermazione di base, si può paragonare un PC, quando si trova di fronte a compiti apparentemente "semplici", a un professore di matematica che, a causa della sua vasta conoscenza, non riesce più a fare 2 + 2. . .

Peccato, quindi.
Esistono ancora alcuni prodotti che permettono di utilizzare il PC come oscilloscopio (per l'analisi dei segnali?), ma a quanto pare manca ancora la funzione per generare forme d'onda rettangolari... inoltre, non so quanto costino.

Sembra che VAGCOM abbia la capacità fondamentale di "controllare" la porta COM in tempo reale.
Altrimenti, non sarebbe possibile un dialogo con i sistemi di trasporto intelligenti (STGen) all'interno del veicolo, poiché in questo caso è fondamentale rispettare determinati intervalli di tempo molto brevi.

Forse si potrebbe analizzare il software VAGCOM in modo da ottenere l'accesso diretto alla porta COM e, a partire da lì, sviluppare un programma di test che funge da adattatore.
Ma probabilmente anche qui sto pensando in modo troppo semplice e troppo "analogico"...

Che sia, quello che non si può fare, semplicemente non si può fare. Sarebbe stato troppo bello.

Grazie ancora per tutti i contributi esplicativi sull'argomento.

Ciao,
Secondo me, VAG-Com non è in grado di farlo.
Il modulo di controllo seriale del PC è responsabile del rispetto delle finestre temporali e di altre impostazioni.

A sostegno di questa affermazione, ci sono dichiarazioni presenti sul sito web di Ross: VAG-COM utilizza solo le funzioni standard di Windows, in modo da non dover sviluppare routine specifiche per ogni versione di Windows. Per migliorare la velocità delle query, si sta valutando o si sta progettando la realizzazione di un adattatore dotato di intelligenza propria.

Christian.

Ciao,

La funzione principale dell'adattatore è la separazione dei potenziali e l'adattamento dei segnali all'unità di controllo. Il circuito dovrebbe realizzare queste funzioni con i tempi di propagazione, gli sfasamenti e le distorsioni degli impulsi più bassi possibili. Ad esempio, se consideriamo una velocità di 9.600 bit/s, i ritardi del segnale dovrebbero essere inferiori di un fattore 5, il che significa che per una velocità di 10.000 bit/s, si ottiene 1/10.000 s, ovvero 100 μs. Con un fattore di 5, questo si traduce in un ritardo del segnale massimo accettabile di 20 μs. Questo corrisponde a una frequenza di test di 50 kHz con un'onda quadra. È evidente che è difficile replicare un generatore e un oscilloscopio da 50 kHz tramite la porta seriale.
Senza le mie modifiche, che includono condensatori da 100nF collegati a R7 e R10 e un condensatore da 100pF collegato a R12, il circuito raggiungeva questo limite. Ora, con queste modifiche, ho ottenuto circa 6 microsecondi. Deve bastare.

Ciao,

Riguardo alla capacità di elaborazione in tempo reale del controllo COM, mi associo a quanto detto dai miei predecessori: il controller gestisce tutto automaticamente. I dati generati vengono inseriti in un FIFO (First-In, First-Out), e quando il FIFO raggiunge un determinato livello di riempimento, viene generato un interrupt. Se la CPU riesce a elaborare i dati prima che il FIFO si riempia completamente, il trasferimento dati continua alla massima velocità (la CPU "svuota" quindi il FIFO e poi si occupa di altro). Se la CPU non riesce a elaborare i dati in tempo, il flusso di dati si interrompe. L'arte sta nel generare un interrupt (IRQ) ogni 10...12 byte (le FIFO hanno solitamente 16 byte), e a 115 Kbit/s, che equivalgono a 15 KB/s, questo si traduce in circa 1500 IRQ al secondo, una quantità che normalmente può essere gestita senza problemi.

Riguardo a VAGCOM: questo sistema deve essere solo abbastanza veloce da acquisire i dati in modo parziale dai driver (che leggono i FIFO), e non deve andare oltre. In particolare, i bit non vengono direttamente utilizzati; l'hardware del controller li assembla in byte in modo conforme al protocollo.

Per quanto riguarda gli oscilloscopi per PC: se non sbaglio, qualcosa del genere si trova, ad esempio, da Conrad... però utilizzano hardware specifico: una scheda di espansione implementa le parti critiche per i tempi, mentre il PC funge da display e da sistema di controllo per questa scheda. È, in sostanza, la versione di lusso di quel gioco con le FIFO.

Nella nostra università, qualcuno ha costruito una scheda ISA per misurazioni parallele in tempo reale (cioè 32 ingressi, ognuno con 1 bit, provenienti da diverse fonti, tutti in parallelo). Il principio di funzionamento è basato su un FIFO di grandi dimensioni e un contatore, quest'ultimo incrementato da un quarzo a 8 MHz. Ad ogni ciclo, il contatore e la maschera dei 32 bit vengono inseriti nel FIFO molto grande (probabilmente circa 16 KB), e la CPU legge i dati da lì, consentendo analisi successive. Anche in questo caso, la questione della misurazione in tempo reale è stata spostata su un hardware dedicato. Con questo dispositivo, sarebbero possibili misurazioni di questo tipo, ma lo sforzo richiesto è notevole.

Cordiali saluti,

Jan.

L'unico aspetto che considero rilevante nella progettazione è la durata del segnale. Si presuppone che l'applicazione funzioni correttamente nei livelli di protocollo superiori. L'adattatore non può fare altro che trasmettere il segnale senza ritardi.

allora, mi dichiaro un esperto di microprocessori a livello hardware (vedi anche il mio profilo) .

Ammetto di non aver mai esaminato attentamente alcun adattatore, indipendentemente dal modello. Infatti, con le velocità di trasmissione dati massime di 10,4 kbps e i componenti utilizzati, il tempo di propagazione del segnale non può avere un'influenza significativa. Se fosse stato così, qualcosa sarebbe andato terribilmente storto. Inoltre, a differenza di molte persone, non ho riscontrato alcun problema con la scheda originale di Jeff, né con diversi veicoli, né con i due laptop Toshiba utilizzati.

Considero che il problema della reattività in tempo reale del sistema operativo sia più probabile in questo caso. L'unica soluzione è terminare i processi in modo massiccio. Ma come fa un processore Pentium II da 266 MHz con 64 MB di RAM, sotto Windows 98SE, a gestire questa situazione, quando ci sono numerosi programmi in esecuzione in background?

okok, guarderò il tutto l'anno prossimo e ci lavorerò un po'. Se necessario, potrei usare un circuito con convertitore DC/DC per aumentare un po' la tensione lato PC... ma potrebbe volerci del tempo, tradizionalmente i clienti si comportano in modo strano all'inizio dell'anno .

Ciao Gremlin.