Bit banging – OgniGiorno.com

L’oscilloscopio PCE-SDS serie 10xx

lucky — Fri, 28 Nov 2014 08:36:02 +0000

L’ampia banda passante da 50MHz rende questo oscilloscopio utilizzabile in molti campi dell’elettronica e della tecnologia di misura.
Il PCE-SDS è un oscilloscopio registratore a 2 canali con un display 7” a colori che lo rende unico nel suo genere, inoltre è dotato frontalmente di una porta USB utile per scaricare ad esempio i dati su di una chiavetta. La maschera dei comandi è molto chiara e facile da usare, il tasto “Auto” permette di utilizzare la funzione integrata di impostazione automatica dei parametri.
Questo dispositivo ha un’elevata sensibilità, la possibilità di impostare la frequenza di campionamento fino a 1GS/s e l’uso di funzioni matematiche integrate.

Per maggiori informazioni: https://www.pce-instruments.com/italiano/

Digitalizzare il plastico del trenino

lucky — Thu, 23 Apr 2009 11:04:38 +0000

Un progetto dedicato agli appassionati di modellismo ferroviario che permette di digitalizzare il controllo di scambi, segnali e altri dispositivi presenti nel plastico.

Il circuito presentato è studiato per trenini Märklin, ma modificabile per adattarlo a tipologie diverse. Come vedremo, la parte di alimentazione è pensata per la corrente alternata, la modifica per adattarla a corrente continua richiede poco e, anzi, permette di ridurre le dimensioni ed il numero di componenti.

Il vantaggio che deriva da questo progetto lo si vede principalmente nel numero di cavi con cui abbiamo a che fare nel cablaggio dell’impianto. A differenza del metodo tradizionale, per cui dobbiamo prevedere 3 fili dalla centrale di comando ad ogni dispositivo (eventualmente riducibile a 2), con un circuito digitale riusciamo ad utilizzare tre soli fili comuni a tutti i dispositivi controllati. Oltre ai due di alimentazione, il terzo filo è quello su cui viaggiano i dati.

Il formato in cui vengono trasmessi i dati prevede di inviare le informazioni relative a quale operazione e quale dispositivo è chiamato a reagire.

Il funzionamento
Il controllo avviene tramite una centralina a disposizione dell’operatore (il modellista che si diverte con locomotive e trenini vari).
Ogni dispositivo viene poi controllato direttamente da un decodificatore. Il decodificatore è collegato in ingresso al BUS di comunicazione (i tre fili che partono dalla centralina) e in uscita direttamente allo scambio da controllare.
Siccome tutti i decoder sono collegati insieme, deve essere individuato un sistema per fare in modo che ciascuno riconosca il comando a cui deve rispondere. Per questo ad ogni decodificatore verrà assegnato un codice (indirizzo). Parliamo poi di “comando” per identificare l’azione che vogliamo controllare. Usando sempre lo scambio come esempio, i comandi sono due: dritto e storto.
Quando l’operatore decide di girare uno scambio, dalla centralina parte un messaggio (che arriva a tutti contemporaneamente) che contiene l’indirizzo ed il comando. In questo modo il decoder confronta l’indirizzo con il proprio e, in caso di corrispondenza, esegue il comando.
Nella realizzazione qui descritta ho implementato un protocollo seriale che prevede un solo byte per l’indirizzo. Questo significa che si possono controllare fino a 255 dispositivi differenti. In caso non siano sufficienti, si può modificare il protocollo. 2 byte estendono a 65535 il numero di dispositivi.

La centralina
La centralina è costituita da una tastiera numerica ed un display a 4 cifre. Ho utilizzato display a 7 segmenti per rendere il numero più visibile e sicuramente più “in stile” con il plastico di come sarebbe stato con un LCD, ma nessuno impedisce di fare diversamente. In questo modo va interpretata la lettura nel modo seguente: le prime tre cifre rappresentano l’indirizzo, la quarta il comando.

Esempio: se chiamiamo 1 il comando “dritto” e 7 “storto”, per raddrizzare lo scambio identificato dell’indirizzo 56, dovremo visualizzare 0561 sul display (056 indirizzo + 1 comando). Visualizzato il numero corretto, si preme “invia” e il messaggio parte dalla centralina.
Nella foto è visibile lo schema a blocchi della centralina. Oltre a quanto descritto, vi è solo l’alimentatore.

Il decodificatore
Lo schema elettrico del decodificatore è visibile qui sotto. La scelta è stata quella di dotare ogni decodificatore di un alimentatore in grado di abbassare a 5v la tensione per il microcontrollore. In questo modo si riescono ad utilizzare solo i tre fili, due dei quali sono comuni con le alimentazioni delle bobine degli scambi. Da 16 a 5 si ottiene una buona stabilizzazione per il PIC anche semplicemente alimentando tramite diodo zener e condensatore il controllore.
Siccome le dimensioni del decodificatore sono davvero contenute (tutto realizzato con componenti SMD), l’aggiunta di 3 componenti non crea grossi problemi. In alternativa, per ridurre ulteriormente le dimensioni, si può prevedere un’uscita a 5v dalla centralina e aggiungere un filo al BUS.
Il jumper serve per l’assegnamento dell’indirizzo. Il decoder funziona normalmente a contatto aperto (senza jumper). Quando presente, il decoder risponde come se avesse indirizzo 0. Dalla centralina è possibile mandare il comando 0 all’indirizzo N, che vene trasmesso come comando N all’indirizzo 0 e interpretato dal decoder che risponde a 0 come comando di assegnamento indirizzo. L’indirizzo viene memorizzato in EEPROM, quindi mantenuto anche a circuito non alimentato.

A circuito nuovo, va quindi fatto un lavoro di assegnamento indirizzo a tutti i decodificatori. Per comodità si può eseguire questa operazione non necessariamente con i decodificatori montati sul plastico, ma tenerceli comodamente a portata di mano (è più facile mettere e togliere il jumper). Rispetto alla soluzione spesso adottata dei DIP switch, questo metodo permette di ridurre dimensioni e costi del decoder. Visto che ormai il 12F519 costa circa 20 centesimi ed è dotato di memoria Eprom, si riesce a realizzare il decoder con i pochissimi componenti come mostrato nello schema per un costo totale inferiore all’euro!
Idee aggiuntive.
Vediamo ora alcuni spunti per ulteriori implementazioni o estensioni del dispositivo.
Si possono costruire decodificatori destinati a controllare altri dispositivi, in modo per esempio di controllare tramite relè l’illuminazione del plastico, o azionare automatismi come i motorini che muovono gru, piattaforme o altro.
In alternativa al PIC 12F519, per il decodificatore si può utilizzare un controllore con più piedini di uscita, in modo da controllare più di uno scambio con lo stesso decoder.

Come funzionano i telecomandi dei cancelli

lucky — Sun, 08 Mar 2009 17:03:33 +0000

Studiamo il funzionamento dei radiocomandi a 433 Mhz solitamente utilizzati per aprire i cancelli. Parliamo qui di quelli a codifica fissa, non dei rolling code.

La codifica/decodifica viene quasi sempre realizzata utilizzando una coppia di circuiti integrati (HT12E e HT12D o equivalenti), dedicati allo scopo, abbinati ad un trasmettitore e un ricevitore radio.

Il trasmettitore invia un codice composto da 12 bit. I radiocomandi hanno solitamente un dip switch che permette di selezionare il codice. Il codice identico deve essere impostato sul ricevitore, per permettere il riconoscimento.

Radiocomandi a più canali utilizzano una parte dei 12 bit per identificare il canale: per N canali si ha un indirizzo a 12-N bit.

Di seguito lo schema a blocchi tipico del radiocomando:

La velocità di trasmissione solitamente utilizzata è di 1000 baud, la codifica è la seguente:

Avendo queste informazioni siamo quindi in grado di realizzare un radiocomando con codifica e decodifica tramite PIC.

Per la parte radio utilizziamo i moduli trasmettitore e ricevitore della Quasar che permettono con pochi euro di ottenere ottimi risultati. Questi moduli possono essere acquistati presso qualsiasi distributore di componenti elettronici, anche se io preferisco risparmiare ed acquistare direttamente sul sito del produttore.

L’utilizzo dei moduli richiede veramente poco. Entrambi ricevitore e trasmettitore hanno 4 connessioni: positivo e negativo di alimentazione, antenna e dati.

Ecco la routine del trasmettitore (la frequenza di oscillazione da me utilizzata è di 8Mhz).

void TxChar(unsigned char c) { unsigned char bitno;

INIT_PORT; bitno = 4; do { TxData = 0; delay_2Us (165); if(c & 1) TxData = 0; else TxData = 1; c = (c >> 1) | 0x80; delay_2Us (164); TxData = 1; delay_2Us (165); } while(--bitno); }

Come si vede dal codice, la routine effettua la trasmissione dei soli 4 bit meno significativi del parametro in ingresso. Questo per maggiore comodità, essendo a 12 bit il codice che deve essere trasmesso.

Il ricevitore è un po’ più complesso, a causa dei disturbi tipici del canale radio. Ho quindi implementato una sorta di macchina a stati finiti con due stati: in attesa e in ricezione:

int RxRadio(void) { unsigned char bitno, tmp, width, w0;

state0: width = 0; d1 = 0; d2 = 0; bitno = 0; while(!RxDt) continue; /* wait for start bit */ while (RxDt) { delay_2Us(4); width++; if (width > 45) goto state0; } if (width < 30) goto state0; state1: width = 0; w0 = 0; tmp = 1; while (!RxDt){ delay_2Us(4); w0++; if (w0 > 90) goto state0; } while (RxDt) { delay_2Us(4); width++; if (width > 90) goto state0; } if (width < 20) goto state0; if (width > w0) tmp = 0; if (bitno > 7) d1 = (d1 >> 1) | (tmp << 7); else d2 = (d2 >> 1) | (tmp << 7); bitno ++; if (bitno == 12) return width; goto state1; }

Per ridurre problemi derivanti da disturbi o errori di ricezione, il decodificatore si aspetta di ricevere gli stessi dati per tre volte consecutive. In caso contrario non effettua la decodifica. La trasmissione avviene quindi correttamente se chiamiamo 3 volte con gli stessi valori la TxChar.

Di seguito un esempio che illustra come poter effettuare la trasmissione di tutte le combinazioni possibili in sequenza, utile se abbiamo perso il telecomando e vogliamo individuare il codice per duplicarlo.

void InitTx(void) { TxData = 1; delay_2Us (165); TxData = 0; } void EndTx (void) { TxData = 0; DelayMs(10); }

...

for (j=0; j<16; j++) for (i=0; i<256; i++) for (t=0; t<4; t++) { InitTx(); TxChar (i); TxChar (i>>4); TxChar (j); EndTx(); } for (;;);

va considerato che la trasmissione completa dura:

(1000 baud x 12 bit + 10 ms + 330 us) x 3 volte = 67 ms per ogni codice trasmesso

2^12 combinazioni x 36 ms = 4096 x 67 ms = 274,432 s = 4,57 minuti

Un protocollo di comunicazione seriale

lucky — Sun, 08 Mar 2009 17:02:05 +0000

Vediamo come realizzare un semplice protocollo di comunicazione basato sul trasferimento seriale. Si tratta di un protocollo basato su messaggi, implementabile in tutti i circuiti basati su controllore, in modo da riuscire a modula rizzare la progettazione.

Costruire circuiti o semplici robot ci porta sempre ad avere bisogno delle stesse periferiche: schede display, tastiera, RTC, …

Lavorando in questo modo, per ogni progetto dobbiamo occuparci della progettazione della scheda madre e di come interagisce con le sue periferiche.

Il protocollo qui descritto offre alcuni vantaggi che lo rendono applicabile anche sui controllori pi piccoli. Ecco le caratteristiche principali:

Protocollo single master/multi slave
Basato su messaggi a risposta singola: ogni comando è costituito da un messaggio di andata (da master verso slave) e una risposta
Previsto indirizzamento. Il messaggio contiene l’indirizzo del destinatario. È possibile quindi avere più periferiche sulla stessa linea.
Ogni messaggio contiene più controlli di integrità. Viene garantita una buona qualità della trasmissione tramite il byte di vli (indica la lunghezza del messaggio) e il check
Esiste un indirizzo di broadcast
Assegnamento dinamico dell’indirizzo delle periferiche

Formato dei messaggi

Comando: [stx][vli][1][cmd][addr]…data…[crc][etx]

Risposta: [stx][vli][0][cmd][addr]…data…[crc][etx]

stx: 0x02

vli: Variable length indicator

cmd: codice che identifica il comando da inviare o a cui si risponde

addr: indirizzo di destinazione o sorgente, in caso di risposta

data: eventuali dati aggiuntivi. Dipende dal comando.

crc: controllo sui dati trasmessi. Io ho implementato XOR su tutti i byte

Etx: 0x03

Comunicazione seriale con controllori PIC

lucky — Sun, 08 Mar 2009 17:01:13 +0000

Sebbene parlare oggi di trasmissione seriale possa sembrare anacronistico, vediamo invece l’utilità che questo metodo di comunicazioni continua ad avere. Stiamo parlando di trasferimento dati all’interno di un circuito tra due controllori differenti, o di comunicazione tra due circuiti.

Escludiamo il PC, per cui oggi preferiamo metodi più “nobili” come l’USB o Ethernet, considerando anche che difficilmente si riesce ancora a reperire un computer dotato di porta RS232.

Il trasferimento seriale

La trasmissione seriale avviene inviando in sequenza su un solo filo i singoli bit che compongono i dati da inviare. Solitamente quando due controllori devono comunicare si utilizzano due linee, una in ingresso (RX) e l’altra uscita (TX).

Se vogliamo avvicinarci allo standard RS232, vediamo quali sono le regole che lo governano:

A riposo la linea mantiene il valore alto (1)
Prima dell’inizio della trasmissione di ciascun byte viene portato a 0 il valore della linea per la durata prevista per un bit (bit di start)
Partendo dal meno significativo vengono trasmessi gli 8 bit.
In coda viene trasmesso un valore alto per la durata di un bit (bit di stop)

La durata di ciascun bit è determinata dalla velocità di trasferimento. Per esempio: 9600 baud significa che ogni simbolo ha una durata di 1/9600 secondi = 104 us.

Adesso quasi tutti i controllori PIC contengono il modulo UART (universal asynchronous receiver/transmitter), in questo caso si realizza la comunicazione sfruttando il modulo, utilizzando i registri che lo controllano.

Può comunque capitare di dover implementare la comunicazione lavorando direttamente con piedini I/O generici. Per esempio se utilizziamo i controllori più piccoli, o se dobbiamo avere più di un’interfaccia su linee distinte.

Vediamo quindi ora l’implementazione della trasmissione.

La criticità principale deriva dalla precisione che dobbiamo avere nella gestione dei tempi. Per questo motivo è preferibile lavorare in assembler.

Io utilizzo MPLAB di Microchip e il compilatore C di HITEC (picc). Le parti di codice in assembler le integro nei programmi C, sfruttando il linker di questo compilatore: basta aggiungere il sorgente .as nel progetto, e fa tutto da solo.

La versione freeware di questo compilatore non è affatto ottimizzata, quindi siamo realmente costretti a lavorare in assembler per i controllori midrange, mentre con i baseline ho avuto buoni risultati anche con il c (per esempio il 16F506 e il 12F519).

Partiamo dalla routine di trasmissione scritta in C:

void Putch(unsigned char c) { unsigned char bitno;


TxData = 0; /* start bit */

bitno = 12;     /* Rallenta la trasmissione, ma migliora la qualità*/

do {

       delay_2Us (50);

   if(c & 1)

      TxData = 1;

   else

      TxData = 0;

  c = (c >> 1) | 0x80;

} while(--bitno);

}

Per poi vedere la sua codifica in assembler:

PSECT text,class=CODE,local,delta=2 GLOBAL _Putch GLOBAL ??_Putch FNSIZE _Putch, 3, 1 #include "aspic.h"


#define Par ??_Putch

#define Tmp ??_Putch+2

#define Bitn ??_Putch+1

_Putch:

   movwf Par

   movlw 0x0c

   movwf Bitn

   bcf TX_port, TX_pin

loop:
; delay 1 bit

   movlw bit_delay

   movwf Tmp

  delay:

   nop

   decfsz Tmp, f

   goto delay

   ; copia il bit in uscita (ultimo bit dx)

   btfss Par, 0 ; skip if set

   goto set0

  set1:

   bsf TX_port, TX_pin

   goto cont

  set0:

   bcf TX_port, TX_pin

  cont:

; ruota a dx il byte, mettendo a 1 il più a sx

   bsf STATUS, 0

   rrf Par, f

   decfsz Bitn, f

   goto loop

bcf STATUS, 5 bcf STATUS, 6 return

Leggermente più complicata la ricezione. Considerando che la linea è alta a riposo, si reagisce appena si abbassa: presente il valore 0, aspetto metà del tempo di durata di un bit, in modo da posizionarmi nel centro e campiono il valore per otto volte.

Il codice in C

char Getch(void) { unsigned char c, bitno; for(;;) { while(RxData) { continue; /* attesa bit di start */ } delay_2Us (25); if(RxData) continue; /* filtro i disturbi*/ bitno = 8; c = 0; do { delay_2Us (50); c = (c >> 1) | (RxData << 7); } while(--bitno); return c; } }

E qui l’assembler

PSECT text,class=CODE,local,delta=2 GLOBAL _Getch GLOBAL ??_Getch, ?_Getch FNSIZE _Getch, 3, 1 define Retv ??_Getch #define Temp ??_Getch+2 #define Bitno ??_Getch+1


_Getch:

   clrf  Retv

;   movlw    0x32

;   movwf    Temp

  Start:

;   decf     Temp, f

;   btfsc    STATUS, 2

;   goto     Uscita

   btfsc RX_port, RX_pin

   goto  Start

         ; delay mezzo bit

   movlw  half_delay

   movwf Temp

  delay1:

   nop

   decfsz Temp, f

   goto  delay1

         ;  disturbo sulla linea: accapo!

   btfsc RX_port, RX_pin

   goto  _Getch

   movlw  0x08

   movwf Bitno
  bitRx:        ; delay 1 bit intero

   movlw  bit_delay

   movwf Temp

  delay2:

   nop

   decfsz Temp, f

   goto  delay2
   bcf  STATUS, 0

   btfsc    RX_port, RX_pin

   bsf  STATUS, 0

   rrf  Retv, f

         ;finito?

   decfsz Bitno, f

   goto    bitRx

  Uscita:

   movf  Retv, w

bcf STATUS, 5 bcf STATUS, 6 return

Con queste due routines facciamo comunicare i controllori riducendo il numero di connessioni utilizzate. Per comunicare con un PC è necessario un adattatore di livelli. Il PIC infatti lavora con valori TTL (0 = 0V, 1 = +5V), mentre l’interfaccia RS232 utilizza valori EIA (0 = -12V, 1 = +12V). Solitamente si utilizza l’integrato MAX232.

Lavorando con i nuovi controllori PIC con oscillatore interno (senza quarzo) a 8Mhz, i risultati migliori li ho ottenuti a 9600 baud (i valori utilizzati nel codice che ho riportato).