domingo, 18 de dezembro de 2016

Fotolito com impressora laser e toner compatível

Alguns de vocês já devem ter tentado fazer placas de circuito impresso. Alguns já devem ter ficados cansados de sofrer tentando fazer transferência térmica com ferro de passar roupa e resolveram partir para outros métodos mais confiáveis e consistentes, como o uso do Dry Film e da Tinta Fotossensível. Pessoalmente, escolhi o Dry Film no começo porque não queria construir uma centrífuga ou comprar um aerógrafo. Alguns dry films podem ser laminados a frio na placa cobreada (como o Kolon Accuimage, que é vendido no Mercado Livre pelo Ricardo Trombeta, do Engenharia Caseira), bastando aplicá-lo debaixo d'água, eliminando todas as bolhas e esperando secar (eu secava debaixo do notebook, com uma toalha entre a placa e o notebook para não marcar o dryfilm). Também existem alguns vendedores no Ali Express que vendem um filme diferente, que só funciona se for laminado a quente. Se você tiver uma laminadora são ótimos, pois são baratos e a placa estará pronta para exposição entre 2 e 5 minutos, dependendo da sua habilidade em aplicar o filme sobre a placa cobreada. Você dificilmente vai conseguir fazer isso de primeira, então o fato de ser um filme mais barato também é um ponto positivo.

Usando dry film ou a tinta fotossensível você inevitavelmente precisará de um fotolito: nada mais do que uma máscara com o desenho das trilhas do circuito em negativo. Ou seja: onde você quer que o filme (ou tinta) polimerize você vai deixar passar a luz (lâmpada germicida, luz negra, flash, ou o próprio sol de um meio dia sem nuvens). Onde você não quer que exista cobre você vai bloquear a luz... e é aí que o problema começa! Se você já imprimiu em transparência, já deve saber que é praticamente impossível conseguir uma cobertura 100% opaca nas áreas pretas. Alguns costumam fazer sobreposições, imprimindo várias transparências e colando todas elas com superbonder para tentar obter um preto 100% preto. Tentei fazer isso uma única vez. O resultado foi uma verdadeira meleca: não só o toner não aderiu totalmente à transparência (que o vendedor disse que era para impressora a laser...), como o superbonder que utilizei para tentar colar as camadas encostou no toner, derretendo o mesmo instantaneamente.

Depois da falha desastrosa com a transparência, descobri que é possível fazer o fotolito usando papel vegetal escolar. Pelas minhas experiências, o melhor tipo é o de 65 a 70 g/m². Abaixo disso também funciona, mas a impressora acaba amassando o papel. Com o toner original o resultado é aceitável, e a maioria das minhas primeiras placas foram feitas assim, sem nenhuma espécie de tratamento do fotolito. Mas aí o toner original que vem na impressora acaba, e você vai trocar. Por outro original? Não, por um "compatível", que custa mais ou menos 30% do original. O toner compatível pode até ter uma qualidade de impressão boa, mas o problema é a qualidade altamente variável entre toners de mesmo modelo. Um pode imprimir tão bem quanto o original, outro do mesmo lote pode deixar manchas pretas, riscos, amassar o papel vegetal só em alguns pontos (que se tornam opacas à luz ultravioleta, provocando falhas nas trilhas)... Acaba que você realmente usa só um de três ou mais toners para realmente fazer fotolito, o resto servindo para as impressões diárias (etiquetas de mercado livre, trabalho de faculdade, etc).

Mas, mesmo que a qualidade do traço impresso seja perfeita, sem manchas, ainda existe um problema: as áreas pretas são apenas semi-opacas. Colocando na frente do monitor você consegue ler o que está escrito através do preto. Você faz a exposição, revela, e aparecem várias áreas de filme que não dissolvem na barrilha, por mais que ela esteja quente, por mais que você esfregue, arriscando arrancar trilhas inteiras. Não tem jeito, não é mesmo? A solução é comprar uma impressora a jato de tinta e usar tinta pigmentada, ou comprar algum papel especial que custa 100 reais por 50 folhas, ou montar um plotter UV para desenhar diretamente no filme, você pensa.

Máscara de corrosão feita com fotolito sem nenhum tipo de tratamento. Observe que há várias áreas com falhas, onde o filme não foi dissolvido totalmente pela solução de barrilha.

Nada disso! Existe uma solução caseira altamente eficaz e barata: basta tratar o seu fotolito recém-impresso com vapor de thinner!

O material necessário é fácil de encontrar: o próprio thinner, que é vendido em latinhas de 900ml por algo como 10 reais, uma caixa que você possa fechar (você encontra isso em algumas papelarias, lojas de artesanatos e presentes) e alguma espécie de tecido, que você molhará com o thinner. Aquele paninho amarelo de limpeza é ideal para isso. O modo de ação é igualmente simples: você prende o tecido em uma das metades da caixa, de modo que ele não possa cair ou encostar no fotolito (o que borraria todo o desenho), e na outra metade você coloca o fotolito, com o toner voltado para o tecido. Depois você derrama um pouco de thinner no tecido, fecha a caixa, espera entre 3 e 5 minutos e depois disso a impressão estará perfeita. Atenção: o tecido com thinner deve ficar acima do fotolito, caso contrário você pode esperar o tempo que for que não vai funcionar, talvez porque o vapor de thinner seja mais denso do que o ar e acabe se acumulando no fundo da caixa. Além disso, se o fotolito ficar tempo demais dentro da caixa, vai acabar ficando ondulado, mas dependendo da espessura das suas trilhas e do espaçamento entre elas, isso pode não prejudicar a exposição, que você fará pressionando o fotolito sobre a placa cobreada laminada com filme usando algum pedaço de vidro ou coisa parecida.



Tecido com thinner em uma metade, e fotolito na outra metade. Quando fechada, o fotolito deve ficar na metade inferior da caixa, caso contrário não vai funcionar.

E é só isso! Funciona com papel vegetal de 70 g/cm², que é o que eu tenho em casa. Não sei se a técnica também serve para escurecer o toner em impressões em outros tipos de papel ou filme, mas para mim o resultado foi ótimo.

Vejam a diferença:

Os dois vieram da mesma impressora, com o mesmo tonner "compatível"


Não! Isso não é um fotolito, mas uma placa de fenolite após a corrosão. Observe como não há nenhum curto, e a hachura do ground plane (que não tem nenhuma utilidade, mas eu achei bonitinho na hora) está em sua maior parte inteira.



quarta-feira, 7 de dezembro de 2016

Radiocontrole com NRF24L01+

O código é dividido em duas partes: uma pro controle, e uma pro objeto controlado. Nos dois códigos tem um union em comum, chamado "Pacote". O propósito desse "pacote" é permitir que você envie e receba as informações necessárias sem ficar quebrando a cabeça com conversões (ex: como eu faço pra transformar 2 bytes em um int?). O funcionamento é o mesmo que o de um código que eu postei alguns meses atrás, que mostrava como enviar informações "binariamente" pela porta serial, ou seja: sem precisar converter de/para texto em nenhum momento.

Esse é o código do receptor. Nele eu liguei dois servos SG90 (que em breve eu irei anunciar no Mercado Livre), um no pino 3 e um no pino 6. As linhas de código que estão comentadas servem para mostrar o X e o Y do controle em um display de LCD, sendo que eu primeiro fiz o teste com ele para só depois usar os servos.




E esse é o código do controlador. Nele eu uso um módulo de joystick com dois eixos, desses que parecem o joystick do Playstation 2 (isso se não for exatamente o mesmo componente). Percebam que ele não espera resposta nenhuma, simplesmente vai enviando. Acredito que eu poderia usar o enableAckPayload e writeAckPayload no barco para poder receber alguma informação dele sem precisar ficar mudando o modo do rádio, mas por hoje vai ser só isso mesmo.



Em funcionamento:




Eu ainda pretendo transformar isso em um barquinho controlado por controle remoto. Por enquanto as minhas tentativas de fazer toda a parte mecânica não deram nenhum pouco certo, mas nada que uma pistola de cola quente não possa resolver no futuro.

É só isso! Como vocês podem perceber o código é bem simples, mas funciona.

quinta-feira, 20 de outubro de 2016

Fazendo um servidor de arquivos no NodeMCU/ESP8266 usando a memória flash do próprio ESP-12E e mais

Boa noite turminha! Essa é uma postagem dedicada a ensinar como fazer um servidor de arquivos usando o ESP8266/NodeMCU e similares. A maioria de vocês já deve ter rodado o exemplo que chama SDWebServer ou coisa do tipo. No caso, o ESP8266 envia arquivos armazenados dentro de um cartão SD... mas você sabia que também pode armazenar arquivos dentro do chip de memória que vem soldado junto com o ESP8266?

Se você já fuçou por aí, deve ter reparado que o ESP8266 normalmente vem em um módulo com dois CI's soldados. Um deles é o próprio ESP8266, e o outro é uma memória flash de um fabricante qualquer, com uma quantidade de memória qualquer. Existem duas maneiras de descobrir o chip de memória do seu ESP8266: uma delas é arrancando aquela capinha de metal, e a outra é rodando um software que te permite identificar o fabricante da memória flash e o tamanho dela. Agora de cabeça não lembro o nome de nenhum software do tipo, mas nada que uma busca no google não seja capaz de resolver.

De qualquer forma, os módulos ESP8266 costumam ser padronizados. Os ESP12e tem todos a mesma quantidade de memória flash (32 megabit ou 4 megabytes), e como esse é o módulo presente no NodeMCU, naturalmente ele terá 4 megabytes de memória. Se você prestar atenção, vai perceber que existe uma opção na IDE Arduino que te permite escolher o tamanho da memória flash: a opção padrão é 4M, 1M + 3M SPIFFS. Isso significa que o seu código pode ocupar 1 megabyte, e além desse 1 megabyte você pode armazenar 3 megabytes de arquivos e configurações na memória flash, usando o sistema de arquivos SPIFFS.


SPIFFS (SPI Flash File System) nada mais é do que uma forma de escrever e ler arquivos dentro da memória flash do módulo ESP de uma forma parecida com aquela usada para ler e escrever arquivos em um cartão SD. Quando você usa o firmware NodeMCU e envia arquivos .lua, é esse o sistema de arquivos que está funcionando por trás das cortinas.

Pra você usar esse sistema de arquivos quando programa o ESP usando a IDE Arduino (ou a Platformio, que é muito melhor), basta incluir a biblioteca FS.h e adicionar o define FS_NO_GLOBALS para evitar que o nome da classe File na biblioteca SD.h entre em conflito com a classe File que existe na biblioteca FS.h na hora de compilar. Os métodos da classe são praticamente os mesmos.

Enviar arquivos para dentro da memória flash do ESP é fácil: primeiro você cria uma pasta "data" junto com o seu sketch, e em seguida você

Se estiver usando a IDE Arduino: usa a ferramenta ESP8266FS, que é um plugin para a IDE arduino que pode ser baixada no seguinte link :https://github.com/esp8266/Arduino/blob/master/doc/filesystem.md#uploading-files-to-file-system

Se estiver usando a Platformio: aperta F7 e clica nessa opção:


Os arquivos que estiverem dentro da pasta data serão transformados em uma imagem .bin e colocados em endereço na memória flash depois do trecho ocupado pelo próprio programa, de tal forma que se você editar qualquer um desses arquivos e fizer o upload deles, você não precisará fazer upload do programa novamente. Que maravilha, não é mesmo?

Depois que os arquivos foram enviados, você pode lê-los da seguinte forma:

    fs::File arquivo=SPIFFS.open(nome,"r");
    servidor.setContentLength(CONTENT_LENGTH_UNKNOWN);
    servidor.streamFile(arquivo,"text/html");
    arquivo.close();

Fácil, não é? Agora vem o plot twist: vou colocar aqui um exemplo de código que mostra um webserver com SPIFFS e de brinde uma forma de enviar  parâmetros com o método POST e lê-los com JQuery. OBS: para este exemplo, você precisará de três LEDs de cores diferentes. Um no pino D1, um no D2 e um no D3, cada um tem um significado que é explicado nos comentários.


Código fonte do servidor:


Código fonte do arquivo "index.htm", que deverá estar dentro da pasta /data e introduzido na memória flash do ESP


Código fonte do arquivo "setup.htm"


O resultado deve ser alguma coisa assim:




E, em ação...

Um vídeo publicado por Ruy Jorje (@ruyjorje) em


Naturalmente é um exemplo extremamente simples, mas ele pode ser aprimorado. Por exemplo: ao invés de buscar o arquivo .js do JQuery a partir de um servidor do google, você pode colocá-lo na memória do próprio ESP8266. Com um script mais refinado você pode ter um botão que envie um formulário com um único parâmetro (ex: arcondicionado=on, ventilador=off, solenoide=on, etc etc etc) sem precisar recarregar a página inteira. As possibilidades não são infinitas, mas dá pra fazer muita coisa legal.

E por hoje é só!

sexta-feira, 23 de setembro de 2016

Programando a Blue Pill (STM32F103C8T6) pela porta USB usando a IDE Arduino

Boa noite, garotada!



Alguns de vocês já devem ter visto uma plaquinha assim rolando pelo Mercado Livre e outros buracos da Internet. Ela é uma plaquinha com um microcontrolador com arquitetura ARM, 64kb de memória flash e várias outras características legais, além de ser relativamente barata. Ela possui 4 pinos para você programá-la com um ST-LINK V2 genérico, mas você sabia que também é possível programá-la diretamente pelo conector USB que existe na própria plaquinha, usando a IDE Arduino?

Para isso você precisa fazer duas coisas:

1- Colocar os arquivos de suporte da plataforma dentro da pasta hardware da pasta da sua IDE Arduino, instalar as placas "Arduino SAM" no gerenciador de placas e instalar o driver da placa Maple Mini. Como o chip STM32F103 utiliza uma arquitetura diferente da AVR, o compilador padrão (avr-gcc) não vai servir, e é por isso que você instala as placas "Arduino SAM" no gerenciado de placas: esse procedimento realiza o download e instalação do compilador de ARM arm-gcc.

Os arquivos de suporte podem ser obtidos aqui, baixando o galho master inteiro do projeto como arquivo ZIP: https://github.com/rogerclarkmelbourne/Arduino_STM32



A versão mais recente da IDE Arduino (1.6.11 no momento em que este post é escrito) aceita os arquivos de suporte sem problema algum, porém algunas versões (depois da 1.6.5 e antes da 1.6.11) podem não exibir as placas novas no gerenciador de placas.


Descompacte o arquivo Arduino_STM32-master e coloque o conteúdo dele dentro da pasta hardware da sua IDE Arduino.
Selecione a opção "Arduino SAM Boards (32-bits ARM Cortex-M3)" e mande a IDE fazer a instalação. É um download razoável, algo como 100 mbs.
Para instalar o driver que permite o Windows reconhecer a plaquinha quando está em modo DFU (Device Firmware Update, que é o protocolo utilizado para fazer o upload do programa para ela, que é o mesmo protocolo utilizado para fazer o upload de um programa compilado para o Arduino Leonardo), você deve rodar o arquivo install_drivers.bat que vem com os arquivos de suporte da plataforma STM32duino. Depois que você instalar os drivers, a sua placa poderá ser reconhecida como dispositivo em modo DFU sempre que for resetada, permitindo que o programa compilado seja transferido para ela.



Com o driver instalado, arquivos de suporte colocado na pasta /hardware, você já pode programar a sua plaquinha. Para isso, você deve configurar a sua IDE da seguinte forma:


Pronto! Agora você consegue programar a sua placa usando a IDE Arduino, sem precisar de qualquer adaptador ou programador externo. A programação é realizada reiniciando a placa por um pulso na linha D- e enviando o programa compilado em .bin com o dfu-util. Note que às vezes o programa que realiza o upload não consegue reiniciar a placa por software. Neste caso, você deve reiniciar a placa manualmente, apertando o botãozinho de reset quando aparecer a mensagem "Searching for DFU device [1EAF:0003]...".

Observação importante: esta placa pode ser reconhecida não só como um dispositivo de comunicação serial, mas também como dispositivo HID (teclado, joystick e mouse), dispositivo MIDI (você escolhe o tipo de dispositivo na configuração USB Type) ou como nenhum dispositivo (por algum erro de programação, porque você escolheu um chip diferente na hora de fazer o upload, etc...). Neste caso, você também precisará resetar a placa manualmente para colocá-la novamente em modo DFU e poder fazer upload do programa compilado para o chip!

Normalmente o uploader é capaz de reiniciar a placa. Caso isso não aconteça, será exibida uma mensagem dizendo que ele não conseguiu encontrar o dispositivo em modo DFU. Isso indica que você precisará reiniciar a placa manualmente, apertando no botãozinho de reset que ela tem.
Quando o uploader reconhece a placa em modo DFU, aparece essa mensagem, o upload é feito e a placa é reiniciada novamente, executando o programa.

Isso tudo também pode ser feito no Linux, mas o procedimento é diferente. Abordarei esse tema específico em outra postagem. A vantagem de usar o Linux é que a compilação é muito mais rápida, e o upload é praticamente instantâneo.

Parece complicado, mas é simples! Observem a apertada do botão de reset em ação:

Um vídeo publicado por Ruy Jorje (@ruyjorje) em


2- Você precisa, obviamente, de uma plaquinha dessas! Mas não é só isso. Elas possuem um resistor Pull-Up no pino PA12 (que está conectado à linha D- do barramento USB) de valor "incorreto", que pode permitir ou não que o chip seja reconhecido pelo seu computador. Isso pode ser corrigido de duas formas: você pode colocar um resistor de 1k5 entre o 3v3 da plaquinha e o pino PA12, ou substituir o resistor R10 por um resistor de 1.5k. Você só precisa fazer isso se a sua placa vier com um resistor de 10k marcado com "R10".

Ainda não cheguei a receber nenhuma placa desse modelo que viesse com o bendito resistor de 1.5k no pino PA12, então eu simplesmente troco o resistor errado pelo correto em todas as placas que chegam para mim. Feito isso, é hora de gravar o bootloader STM32duino (que é uma derivação do Maple Mini, se eu não me engano) no microcontrolador usando um ST-LINK ou um adaptador USB-Serial. Pra fazer isso você precisa colocar o STM32 no modo bootloader serial, e então fazer a gravação do bootloader novo (generic_boot20_pc13.bin) usando o ST-Link Utility ou o Flash Loader Demonstrator, sendo que ambos os programas você consegue baixar no site da ST (vou colocar o link dos dois no final do post de qualquer forma).

Para quem não quer ter o trabalho de dessoldar/soldar um resistor 0603, este que vos escreve vende essa plaquinha já com o resistor trocado e com o bootloader STM32duino/Maple Mini gravado, bastando que você faça a primeira parte deste post ( Link do anúncio no Mercado Livre aqui. No momento em que este post é escrito o anúncio está pausado pois ainda estou esperando o Correio entregar o último lote que eu encomendei para realizar a conversão...). Assim que este último lote chegar, escreverei uma postagem ensinando a fazer troca do resistor.


Links úteis:

  • Flash Loader Demonstrator: http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/flasher-stm32.html
  • ST-Link Utility: http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link004.html
  • Bootloader Stm32duino 2.0 para a plaquinha Blue Pill (generic_boot20_pc13.bin) pode ser baixado entre estes arquivos: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/STM32F1/binaries

MPU6050 no Maple Mini + Exibição dos dados na interface feita em Processing

No post anterior eu mostrei como enviar dados pela porta serial sem precisar fazer qualquer interpretação de texto e exibir esses dados em uma interface em um sketch de Processing. Usando aquela mesma interface, eu vou exibir dados extraídos de um acelerômetro/giroscópio MPU6050 ligado em um Maple Mini. Pra fazer a comunicação entre o Maple Mini e o MPU6050 eu não usei nenhuma biblioteca além da HardWire.h, que permite que você utilize as duas interfaces i2c da plaquinha separadamente. A comunicação com o MPU6050 é feita basicamente escrevendo em registradores para enviar comandos e requisitando os dados depois.

O programa inclui ainda uma forma bem rudimentar de calibrar o MPU6050. Internamente, é como se o MPU6050 tivesse 6 "molas", e as propriedades elétricas (como resistividade) dessas micro-molas mudam conforme o módulo é acelerado/girado. Como são estruturas microscópicas, já dá pra imaginar o inferno que é produzi-las de maneira consistente. Por isso mesmo é preciso realizar a calibração do módulo. Esse procedimento é realizado enviando valores de offset de cada componente do acelerômetro e giroscópio para o módulo até que, estando em repouso, ele informe apenas a aceleração da gravidade e só um pouquinho de ruído. Há outros "defeitinhos" deste CI que precisam ser contornados, mas só abordarei esse assunto mais pra frente.

Enfim, eis o código:

Depois que a plaquinha está ligada no MPU6050 e enviando os dados pela porta serial, a interface no Processing fica desse jeito:

Displaying data from mpu6050 accelerometer in processing #arduino

Um vídeo publicado por Ruy Jorje (@ruyjorje) em

É isso aí! O próximo post vai ser sobre como enviar as informações do MPU6050 através de um módulo NRF24L01+, empregando uma técnica parecida para transmitir os dados em modo binário!

quarta-feira, 21 de setembro de 2016

Enviando informações pela porta serial em modo binário

Este exemplo é um programa em duas partes: uma é um programa que roda em um Arduino/Maple Mini, e a outra é um programa que roda em Processing. A parte legal do Processing é que você pode baixar a "IDE" dele, programar e executar o seu programa imediatamente, sem ficar escolhendo compilador nem escrevendo makefile. Na verdade ele roda por cima do Java, mas você não precisa se preocupar com nenhuma dessas coisas.

Vou só colocar o código aqui, porque ele é simples e é praticamente auto-explicativo.

Programa que vai rodar no Arduino/Maple Mini:


Programa que vai rodar no Processing:


A técnica utilizada é bem simples: todos os dados estão dentro de um struct, que por sua vez está dentro de um union. Como esse struct tem um tamanho fixo (28 bytes), o meu sistema mestre (rodando no processing) sempre recebe uma estrutura de dados correta, e é só transformar os bytes novamente em floats.
A seguir, duas demonstrações. Uma rodando em um Arduino, e a outra em um Maple Mini, transmitindo dados obtidos a partir de um MPU6050.

Reading data from #arduino in Processing

Um vídeo publicado por Ruy Jorje (@ruyjorje) em


Displaying data from mpu6050 accelerometer in processing #arduino

Um vídeo publicado por Ruy Jorje (@ruyjorje) em

domingo, 17 de julho de 2016

Usando o RTC interno do STM32f103c8t6


Alguns de vocês já devem ter visto essa plaquinha pela internet. À primeira vista parece um Arduino Nano ou coisa parecida, mas se você prestar atenção, descobrirá que o mcu nela encontrado, além de ser muito mais rápido que os Atmega8/168/328, rodando a 72mhz, ter mais memória FLASH do que eles (64k vs 32, 16 e 8) também possui uma série de características muito interessantes, tais como:


  • Bootloader serial permanente (você pode programá-la com qualquer conversor USB-Serial)
  • Funciona em tensões entre 2.0 e 3.6v (ou seja, se você pode alimentá-lo com uma única bateria de lítio)
  • 2 interfaces I2C
  • 3 interfaces USART
  • 2 interfaces SPI
  • Interface USB 2.0 nativa
E outras, das quais o RTC interno se mostra como um recurso interessantíssimo porque basta adicionar uma bateria de lítio ou um supercapacitor ao circuito para que você tenha um dispositivo que saiba que horas são mesmo estando desligado. Para o povo arduineiro, essa tarefa é rotineiramente realizada usando algum módulo RTC externo (como o DS1302, DS1307 e etc), que nesse caso é desnecessário, pois a ST colocou um no próprio MCU!

Tem algum datasheet da ST que explica  exatamente quais registradores devem ser escritos/lidos para que você possa utilizar o RTC, mas o que eu vou fazer aqui é o jeito mais fácil de descobrir essa funcionalidade: pegando um código pronto e adaptando-o de maneira muito sutil. O código em questão é um exemplo que vem com o pacote stm32duino: ele se chama Test_RTClock, e nada mais é do que um pequeno exemplo de utilização da biblioteca RTClock.h (também inclusa no pacote stm32duino).

Para este código funcionar, você precisará de uma bateria de lítio de 3v com o positivo ligado no pino VBAT do seu STM32. Na plaquinha azul (conhecida como bluepill), este pino é identificado com a sigla "VB".  Também é necessário ter instalada a biblioteca Time, para converter o tempo retornado pelo RTC do STM32 (que é o número de segundos que se passou desde algum dia na década de 70) em uma data humanamente legível. É só isso! Nenhum outro componente externo é necessário, além da própria bateria. Note que, para que o seu STM32 seja reconhecido pelo Windows é preciso que ele tenha um resistor pull-up de 1k5 no pino PA12 e que o driver que vem com o pacote stm32duino esteja instalado, mas isso será assunto de outra postagem.

Edit: me parece que o cristal que vem com essa placa é de qualquer frequência, menos 32.768 hkz. Depois de mais ou menos uma hora, o reloginho já estava meia hora atrasado. Modificando o código pra mostrar quantos milisegundos haviam se passado entre uma exibição e a outra, percebi que o valor variava entre 1500 e 2000 (!). O jeito foi colocar um cristal de 32.768 khz adicional entre os pinos C14 e C15. Magicamente, o período de tempo entre uma exibição e outra caiu para 1000 milisegundos exatos, e o relógio passou a funcionar precisamente.





Veja aqui o RTC em ação: