Scheda COR “CARRIER OPERATED RELAY” – Primo "BUG"

Se chi ben comincia é a metà dell’opera, non possiamo dire che al COR vada benissimo ;)

A parte le battute, con grande soddisfazione mi sono portato una versione prototipale del nuovo COR alla  fiera di Osimo svoltasi lo scorso 14 e 15 dicembre 2013.

Sempre carico e soddisfatto ho tirato fuori il pacchetto per far vedere quello che é lo stato avanzamento e  soprattutto per comunicare a tutti che siamo ad uno stato molto avanzato (quasi al termine). Il fatto che le  cose stavano andando per il verso giusto lo sapevo da tempo (altri articoli sul COR possono essere trovati  qui e qui) ma non lo avevo mai palesato.

Il tempo di collegare l’alimentatore e mostrare i segnali di ingresso ed uscita alla scheda, come:
- Potenziometri per simulare lo squelch/Busy del segnale radio Ponte e del segnale radio Link
- Led di segnalazione dello stato dei 2 PTT
- Display di debug e controllo del funzionamento (visualizzazione compatta ed estesa)
- Led per la visualizzazione del segnale PWM (beep o altro)
- Led per lo stato degli switch audio
- Pulsanti e led per il comando di play e controllo della riproduzione delle 3 sintesi vocali previste
(per maggiori informazioni su questa scheda premere qui)
- La seriale RS232 per impostare i tempi, le priorità e tutti gli altri parametri di configurazione (sono
molti) che possono essere modificati “al volo” durante il funzionamento della scheda COR

Poi ho fatto vedere il funzionamento classico la durata della coda, l’intervallo delle sintesi vocali, la
disabilitazione dell’apparato di Link, l’impostazione della soglia di squelch (impostazione manuale o
automatica) ecc...

E finalmente arriva la prima domanda di Claudio IK6DIO:
“Ma se arrivano due segnali in contemporanea tra Ponte e Link?”
“Nessun problema” rispondo, é una situaziopne prevista dove la priorità viene data al Link.
Peccato che nel far vedere la cosa mi sono accorto che il segnale di switch audio del ponte che doveva  andare basso non ci andava..... facendo qualche prova in più, se il segnale busy del link arriva prima di  quello del ponte tutto funziona senza problemi, ma se arriva prima ils egnale di busy link, l’audio del ponte  non viene interrotto.... in pratica un BUG.

A parte lo scherzoso aneddoto, siamo ad uno stato avanzato degli sviluppi, ora dobbiamo collegare i
componenti a contorno come gli switch audio, la scheda di sintesi vocale ecc... e siamo pronti per le prime  prove con le radio.

Il firmware é organico e completo ed il livello di configurabilità della scheda é altissimo, attraverso un  normale terminale seriale RS232 a 9600 baud si possono impostare tantissime cose e verificare lo stato di  tutte le uscite e di tutti gli ingressi, é anche possibile eseguire un completo reset della scheda ed il ritorno  alle impostazioni iniziali.

Come accenanto negli altri articoli, tutte la configurabilità da seriale ci permette di creare delle schede  aggiuntive per aumentare le funzionalità di questo modulo base (per esempio una estenzione bluetooth,  una estensione ethernet, oppure il collegamento al sistema di telecontrollo).

Per quanto riguarda i pin, abbiamo utilizzato circa l’80% degli I/O disponibili e siamo a circa il90% della  memoria utilizzata. La questione dell’elevato utilizzo della memoria programma mi impensierisce un pochino per gli sviluppi  fututi, ma non ho potuto fare altrimenti ... la configurabilità si paga da qualche altra parte. Eventuali  “aggiunte” saranno gestite da microcontrollori esterni alla scheda base.

I prossimi passi:
- Collegamento degli switch audio
- Collegamento della scheda di sintesi vocale
- Collegamento dei segnali di squelch/busy dell’apparato di ricezione ponte e dell’apparato di Link

Poi passeremo alla ingegnerizzazione del PCB e ad una prima versione della scheda COR.

Il tutto dopo aver scovato e risolto il bug di Osimo.
Buon Natale
Saluti.
Sergio IW6CQF

Scheda COR “CARRIER OPERATED RELAY” – Le Logiche

Una volta terminte le impostazioni delle porte ci siamo buttati sul codice per la gestione delle logiche.

Per logiche intendo tutte i comportamenti che la scheda deve assumere all’accadere di qualche evento.

Queste logiche sono configurabili da seriale, una grande quantità di codice é stata scritta per permettere di impostare i tempi, le priorità, le uscite e gli ingressi da dei menù su tre livelli consultabili dal seriale RS232.

La pressione del pulsante User avvia la procedura di configurazione e viene spedito il menù principale su seriale. La selezione della voce desiderata e la pressione dell’invio permettono la navigazione dell’albero del menù e l’inserimento di tutti i parametri di funzionamento.
Questo é il menù principale ricevuto sulla seriale (9600,n,8,1):

La seconda funzionalità é quella propria della gestione degli apparati radio.
Abbiamo previsto un apparato denominato Ponte ed un apparato denominato Link, senza scendere nelle caratteristiche di ognuno, l’apertura dello squelch (busy) in uno fa attivare il PTT dell’altro (o su entrambi) secondo una serie di priorità e di logiche.

Proprio questa parte, unitamente a quella di switch sui 4066 del flusso audio é la parte mancante, mentra stanno funzionando sotto test le procedure di gestione della coda sul PTT (durata configurabile) e dell’avvio ad un certo intervallo delle 3 sintesi vocali disponibili (intervallo configurabile per ogni apparato e per ogni sintesi).

Sotto una foto della breadboard che rispetto alla fase precedente é cresciuta di una scheda:

Saluti
Sergio IW6CQF

Scheda COR “CARRIER OPERATED RELAY” – Prime Impostazioni

L’idea iniziale sta prendendo forma.

Abbiamo identificato il micro e quasi terminato la configurazione e definizione delle periferiche necessarie.

Come accennato nel precedente articolo, la base tempi era una priorità ed il timer interno del micro ed il codice che lo gestisce sono stati configurati per darci una facile gestione delle macchine a stati che gestiranno le logiche di funzionamento del COR. I tempi sono abbastanza precisi, dalle prove effettuate tale precisione va benissimo per i nostri scopi (al momento nessuna necessità di montare l’oscillatore esterno).

Altra periferica importante del sistema é la seriale che sarà utilzizata per la configurazione del COR e per controllare il funzionamento della scheda. Non mi dispiace affatto la possibilità di utilizzare la USART per la comunicazione bidirezionale con schede aggiuntive esterne.

Tra le periferiche principali non possiamo dimenticare il display. Un comune LCD HD77480 4 righe per 20 caratteri permette un debug completo di funzionamento e la visualizzazione dello stato del sistema. Una volta che la scheda é configurata il display potrà essere disabilitato attraverso una configurazione da porta seriale (il display risulta inutile nel momento in cui il sistema é installato e funzionante).

Terminano la lista delle periferiche i digital output (led di stato ecc...), digital input (pulsante di accesso al menù sulla seriale ecc...) e analogi input (Vox di detect del busy ecc...)

Nel momento in cui scrivo questo articolo tutte le periferiche sono state provate e l’oscillatore interno ad 8MHz permette la gestione di tutte contemporaneamente senza problemi di performance.

In effetti in una applicazione di questo tipo non é critica la potenza del micro quanto la numerosità di input ed output necessari alla gestione.

Stiamo utilizzando un PIC18F4550 che é un 40 pin e siamo a circa l’80% dei pin utilizzati.

Il COR su breadboard:

 

Il prossimo passo sarà la creazione del codice firmware per la gestione delle logiche funzionali del COR.

L’imminente “nascita” della scheda di sintesi vocale definitiva ci permette di pensarla come parte integrante di questo COR.

Saluti

Sergio IW6CQF

Adattatore per Programmazione PIC (vari formati/piedinature)

Come molti, mi sono avvicianato al mondo dei microcontrollori grazie alla semplicità d’uso e la facilità di reperimento dei PIC (Microchip).
Ho iniziato a fare piccole cose e pian pianino ho avuto la possibilità di divertirmi con progetti più complessi. Nella mia esperienza hobbistica non ho mai incontrato problemi insormontabili per questi micro (a parte qualche volta la potenza di calcolo) e sono sempre stato convinto che una scheda a microcontrollore dovesse avere anche il connettore per la programmazione ed il debug del micro a bordo.
Questo permette di scaricare direttamente il firmware e di poter andare in debug, la cosa negativa é che alcuni piedini del micro rimangono utilizzati dal debugger e non sono utilizzabili al fine del progetto (a patto di non montare jumper).
In questo periodo ho avuto la possibilità di utilizzare PIC di taglio medio/piccolo per fare dei semplici prototipi e per delle piccole automazioni (di debug) del sistema ponti. Per queste cose non ho voluto scomodare gli STM32, ed ho utilizzato quanto disponibile in casa e dato che é molto più pratico un micro su contenitore DIN per il montaggio su breadboard sono ricaduto sui cari PIC.
Ecco che mi sono dovuto ricredere sulla mia convinzione iniziale di avere sulla scheda anche la programmazione ed il debug del micro.
Essendo PIC di taglio piccolo, é essenziale avere tutti i pin a disposizione, ma a questo punto come programmare agevolmente i PIC?

Il primo passo é stato quello di collegare “al volo” i piedini del micro con l’ICD2. Ma dato che la frequenza delle volte che mi serviva una cosa del genere stava salendo, mi sono convinto nel fare una semplice schedina che con diversi zoccoli DIN permettesse la programmazione dei PIC nei vari package.
In giro per la rete ho trovato diverse soluzioni, ho preso degli spunti tra le varie informazioni che ho trovato ed ho realizzato la mia schedina (ne migliore ne peggiore di altre).
La programmazione é possibile solamente se si configura l’ICD2 per dare alimentazione al microcontrollore. Per non dimenticare questo passaggio, volevo montare un LED rosso di segnalazione, ma per pigrizia non l'ho ancora fatto. Nella parte destra della scheda ho montato dei normalissimi pin strip che riportano tutti i pin di programmazione.

La disposizione é compatibile con quella del pickit2 e la riporto sotto:
1- Vpp/MCLR
2- VDD Target
3- Vss (GND)
4- ICSPDAT/PGD
5- ICSPCLK/PGC

In questo modo é possibile programmare i micro sia con il PicKit sia con l’ICD2.
I PIC hanno diverse piedinature, le più utilizzate a livello hobbistico e le più diffuse sono 8/14/18/20/28 e 40 tutte rigorosamente in package DIN. Lo scopo é proprio quello di poter programmare PIC con queste piedinatura con la stessa scheda adattatore.
Per verificare quali fossero i piedini di programmazione dei PIN con le varie iedinature ho preso a campione dei datasheet dal sito ufficiale Microchip.

Il pinout dell’icd2 é:
1- Non connesso
2- ICSPCLK/PGC
3- ICSPDAT/PGD
4- Vss (GND)
5- VDD Target
6- Vpp/MCLR


La scheda é un adattatore, non contiene logica o alimentazione. Parliamo di una connessione fisica dei segnali che vengono dall’ICD2 su ogni pin di ogni zoccolo DIN (i PIC con lo stesso numero di piedini, hanno i PIN di programmazione nella stessa posizione indipendentemente dalla famiglia e del modello).
Per la piedinatura dei PIC di varie “dimensioni” potete fare riferimento al datasheet.
Non sono presenti gli zoccoli da 8 e 14 pin in quanto hanno la stessa piedinatura del 20 pin, rispettando il pin 1.
I componenti:

Ecco la foto del lavoro ultimato:

Sugli zoccoli DIN ho tagliato i pin non necessari per evitare contatti che potrebbero inficiare negativamente sul funzionamento.
Vi prego di non fare caso agli zoccoli che nel caso del 18 pin e del 20 pin li ho dovuti tagliare (sempre nell’ottica di utilizzare quello che era disponibile immediatamente e nel raggio di 20mt).

Saluti
Sergio IW6CQF