Hi-tech – OgniGiorno.com

Oracle compra Sun

lucky — Mon, 20 Apr 2009 15:00:04 +0000

È di oggi, fresca fresca, la notizia che potenzialmente stravolgerà il mondo che gira intorno a Java e all’Open Source. Dopo i rumors dei giorni scorsi che vedevano coinvolta IBM, arriva la doccia fredda e la dichiarazione che “nulla cambierà: le due società continueranno a lavoarae indipendentemente”. Ma allora perché comprarla?
Perché mantenere in casa dei doppioni come MySql, GlassFish, NetBeans?

Più plausibile, invece una pulizia a discapito dei doppioni freeware. Perché una società che vive degli introiti del suo prodotto software dovrebbe mantenere un prodotto analogo gratuito?
Vediamo invece che cosa manca a Oracle, dopo acquisizione:

Hardware
Sistema operativo
Middleware di integrazione
Database
Linguaggio di programmazione
Application server
Strumento di produttività (OpenOffice)

Se non sbaglio, non manca proprio nulla! E poi il monopolista è Microsoft?

Dalla fine del 2005 sun ha acquisito più di 50 aziende nel settore IT espandendosi in quasi tutti gli ambit possibili.
L’ultima di queste (prima di quanto annunciato oggi) è BEA weblogic.

Possiamo considerare questo gesto come l’inizio della fine dell’Open source? Per rispondere bisogna attendere le decisioni strategiche del nuovo proprietario del linguaggio per eccellenza free.
Ma non è solo il linguaggio la chiave centrale della questione. MySQL, per esempio, è il databse che rappresenta lo standard di fatto del mondo open. Il primo scossono si è temuto con la sua acquisizione da parte di SUN, ma adesso i timori hanno tutto il diritto di crescere: Oracle ha già il suo database, che cosa se ne fa di questo?
Ovviamente le voci ufficiali parlano di un fantastico giorno per il mondo dell’information technology… staremo a vedere!

Aumentare l’efficienza dei pannelli solari

lucky — Sun, 19 Apr 2009 14:50:35 +0000

Vediamo come un inseguitore solare ci permette di raddoppiare l’efficienza del nostro impianto fotovoltaico. Oltre a vederne la teoria, presento delle misurazioni pratiche che più di molte descrizioni sono realmente indicative dei risultati.

La teoria
I pannelli solari sono in grado di generare energia elettrica a partire dalla luce del sole. È ovvio quindi che, per avere un buon rendimento, dobbiamo collocare i nostri pannelli in un luogo bene irradiato, soprattutto nelle ore in cui il sole splende al meglio. Per questo motivo solitamente si orientano verso sud, sfruttando le ore di maggior illuminazione.
Cosa significa? Perché non li mettiamo paralleli al suolo, di modo che siano illuminati tutto il giorno? Non è per via della pendenza del tetto che si tende a inclinare i pannelli.
Il sole si riesce a sfruttare con la massima efficienza quando ci si colloca perpendicolare all’irraggiamento. L’inclinazione del pannello solare nasce proprio da qui: è la posizione per cui il pannello risulta essere perpendicolare ai raggi solari quando questi forniscono la massima energia (certo: mediato dall’inclinazione del tetto… era così indipendentemente dal nostro impianto fotovoltaico!).
Da qui si capisce che possiamo ottenere molta più energia se riuscissimo mantenere costantemente perpendicolare al sole la superficie del pannello.
Si può quindi pensare di montare il tutto su un piano motorizzato inclinabile e fare in modo che questo, come un girasole, modifichi continuamente la sua posizione.
Probabilmente per i pannelli sul tetto, il fai-da-te risulterà un po’ difficile, ma per impianti di ridotte dimensioni, sicuramente possiamo auto costruire tutto.

La tecnica dell’inseguitore
Per inseguire il sole dobbiamo montare il pannello su un piano inclinabile rispetto a due assi, ma otteniamo buoni risultati anche se ne utilizziamo uno solo.
Senza addentrarci nei dettagli costruttivi, vediamo come è possibile realizzare la logica di controllo, per muovere il piano e fermarlo automaticamente quando perpendicolare al sole.

La tecnica più utilizzata è quella di basarsi su fotoresistenze montate saldamente al piano e messe opportunamente in ombra, in modo da essere indicative sulla posizione del pannello.
Nel grafico ho schematizzato il meccanismo. Quando il piano si trova perpendicolare al sole, le due resistenze avranno identico valore, altrimenti ci sarà una differenza. Leggendo il valore tramite un controllore, possiamo pilotare il motore per azzerare la differenza.
Facciamo i conti
Ma quanto effettivamente conviene, e quanto ci permette di migliorare questo meccanismo? Riporto il grafico che rappresenta delle misurazioni effettuate su un pannello solare da 10W. Le due linee rappresentano i due casi di pannello fisso e pannello mobile (un solo asse).

Già ad occhio si riesce a vedere una bella differenza, ma preferisco fare dei conti.
Ricordo che l’energia (misurata in watt Ora) si può vedere nel grafico come l’area della curva. Proviamo allora a fare i conti. Per semplicità di calcolo, calcoliamo l’area della figura geometrica che più si avvicina a quanto rappresentato.
In un caso un triangolo (pannello fisso) e nell’altro un trapezio.
Questo calcolo risponde anche alla domanda di chi desidera sapere quanta energia produce un pannello solare in una giornata.

Abbiamo 40,5Wh nel caso di pannello fisso e 99Wh nel caso mobile.
Come si può vedere, più che raddoppiata, cioè più che dimezzata la spesa del pannello solare, a meno dell’inseguitore.

Valutiamo quindi bene eventualità di un costo aggiuntivo che ci permette di dimezzare il tempo in cui ripaghiamo l’investimento. Se poi si tratta di un impianto piccolo, possi dire che sicuramente ne vale la pena, almeno per divertirci a costruirlo!

Decodificare i telecomandi infrarossi

lucky — Sat, 21 Mar 2009 13:36:03 +0000

I telecomandi infrarossi (IR) sono utilizzati da molti anni per controllare televisori, impianti stereo, videoregistratori e molti altri dispositivi. Posso immaginare che in ogni casa ce ne sia almeno uno. Anzi… immagino che molti pensino: “Magari ne avessi solo uno!!”.
Il meccanismo di controllo remoto è basato su un trasmettitore (telecomando) ed un ricevitore (incorporato nel dispositivo che si controlla). Vediamo in questo articolo il protocollo che implementano.
Vedremo anche esempi pratici e il codice per realizzare tramite controllori PIC un decodificatore. Le applicazioni sono demandate alla nostra fantasia. Per esempio possiamo controllare la luce del salotto con lo stesso telecomando del televisore.

Il modulatore
Per la comunicazione viene utilizzato un LED emettitore di infrarossi, un led che emette luce ad una frequenza non visibile. Questa luce viene modulata in modo da trasmettere in sequenza (trasmissione seriale) le informazioni (bit).
Nell’ambiente esistono moltissime fonti di infrarossi (la luce del sole, le lampadine, …) per questo motivo le informazioni vengono solitamente modulate su una portante di qualche decina di kHz (i valori utilizzati vanno da 30 a 60).
Vediamo cosa significa:

La trasmissione viene miscelata alla frequenza della portante. Il risultato è visibile in figura. In questo modo il ricevitore è in grado di ricostruire il segnale originario tramite un filtro passa-banda centrato sulla frequenza della portante. Si eliminano in questo modo disturbi ed interferenze.

A semplificazione del circuito di decodifica sono disponibili in commercio componenti che racchiudono ricevitore e filtro (TSOP12xx, dove xx indica la frequenza della portante. TSOP1236 riceve a 36kHz, TSOP1248 a 48kHz, e così via). Questi ricevitori hanno 3 piedini: +5v, GND e signal out. Quest’ultimo si può collegare direttamente al piedino di ingresso del nostro controllore.

La trasmissione
A questo punto possiamo concentrarci esclusivamente sui dati che vengono trasmessi, pensando al protocollo di comunicazione e a come vengono codificati i simboli (1 e 0). Purtroppo non esiste uno standard universale, ma ogni produttore ha sviluppato il suo.
Mi voglio concentrare in questo articolo sul protocollo adottato da Philips (il mio telecomando), tratterò a parte una raccolta di protocolli differenti. Il protocollo qui descritto è uno dei diversi implementati da Philips. Il nome corretto è RC-5.

Codifica
Il primo elemento da analizzare è come vengono rappresentati i due simboli 1 e 0. è in base a questo che va scritto l’algoritmo per il PIC (assembler o C).

La portante utilizzata è 36kHz
Modulazione:

Protocollo
3 bit di start – 5 bit indirizzamento – 7 bit comando

I primi 3 bit vengono utilizzati per segnalare l’inizio trasmissione: i primi due hanno valore fisso a 1, il terzo cambia ogni volta che viene lasciato e ripremuto un pulsante. Serve per distinguere tra una pressione prolungata dello stesso tasto e due pressioni successive. Questo bit viene chiamato Toggle (T)
L’indirizzamento è utilizzato per identificare il dispositivo da controllare (televisore, videoregistratore, …)
Il comando identifica il tasto premuto.
In figura vediamo come è composta la stringa che vene trasmessa alla pressione di ogni tasto. I valori dell’esempio sono: Indirizzo = 2, comando = 13

Passiamo alla pratica.
Manca solo il codice. L’esempio qui allegato decodifica il telecomando e trasmette sulla seriale (RS232) i due valori di comando e device. Serve come esempio, per comprendere il funzionamento della routine di decodifica. Questa può essere infatti utilizzata per qualsiasi impiego. Il progetto allegato è scritto e compilato per il 12F519, ma il codice è utilizzabile per tutti i PIC baseline. Con la versione free del compilatore picc di HI-TECH (quello che utilizzo io) vanno modificati i tempi per controllori di fascia più alta (l’ottimizzazione non è il massimo). In alternativa va riscritto il codice in assmbler. Per ora l’ho utilizzato solo su questo controllore, ma appena scriverò l’assembler, lo posterò.

Modulo display a 7 segmenti

lucky — Wed, 11 Mar 2009 11:00:21 +0000

Nella progettazione e realizzazione dei progetti adotto da tempo la tecnica “modulare” che consiste nella realizzazione di periferiche con interfacciamento standard (seriale nel caso specifico). Vediamo qui la scheda del modulo display a 7 segmenti.

Le caratteristiche principali:

4 cifre
Interfaccia seriale 9600 baud
256 byte EEPROM

L’interfaccia seriale comunica utilizzando il protocollo descritto qui ed implementa i seguenti comandi:

aggiunta cifra a destra
cancellazione ultima cifra inserita
cancel completo (porta a 0 tutte le cifre)
Lettura valore visualizzato
Scrittura EEPROM
Lettura EEPROM

L’utilizzo tipico avviene tramite tastiera, per cui ad ogni tasto premuto viene visualizzata la relativa cifra, partendo da destra con shift verso sinistra. Il comando di lettura del valore visualizzato permette la completa asincronicità tra display e utilizzatore: quando serve viene letto il valore.

Gli ultimi due comandi servono per sfruttare la memoria EEPROM disponibile sul controllore, che per la gestione dei disply non vengono utilizzate. Siccome c’è sempre carenza di memoria, perché non sfruttarla?

Schema elettrico

R1-R4: 1k ohm

R5-R12: 330 ohm

T1-T4: BC517

DIS1-DIS4 Display anodo comune

Il controllore visualizza i valori delle 4 cifre, multiplexando i 4 display, alimentati tramite 4 darlington. L’interfaccia seriale lavora a livelli TTL e sfrutta gli stessi pin utilizzati per la programmazione (ICSP).

Firmware

Allego il progetto completo MPLAB. Il compilatore utilizzato è il PICC di Hitech

Per implementare altri comandi di deve modificare la funzione

unsigned char interrupt ricezione(void), in particolare intervenendo nel blocco switch, inserendo altri case, riferiti ai comandi da implementare:

... c = GetCommand(); if (!c) { switch (read_Buff(2)) { case 5: ...
Esempio di utilizzo

ecco ora una parte del codice di un progetto che utilizza il modulo:

c = ReadKey(); switch (c) { case 0x0a: sendCommand (0x35, 6, 0); break; case 0x1a: sendCommand (0x35, 7, 0); break; case 0x0b: DelayMs (200); sendCommand (0x35, 8, 0);

if (getCommand()==0) sendSlave(); break; default: DelayMs (200); c += 0x30; sendCommand (0x35, 5, c); }

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).