STM8S UART test in Single Wire (half duplex) mode

I received an answer from an STM engineer after my question in the forum at this link: . The question was about the loss of UART_RX if remapping the TX on the pin 5 (PA3). The answer confirmed my opinion about a mistake in documentation, but the engineer suggested the use of the UART in single-wire half-duplex mode, where only the UART_TX pin is used. So, I tested this operative mode and it worked. Then, I decided to publish the full project folder (schematics and C sources) in order to expand my tutorial about the STM8S microcontroller (hope it helps).

The working prototype

Using a single wire UART means that you must “mix” the output and input line to have your communication. In the microcontroller such mixing circuit is inside the chip, but if you want to use (for example) an USB-Serial converter standard to drive the micro, you will add some hardware. Not so much: just a diode and a resistor. Look at the schematic here below:

The diode used in this case is the BAT43, a Schottky diode with low forward voltage drop. This is necessary in order to have a “zero” level inside the microcontroller VIL limits. Note that such “mixer” isn’t very good if you plan to use the serial interface at very high speed, ‘cause the “high” level comes from the pull-up (10K) only, being the serial line “open drain” like. So, the rising time of the signal depends upon the capacitive loads on the line. Using a transmission speed of 115200 BPS, means that every bit is about 8.7 uS long and the internal sampler of the UART takes 3 samples at the ideal center of the bit. I recommend to use transmission speeds not higher than 19200 BPS. In this experiment I used the quite good 9600 BPS (104 uS per bit) with 8 data bit, one stop bit, no parity.

The firmware in C language is available in a fully working folder with all the necessary files to edit / compile / debug the experiment. Please read the starting point for setting-up the working environment at my previous article here.

The program is very simple. You can use any terminal program on your PC as the controller part, setting the communication speed as mentioned before. You have just two valid commands: AT0<cr> to turn OFF the led on the microcontroller board or AT1<cr> to turn it ON. In both cases you will receive an answer “OK”<cr><lf>. Every different input will produce an answer like “Error”<cr><lf>. The max length of the command string is 4 characters. Look at the terminal window:

Firmware description

First of all, we have to set the options bytes in the STM8S001J microcontroller. We connect the SWIM interface and run the ST programmer. We now modify the AFR1 and AFR0 bits in order to remap the UART_TX on pin PA3 (pin 5). The options can be written from the C program in the micro (it’s almost like write to the EEPROM), but for this test we just use the STM programmer, before loading the test program in the microcontroller. This is the screenshot of the modified option bits:

click the image to enlarge

With the microcontroller’s options programmed in this way, we can try to start debugging the test program. The folder that contain all the files can be downloaded from this link: Please expand the zip file using the program 7Z and the password: eficara.

Now, some details about the C source. First of all, we have to set the port PA3 to be output open-drain. When the serial TX transmits a “zero” the line is pulled down from the internal mosfet; when the TX sends a “one” the line is “open”, so the high level is supplied by the pull-up resistor (10K, see schematic). Here are the C source lines:

After this, we set the UART registers to have 9600,N,8,1 protocol in Single wire, half-duplex mode. In such mode, the micro uses only the I/O PA3 for both TX and RX.

Now we create a function to transmit a character on the serial port. Note that every character sent will be received in the same time ! So, I set a flag called echo that will be used in RX interrupt to discard the data just received (such echoed data will not be stored in RX queue).

It’s better to take a look at the RX interrupt to clarify the concept. The serial RX interrupt will save the received data in a circular buffer. If the echo flag is set, the received data is NOT stored, so it is filtered out.

The data stored in the circular RX buffer will be used to fill the command buffer that is asynchronously handled in the main program as part of TimedEvents.

If head and tail pointer of the circular buffer are different, there is some data pending, so the data is taken from the buffer and the tail index is incremented. The received data is then compared with 0x0D (the CR) and if it’s equal, the received command can be executed. Note that the program also tries to execute the program if the buffer is filled (command too long). The command execution is very simple (this is just a proof of concept !). Look at the parser:

So, the accepted commands are “AT0” and “AT1” followed by CR,  that respectively turn OFF and ON the led on PB4. You can read all of the program on the main.c and stm8_interrupt_vector.c files in the project folder. Hope it will be interesting for you. Have fun!

GATC_note – convert text to DNA

Modified: 2018 Jun 30

Many years ago I saw a movie named “GATTACA”. The film was based on a novel where a man with some “defects” in his DNA was excluded from the crew of a stellar mission (due to such defects). That man, using a trick (exchanging his DNA with another one coming from a friend genetically perfect, but unable to walk after an accident) finally was accepted and started his journey to the stars.

Why “GATTACA” ? The answer is simple: the DNA has only 4 elements (I don’t know their exact names, try Google search for full information) named A, C, G, T. Such four elements, sequentially disposed on a “string”, are able to describe THE LIFE. The DNA is like a program with all the instructions to build the life in its wide range of forms.

When I discovered that just 4 letters are used for the “strings of life”, I immediatly thought about a byte. In one byte (8 bit) I can save four symbols. Many years later (three years ago) I realized a small Internet connected device and decided to use a special coding to transmit the data from the microcontroller to the webserver and so I encoded every byte as a string of 4 characters “A”,”C”,”G”,”T” sending the packet as simple ASCII string. Obviously, the byte array was small and was previously encoded with my own key. It was just an experiment, easy to implement in the microcontroller C program and in the receiving PHP script on the server.

Well, last week I have seen on TV that some scientist are studying the way to save huge amount of information on molecular support, using the DNA structure! So, we will have many terabytes of data on a very small organic  support. I don’t know when it can be ready for the public, but is a very exciting idea for data storing. I just can’t imagine how a “reader” for such data can be realized, but in the meantime I decided to write a small App for Android to “translate” a text in “DNA code” form. This is the App icon:

The App is simply a text editor that can convert from text to “DNA code” and viceversa pressing a button. It’s funny and you can save some “sensitive” data on your smartphone with this special encoding. Note that the coding / decoding algorithm is VERY easy and any “decent” programmer will break and decode the text in few minutes, so don’t use this way to store your precious bank accounts! It’s just a funny way to save the data with a “futuristic” look.

Here is the screenshot of a text written in the edit box:

And now, look what happens when I press the button “GATC it !”:

The operation is reversible: if I tap again the button “GATC it!” the “DNA code” reverts to normal text. There are buttons to save / load the files to / from the smartphone’s memory. The files are saved in the program directory that is named GATC_note/. You can save or retrieve files to / from the directory connecting the smartphone to the computer as an USB memory. Note that the files are in Android format, so the line terminator is simply LF and not CRLF as in Windows Notepad.

Modified in GATC_note V0.2 >> Note the “double colon” at the end of the “DNA code”: this is appended by the program as a marker in order to recognize that the text is “GATC code”. I changed such marker from “Black Star” (Unicode 9733 decimal) of previous release to “double colon” in order to make easier editing GATC text (for experiments). I added also a check for the text length (in GATC mode) ‘cause such text must be multiple of 4 in length (4 GATC symbols = 1 Byte). Finally, I modified the text entry in order to avoid that the keyboard can overlap the text (in case of long strings).

Using just one byte for character has a limit: not all the characters in the edit text can’t be decoded. Only the characters with code from 0 to 255 can be represented with 4 characters ACGT. In case of characters out-of-bounds, the program will set a message dialog asking you if you want to accept the limits (changing the extra characters in blanks) or if you refuse to exchange. This is the screenshot of the dialog:

The “load” and “save” buttons are used to save and load files. You can save files in text or DNA format. The only difference is that ANY file that ends with the “black star” is considered as “DNA”, otherways is a text file. Pressing a file name for long time calls the “delete” procedure and you can decide to erase a file from your smartphone’s memory.

The App has been published on my Google Play developer page at this link: It’s absolutely free and without any advertisement. If you find some error or if you wish for new features to add, send me a message. I will try to improve / debug the program in my free time.

If someone has a true DNA to convert with the program and then discovers that the converted data contains some useful instructions to develop a special anti-gravitational machine, please invite me (for free) to the first interstellar journey on a starship that uses such new technology, thank you.

IrSwitch: remote switch uses any TV controller (IR)

After my recent tutorial (in Italian language) for the STM8S microcontroller, I decided to realize a small device using the STM8S001J (8 pins) microcontroller, in order to expand the tutorial itself. This device has a practical application: I don’t live anymore in a B&B, but in a “residence” and I’m going to solve the problems that I face in this new location. The first problem to solve is that I don’t have any switch close to my bed to turn off the lights when I go to sleep. So, I decided to make a remotely controlled switch. Well, I don’t want to build also a remote controller, so I used the one that currently works for the TV.

This remote switch is based on IR reception from any TV controller that has a protocol like the NEC or equivalent. The schematic is very simple as you can see in the picture here below (click this link to download the schematic in PDF format):

The question is: how can I control my switch without disturbing my TV (or viceversa) ? I don’t want to read a specific keycode coming from TV remote; I just want to detect that one key has been pressed (or released), I don’t mind what key.

The algorithm is very simple. Look at these steps:

– define “key pressed” event as an IR burst detected for at least 3mS (the NEC protocol has 4.5mS header, even in repeated keycode). After the header there is the data, followed by a pause (no signal) for at least 20mS.
– define “key released” event as the absence of any “key pressed” event for a certain time.

This part of the algorithm is executed in the TIM4 interrupt (1mS tick). The IRIN is the input connected to the IR receiver TSOP4838 that gives a low output when a 38KHz burst is received.

The next steps are executed in the main program (TimedActions) every 256mS:
– wait for “key pressed” event

If the “key pressed” event arises, the red led turns ON, the state machine goes to the next state and a time counter of 8 * 256 mS is started. In such time no others “key pressed” events must occur or the time counter will be restarted.

– wait for “key release” event

– start a “time window” of 8 * 256mS (with red led blinking) where you can press a key to toggle the remote switch

If a key is pressed in this time, the relay toggles and the state machine immediatly changes to the next step. In any case, this step terminates with the red led off and a delay of 4 * 256mS in which no events are taken.

– close the “time window” and restart from idle

That’s all. The remote switch will be activated by any key pressed on your TV remote control. The red led light will turn on and stay on for all the time you continuously press the key. When you release the key, the red led will blink for 2 seconds and any key pressed in such time will toggle the relay. If you don’t press any key while the led is blinking, the command will be aborted and the cycle will start again. I assumed that when you use the remote control for the TV, you often press the key for a short time (as for program change) or repeatly (such in volume control). Using the “time window” after key released is a good way to activate the remote switch without disturbing the TV and viceversa. If you have on your TV remote control some “special key” that hasn’t any relevant effect on the video, use it ! Obviously, if the TV is turned off, you can use any button excluding the “ON” 🙂 that will turn on the TV set !

The full project folder is available for download from here: IrSwitch. Please, use the 7Z program with password: eficara to decompress it. Look at the STM8 tutorial for the working environment. You have the C sources, so you will be able to improve, modify or completely change the algorithm that I developed for my specific situation. Have fun !

Sviluppare in C per STM8

Di recente ho fatto una ricerca in Internet per trovare il microcontrollore più economico. Tale ricerca è stata effettuata sui siti dei maggiori distributori professionali di componenti elettronici ed il risultato è stato chiarissimo: il micro più economico (per quantità da produzione) è lo STM8.

Le versioni disponibili sono tante, ma rimanendo sul principio del “very cheap”, ho selezionato due modelli. Il primo è lo STM8S001J3M3 (8 pin) e il secondo lo STM8S103F3P6 (20 pin). Per vostra informazione, il secondo si trova anche montato su delle piccole schede di sviluppo, di manifattura Cinese, disponibili on-line a 1 Euro! Sì, con 1 Euro comprate una scheda di sviluppo che comprende: il microcontrollore, una presa microUSB per l’alimentazione, un regolatore di tensione a 3.3V, un pulsantino di reset e un paio di leds. La scheda ha inoltre i connettori “strip” a passo 2.54mm per collegare le vostre periferiche agli I/O disponibili.

Per poter caricare e testare i vostri programmi sul microcontrollore, avete poi bisogno dello strumento hardware che svolge le funzioni di programmer / debugger. Bene, questo strumento (che potete trovare cercando: ST-Link V2) si compra on-line, sempre di produzione Cinese, a meno di 2 Euro! Sì, programmare e fare debug in real-time per meno di 2 Euro! E’ incredibile. Io iniziai la mia carriera sul sistema di sviluppo Intel nel 1977 e ricordo che il “blue box” costava quanto un’automobile di media cilindrata… Se siete curiosi di vedere com’era fatto, potrete trovarlo in una foto del mio ufficio di progettazione (nel 1979) a destra di un me stesso assai più giovane e magro 🙂 Quell’oggetto che sembra un PC, ma non lo è, perché il PC ancora non esisteva, è in effetti il sistema di sviluppo Intel per microprocessori 8080/8085.

Torniamo ad oggi: ho comprato il modulo con il microcontrollore e quello con il programmatore, ma poi ho deciso di montare anche un circuitino tutto mio su una scheda per prototipi. La ragione di questa decisione è la necessità di testare il micro più piccolo, quello con soli 8 pin, che dovrà andare a sostituire modelli analoghi in alcuni miei progetti di produzione industriale.

Il sistema di sviluppo completo. Programmer/Debugger e microcontrollore STM8S001J3M3

Il microcontrollore piccolo (STM8S001J3M3) ha alcune limitazioni e presenta dei rischi. Se programmato con impostazioni errate delle porte di I/O, diventa irrecuperabilmente bloccato e non più riprogrammabile! Questo problema non si presenta con il modello a 20 pin e più avanti vedremo perché.

Gli strumenti software

Ora che abbiamo tutto il necessario per quanto riguarda l’hardware, possiamo pensare al software. Anche in questo caso avremo delle liete sorprese. Tutto (e dico tutto) è disponibile gratuitamente! Abbiamo a disposizione l’ambiente di sviluppo (IDE) e il software per caricare il programma sul microcontrollore forniti direttamente dalla ST e il compilatore C (completo e senza limitazioni) fornito dalla Cosmic. Per scaricare i pacchetti software è necessaria una registrazione, ma è gratuita. Quindi, facciamo i conti: 1 Euro per il modulino di test, 2 Euro per il programmatore e zero Euro per il software di sviluppo… Con 3 Euro possiamo scrivere software in C ed effettuare il debug in real-time. Beh, non è caro! 🙂

Ecco i link che vi propongo per leggere la documentazione (abbondante) e scaricare il software:

-sito principale con le informazioni ed i vari documenti disponibili:

-pagina di download del programmatore STVP-STM8:

-pagina di download dell’ambiente di sviluppo IDE STVD-STM8:

-pagina di download del compilatore C di Cosmic:

Come anticipato, per poter effettuare i downloads sarà necessaria una rapida registrazione gratuita sia sul sito ST che sul Cosmic.

Oltre al software scaricato, conviene procurarsi subito tre PDF molto utili. Il primo è il datasheet del componente e si chiama stm8s001j3.pdf; il secondo è la lista dettagliata dei registri delle periferiche e si chiama RM0031.pdf; il terzo è il manuale di programmazione con le istruzioni assembler e si chiama PM0044.pdf. Inserendo i nomi elencati in un motore di ricerca, troverete i link per il download. Probabilmente l’ultimo file non vi servirà per scrivere applicazioni “normali”, ma se volete capire bene come funziona un micro (qualsiasi micro), date sempre una lettura approfondita alle sue istruzioni assembler, ai modi di indirizzamento, eccetera.


Per prima cosa installiamo il compilatore Cosmic C. Ad installazione avvenuta vedremo che abbiamo a disposizione sia il compilatore per STM8 (completo e senza limiti) che quello per STM32. Quest’ultimo, però, ha un limite di 32K (sufficienti, comunque, per molte applicazioni). Si noti che il compilatore installato ha anche un suo IDE (chiamato IDEA-STM8) e potrebbe quindi essere usato come strumento di sviluppo completo, senza usare i software ST. Io ho deciso di usare l’IDE ST, ma è stata solo una scelta personale. Nulla vieta di utilizzare l’ambiente Cosmic, ma gli esempi che pubblicherò di seguito sono stati scritti per quello ST.

Oltre ad aver fatto la registrazione al sito Cosmic, dovremo ora ottenere la licenza (gratuita) per il compilatore. Per far ciò dobbiamo andare nella cartella dove è installato il compilatore e cercare il programma apposito:

C:\Program Files\COSMIC\FSE_Compilers\CXSTM8\LmregFSE.exe

Ovviamente, il percorso è valido se il programma è stato installato su C:\Program Files. Lanciando l’applicazione, troveremo dei campi da riempire.

Inseriamo quindi i nostri dati e clicchiamo il pulsante On the Web. Riceveremo quindi sulla nostra email un file di licenza da copiare nella directory di installazione del compilatore (notate che ho salvato anche il file lic-data che contiene i dati inviati per ottenere la licenza, giusto per avere un riferimento futuro).

Se non eseguiamo questa operazione oppure se copiamo il file di licenza su di un altro computer, all’atto della compilazione di un sorgente in C riceveremo questo errore (cliccare l’immagine per ingrandire):

Quindi, se cambiamo PC e reinstalliamo il compilatore, dovremo eseguire nuovamente la fase di richiesta della licenza.

Ora installiamo i due software ST che abbiamo scaricato in precedenza e cioè il programmatore e l’IDE. Qui non dovremo effettuare alcuna richiesta di licenza. Al termine di tutte le installazioni troveremo sul nostro desktop tre nuove icone.

Lanciamo l’IDE (icona centrale) e iniziamo a prendere confidenza con l’ambiente. Nella figura sottostante vediamo il programma aperto sullo spazio di lavoro (workspace) chiamato Test. In genere, per progetti semplici come sono quelli da pochi KB di codice, io uso lo stesso nome sia per lo spazio di lavoro che per il progetto. Proviamo quindi ad aprire il tab Project e selezioniamo dalla lista la voce Settings.

Si aprirà quindi la finestra delle impostazioni. Nella figura successiva è mostrato il primo tab (General) relativo alla configurazione Release, cioè quella finale, destinata alla produzione. In alto a sinistra (dove c’è scritto Settings for: Release) è possibile cambiare la selezione in Debug, quella che sarà utilizzata nella fase di sviluppo del programma.

Possiamo lasciare gran parte delle impostazioni standard, limitandoci a scegliere solo il tipo di microcontrollore da usare (tab MCU Selection), permettendo così al sistema di utilizzare i valori di default ad esso collegati.


Ora possiamo iniziare con l’hardware. Lo schema del circuito minimo è quello visibile nella figura sottostante (cliccare l’immagine per ingrandirla).

Come vedete, è davvero molto semplice e si può montare su una scheda per prototipi, utilizzando per il microcontrollore un adattatore da SO8N a DIL, reperibile on-line a costo minimo. Se invece vi dilettate di fotoincisione, potete usare il piccolo PCB che ho disegnato.

Il PDF in scala 1:1 per effettuare la fotoincisione (singola faccia, lato rame) può essere
scaricato da questo link (file Top.pdf)

Come si vede dallo schema elettrico, i (pochi) pin di I/O disponibili sono assegnati a più porte del micocontrollore. Questo significa che i pin sono fisicamente collegati a più I/O in parallelo.Questo non è un problema al momento del reset, in quanto tutte le linee di I/O del micro si settano automaticamente come inputs ad alta impedenza. Ovviamente, se durante la fase di inizializzazione dell’I/O del nostro programma mettiamo due linee parallelate in stato di Output push-pull e diamo ad una il valore “basso” e all’altra “alto”, facciamo una gran brutta cosa! Bisogna quindi fare attenzione. Da un certo punto di vista, il fatto di avere delle linee di I/O parallelate può essere un vantaggio: per esempio, possiamo ottenere da un pin di output una corrente maggiore se pilotiamo contemporaneamente due o più porte. Se usiamo il pin 7 e settiamo le porte PC3, PC4 e PC5 come outputs push-pull (pilotando le linee contemporaneamente tutte alte o basse), potremo ottenere una corrente tripla, rispetto a quella di una singola porta.

Questo può essere molto utile, per esempio, per pilotare un mosfet di potenza. Il problema dei pin parallelati si fa sentire in modo pesante sul pin 8, non a caso il più parallelato di tutti. Ci sono ben 4 porte del micro collegate allo stesso pin e purtroppo è anche il pin di SWIM, cioè l’interfaccia di programmazione / debug, quella che ci permette di scaricare / debuggare il nostro firmware. Cosa succede se nel nostro programma assegniamo ad una delle porte PC6, PD1, PD3 e PD5 la funzione di output push-pull? Semplice: lo SWIM non funziona più e il micro è bloccato per sempre. Ho tentato mille manovre, sperando di recuperarlo (sì, ho fatto un errore anch’io) e non è stato possibile. Ho tentato anche di alimentare il micro sotto la tensione di brown-out per sfruttare il reset in tale condizione, ma non c’è stato niente da fare. Attenzione: se notate, la porta PD5 è usata anche come linea di trasmissione della UART e così se userete la porta seriale nel vostro programma, al momento del set-up del relativo registro di controllo automaticamente bloccherete il micro e dovrete dissaldarlo e buttarlo via (è quello che è successo a me).
La ST suggerisce (fatelo) di inserire all’inizio del programma, proprio al reset, una pausa di circa 5 secondi prima di fare qualsiasi operazione di inizializzazione di porte e registri. In questo tempo lo SWIM funzionerà di sicuro e quindi vi sarà possibile riscrivere un programma opportunamente corretto, in caso di errori. Ovviamente è una cosa un po’ limitativa, perché 5 secondi di attesa al power-on sono inaccettabili per qualsiasi progetto industriale, ma quando questo sarà completamente testato, potrete rimuovere la pausa iniziale di 5 secondi, con la consapevolezza, però, di avere un micro OTP (One Time Programmable). Un vero peccato, specie perché la UART a bordo di un micro così piccolo ed economico è un bel “plus”. Si noti che la UART può essere “rimappata”su un altro pin (il 5, connesso a PA3). Infatti, dovendo usare la UART, la mia idea è stata subito quella di rimappare su PA3 lo UART1_TX eliminando così il problema della sovrapposizione con lo SWIM. Il remap si può eseguire tramite i registri di configurazione (con il programmatore) e quindi credevo di aver risolto i miei problemi. Purtroppo, dopo aver fatto il remap, il segnale di UART1_TX era presente (trasmissione dei caratteri OK), ma la ricezione sul pin 1 (PD6) non funzionava assolutamente. Ho provato in mille modi, cercando di capire perché nessuno dei “flag” relativi alla ricezione seriale o agli errori venisse settato, nonostante le impostazioni fossero corrette (e confermate dai segnali che uscivano regolarmente da TXD). Alla fine sono andato sul forum della ST e lì ho trovato altra gente col medesimo problema. Ho aggiunto la mia esperienza e le mie considerazioni ( e, chiedendo che qualcuno degli esperti tecnici ST intervenisse per dare una risposta, ma non si è fatto vivo nessuno.  Per quanto ne so, al momento, il remapping della UART non funziona. Aggiornamento del 29/06/2018: un tecnico della ST ha risposto al quesito confermando la mia ipotesi. Il pin RX viene anch’esso rimappato, ma su un I/O non accessibile. La UART potrebbe quindi essere utilizzabile solo in modo single-wire / half-duplex. Per usare la UART sul pin “naturale”,  dovete quindi considerare che il ritardo iniziale di 5 secondi DEVE essere inserito, prima di effettuarne l’abilitazione, oppure butterete via un sacco di microcontrollori.
In fase di produzione, quando il ritardo di 5 secondi al power-on sarà inaccettabile, suggerisco di inserire nella routine di ricezione seriale, la decodifica di un comando “speciale”, per esempio +++ e Ctrl-C. Quando il programma riceverà questa sequenza, dovrà disabilitare la UART e rimanere in un loop infinito. In questa condizione sarà possibile usare di nuovo lo SWIM e riprogrammare il micro. E’ uno sporco trucco e sarebbe molto meglio se il remapping venisse risolto o se la porta PD5 venisse mappata altrove (per esempio sul pin 6), ma questo significa aspettare una nuova maschera del chip (se pure qualcuno della ST si convincesse a farla).

Il primo programma

Iniziamo con il primo programma, un classico “led blinker” che ci permette di testare alcune funzioni base, tra cui l’interrupt del Timer 4. L’intera cartella di progetto si può scaricare da questo link. Il file è zippato; per decomprimerlo usare il programma 7Z e la password: eficara.

Mettete la cartella scompattata in una directory di lavoro, per esempio documenti/progetti STM8. Al suo interno troverete questi files:

Cliccate sul file Test.stw e il sistema vi chiederà (dato che l’estensione .stw non è associata) con quale programma volete aprire il file. Allora andate sul percorso evidenziato nella figura sotto e scegliete l’IDE della ST.

A questo punto l’IDE si aprirà e subito vi verrà richiesto dove si trova il file di licenza del compilatore C Cosmic.

Cliccando next si aprirà un dialogo di navigazione dei files e voi andrete a specificare la cartella License che abbiamo visto in precedenza. Fornito il percorso verso il file di licenza, tutto è pronto all’uso. Colleghiamo quindi ad una porta USB il nostro programmatore / emulatore compatibile ST-Link V2. Verrà subito riconosciuto dal sistema e il driver verrà scaricato da internet. Associamo quindi il debugger all’IDE cliccando sul tab Debug Instrument.

Ora siamo pronti. Nella finestra a sinistra troviamo i files sorgenti in C che sono inclusi nel progetto e che sono main.c e stm8_interrupt_vector.c. Clicchiamo sull’uno e sull’altro ed entrambi verrano aperti nella finestra di edit a destra, con due differenti tabs. A questo punto lanciamo la compilazione cliccando il “compila tutto”.

Se tutto è stato impostato correttamente, non avremo errori di compilazione. Ora colleghiamo il nostro circuito di test all’emulatore ST-Link. Useremo i 3 fili GND, SWIM e 3.3V (oppure 5V). In questo modo il circuito verrà alimentato direttamente dall’emulatore. Si noti che l’emulatore ST-Link V2 “vero“, quello di serie fornito dalla casa madre, NON ha l’uscita di tensione attiva, anzi, presume che il circuito sia alimentato dall’esterno. Questo è certamente più corretto, in quanto la circuiteria interna deve “adattarsi” alla tensione di alimentazione del DUT (Device Under Test). Nel nostro caso, abbiamo speso poco e ci accontentiamo di una soluzione tecnica meno precisa…

Avviamo quindi il debug cliccando l’apposita icona.

La versione del programma appena compilata verrà trasferita nel microcontrollore. Al termine del trasferimento potremo avviare l’esecuzione del firmware cliccando l’apposito pulsante (run).

Aspettiamo i famosi 5 secondi che precedono l’esecuzione del programma vero e proprio e poi vedremo lampeggiare il LED sul circuito. Se lampeggia, è tutto a posto. Potremo d’ora in poi sviluppare le nostre applicazioni utilizzando questo bell’ambiente di lavoro completamente gratuito.

Analisi del file sorgente in C

Diamo ora una rapida scorsa al listato dei files sorgenti in C, iniziando da main.c:

Qui vediamo alcune definizioni che uso per mantenere la compatibilità con altri compilatori (per altri microcontrollori) che uso abitualmente. Per esempio, definisco _CLI() come _asm(“SIM”) perché con altri microcontrollori uso questa istruzione per disabilitare gli interrupts; così posso passare più facilmente da un listato scritto per un micro ad un altro modificando solo i define iniziali. Stesso discorso vale per BYTE e WORD al posto di unsigned char e unsigned int. Si tratta quindi di una mera “traduzione”.

Qui ho indicato il file di header da includere. Questo contiene tutte le definizioni relative allo specifico microcontrollore. Bisogna stare attenti al file che si include: se si usa il generico iostm8s.h, per esempio, i registri del timer TIM4 risultano all’indirizzo sbagliato e quindi il timer non funzionerà!

Qui ho definito una costante che userò nel caricamento di un registro del timer TIM4 per ottenere un “tick” di 1mS.

Qui ho definito una variabile bit (boolean) che corrisponde al bit 4 del registro PB_ODR, che è in pratica la PortB (out). In questo modo potrò usare il simbolo RLED per fare riferimento alla linea di I/O.

Qui ho definito due variabili BYTE che userò nel programma. La keyword “volatile” sta ad indicare che il compilatore non dovrà fare ottimizzazioni su di esse. Conviene usare sempre questa modalità per variabili che vengono usate sia in interrupt che nel main (contatori, flags, eccetera).

Ecco il “corpo” dell’interrupt relativo al timer TIM4. La funzione viene eseguita con un timing di 1mS. Notate la riga 49, dove il flag relativo all’interrupt attivo viene resettato. Se non lo si resetta, il programma continuerà ad eseguire interrupts a valanga! Nelle istruzioni successive si incrementa un contatore e quando il nuovo valore vale 0 (incremento da 255 +1), viene settato il flag “flag250ms” che verrà usato nel main successivamente. Questo è solo un esempio d’uso, la stessa funzione può essere realizzata in mille modi!

Questa è la funzione chiamata ciclicamente dal main. Il suo nome è TimedEvents perché abitualmente creo una serie di task non bloccanti, ognuno dei quali si occupa di eseguire le proprie operazioni e quindi rientra al main. In questo caso, la funzione ritorna senza fare nulla se il flag250ms non è settato. In caso contrario, il flag viene resettato e viene eseguito il compito “a tempo” (cambio di stato del Led rosso). Si notino le istruzioni _CLI() prima e _SEI() dopo il reset della variabile flag. Per ogni variabile utilizzata sia nel main che nell’interrupt è necessario fare in modo che non ci possano essere scritture in interrupt mentre il main ne sta eseguendo un’altra. Insomma, è un modo come un altro per dare un accesso esclusivo o protetto ad una variabile.

Ecco il “main” vero e proprio. Al reset del micro, si parte da qui. Notiamo una serie di istruzioni ASM che servono per effettuare il famoso ritardo di circa 5 secondi. Il codice avrebbe potuto essere scritto in C, ma ho voluto mostrare come sia possibile utilizzare il compilatore anche per scrivere piccole parti in assembler. Nello specifico, troviamo due loop annidati l’uno dentro l’altro. All’inizio, vengono salvati sullo stack i registri X (16 bits) ed A (8 bit); poi in X viene caricato il valore immediato 0xFFFF e in A il valore 50, quindi il registro A viene decrementato finché non diventa 0 e a questo punto si decrementa il registro X e si torna a settare A col valore 50, fino a quando anche X non arriva a zero. A questo punto i valori iniziali di X ed A vengono recuperati dallo stack e il ritardo è finito. Si passa quindi alla prossima istruzione del codice C.

Nelle linee subito dopo il ritardo iniziale settiamo i valori per i registri che ci interessano. Alla linea 84 forziamo il clock del sistema dall’iniziale 16MHz/8 (2MHz) al più veloce 16MHz/1. Poi impostiamo le porte; non tocchiamo la PortA, la PortC e la PortD perché sono già messe in input automaticamente al reset. Sulla PortB forziamo PB4 a diventare un output, perché ci sarà collegato un led. Attenzione, le linee che possono diventare segnali IIC bus, non sono push-pull, ma open-drain. Dopo l’I/O settiamo infine il timer TIM4 in modo da prendere come prescaler il valore 128 (2 alla 7) e lo forziamo a resettarsi al valore TOP1MS, con il risultato di avere un overflow  (e quindi un interrupt) ogni 1mS.

Infine, ecco il “magro” main loop. Nelle applicazioni “serie”, all’interno del while(1) si mette un reset del watchdog, per fare in modo che le varie funzioni (o i vari tasks) richiamati, siano sotto controllo. Infatti, se una di esse non ritorna al main nel tempo impostato per il watchdog, il micro si resetta e riprende il suo normale ciclo. Ovviamente, è utile tener traccia di questi errori salvando (magari in EEPROM) le condizioni per cui si è avuto un watchdog reset. In un programma ben strutturato, il loop principale sarà sempre una serie di chiamate alle funzioni “concorrenti”, il più semplice possibile.

Vediamo ora l’altro file sorgente che fa parte del progetto: lo stm8_interrupt_vector.c

Alla linea 1 viene definito un nuovo “tipo” di variabile, che è un puntatore alla funzione di interrupt. Poi viene definita una struttura che ci dice che un vettore di interrupt è composto da un byte (il codice ASM relativo alla call interrupt) seguito dall’indirizzo di memoria in cui la funzione è allocata. Ancora dopo, viene definita una funzione di interrupt “fittizia”, che sarà usata per riempire la tabella dei vettori di interrupt nei punti che non usiamo (tutti gli interrupts non utilizzati). Inserendo, in fase di debug, un breakpoint sul “return” (linea 10), potremo accorgerci se qualcosa di imprevisto accade. Per esempio, se abbiamo abilitato un interrupt su un pin di I/O e non abbiamo scritto la relativa procedura, avremo un breakpoint che ci avvisa dell’errore. Infine abbiamo la definizione di _stext() che è la funzione chiamata al reset e che contiene il codice di inizializzazione aggiunto dal compilatore C in base al modello di compilazione richiesto e per ultimo un riferimento alla funzione di interrupt _TIM4_OVF che abbiamo visto sul main. Dato che questa funzione è esterna al modulo stm8_interrupt_vector.c, viene appunto definita come “extern” e sarà il linker ad assegnare l’indirizzo giusto, al termine della compilazione.

E finalmente ecco i “vettori” di interrupt. In pratica, dall’indirizzo 0x8000 (il vettore di reset) a 0x807C (riservato ad irq29) abbiamo una serie di [0x82 0xnn 0xnn 0xnn] dove 0x82 è l’istruzione di call interrupt e i restanti 3 bytes sono l’indirizzo in cui la routine è stata allocata. Un interrupt da timer TIM4, per esempio, provocherà un cambio del program counter dalla locazione corrente verso l’indirizzo 0x8064 con conseguente chiamata della funzione di interrupt. Chiaramente, la chiamata di un interrupt ha come differenza da una chiamata di subroutine qualsiasi, il salvataggio automatico di alcuni registri essenziali, che vengono poi rimessi a posto al termine della routine stessa (anche il return di un interrupt è diverso dal return di una subroutine).


Faccio presente che tutto ciò che ho scritto (a parte i problemi di blocco del microcontrollore) vale anche per gli altri modelli di STM8, basta cambiare le impostazioni del compilatore (scegliendo il tipo adatto nell’IDE) e il file di header selezionato nel sorgente main.c. In futuro, nel mio tempo libero, aggiungerò altri esempi (un po’ più elaborati) di firmware scritto in C per la serie STM8.

A presto…

Invention #6: the (c) WaterShadow

This device is composed by an orange box of 36x24x12 cm. On the top of the box there is a solar cell, capable of charging the internal batteries and powering the electronic circuit inside; in the bottom part there are two small but powerful electric motors with propellers and two ultrasonic sensitive microphones. The internal part of the box is almost all available to the user: you can put in it your car’s keys, documents, usb keys, cellphone, bath towel etcetera. The all box is fully waterproof, thanks to neoprene seals. Another fundamental part of this invention is the wrist bracelet with special ultrasonic emitting capsule. When you want to swim and you have precious things, and you don’t want to leave them abandoned on the beach, put all inside your WaterShadow box and wear the bracelet. Then go into the water and take with you the orange box. When in the water, the box will follow you everywhere, using his double ultrasonic microphones for tracking your emitting bracelet. Have a nice swim and forget any problems.

Special notes:
1) If you swim too slowly, the WaterShadow can overtake you, and sometimes can play an “hurry up” with the embedded loudspeakers.
2) Some californian scientist asserts that the ultrasonic beep emitted by the bracelet can attract male sharks, but I can calm down you, it’s not true. It can attract only female whales.

P.S. Have a nice April First and eat some mellons taken from my tree

Do you want to read more “Probably True” stories ? Take a look at my Probably True Corner

Domenica: imparare codici di radiocomandi sconosciuti

La scorsa domenica ho costruito un piccolo circuito per imparare i codici trasmessi da un radiocomando di cui non conoscevo le caratteristiche. Nel video trovate una breve descrizione del funzionamento. Il circuito è praticamente identico a quello che ho già pubblicato sul mio sito (RxMet1 – ricevitore per sensore esterno Hygro-Thermo a 433 MHz) e sulla rivista CQ elettronica nel 2007. La decodifica del protocollo del sensore umidità/temperatura fu allora molto più difficile, dato che non c’era alcuna informazione disponibile su internet (esisteva la descrizione di un protocollo precedente, ma era totalmente diverso). Quell’esperienza, però, mi è servita a produrre questo giocattolino perfettamente funzionante in un noioso pomeriggio domenicale.

WiFi to IR interface

Last update: 2018-02-25 15:30 (See the note at end)

Once again a project realized in the B&B during my free time, far from home. The circuit described here will be capable to drive almost any device that currently uses an IR remote control, by means of WiFi connection, as to say: with your smartphone. This time I want to show all the route from the idea to the running device. I had the idea some years ago (look at my previous articles regarding IR and WiFi), but I completely forgot it until today.

When I start a new project, there is the first step that I call: “sofa time”. I spend such time lying down on the sofa, without any computer, pen, document or tool. I just think about how to realize the project with the minimal effort.

After this time, I take a block-notes and draw with a pencil (or a pen) a very minimal schematic. In practice, it’s just a brief list of essential connections for the various components that I’m going to use. Here is such minimal schematic:

I don’t need a full schematic, at this time. I will draw it “seriously” with a CAD in the final steps. Well, now I can start building the prototype. First of all I search in my “junk box” what components are available and eventually I change the schematic in order to make it possible to be realized with available components. Usually my laboratory is very complete, but currently I have only few parts, being far from home. This is the prototype, wired on a proto board :

If you are curious to see how this circuit is wired, look at the bottom part :

Note the presence of some SMD components. Sometimes I put such components mixed with the through-hole parts for space saving or just to substitute missing parts of the required value. It’s a simple circuit, but requires soldering skills to be built !

Did you noticed that I used a 16MHz crystal? Did you also noticed that I used a linear 3.3V regulator for powering the microcontroller ATmega88 and the WiFi module ESP-01? Well, there is a mistake ! A 16 MHz crystal is out of specs at 3.3V as you can see in the next picture:

The diagram is taken from the ATmega88 datasheet and says that the maximum crystal frequency at 3.3V is about 13.3MHz, evaluated with dF=(20-10)MHz and dV=(4.5-2.7)V. The nearest value that I have in my junk box is 12.288MHz, then I’m going to replace the component onto the circuit (it will be an easy job).

I plan to power my circuit with a 5V wall adapter, probably a phone charger, but during the tests I will use a Li-Ion battery, just to limit the number of cables on my unfair working place. Note that the LM1117-3.3 IC does NOT stabilize very well with the power supply taken from a Li-Ion battery. Look at this picture taken from the component’s datasheet :

A fully charged battery has 4.2V voltage, so it’s under the minimal dropout at 100mA to have a stable 3.3V output. Consider that the ESP-01 can have current peaks greater than 250mA, so the regulator output may be unstable. This situation will degrade more when the battery discharges to 3.7V (its nominal voltage) and the residual charge is about 10% of the nominal capacity. I used a 100uF capacitor connected to the ESP-01 power lines in order to absorb part of the current spikes in WiFi transmission and if necessary I will increase such capacity. In the “real life” the circuit, powered with a 5V-700mA wall adapter, will work fine ; for this test version I can accept some limitations.

Here is the first version of the circuit schematic (still subject to change):

For a better view, you can download the drawing in PDF format from this link. The pinout for the wifi module ESP-01 in the schematic diagram corresponds to this figure:

Note: if you want to replicate this project, you must program the ESP-01 module to use a 9600 BPS communication speed. There is an AT version created with such default speed on this website: ; go there and look for ai-thinker- You can also alter (in a permanent way) the current communication speed of your ESP-01 module using AT commands. There are two, that works depending upon the version of firmware installed. Try both of them; the first that gives answer “OK” is the right one.

For additional information and useful SW tools, take a look at my previous articles here:
Interfacciare il modulo ESP-01 con una porta USB
AT-commands tool

The firmware – Part 1

At this moment I don’t want to write an App to test the device, so the first version of the firmware contains a very basic webserver, just to check if I can connect to the device with my smartphone using the default browser. The first release of the firmware (about 3 KBytes) is available at this link. The file is zipped with password. Use the program 7Z with password: eficara to expand it. The zip contains the .hex file to program the micro and the following image for the fuses map:

When the microcontroller has been programmed, you can try to check if it works. First of all, connect your smartphone to the AP that is presented by the Esp-01 module. You will be informed, obviously, that you are NOT connected to the Internet:

Note that the last 6 characters of the AP SSID will differ from the ones showed in the image, being the representation of last 3 bytes of the MAC address of the module and also the ESP_  part can differ if there is another release of the AT firmware in the module.

After connecting your smartphone to the Esp-01 AP, you can open the default browser and navigate to the single page available on this minimal webserver implementation. Here is an example:The page is always located at (the Esp-01 IP) /cmd.htm (the single implemented web page) and the command ?k= followed by 4 hexadecimal digits. You will receive an html page with the same hex digits. This is just for test purposes. Please note that the hex digits that you will use in your requests must be in capital letters, or you will receive wrong answers:IR protocols – Tools

Now I must indagate the IR protocols that I want to use in this device. Many, many years ago, I realized an IR protocol analyzer under MS-DOS using Borland C and some subroutines in Asm 8086. It worked  with direct I/O control of the pins of a COM port. Here is the hardware I used for IR protocol analysis:

At the left, the “receiver” part ; in the middle, a more recent wired prototype used with a microcontroller and at the right the “transmitter” part, from  the same MS-DOS tools suite.

Well, I will NOT present here such old MS-DOS programs because I have found on the internet a great page published by Ondřej Staněk at this link: that has a freely downloadable tool that is much more complete and powerful than mine. It works under Windows and the involved hardware is very simple to build. Here is a screenshot of the program running on my PC:

The software uses the MIC (audio) input of your PC / Notebook to capture the IR signals from a remote controller. You can use a simple photodiode like this :

My interface, mounted on a 3.5 mm stereo jack

Or, if you can’t find the photodiode, you can try with a normal IR emitter (LED) using this circuit. I made it ‘cause I haven’t any photodiode in my “mobile laboratory”, but I have an IR emitter (LED) mounted on a small proto-board. I tested this unconventional circuit on my notebook and after a couple of tries it worked (the previous screenshot was taken with this interface).

Another detector that uses a normal IR LED as receiver. Don’t consider the other components on the board. Those parts are from another circuit !

Here are some audio settings I used on my notebook in order to make it work:

Here is a list of some articles on my website about the IR remote controls:

WM8650 tablet as remote control for Sony TV
Using Android tablet as SIRC remote control (#2)
General purpose infrared remote control receiver with RS232 output
Usare lo smartphone come telecomando TV
Un altro telecomando TV per smartphone Android

The firmware – Part 2

Well, I finished this project or, better, this “proof of concept”. It works, I can control my TV using the browser of my smartphone. The IR protocols used here are NEC and RC5. Due to the low power of IR led, driven directly by uC Port with a single resistor, the distance from the device to the TV (or other apparatus) will be 1 meter max. Add a transistor interface if you want long distance.

Note (Feb, 25 2018): I tested the circuit in the picture below and the distance now is over 3.5 meters. I can’t test if it works over 3.5 meters ‘cause my B&B room is very small !

One reader from Hackaday proposed to use multiple output pins in parallel to drive the IR LED with more power.  It’s a good idea, but the software needs to be modified ‘cause I used the SBI I/O,#bit and CBI I/O,#bit instructions respectively to turn OFF (remember, negative logic for LED) and ON the port bit.

Part of the C source (commented ASM listing) – Section: Nec protocol – Xtal: 12.288MHz – Interrupts: disabled

Controlling multiple port bits at the same time needs the OUT I/O,R instruction. Using the OUT instruction also involves to get the port status (in order to save other bits not used for IR led) and save it to 2 different registers, one to be used when you want low level on the IR outputs and the other when you want high level, without affecting the “non IR led” bits. Such approach changes the number of clock cycles needed to generate the 38KHz (Nec) and 36KHz (RC5) frequencies.  This is absolutely not difficult to realize, but at this moment I closed my test firmware, so the transistor solution is simpler.

At power-on (reset) the microcontroller automatically sends one command for testing the NEC and RC5 protocol as you can see in the Main procedure.

After sending the test commands, the main procedure loops in the wifi section (function: Parameters) waiting for commands from any browser. The same IR code used in the test procedure can be sent with the smartphone, with the same  effect.

The command 0x0408 (address, 0x04, cmd 0x08) turns on  or off the TV in my B&B room 🙂 This is the screenshot of the IR tester, splitted in two parts ‘cause is a bit long:

In the Main procedure there is also a transmission of one RC5 code. This is the screenshot of the actual code set (RC5 is smaller)

Note that in order to send RC5 protocol IR commands, you must use another string in the browser. In place of: cmd.htm?k= you must use: cmd.htm?r= . This informs the firmware that the following 4 characters (hex) must be used as address and command for RC5 protocol, not for NEC. Please, remember that the standard RC5 protocol has 5 bits address (0x00..0x1F) and 6 bits command (0x00..0x3F). Codes out of the limits will be cut out with a simple “and” operation.

Finally, the new release of the firmware. It’s only 3034 bytes long. In the zip file you can find the .hex to burn the micro and a picture of the fuses configuration. Download the file from here and use the program 7Z to expand it. The password is: eficara.

Have fun !

Note (Feb,21 2018): this article was linked by Hackaday and then I’ve seen many comments there about the “unuseful” ATmega88 micro used in my circuit. Someone assumed (wrongly) that I used the Arduino IDE to create this project ! Well, there is a big misunderstanding. May be that someone leaves his opinion before reading the article or simply thinks that reading the article is just an option. Ok, I just want to make clear that I wrote all the firmware in C language (some ASM code was optimized to C) and without using any “pre-cooked” library for ESP-01 or IR functions. All the webserver via AT commands and the IR RC5 and NEC protocols are mine, not copied from other people’s works. I know that the Esp8266 itself is a fully programmable device, but my target was to use a preprogrammed part (Ai-Thinker ESP-01 module with AT firmware) and just control that part how it comes “out-of-the-box”, without any modification, to create my “proof of concept”. I also know that there is a Lubuntu virtual machine (VirtualBox) with the complete environment to develop C language applications for the ESP8266. I have such VM enabled and working on my desktop computer, at home.

Play with colors (not for painters)

First of all, happy new year ! Another boring weekend in this B&B and another game realized for Android smartphones. It’s a well known game. The machine creates a combination of four colors (on a six colors palette) and you have to find the right combination in max 12 attempts. Every attempt has an answer that is a white dot if there is the right color in the right position or a black dot if there is a right color in a wrong position. Obviously, if the selected color isn’t part of the combination, no black or white dot appears.

The game icon as it appears on Google Play

The application is free and without any advertisement. It’s a present, so -please- don’t leave evil comments if you don’t like it !

Google Play link:

Screenshot of the game running

The buttons on the right are used to select the color you want to add to your try. The [ C ] button clears an entered combination in case of errors. The [ Ok ] button accepts a combination, so the machine can answer with the results. The button [ nuovo codice ] generates a new random colors combination. The small orange arrow at left is a pointer to the list of attempts. If you don’t find the solution in 12 attempts, the machine will show you the result with a short animation. The program exits after 10 minutes of continuous play time. This is ‘cause you must rest after such time ! Obviously you can restart immediatly, but I suggest to not spend too much time playing with your smartphone, with your eyes focalized always at the same distance. So, after 10 minutes, take a rest ! Look out of the window !

I did the first version of this game some years ago, for the iOS environment, using a software tool called DragonFire SDK. You can read an article I wrote about this tool at this link: Following the link, you can also find a downloadable executable (runs like an iPhone emulator) to play the game on any Windows PC. The source file written in Visual C++ is included in the packet. Note that the libraries sold with the DragonFire SDK are NOT included ! The source file may be useful to see how the program works. The software tool was able to translate the Visual C++ source in iOS Objective-C source and compile it on remote Mac machine, giving as result the App ready for the market.

In case of errors or suggestions contact me by email and in my free time I will try to update the App. Have fun ! Bye.

Micro PLC – 2 In 2 Out

Questo progetto ha un’origine molto “antica”. Realizzai la prima versione nel 2001 per due prodotti commerciali su microcontrollori Mitsubishi M16C (oggi Renesas). Poi, nel 2007 ne feci una versione molto ridotta con il micro Zilog Z8 ; venne anche pubblicata sulla rivista CQ Elettronica (vedi pubblicazioni e Successivamente (nel 2013) modificai, semplificandoli ancora, il circuito e il firmware per un amico che aveva la necessità di fare dei “programmi” per saldare delle gabbiette di fil di ferro. In sostanza, a lui serviva qualcosa che fosse azionato da uno o due pulsanti e che potesse azionare uno o due relè con tempi programmabili per attivare la saldatrice. Per realizzare l’oggetto, utilizzai un display LCD a caratteri 1×16 recuperato da una vecchia centrale d’allarme e un microcontrollore ATmega88 “di recupero”.

Oggi mi ritrovo, dopo qualche anno, ad avere l’esigenza di un dispositivo del genere per me stesso. Ho quindi deciso di “trasportare” il firmware su un nuovo circuito che ha come base una piccola scheda “Nano3” comprata on-line a circa 2 Euro. Il microcontrollore è l’ATmega328P, che ha molta più memoria del precedente ; tuttavia, ho modificato il programma solo per lo stretto indispensabile, senza sfruttare le più ampie possibilità offerte dal nuovo hardware. Anche se la board Nano3 è venduta come “compatibile Arduino”, il firmware è scritto esclusivamente in C e viene trasferito nel microcontrollore attraverso il connettore ICSP senza l’uso di bootloader. Nella figura sottostante potete vedere come si presenta l’oggetto:

Appena acceso, il display mostra due opzioni: ESEGUI o SCRIVI. La prima manda in esecuzione il programma che è stato precedentemente registrato nella memoria EEPROM del microcontrollore ; la seconda ci permette di inserire (scrivere) il nostro programma tramite i pulsantini che vediamo nella foto in alto a sinistra. I pulsanti hanno le classiche funzioni di Up, Down, Left, Right, Ok, Esc con cui si può fare praticamente di tutto…

Se ci spostiamo sul campo SCRIVI con il pulsante Right e quindi premiamo Ok, ci troveremo nel menù di programmazione e potremo quindi scegliere quale programma scrivere. Ce ne sono a disposizione 8, ognuno con un massimo di 32 istruzioni.

Con i pulsanti Up e Down potremo scegliere il numero di programma ; con Ok entreremo nella fase di scrittura delle istruzioni. Vediamo come si compone una linea di programma:

Il programma va da 1 a 8 ed indica una delle 8 sequenze di istruzioni programmabili. Ogni programma può avere un massimo di 32 passi, che vanno da 0 a 31. Ogni istruzione occupa 1 byte delle memoria EEPROM del microcontrollore e così risulta che l’occupazione massima di tale memoria è di 8 * 32 bytes, cioè 256 bytes. Nella EEPROM del micro c’è quindi parecchio spazio ancora libero per aumentare sia il numero dei passi, sia quello dei programmi. Veniamo ora ai codici operativi, le istruzioni vere e proprie. Sono davvero pochi ! Questo sì che è un RISC (Reduced Instruction Set Computer) !

Organizzazione dei codici operativi nel file sorgente in C

Vediamo tutti i codici in dettaglio:

- ACCESO   (operando R1 o R2)
- SPENTO   (operando R1 o R2)
- ATTESA-A (operando S1 o S2)
- ATTESA-C (operando S1 o S2)
- RITARDO  (operando da 01 a 99)
- RIPETI   (senza operando)
- FINE     (senza operando)

[ACCESO  ] - è il codice operativo per accendere un relè.
           L'operando può essere R1 (relè 1) o R2 (relè 2).
[SPENTO  ] - è il codice operativo per spegnere un relè.
           L'operando può essere R1 (relè 1) o R2 (relè 2).
[ATTESA_A] - è il codice operativo per attendere che uno
           switch (input) sia aperto.
           L'operando può essere S1 (switch 1) o S2 (switch 2).
[ATTESA_C] - è il codice operativo per attendere che uno
           switch (input) sia chiuso.
           L'operando può essere S1 (switch 1) o S2 (switch 2).
[RITARDO ] - è il codice operativo per attendere un certo tempo.
           L'operando può andare da 01 a 99 ed indica il tempo
           d'attesa in passi da 0.1 Sec.
[RIPETI  ] - è il codice operativo per ripetere il programma a
           partire dalla prima istruzione.
[FINE    ] - è il codice operativo per terminare il programma.

I pulsanti Right e Left servono per muoversi tra i campi Passo, Codice Operativo e Operando, mentre Up e Down per modificare i valori relativi al campo interessato. Il pulsante Ok accetta a salva l’istruzione corrente, mentre Esc termina la programmazione.

Vediamo un paio di esempi:

Programma 2, passo 0: Attesa switch #1 chiuso

Programma 2, passo 2: Ritardo di 40 unità di tempo (40 x 0.1 Sec = 4 Secondi)

Chiaramente, dopo aver scritto un programma, ci verrà voglia di mandarlo in esecuzione ! Per fare questo, ci sposteremo nella posizione Esegui del menù principale e premeremo Ok. A questo punto con i tasti Up e Down selezioneremo il programma da avviare (da 1 a 8) e quando sul display comparirà il numero desiderato, premeremo ancora Ok per avviarne l’esecuzione.

Vediamo ora lo schema elettrico. Per le prove, ho alimentato il prototipo attraverso la presa mini-usb presente sulla Nano3, collegata ad un caricabatterie per telefono. Conviene, però, usare un alimentatore esterno da 6 a 9V collegato al connettore JP1, più che altro per l’affidabilità dei contatti. Sulla Nano3 c’è un regolatore lineare low-drop a 5V con una corrente di uscita sufficiente per questo circuito.

Se stiamo alimentando il circuito attraverso la presa USB e se abbiamo installato il driver per il convertitore USB-Serial presente sulla Nano3 (nel mio caso un CH340G) potremo anche attivare un terminale seriale a 9600,N,8,1 (se non lo avete, qui ce n’è uno scritto da me). Con il terminale collegato, vedremo che resettando la Nano3 tramite il pulsantino presente on-board, apparirà la scritta V171217 che è la release del software (yymmdd – 17 Dic 2017). Per testare anche la trasmissione seriale potremo dare da terminale un ctrl-G (ASCII 0x07) e il buzzer sul circuito emetterà un beep di conferma.

Per una migliore visione dello schema, è possibile scaricare il file in formato PDF.

Veniamo ora al firmware. Il file da programmare nel modulo Nano3 è fornito in formato .hex e sarà inviato al microcontrollore tramite connettore ICSP (6 pin), mediante un tool idoneo. Io uso un mySmartUSB light, ma ce ne sono a decine con prestazioni simili. Come software di “burning” qui ho usato myAvr ProgTool, abbinato al tool hardware.

Per la configurazione dei “fuses”, guardate la riga 11 in questo screenshot del file in C:

Infine, il file .hex può essere scaricato da questo link. Il file è zippato con password. Per decomprimerlo usate il programma 7Z e la password: eficara. Buona sperimentazione !

Your HotSpot is a presence detector

note: USB connector used only to power the circuit

I never connect my devices to “free wifi” hotspots. I’ve seen what a (bad) hacker can do, using one laptop, a battery powered Raspberry PI board and a collection of software tools. He can spy (almost) any smartphone that is connected to the same “free wifi” hotspot.

For this reason, I always use my own LTE 4G connection and my smartphone is always enabled to share such internet connection with my other devices (one laptop, another smartphone and some other) using an access filter based on MAC address of every device. This is more secure than use “free wifi” hotspots and I suggest to everyone the same approach. However, this isn’t the subject of my post.

Having my own hotspot, with the SSID choosen by myself, I can use the smartphone for a lot of nice services. In this article I will describe one of them.

The presence blinker

I’m currently living in a B&B, ‘cause I’m far from home, due to a contract job. When I am in my room, I don’t make too much noise. I just read or write documents; the TV is turned off and also the music is off. So, it happens that other hosts of the B&B, when going out, lock the main door with the key! This makes me a bit claustrophobic! To avoid this unfair situation, I decided to build a flashing light that will be visible from the low side of my room’s door, just to warn the other hosts that I am in my room

I thought about a passive IR sensor, but such devices work only if there is a movement in the room, and I don’t move so often. Also microwave sensors based on Doppler effect work in the same way; they activate the output when there is a movement. Finally, I decided to use my smartphone as a presence detector… I built a small device based on the well known ESP-01 module. This device has an ATtiny2313 microcontroller and a blue led (high luminosity) that blinks when I am in the room (with my smartphone). When my smartphone goes out (with me) the led stops blinking…

The working principle is very simple. The microcontroller sends AT commands to the ESP-01 to get the list of active hotspots in the area. One of such hotspots is my smartphone, so the SSID string is taken and compared with the one programmed in the internal flash memory. If the two strings match, the led blinks; otherwise the led remains off. So simple…

Note that no connection is active between the module and the smartphone; there is only a periodic check of the visible hotspots. This timed check happens every six seconds and the led lights for 250 mS each time (if your SSID is found).

Note that the SSID of your smartphone must be programmed in the flash memory of the microcontroller (the default is “myHotspot_15car”) so I added an application for PC that modifies the original .hex file to change the default SSID to the one that you like. The max number of characters allowed for your SSID is 15. This limit comes from the low amount of ram memory available on the ATtiny2313 microcontroller (just 128 bytes). Remember that you can choose your SSID in the smartphone using the appropriate menu, so write down one that has max 15 characters and the job is done. Another limit imposed by low ram resources (lack of buffers for serial communication), is that you must program the ESP-01 module to use a 9600 BPS communication speed. There is an AT version created with such default speed on this website:

go there and look for ai-thinker- You can also modify (in a permanent way) the current communication speed of your ESP-01 module using AT commands. There are two, that works depending upon the version of firmware installed. Try both of them; the first that gives answer “OK” is the right one 🙂

For additional information and tools, take a look at my previous articles here:

You could also look at another my article, that was the “starting point” for this project. There you can find a downloadable executable and the relative source program in FreeBasic. It can be useful to better understand how it works. The link is:

Someone can say: “Hey, I can program the same SSID on my smartphone and fool your device so it thinks that you’re in the room, while you aren’t” ! Then I can answer: “so, I will add to my firmware a check of the WPA2 password of my hotspot, that’s invisible to you” ! Such password check option opens the road to many applications where your smartphone will be the key to unlock your car, your door, to turn on lights at home and every thing you want, simply having it near to you. No buttons to click, no Apps to run, just the “native” HotSpot feature active. It’s easy !

In the downloadable file you can find the .hex file that must be programmed in the microcontroller and the .exe that allows you to insert your SSID in the flash memory, prior to program the micro ! The firmware is very small (less than 1 Kb) and has been written in pure C without any special library.

The schematic of the device is simple. Here below there is a picture of it. You can also download it in PDF format for a better view (click this link).

Disclaimer of Liability.
The program or software described, freely downloadable from the site, has to be considered a free “demo” and therefore the author Emilio P.G. Ficara will not provide any support nor will be responsible for any problem, damage, or consequence that may occur during download or execution of the application.

By clicking this link to download the file, you implicitly declare that you have read and understood the non-assumption clause and to accept it.

Always check the MD5 checksum for the files you download! In this case, it must be FC211B2DCBF05C7874489AC32C7D9641 . If it is different, the file is corrupted or is not the original one, so do not unpack it and throw it away! If it is all right, you can unzip it (use the 7Z program with the password: eficara).

You can also run the executable on a USB memory stick as it does not need installation, being a pure executable.

Have fun !!!