Lo schema elettrico della scheda GPCM-ESCC, mostrato in figura 2, per molte parti risulta assolutamente standard e non richiede pertanto particolari commenti. Tali sono le parti relative alla decodifica degli indirizzi, realizzata con ad U2, U5, U6 ed U7, l'interfacciamento verso il bus dati, realizzato da U1 ed U4, la parte di abilitazione, pilotaggio e scelta della linea IRQ e del canale di DMA, realizzata attorno ad U3 ed U8 ed il ritardo variabile sulla linea IOW realizzato mediante U9 e selezionabile mediante SW5.
Avendo realizzato GPCM-ESCC come scheda a 16 bit, risulta possibile utilizzare anche gli IRQ alti solitamente liberi (10 ed 11) oltre ai consueti 2...7, permettendo una facile convivenza con schede seriali e parallele a 8 bit. Per mantenere, per quanto possibile, la compatibilità con Itacard, si è avuto cura di disporre nella stessa posizione i bit di abilitazione dell'interrupt e del DMA nell'apposito registro (U3).
Un commento un po' più dettagliato è invece opportuno per le parti relative ai clock ed alla generazione delle temporizzazioni.
Abbiamo scelto di separare il clock per la generazione dei baud rate dal clock dell'ESCC, in modo da poter cambiare senza problemi ESCC e clock qualora fosse richiesto per gestire velocità maggiori di 2 Mbit/s. Le specifiche dell'ESCC, infatti, impongono di utilizzare una frequenza di clock minima uguale a quattro volte il bit rate. Ciò significa che coi normali ESCC da 8 MHz si ha un limite di 2 Mbit/s e che per raggiungere, in un eventuale futuro, i 5 Mbit/s, occorre cambiare ESCC e frequenza di clock, portando entrambi a 20 MHz, con l'evidente necessità di poter sostituire facilmente l'oscillatore senza alterare alcuna altra frequenza o temporizzazione. Sullo stampato, per essere conservativi, è anche prevista la possibilità di utilizzare un oscillatore doppio, 8/16 MHz o 10/20 MHz, con selezione mediante apposito jumper (SW6) per quanto sia una possibilità che probabilmente pochi sfrutteranno, considerato il costo e la non facile reperibilità di tali oscillatori doppi.
E' quindi necessario poter cambiare agevolmente l'oscillatore che dà il clock all'ESCC, mentre quello che serve a generare i baud rates deve restare fisso, quindi conviene che sia separato e di una frequenza standard facilmente reperibile ed utilizzabile; ecco perché abbiamo scelto il consueto oscillatore a 4.9152 MHz, che consente di ottenere esattamente tutti i baud rates di uso comune mediante divisione per opportune potenze di due.
Poiché, per velocità superiori a 250 kbit/s, non è più possibile usare il DPLL interno all'ESCC, che richiede un clock 32x il bit rate, per recuperare il clock in ricezione, è prevista la possibilità di pilotare l'ESCC col clock ricostruito esternamente dal modem (o dal circuito sincronizzatore/scrambler/descrambler dell'RTX a 1.22 Mbit di M.Vidmar), quindi gli ingressi dei clock di ricezione e trasmissione (RTXCA TRXCA RTXCB e TRXCB) sono disponibili anche sui connettori di uscita. Naturalmente, se si fa uso di questa possibilità, occorre lasciare non ponticellati i relativi jumper di SW3.
Per evitare una proliferazione incontrollata di oscillatori, la frequenza di 4.9152 MHz viene anche utilizzata come frequenza di partenza per la generazione delle temporizzazioni. E' obbligatorio utilizzare il 4.9152 MHz, e non la frequenza di clock dell'ESCC, per le considerazioni fatte in precedenza. Il segnale generato da U11 viene inviato quindi sia all'ingresso CLK0 dell'82C54, sia, mediante il jumper SW3, agli ingressi dei clock di trasmissione e ricezione dell'ESCC (RTXCA TRXCA RTXCB e TRXCB).
L'82C54 è un counter/timer programmabile a tre canali. Ogni canale è composto da un contatore indietro a 16 bit con vari modi di funzionamento possibili. Nel nostro caso, il counter 0 (quello che fa capo a CLK0 G0 e OUT0) viene utilizzato come divisore di frequenza programmabile: al suo ingresso (CLK0, appunto) è collegato il segnale a 4.9152 MHz e da OUT0 si preleva un segnale diviso a piacere per qualsiasi numero compreso fra 1 e 65536. Il fattore di divisione scelto dal software è 1229, quindi all'uscita OUT0 si ottiene un'onda quadra alla frequenza di 4 kHz, periodo 250 microsecondi (per i pignoli, 3999.35 Hz e 250.04 microsecondi). Tale frequenza viene inviata agli ingressi CLK1 e CLK2 dei due counter rimanenti, configurati dal software come monostabili a ritardo programmabile. Le rispettive uscite OUT1 ed OUT2 sono collegate rispettivamente agli ingressi CTSA e CTSB dell'ESCC.
Questa, apparentemente strana, configurazione consente di gestire le temporizzazioni nel modo seguente. Supponiamo di dover generare un ritardo di 5 ms per il Txdelay della porta A; per fare ciò è sufficiente impostare tale ritardo sul counter voluto (per la porta A, il counter 1, per la B, il counter 2), espresso in unità di 250 microsecondi, nell'esempio quindi si imposterà 20 nel counter 1, dopodiché si può lasciare libera la CPU per fare altro, cosa molto importante in un sistema multitasking come xNOS o Linux. Trascorso il tempo richiesto, il conteggio arriva allo zero e l'uscita OUT1 cambia stato, facendo cambiare stato all'ingresso CTSA. L'ESCC reagisce a questa variazione su CTSA generando una interruzione (Port A External Interrupt) la quale segnala al driver che è trascorso il tempo richiesto e che è ora di fare quel che si deve fare, nella fattispecie iniziare a trasmettere i dati del frame.
Naturalmente, il valore scelto per il fattore di divisione del counter 0 non è assolutamente vincolante: qualora si reputasse necessaria una risoluzione più elevata dell'attuale, è sufficiente ridurre il fattore di divisione programmato nel counter 0, esprimendo così i tempi in unità da cento (come fatto nel driver specifico per Linux, in cui il fattore di divisione impostato è 491, corrispondente ad una frequenza di 10KHz), o addirittura, volendo, anche da dieci microsecondi. Il limite della risoluzione imposto dall'hardware si situa, infatti, attorno a tempi dell'ordine di un quarto di microsecondo, stante la frequenza di clock impiegata.