
I comandi per le portiere delle automobili sono tipicamente composti da micro-interruttori che accendono direttamente le correnti necessarie per azionare vetri e specchietti. Nel caso di specchietti apribili azionati elettricamente, un solo interruttore deve controllare sei motori in entrambe le direzioni. Tale complessità, combinata con le elevate correnti necessarie, rende il cablaggio eccessivamente pesante, costoso, nonché difficile da installare, specialmente in corrispondenza della portiera del guidatore.
La quantità di rame che si trova sul perno, in corrispondenza dell'area in cui l'imbracatura si interfaccia con il corpo principale del cablaggio, può inoltre creare un difficile compromesso di progettazione fra durata e semplicità d'uso.
Pulsanti per gli specchietti
Una portiera auto è sostanzialmente diversa da un calcolatore o da un telefono, nel senso che può essere necessario premere più di un pulsante alla volta. Ciò rende il tradizionale approccio alla progettazione di comandi a tastiera, una matrice bidimensionale X-Y, di limitato utilizzo in applicazioni automotive. Senza componenti aggiuntivi, infatti, una matrice ha una capacità limitata di decodificare se sono stati premuti contemporaneamente più pulsanti. Se due pulsanti sono premuti sulla stessa riga o sulla stessa colonna, la capacità di identificare un terzo pulsante premuto diminuisce. Il riconoscimento di un solo comando alla volta (su, giù, destra, sinistra) permette di utilizzare comunque una matrice. Il design qui illustrato utilizza questa disposizione per le otto funzioni utilizzate dai due specchietti. Per ottenere che gli specchietti siano anche apribili, si aggiunge una nona funzione (che diventeranno se si vogliono specchietti apribili e richiudibili indipendentemente l'uno dall'altro) e la matrice di controllo diventa di dimensioni 5x2.

Implementazione dei comandi per uno specchietto
Tasti per i finestrini
I requisiti dei comandi di controllo dei finestrini sono sensibilmente diversi da quelli degli specchietti, poiché la portiera del guidatore potrebbe presentare i pulsanti di comando per tutti e quattro i finestrini. E' inoltre ragionevole aspettarsi che due o più di questi quattro comandi possano essere azionati simultaneamente. Per questo motivo, sebbene possano essere necessari 8 oppure 6 tasti, la matrice convenzionale non è necessaria. Sebbene far azionare i quattro finestrini in apertura e chiusura (giù e su) comporti la presenza di 8 pulsanti, un successivo intervento su di un pulsante fa sì il finestrino continui la sua corsa verso il basso o verso l'alto, anche dopo che il pulsante è stato rilasciato.
Il modo più semplice di implementare questo comportamento è disporre di 16 interruttori. Poiché l'uso di una matrice 4x4 non è indicato senza alcuni componenti aggiuntivi, questa soluzione usa 16 linee di Input/Output dal controller MCU. Un numero così elevato di interruttori potrebbe richiedere un dispositivo più costoso oppure forzare l'uso di un numero più alto di pin.
Possibile disposizione per i comandi dei finestrini

Hardware
L'MCU per il modulo della pulsantiera è il componente MC68HC908EY16. Poiché questo MCU non è attualmente disponibile (alla data di pubblicazione di questo manuale), l'applicazione utilizza il componente MC68HC908AZ60A. L'utilizzo del componente MC68HC908EY16 e EY8 ridurrà i costi in maniera significativa. Non solo il dispositivo MC68HC908EY16 avrà un costo inferiore, ma includerà un modulo integrato ICG (generatore per l'orologio interno) che renderà inutile la presenza di un componente aggiuntivo quale il risonatore in cristallo o il risonatore in ceramica.

Schema circuitale del modulo della pulsantiera
Il modulo della pulsantiera utilizza il software del driver FreeScale/Metrowerks LIN, in modo che l'attività di Input/Output sia gestita senza il codice dell'applicazione che semplicemente utilizza una chiamata alla funzione LIN_PutMsg() per aggiornare il buffer utilizzato dai drivers.
Analogamente, la funzione LIN_GetMsg() è utilizzata per la ricezione dati. Lo scopo principale del modulo della pulsantiera è fornire i dati per i modulo dei finestrini e degli specchietti e la caratteristica del modulo controllato da LIN_GetMsg() è permettere l'illuminazione della pulsantiera stessa. L'uso dei driver LIN permette agli programmatori di pensare solo all'implementazione dell'applicazione senza che debbano preoccuparsi di implementare e gestire il protocollo di comunicazione.
Codice Sorgente
Questo è una solo una piccola porzione del codice sorgente. Vi preghiamo di contattarci per il codice completo.
/****************************************************************************** * Function: LIN_Command * * Description: User call-back. * Called by the driver after successful transmission or receiving * of the Master Request Command Frame (ID Field value '0x3C'). * * Returns: never returns * ******************************************************************************/ void LIN_Command() { while(1) { } } /****************************************************************************** * * Function name: Main * Originator: P. Topping * Date: 5th June 2001 * ******************************************************************************/ void main (void) { unsigned char count = 0; unsigned char window_last; unsigned char mirror_last; CONFIG1 = 0x71; CONFIG2 = 0x19; DDRA = 0xF0; DDRB = 0xFF; DDRC = 0x34; DDRD = 0x00; DDRE = 0xDD; DDRF = 0x7F; DDRG = 0x00; DDRH = 0x00; PTA = 0x00; PTB = 0x00; PTC = 0x00; PTE = 0x04; /* MC33399 enable high */ PTF = 0x00; Kpm_data[0] = 0; Kpm_data[1] = 0; Kpm_data[2] = 0; Kpm_data[3] = 0; asm CLI; LIN_Init(); LIN_PutMsg (0x20, Kpm_data); PITSC = 0x10; /* start PIT at /1 */ PMODH = 0x27; /* /10000 for a repetition */ PMODL = 0x10; /* rate of 200Hz @ 8MHz. */ while (1) { if (PITSC & 0x80) /* is PIT overflow set? */ { PITSC &= ~(0x80); /* yes, clear it */ window = ~PTD; /* read window port */ PTB = 0x04; /* mirror, column 1 */ mirror = ((~PTH & 0x03) | (0x04*(~PTG & 0x07))); /* read rows */ if (mirror == 0) /* key pressed? */ { PTB = 0x08; /* no, try column 2 */ mirror = ((~PTH & 0x03) | (0x04*(~PTG & 0x07))); /* read rows */ if (mirror) /* key pressed? */ { mirror = mirror |= 0x20; /* yes, set 2nd column bit */ } } if ((0x04 & PTA) == 0x04) /* child lock active? */ { mirror = mirror |= 0x80; /* yes, add MSbit */ } if ((mirror == mirror_last) && (window == window_last)) /* same ? */ { if (count == 1) /* yes, third time ? */ { Save_history(); /* yes, save prev. window */ mirror_cur = mirror; /* set-up and xfer new */ window_cur = window /* status into current */; Prepare_new_data (); /* xfer data to LIN buffer */ count ++; /* count=2 stops re-entry */ } else if (count < 1) /* count=2 stops increment */ { count ++; } } else { count = 0; /* no, different, so reset */ mirror_last = mirror; /* count and save current */ window_last = window; /* status as last status */ } LIN_GetMsg (0x21, Master_data); if ((Master_data[2] & 0x40) == 0x40) { PTF |= 0x01; /* lights on */ } else { PTF &= ~(0x01); /* lights off */ } } } }

chissà se è protetto dagli spike che avvengono sulle autovetture, non vorrei durasse il tempo di un viaggio.
In effetti c’è bisogno di una ottimizzazione di questo progetto per avere una maggiore stabilità… Ma è una buona idea innovativa!!
Un esempio perfetto di come sia possibile aumentare le prestazioni di un dispositivo elettronico mantenendo sempre e comunque un occhi ai costi! Le normali tecniche in effetti falliscono o quantomeno si complicano nel momento in cui si trovano attivi + tasti su una riga o colonna(dipende dal tipo di tecnica di ricerca!) e bisogna rilevare la pressione di entrambi(in casi normali si troverebbe il primo tasto premuto)
Questo progetto lo vedo più che altro didattico, ma niente di così originale o nuovo che non si sapeva già. L’unica cosa utile è che fa riflettere sulla problematica relativa alla lettura di più tasti di un tastierino premuti in contemporanea, problema che si può risolvere facilmente curando la distribuzione delle funzioni ai vari tasti oppure tramite soluzioni ibride (nell’articolo usano una soluzione ibrida con un tastierino a matrice 2×2 + 2 tasti singoli gestiti separatamente) senza svenarsi a scrivere complicatissimi firmware.
Io trovo che la chiusura automatica delle portiere sia una bella cosa ma nello stesso tempo prolematica…
non vorrei essere ne pessimista ma neanche ripetitivo solo che questo progetto mi sembra che abbia bisogno di una revisione…non è così semplice gestire tutta questa serie di cose.
E’ molto complicata gestire cose simili… c’è da studiare su!!!
La cosa che secondo me andrebbe studiata per bene è il protocollo LIN (più semplice rispetto al CAN) e i comandi che l’autovettura si aspetta di ricevere per la gestione della portiera. Qui nell’articolo ci si è soffermati molto sull’aspetto della gestione di tasti premuti in contemporanea, ma niente di così poco intuitivo! Per quanto riguarda il bus LIN, le varie case produttrici di microcontrollori integrano nei loro dispositivi l’interfaccia hardware per questo tipo di protocollo, quindi anche il problema della gestione del bus è facilmente risolvibile.
Scusate: qualcuno sa dirmi cosa “passa” invece nel LIN relativamente alla gestione dell’alternatore ?