collapse

* Posts Recentes

Dúvida com fonte de alimentação comutada por filjoa
[28 de Outubro de 2024, 21:57]


Motoserra Stihl 120C por dropes
[26 de Outubro de 2024, 19:01]


Shelly em jeito de watchdog por SerraCabo
[24 de Outubro de 2024, 19:24]


Meu novo robô por josecarlos
[06 de Outubro de 2024, 13:33]


Sirene NOVA maluca por dropes
[01 de Outubro de 2024, 18:26]


Transmissão de energia sem fios por dropes
[21 de Setembro de 2024, 16:50]


Spot Welder - O que acham? por jm_araujo
[20 de Setembro de 2024, 09:34]


Fita Isoladora - Tipos ou Qualidades diferentes? por dropes
[21 de Agosto de 2024, 15:53]


Cabo/Tubo? para passar ligação sensores - horta por SerraCabo
[21 de Agosto de 2024, 12:14]


Impressora - Valerá a pena? por dropes
[16 de Agosto de 2024, 17:09]

Autor Tópico: Clock, Humidity and Temperature Sensor  (Lida 4929 vezes)

0 Membros e 1 Visitante estão a ver este tópico.

Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.247
Clock, Humidity and Temperature Sensor
« em: 04 de Fevereiro de 2022, 18:43 »
 

Descrição:
Pequeno aparelho portátil para visualização horária, temperatura e humidade relativa (alternadamente).
Já tinha trabalhado anteriormente com o sensor SHT21 da Sensirion, na construção de um controlador de estufa, é pequeno 3x3mm mas tem uma boa resolução (12/14bit for RH/T = RH0.04 & T0.01), apesar de fazer a leitura com esta precisão, uso aqui apenas uma casa decimal ás limitações do display.
Não foi implementado na programação medições de temperatura negativas, embora seja possível com outro tipo de display.
O sensor foi aqui montado numa placa á parte para minimizar a transferência térmica com a pcb principal (também sugerido na sua ficha técnica), entretanto a sua alimentação só é activada no momento das medições, reduz o consumo e tem maior precisão na leitura.
Desenho do circuito, fabrico da PCB, montagem e programação em 7 dias.

Caracteristicas:
- Microcontrolador atmega8 a 4MHz interno (não há necessidade de precisão aqui)
- Relógio RTC (PCF8563) com recurso a supercap 0.047F para retenção horária
- Possibilidade de acerto horário através dos switchs, modo ADC
- Sensor STH21 alimentado a 2.8V (VDD 2.1V to 3.6V), level shifter através de 2 BS170
- Consumo de 8 a 12mA (depende da intensidade do display)
- Brilho ajustável



Normalmente desenho PCBs de face simples com jumpers, ao aumentar a complexidade por ter uma dimensão fixa, acaba por passar a duas faces. (not this time)
Neste caso resolvi a face superior por meio de fios isolados, estes foram soldados aos rebites, também funcionaria se entrarem nos furos, mas não aconselho a fazer isso, além de poder provocar um curto escondido, nunca se deve colocar mais de um terminal por furo.
Todas as pistas são de 0.35mm, incluindo as de alimentação...
 


Aqui vista superior já com os componentes montados, o LED á direita consome menos de 1mA, ainda ponderei se o montava.
Á esquerda o famoso sensor



Vista inferior, resistências 0805, um pequeno LED á direita para reduzir em 1.7V a alimentação e níveis lógicos do sensor.
 


Demonstração do seu funcionamento (temperatura neste momento, sensor tapado)
 


Acabei por proteger o sensor de poeiras com uma rede, a humidade fica obstruída se for tapado completamente.

https://github.com/pdropes/Clock-Humidity-and-Temperature-Sensor
Simples

ps: clicar nas imagens para as maximizar
ps2: humidade é sem h ?!  ???


Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #1 em: 04 de Fevereiro de 2022, 23:17 »
Boa noite @dropes, fizeste um projeto muito interessante e bem documentado os meus parabéns.
E já me ensinaste uma coisa, que se podem fazer level shifter 5V para 3.3V bidirecional muitos simples com  um FET do tipo N econômico o BS170 e uma resistência externa pois a outra dentro do MCU pois deves ter ativo o modo do pino em Pull Up que não vi no Atmega 8 mas deve ser na ordem dos 2K, certo?
Criares uma segunda alimentação de 3.3 V a partir dos 5 V do pino do Mega só com um LED verde também está engraçado, mas essa eu já conhecia hehehehe :-)

Outra coisa a PCB é branca? Não sabia que haviam PCB’s brancas sem ser a de RF e Microondas as de cerâmica. Podes dar mais detalhes sobre a PCB?

Por ultimo e isto é só uma sugestão, tu tens umas fotos tão fixolas neste post que mostram todo o projeto em toda a sua glória, mas no entanto na página inicial do repositório do projeto do teu GitHub só tens texto e não tens nenhuma foto, apesar de teres um folder de imagens.

Podes incluir facilmente uma imagem no README.md fazendo (substitui o texto descritivo pelos símbolos, só não os coloco aqui para não “marar” a formatação do post ):
“Ponto de exclamação” “Abrir parênteses retos” “frase de descrição da imagem” “fechar parênteses retos” “Abrir parênteses curvos” “Path até à imagem a começar por ponto barra na diretoria onde está o README.md” “ Fechar parênteses curvos”

É como incluir um link no markdown mas tem mais um ponto de exclamação no inicio antes do parênteses.  Podes incluir .png, ,jpg, gif, gif animado e SVG’s. Nos SVG’s existe uma particularidade é que podes colocar um SVG de uma animação que fica engraçado e ocupa pouco nos recursos da página.   

Cumprimentos,
João

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #2 em: 04 de Fevereiro de 2022, 23:51 »
Fui dar uma vista de olhos no código e acabei de ver que programaste o AVR ATMega8 em Basic, tenho de te tentar convencer a experimentares o Rust para AVR, eu ainda não tenho nenhuma experiência de jeito para poder falar de todas as qualidades ou deméritos do Rust para embebidos, mas já estudei uns 50 programas de exemplo do STM32 BluePill e já li quase toda a documentação referente ao Rust para STM32F103, stm32 em geral e para RTIC, fora 3 livros gratuitos nos respetivos sites de Rust para embebidos e posso dizer que o Rust é muito interessante. Já tenho o Rust a funcionar no BluePill, mas ainda não escrevi nenhum código de jeito fora pequenas brincadeiras. Tenciono fazer coisas engraçadas com ele tanto para STM32 e como para Raspberry Pico em Rust embebidos, em Rust normal para PC já devo ter 1 ano e meio de experiência.

Mas AVR também é interessante (O teu chip o AVR ATMega8 é suportado e muitos outros AVR’s também são):

Deixo aqui uns links:

The avr-rust Project Homepage
An open source project adding AVR microcontroller support to Rust.
https://www.avr-rust.com/

AVR Rust Book
https://book.avr-rust.com/

avr-hal - Hardware Abstration Layer
https://github.com/Rahix/avr-hal

avr-hal examples  - Vê o os exemplos para o UNO, isto é da utilização da HAL, por isso deve ser igual para o ATMega8
https://github.com/Rahix/avr-hal/tree/main/examples

Crate avrd - Constants and definitions for AVR microcontrollers
https://docs.rs/avrd/latest/avrd/index.html

awesome-avr-rust
https://github.com/avr-rust/awesome-avr-rust

AVR Device Crate
https://crates.io/crates/avr-device

Obrigado,

Cumprimentos,
João
« Última modificação: 05 de Fevereiro de 2022, 08:54 por blabla »

Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.247
Re: Clock, Humidity and Temperature Sensor
« Responder #3 em: 05 de Fevereiro de 2022, 20:54 »
Boa noite @dropes, fizeste um projeto muito interessante e bem documentado os meus parabéns.
E já me ensinaste uma coisa, que se podem fazer level shifter 5V para 3.3V bidirecional muitos simples com  um FET do tipo N econômico o BS170 e uma resistência externa pois a outra dentro do MCU pois deves ter ativo o modo do pino em Pull Up que não vi no Atmega 8 mas deve ser na ordem dos 2K, certo?
Criares uma segunda alimentação de 3.3 V a partir dos 5 V do pino do Mega só com um LED verde também está engraçado, mas essa eu já conhecia hehehehe :-)

Obrigado pelo comentário  :)
Foi um daqueles projectos em que bastou juntar alguns trabalhos anteriores sem ter de procurar muitas informações.

Já não sei onde fui buscar o level shifter bidirecional, deve ter sido pela internet em 2011.
Neste momento apenas fiz a simulação para comprovar, o mais frequente é usar resistências a contar com as tolerâncias TTL ou um IC dedicado, era o que tinha á mão.


Citar
Outra coisa a PCB é branca? Não sabia que haviam PCB’s brancas sem ser a de RF e Microondas as de cerâmica. Podes dar mais detalhes sobre a PCB?
Estive á procura onde poderia ter vindo esta pcb, infelizmente não encontrei grande informação, apenas esta SEM cobre que parece semelhante:
https://www.tme.eu/en/details/lam100x160_1.0/one-layer-laminates/

Ao cortar não parece ser de fibra de vidro, também não me cheira a baquelite, logo desconheço o material, é mais fraca que FR4.
Tenho de ter mais cuidado a soldar para não manchar ao sobreaquecer, e o tempo de insolação também é diferente (-30%)... lembrei-me, esta foi adquirida na empresa Aliatron, já fechou.
Citar
Por ultimo e isto é só uma sugestão, tu tens umas fotos tão fixolas neste post que mostram todo o projeto em toda a sua glória, mas no entanto na página inicial do repositório do projeto do teu GitHub só tens texto e não tens nenhuma foto, apesar de teres um folder de imagens.

Podes incluir facilmente uma imagem no README.md fazendo (substitui o texto descritivo pelos símbolos, só não os coloco aqui para não “marar” a formatação do post ):
“Ponto de exclamação” “Abrir parênteses retos” “frase de descrição da imagem” “fechar parênteses retos” “Abrir parênteses curvos” “Path até à imagem a começar por ponto barra na diretoria onde está o README.md” “ Fechar parênteses curvos”
Tens razão, não coloquei nenhuma foto na página inicial, foi lapso meu.
Quando o projecto é mais complexo ainda o faço, mas este foi mesmo esquecimento...

Quanto ás fotos costumo abusar mesmo, nesta brincadeira tirei 80, para publicar apenas
4; foi como no projecto "Aperture Science" á 1ª vista parece simples, entretanto foram necessários 7G em 16k ficheiros.

Citar
É como incluir um link no markdown mas tem mais um ponto de exclamação no inicio antes do parênteses.  Podes incluir .png, ,jpg, gif, gif animado e SVG’s. Nos SVG’s existe uma particularidade é que podes colocar um SVG de uma animação que fica engraçado e ocupa pouco nos recursos da página.   
Boa, não sabia que era possível colocar uma animação, agora fiquei curioso.

Fui dar uma vista de olhos no código e acabei de ver que programaste o AVR ATMega8 em Basic, tenho de te tentar convencer a experimentares o Rust para AVR, eu ainda não tenho nenhuma experiência de jeito para poder falar de todas as qualidades ou deméritos do Rust para embebidos, mas já estudei uns 50 programas de exemplo do STM32 BluePill e já li quase toda a documentação referente ao Rust para STM32F103, stm32 em geral e para RTIC, fora 3 livros gratuitos nos respetivos sites de Rust para embebidos e posso dizer que o Rust é muito interessante. Já tenho o Rust a funcionar no BluePill, mas ainda não escrevi nenhum código de jeito fora pequenas brincadeiras. Tenciono fazer coisas engraçadas com ele tanto para STM32 e como para Raspberry Pico em Rust embebidos, em Rust normal para PC já devo ter 1 ano e meio de experiência.

Obrigado pelas referências  :)
Como já comentei aqui, fui buscar rotinas de outros projectos, sim, basic, lembro-me que tive algumas dificuldades em comunicar com o sensor, e isso não queria voltar a passar quando estou familiarizado com o bascom, na necessidade de maior velocidade recorro ao assembler, seja em AVR Studio ou mesmo dentro do Bascom AVR.

No modo geral, o conceito de programação mantém-se semelhante independentemente da linguagem usada, existem porém variações de nomes dos registos ou algo mais particular a cada micro.
Nunca programei micros com mais de 8bits, tenho por aqui um ESP32 mas não me entendo com ele, suporta interface arduino, MicroPython, se calhar até Rust.
Ainda o testei com arduino e funcionou, se bem que me recuso a programar seja o que for com a interface arduino, muito limitada.

Já ouvi falar do BluePill, parece ter potencialidades ás dimensões reduzidas, velocidade e preço.

Citar
Mas AVR também é interessante (O teu chip o AVR ATMega8 é suportado e muitos outros AVR’s também são):

Deixo aqui uns links:

The avr-rust Project Homepage
An open source project adding AVR microcontroller support to Rust.
https://www.avr-rust.com/

AVR Rust Book
https://book.avr-rust.com/

avr-hal - Hardware Abstration Layer
https://github.com/Rahix/avr-hal

avr-hal examples  - Vê o os exemplos para o UNO, isto é da utilização da HAL, por isso deve ser igual para o ATMega8
https://github.com/Rahix/avr-hal/tree/main/examples

Crate avrd - Constants and definitions for AVR microcontrollers
https://docs.rs/avrd/latest/avrd/index.html

awesome-avr-rust
https://github.com/avr-rust/awesome-avr-rust

AVR Device Crate
https://crates.io/crates/avr-device

Obrigado,

Cumprimentos,
João
Excesso de informação é desanimador, não tenho cabeça para tanto (basic mode)  ::)
Vou verificar esses sites

Obrigado eu, João
É sempre bom ler opiniões e dar vida a algo que adoro fazer, electrónica  8)

Cumprimentos
Paulo


Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.247
Re: Clock, Humidity and Temperature Sensor
« Responder #4 em: 05 de Fevereiro de 2022, 21:29 »
Fiz agora um vídeo  ;)

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #5 em: 06 de Fevereiro de 2022, 10:58 »
Bom dia @dropes, dando-te a minha opinião muito sincera, no teu caso em que tu percebes a fundo de eletrónica e a fazes electronica por gosto, tanto a desenhar os teus próprios circuitos analógicos como no uso dos micro-controladores (digitais). Também concordo contigo que Arduino não faz sentido nenhum! Se podes comutar um pino a 20 MHz porque razão às de ficar limitado a comutar um pino a 1 MHz?!?!?!? Se podes aproveitar todo o low-level da hardware porque às de estar limitado somente a trabalhar a “100 Km de altura” por cima camada da abstração da abstração da abstração, enfim acho que me faço compreender. Se podes usar algo de alta performance, porque às-de usar algo de baixa performance!

Eu gostava de te dizer que a melhor solução para ti é o Rust, e talvez até seja senão para alguns chips, mas para outros não neste momento, mas se calhar num futuro a breve prazo.

Mas muito sinceramente tu deves a ti próprio como pessoa com muita capacidade técnica, de tentares utilizar a linguagem standard dos micro-controladores o C. Mesmo que depois não o escolhas usar por alguma razão ou por alguma preferência, mas deverias caso não tenhas essa skill (coisa que não sei se a tens ou não) ficar bom em C. C é fácil de aprender mas difícil de dominar! Mas bolas, tu programas nos dois extremos, ou em Basic ou em Assembly, vais de uma das linguagens mais simples para um dos métodos mais complexos (O Assembly) e assembly já é para duros que sabem bem o que estão a fazer! Independente se o chip é um chip simples pequeno ou um micro ARM Cortex M7 cheio de periféricos!!!!! Fazer programas em Assembly é para duros, por isso não terás problema nenhum em ficar proficiente em C, apesar do C ser uma linguagem fácil de aprender mas  difícil de dominar!

Eu não pretendo dizer aqui que domino de alguma forma o desenvolvimento de micro-controladores mas já programei em vários e já fiz várias coisas diferentes em vários, sobretudo muitas brincadeiras umas mais complexas do que outras. Eu comecei a programar micro-controladores lá para o ano de 1996 ou 1997, algo por ai e foi com os grandes PIC da Microchip com  MCU’s de janela de UV para apagar a EPROM e não a EEPROM. O meu estudo de micro-controladores foi sempre muito autodidata e a ler muitos e muito livros, tudo o que eu conseguia apanhar, apesar de ser de engenharia de informática, tive bastantes cadeiras de eletrónica analógica e digital (incluindo FPGA’s) e sempre gostei da eletrónica, mas não tinha nenhuma cadeira de micro-controladores, mas depois um dia alguém me falou dos MCU’s e eu comecei a investigar sobre eles e gostei muito do que vi! Eram os PIC de 8 bit’s muito simples mas com bons livros na altura! E com muitos projetos engraçados a sair na Elektor que eu estudava que era o que na altura me atiçava a curiosidade! Na altura tinha uma cadeira em que se tinha de fazer dois projetos, um primeiro era um core de um CPU enquanto uma EEPROM que continha micro-código e uma unidade de execução em que se fazia lógica discreta e o segundo projeto era de uma FPGA em VHDL,  eu queria fazer o projeto da FPGA e fiz esse mas o primeiro consegui convencer o professor de me deixar fazer usando micro-controladores e de com isso ainda adicionar muito mais features acho que era o de o controlo de uma bomba de gasolina virtual. E eu comprometi-me a aprender por mim próprio como se utilizavam esses PIC’s e de ficar por minha própria conta e risco nesse projeto! E foi o melhor que eu fiz, fiz uma data de diretas mas consegui por tudo a funcionar na altura ainda tinha um ecrã de 16x2 e tive de mudar a meio do projeto para um PIC muito maior, pois preenchi o espaço todo do meu PIC original. Os tempos de um ciclo de programação com o mini forno de UV eram horríveis quando tinhas de mudar uma letra tinhas de esperar todo aquele tempo e tinhas de ter todo aquele processo. Mas no final correu tudo bem e tive uma boa nota na cadeira.

Resumindo, as famílias de MCU’s e ambientes de desenvolvimento que já usei foram PIC (Assembly e C), NXP ARM Cortex M0, Arduino Uno, Leonardo, Micro, Nano e Mega (ou seja AVR sob Arduino), Já usei AVR diretamente (alguns ATMegas e Alguns ATTiny programados no AVR Studio em C), já programei em STM32 Cortex M3 (F1), Cortex M4 (F4), Já programei em ESP8266, ESP32 e tenho cá um ESP32-C3 (RISC-V) que foi oferta da ExpressIF e que ainda não lhe mexi, mas que promete ser muito interessante para Rust Nativo. Já programei em Blue Pills (STM32F103  Cortex M3 em Rust e em C), já programei num STM32 M4 em MicroPython e já programei poucas coisas em Raspberry Pi Pico Cortex M0+ em MicroPython e em Rust, mas poucas coisas. Cypress PsoC 4 e PsoC 5 (em C na ferramenta da Cypress gratuita).

De todas esta minha (alguma) experiência, acredito que para o teu caso, os que se adaptariam mais aos teus conhecimentos profundos de eletrónica de quem quer construir coisas e as suas próprias placas seria mesmo os AVR, ATMega e ATTiny (tal como tu já os usas, pois eles necessitam de poucos componentes externos para fazer uma PCB mas em vez de programar em Basic e Assembly, eu programaria em C no AVR Studio, como tu bem sabes, são tudo ferramentas gratuitas).

Depois para passar para os ARM eu optaria por aprender os STM32, pois aqui é onde tens mais variedade de chips e dentro destes via as seguintes famílias:

o F1 (ARM Cortex M3),
-Design de chip mais antigo mas boas specs dos periféricos incluindo analógicos e bem documentados.
-A família F1 precisa de poucos condensadores para fazeres a tua PCB, mas ainda são alguns e tem RC clock próprio se não necessitares da precisão de um cristal.
-Chips mais bartatos e tens dev boards por 9 euros + Iva da STM32. (Mauser Electronics ou TME são dois dos sítios onde as encontras)
-O BluePill é um STM32F103 destes, contudo o BluePill que existe à venda ao contrario do original tem chips clones chineses dos STM32 e como tal não é sempre certo que funcionem como os STM32 originais e que estão especificados nos datasheets o que é uma verdadeira porcaria! Pois não existe nada pior do que um datasheet dizer que se colocares um bit a 1 num registo no bit 9 ele ativa uma função mas naquela implementação do clone fizeram de foram diferente ou não implementaram chip, ou não consegue funcionar aquela velocidade! Enfim dá para perceber onde eu estou a tentar chegar com esta explicação. Enfim, desenvolvimento de sistemas embebidos já é difícil, mas com hardware clonado que não se comporta como está descrito na especificação é simplesmente um caos. (programas em C ou em Rust, bem suportados em Rust)

o F4 ( ARMCortex M4 tem floating point e instruções assembly de DSP de FMA)
-Muita velocidade mas para a tua própria board, condensadores como se não ouvesse amanhã, mas muito rápidos, chips mais caros e tens dev boards por 13 euros + Iva da STM32.
-Design de chip mais antigo mas boas specs dos periféricos incluindo analógicos e bem documentados. (programas em C ou em Rust, bem suportados em Rust)

e o G0 (ARM Cortex M0+)
-Muito recente, mais recente do que do F1, vêm substitui-los de alguma forma a 64 MHz, baratos, com melhores periféricos e modo de 16 bit’s nos ADC’s (por averaging por hardware), como é um novo design a ST fez com que fosse o chip com menos condensadores num desenho mínimo de PCB, mesmo a 64 MHz. Mesmo muito interessante. Boa documentação e cursos gratuitos no próprio site da ST tens os links para eles se procurares no site ou no google ou no meu guia de micro-controladores no meu github. (Estes em primeiro lugar e os F1 em segundo lugar. Programas em C ou em Rust são os que eu mais te aconselho para além dos AVR’s que já usas mas em C). (programas em C ou em Rust, bem suportados em Rust)

e o G4 (ARM Cortex M4 tem floating point)
-Estes veem na sequencia dos STMF4, veem substitui-los e são melhores do que esses e necessitam de menos condensadores para fazeres o spin de uma board tua, não tem comparação, os F4 é o planeta do condensador! São mais do que sei lá quantos, vê o reference design para perceberes o que eu estou a dizer.
-São de alta velocidade e já existem cursos gratuitos para eles na ST. Bom hardware com spec de periféricos fantásticos.  (programas em C, acho que o suporte em Rust ainda só está a começar por isso ainda vai demorar algum tempo para que sejam bem suportados em Rust)

STM32 F7 (Estamos a falar de ARM Cortex M7)
-Estamos a falar de mais alta velocidade em que tens de saber muito bem fazer o spin do layout de uma board para que não tenhas problemas, estamos a falar num chip que para ser vendido já está na lista de coisas que não podem ser exportadas/importadas à balda pois entra em possíveis usos militares. Por isso esquece este chip, não vale a pena para os usos normais. Também é mais caro, e as boards dev também são mais caras.
Para fazer uma board é por definição o planeta do condensador! Ainda mais do que o F4!!!!
(Programas em C e não sei qual é o suporte para Rust, não procurei)

As ferramentas de C agora são gratuitas da própria ST, mas aquilo funciona com o Cube para definir os parâmetros e configurações de periféricos e basicamente tens de estar a preencher código entre comentários que te dizem  inicio colocar código aqui e fim de zona de código desta função. E isso faz com que o código fiquei esteticamente muito feio! Sinceramente já fiz mas não gosto do aspeto visual da coisa. Mas é como ele é usado. Também pode usar Keil para desenvolvimento até algum limite pequeno de tamanho limitado de flash (da minha experiência, não aconselho-te esta ultima solução).

Raspeberry Pi Pico
-Dois cores ARM Cortex M0+
Outra boa solução para ti que pode ser boa se souberes soldar SMD bem, é o RaspBerry Pi Pico, em C ou em Rust,  as API’s de C estão bem documentadas e o chip está bem documentado, mas tem de ter uma flash externa caso queiras fazer o layout da tua própria board, tem poucos condensadores. Os pinos não são só 3.3 V não são 5 tolerant como muitos dos STM32 que tem muitos pinos 5 V tolerant. Se fosse a ti usaria mais como dev board de 4.5 euros que podes overvclokar a 420 MHZ cada um dos cores. E vem com 2 Mbytes de Flash externa.
-ADC só de 5 canais, de 500KSamples por segundo em que um é o da temperatura do chip.
-Mas tem as máquinas de estado PIO e isso é interessante.

ESP32
-Usa core Tensilica o que é uma treta para Rust pois este core ainda não é bem suportado, existe um port para Tensilica mas não sei o estado dele.
-Este chip é muito interessante pois tens WIFI e BLE e não é muito caro especialmente nas boards de dev da Express IF originais e nos clones chineses (mas cuidado com os chips de USB-Serial, pois pode gerar confusão no clones).
-Podes programar em Arduino, mas para ti se os quiseres programar faz o curso de ESP-IDT de que falo num outro post recente que é económico e vai a fundo no chip.
-A parte analogica do chip é tão má é de bradar aos céus os tipos da ExpressIF fizeram o pior ADC que eu já alguma vez vi pois não é linear! E funciona mesmo mal!!!! Não mede junto aos extremos da voltagem e de forma genérica não é preciso. A caracterização analógica detalhada não está lá, os STM32 são muito melhores nisso do que a Express IF mas o ESP32 e o ESP8266 são por excelência os chip de IoT, tens WIFI e BLE e ESP-NOW para comunicar entre chips em Mesh, existem alguns com Lora se não me engano.
Apesar de terem 2 cores a performance é inferior a um STM32 F4 ou a um STM32 G4.

Online Course - Learn ESP32
https://learnesp32.com/

ESP32-C3 e C6 (Com core RISC-V)
-Bem suportado em Rust e até existe um suporte nativo mas acho que no suporte nativo exclusivo da Rust ainda não tem as funções de WIFI e Bluetooth a funcionar (O suporte Rust não nativo, faz bindings para o C do ESP-IDT e acho que esse funciona com tudo, mas não tenho experiência com esse).
-Mas este promete muito, quanto a ADC e DAC analógico, bem a Express IF não é o melhor exemplo de periféricos analógicos ou de documentação a caracterizá-los em datasheeet, quanto muito tens a documentação da API e eu não gosto muito disso.
-Mas estes são chips a ter um olho neles pois o suporte para Rust vai ser muito bom no futuro, quando tiverem o WIFI a funcionar.
-As dev boards são muito baratas, os chips são o mais barato de tudo, mas os módulos já com antena para incluir como castelation dentro da tua board são mesmo muito económicos e já trazem tudo é só ligar.
-Estes vêm com debug por hardware incluindo bastando só ligar os pinos do USB, o ESP32 normal não vem com isso.

E prontos estes são os chips que te recomendo da minha modesta experiência e do que eu sei:
C ou Rust:


-AVR Mega e ATTiny 
-STM32G0 e F1 e mais tarde G4 e F4
-Raspberry Pi Pico (dev Board 4.5 euros)
-ESP32-C3 e C6 (Com core RISC-V)

Cumprimentos e votos de um bom domingo,
João
« Última modificação: 06 de Fevereiro de 2022, 12:00 por blabla »

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #6 em: 06 de Fevereiro de 2022, 12:20 »
O que o Rust te faz e obrigar a pensar “up front” em todas as coisas que em C só aprendias depois com muita experiência e que o compilador de Rust te diz, olhe nesta linha A vocês está a fazer isto e naquela linha B, 100 linhas à frente vocês está a fazer outra coisa e essas duas coisas são incompatíveis pois violam regras do modelo do Rust. E isto tudo bem explicado. As regras não são muito diferentes do C ou do C++ bem feito e bem escrito, mas o compilador de C ou de C++ deixa compilar e gerar um programa de algo que não cumpre essas regras e depois o nosso programa pode ter comportamentos diferentes do esperado ou não definidos. Por isso quando mais não seja, aprender Rust torna-te num programador de C ou de C++ muito melhor! Como dizia uma vez um programador muito experiente de C++, o Rust do momento zero me obriga a usar todos os truques de boa programação que em aprendi por experiência em C++ ao longo dos últimos 20 anos, só que neste caso é o compilador que faz o “enforcement”. Existe uma pessoa muito proeminente no Rust o Nikko que uma vez escreveu numa apresentação a seguinte frase:

“Rust, where you get the hangover first!”

E de facto é verdade, pois os problemas aparecem todos (quase todos) quando se está a tentar compilar o código e não depois quando se está a executar o código.

Existe uma brincadeira que os programadores de Rust costumam dizer e que em muitas circunstâncias muitos deles, incluindo eu próprio, já experimentaram esse efeito e é o seguinte…. Em Rust se um programa compila (depois de uma pessoa ter lutado muito com o compilador) normalmente ele funciona à primeira quando é executado e está correto! Pois um programador de Rust conhece mais profundamente o seu programa do que (normalmente) por exemplo um programador de C e muito mais do que um de C++, pois teve de lutar muito mais tempo com o compilador para por o seu programa a compilar e teve de pensar muito mais nesse mesmo código e na sua estrutura, no que ele está a fazer.

Por isso aprender Rust, mesmo para quem não pretende ou não vai usar profissionalmente Rust, faz bem a um programador! E treina-o em boas práticas de programação!
Para além disso, it’s lot’s of fun, daí os programadores de Rust estarem sempre como que a “evangelizar” a linguagem a outros, pois é mesmo uma linguagem que dá mesmo muito gozo programar nela! E é uma lufada de ar fresco nos ultimos 40 anos das mais tradicionais linguagens de programação

Cumprimentos,
João

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #7 em: 06 de Fevereiro de 2022, 12:56 »
Outra vantagem do Rust, é que em Rust tens o Livro do Rust que é gratuito e é bom.
No início quando vens de outra linguagem de programação e estás a ler O Livro, ficas a pensar, como é possível alguém programar assim, com estas regras? Depois pensas que, se já tens experiência de C e  C++ bem feito, que essas linguagens quando bem programadas, também já é muito parecido com isto, pois as regras são de boa programação. E depois começas a fazer os teus primeiros programas e rogas umas pragas ao Rust e em especial ao seu compilador o “rustc”, mas depois começas a aprender a fazer as coisas e depois começa tudo a funcionar e a encaixar-se e começas a gostar de programar em Rust, daí a dar um gozo dos diabos, é só um passinho!

The Rust Programming Language – Free Book
https://doc.rust-lang.org/book/

Cumprimentos,
João

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #8 em: 06 de Fevereiro de 2022, 15:59 »
Nem por acaso, este vídeo saiu há duas horas, tens aqui um vídeo que ensina todos os passos para programares Rust no Arduino Uno, no ATMega 328p, canal de youtube Low Level Learning.

Rust Runs on EVERYTHING, Including the Arduino - Adventures in Embedded Rust Programming


avr-hal
https://github.com/Rahix/avr-hal

E documentação das 3 HAL's em:
https://rahix.github.io/avr-hal/arduino_hal/index.html

tens documentação e as seguintes Hal’s que te vão dar jeito:
arduino-hal
atmega-hal
attiny-hal

Nota: A forma como ele viu o tamanho do programa não é a correta ele viu todos os segmentos, o programa que é flashed no chip é muito mais pequeno, pois não são todos os segmentos gravados, existe uma forma de ver isso com o object dump mas não me recordo neste momento como se faz isso de cabeça tinha de pesquisar.

Cumprimentos,
João

Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.247
Re: Clock, Humidity and Temperature Sensor
« Responder #9 em: 06 de Fevereiro de 2022, 22:45 »
Respirar fundo...

É assim, programação para mim é saber o que estou a fazer e o resultado que vou ter, a compilação e programação do micro deve ser rápida. O pior que posso fazer é escrever todo o programa e depois testá-lo, não vai funcionar por certo e encontrar o problema fica penoso.

Ainda faço umas simulações para confirmar algumas rotinas em que desconfio dos valores ou do tempo que vai demorar a executar com o clock definido.

Sim, gosto de escrever em basic, aliás, é uma linguagem de alto nível e comparei alguns procedimentos ao assembler, faço isso constantemente, posso afirmar que muitas das vezes basic é mais rápido ao código assembler, muitos dos algoritmos que uso não são os mais adequados, e tento perceber onde falhei.

Outras vezes o basic espalha-se ao comprido e demora uma "eternidade" para operações simples, nem sempre isso acontece, é mais frequente quando se usam bibliotecas e os poucos registos têm de manter a integridade (mesmo dentro da biblioteca).
Acredito que isso também acontece com outras linguagens.
Entretanto desconheço de alguém que vá editar uma biblioteca para o propósito, o mais certo é mudar de micro.

Achei engraçada a história dos micros com janela para apagar via UV, ainda hoje existem micros que só dão para gravar uma única vez, sem janela, mais baratos.
Eprons é fácil encontrar, principalmente nas motherboards antigas onde está gravada a bios.
A 1ª vez que li sobre os PICs foi numa revista... Electronique Pratique, época em que a Elektor ainda não existia em Portugal, Basic Stamp se não me engano.
O 1º micro que programei também foi um 8051, lentooooo com uma memória eeprom externa de 256bytes, ainda levava umas boas 100 linhas lol
O 2º já foi um Motorola 68hc11, posso dizer que aquele bixo é a coisinha mais sensível á estática que já encontrei, avariei dois só de olhar para eles.
O 3º já correu melhor, o 89s2051, 2k de memória fazem maravilhas quando programado em assembler 51 (modo paralelo).
Este último tinha um grande defeito, o núcleo 8051 necessita 12 ciclos no mínimo para cada instrução.
Então foi que me virei para os AVRs.

Tudo o que aprendi de electrónica foi por curiosidade, muita leitura e centenas de revistas; tenho apenas o 12º , estudava, mas não dos livros escolares, comecei a trabalhar aos 19.

Os programas usados em electrónica costuma ser bem dispendiosos, as empresas têm de ter tudo legal, mas para uso particular já não funciona bem dessa forma.
Rust é interessante, ainda estou meio perdido mas com o tempo lá chego.

Obrigado por tudo, e a ver se não escreves tanto, não consigo assimilar tudo  :-\

Cumprimentos,
Paulo

ps: um site que encontrei sobre AVR asm há algum tempo, muito bem explicado: http://www.rjhcoding.com/avr-asm-tutorials.php
« Última modificação: 06 de Fevereiro de 2022, 22:49 por dropes »

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #10 em: 07 de Fevereiro de 2022, 11:18 »
Bom dia @dropes, gostava só de deixar um apontamento que me esqueci de falar nos meus post’s anteriores.

Em Rust existe uma coisa muito boa é que os drivers para os diversos devices externos ex: ecrã de LCD 16x2, ou chip especifico I2C ou SPI ou outra coisa qualquer em Rust funcionam para qualquer micro-controlador pois esses drivers são implementados para funcionar com o camada de abstração de hardware (que é uma interface ou um trait) embedded-hal, que depois é implementada por todas as HAL’s especificas para cada chip, certo? Ora isso faz com que o número de implementações dos drivers para que suportem todas as famílias de chips necessitem de ser muito menores em número para cobrir os mesmos chips e assim tirar-se o máximo partido de um único desenvolvimento de um driver. Ex: Exemplo driver xpto desenvolvido para o trait ou interface embedded-HAL e testado em STM32F1 depois funciona também no F4, no G0 e por exemplo no Raspberry Pi Pico que é um ARM Cortex M0.
Quase todas as HAL’s são desenvolvidas implementando o trait ou a interface da Embedded-HAL para ter esta vantagem, ou seja o número de implementação necessário para cobrir todos os chips com driver é n+m e não n*m, em que n é o número de família de chips e m é o número de drivers.

Exemplos de HAL’s que implementam o trait, para uma determinada família de micro-controladores:
-Todas as HAL’s para todas as famílias dos STM32 implementam o trait/Interface da Embedded-HAL (F0, F1, F4, F7, G0, G4, L0…..),
-A HAL do Raspberry Pico,
-A Hal das famílias da antiga Atmel (atual Microchip) atsamd-hal e atsame-hal.
-As hal’s famílias da NORDIC nRF,
-A família da ExpressIF ESP-IDF-HAL,
-A hal dos Texas Instruments Stelaris e TIVA,
-A hal do hifive,
-A hal da família NXP LPC,
-A hal da família NXP imxrt-hal
-A hal do teensy4,
-As hal’s dos Arduinos mkr1000, mkr4000, mkrzero, nano33iot,
-ATmega32U4-HAL
e muitos mais que eu não tive pachorra para escrever aqui, podes ver todos em

https://crates.io/crates/embedded-hal/reverse_dependencies

Mas acho que as do arduino-hal, atmega-hal e attiny-hal ainda não implementam a interface, talvez no futuro implementem a interface.

Para veres o número de drivers atualmente existentes, vais ao site crates.io (onde estão listados todos as libs de Rust) e procuras pela string “embedded-hal driver” e vais ver que existem neste momento 257 drivers que podem ser usados nestas famílias todas de chips e isso é um “super poder” do desenvolvimento em Rust para embebidos, uma coisa que foi mesmo bem feita em Rust.

E este número está sempre a subir, há umas semanas eram só 223 hoje já são 257 daqui a mais uns tempos vão ser mais de 300 e por ai em diante. Como atualmente está a ocorrer um grande momento atrás do Rust para embebidos, a rapidez com que vão aparecer drivers e a maturidade e suporte das HAL’s especificas dos chips só tende a aumentar a passos largos. 

Obrigado,

Cumprimentos,
João
« Última modificação: 07 de Fevereiro de 2022, 11:21 por blabla »

Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.247
Re: Clock, Humidity and Temperature Sensor
« Responder #11 em: 07 de Fevereiro de 2022, 15:26 »
Boas  :)

Gostei de saber sobre o alcance dos drivers para periféricos.
No meio de tanto hardware, os fabricantes tendem a normalizar a compatibilidade, mantêm os endereços assim como as rotinas, que tenha reparado isso acontece em lcds e memórias, em que os comandos são idênticos (+-um).

O que é um driver afinal, se não a interface entre o microcontrolador e o dispositivo, falarem a mesma língua é essencial (independentemente do hardware interno).

Neste momento estou concentrado em 3 projectos adiados, um deles irá ter um esp32...
Acho motivador ter conceitos do funcionamento e depois por em prática, ultrapassar problemas e desenvolver protótipos únicos.

Este tópico está a fugir um bocadinho do assunto, agradeço o que tens partilhado aqui.
Curiosidade, tens algo realizado fisicamente?

Cumprimentos,
Paulo



Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #12 em: 07 de Fevereiro de 2022, 17:23 »
Das coisa que já fiz em ambiente DIY quase nada está documentado, muito do que fiz foi desenhar, fazer, por a funcionar e depois passar ao projeto seguinte, e já tive uns grandes hiatos entre projetos de eletrónica, mas quase nada de eletrónica que eu tenha feito DIY está documentado. Muitas coisas foram feitas antes de eu levar mais a sério o meu GitHub. Agora estou a tentar voltar aos projetos de eletrónica e desta vez tenciono documentá-los muito melhor. Por exemplo a minha filha tem um monte de caixinhas de eletrónica feitas comigo ao longo dos anos, mas é quase tudo são coisas simples, lá uma ou outra é algo um pouco mais complexo, alguns apontamentos, como de uma vez que fiz uma caixinha pequena com  um PsoC 4. Que tinha umas pilhas que duravam anos e que tocava uma musica mas que depois tinha uns modos de low power e hibernação muito engraçados e que acordava quando se tocava na mesa de cabeceira comum com único dedo ao de leve pois estava a usar o piezo para mais do que uma finalidade e estava a usar um comparador interno da parte analógica do Psoc 4 para gerar interrupções que o acordavam de hibernação se subi-se acima de um certo nível que correspondia a tocar com um dedo na mesa do outro lado da mesa. Algumas tem alguns apontamentos de coisas assim engraçadas, também fiz umas sequências de vários (acho que foram 5) emissores de AM por software de muito curto alcance 2m e só pela piada , culminado com um em PsoC 4 que fazia mudelação em AM uma voz humana, usando uns truques engraçados do PsoC 4. Uma vez também tentei fazer um emissor de FM de curtíssimo alcance 2 metros (só como prova de conceito), mas infelizmente nunca o consegui por a oscilar a frequências que o meu rádio conseguisse receber, acredito que tivesse a oscilar a 300 MHz em vez dos 100 MHz. Também fiz uma board PCB mais complexa para um hackerspace com um colega do altlab que permitia abrir uma porta interna através da introdução de um código num telefone rotativo antigo preto (tipo agente secreto Smarth), em que os números eram detetados e processados por interrupts no IO (devido ao ruído do componente rotativo dos números essa parte tinha uma complexidade louca de timers e de interrrupts com debouncing muito marado e de montes de horas de debug ao osciloscópio), em que tinha um NXP Cortex M0, com uma EEPROM externa onde guardava-mos uma voz comprimida por ADPCM e descomprimida em tempo real para um pequeno amplificador por PWM não me recordo se era ou não um classe D improvisado, que depois saia a voz no speaker do telefone a dizer “Ponha o código s.f.f. !” E que tinha o conceitos de diferentes users com códigos diferentes configurados através de uma aplicação em C# .net.  Não me recordo neste momento dos detalhes, mas acho que tinha um modulo de comunicação também ligado ao NXP M0. Também fiz um projeto durante algum tempo, um protótipo de uma camera acústica feita com 4 microfones e com uma parte analógica maior e com uns algoritmos mais complexos de DSP e com FFT’s que primeiro desenvolvi em Python (até fiz um simulador acústico no PC para os desenvolver e testar, mas isso não está em Open Source) e depois passei tudo para C e os cálculos passaram todos de floating pointe 64 bit’s em aritmética de fixed point. Também fiz com outro amigo um sistema para medir altura de um liquido num recipiente por ultra-sons com um disco de piezo simples na parte de fora de um recipiente, por dois métodos diferentes, quer por frequências de ressonância, quer por reflexão do eco no topo do nível de água.  E muitas, muitas coisas mais em projetos DIY, quanto mais não seja por piada ou para ensinar, divertir e passar um bom bocado a construir coisas com a minha filha. Depois existiram ainda coisas mais estranhas como uma alta voltagem como speakers de plasma a tocar a tocar a banda AC/DC hehehehe esse foi giro! Depois fiz um monte de projetos pequenos só para testar umas ideias como por exemplo o LED envergonhado que é um LED que está ligado e que quando apontas uma luz para o led ele se desliga, quando retiras a luz ele volta a ligar-se. Ou quando tentei fazer com sucesso um LED que se apaga ao soprar mas que não o fiz com um LED SMD microscópico como é normal mas sim com um LED normal e alguns truques. Ou quando fiz um joystick capacitivo a 3D, ou quando estava a tentar detetar a minha filha a passar no corredor ao lado através da parede usando placas de cartão enormes cobertas por folha de alumínio de cozinha, pela piada da coisa e para ela se divertir. Ou quando fiz com um ESP32 e um algoritmo de Machine Learning implementado do zero ligado aos dados de WIFI para detetar a localização, dentro de que divisão da minha casa estava um ESP32. Um certo ano, no Natal decidi fazer um monte de drawAudios em lápis a partir dos componentes para dar à “miudagem” toda da família. Perto de um aniversário da minha filha quando ela era mais pequena num fim de semana fiz um sistema de luzes para cada divisão da casa de bonecas dela, isto com muitos leds simples e um controlo engraçado para cada divisão. Foram mesmo muitas coisas só pelo gozo. Sabes o meu pai foi técnico de eletrónica durante muitos anos e por isso eu “nasci já dentro de uma oficina de eletrónica”, e o meu pai também me queria ensinar tudo e mais um par de botas quando eu era míudo e o por isso o bichinho acabou por ficar.
Para além disso durante algum tempo e já há alguns anos atrás fiz algumas coisas de hardware mais profissional, mas isso já não eram coisas só pelo gozo da eletrónica e  embebidos :-)

Cumprimentos,
João
« Última modificação: 07 de Fevereiro de 2022, 17:28 por blabla »

Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.247
Re: Clock, Humidity and Temperature Sensor
« Responder #13 em: 09 de Fevereiro de 2022, 17:08 »
Das coisa que já fiz em ambiente DIY quase nada está documentado, muito do que fiz foi desenhar, fazer, por a funcionar e depois passar ao projeto seguinte, e já tive uns grandes hiatos entre projetos de eletrónica, mas quase nada de eletrónica que eu tenha feito DIY está documentado. Muitas coisas foram feitas antes de eu levar mais a sério o meu GitHub. Agora estou a tentar voltar aos projetos de eletrónica e desta vez tenciono documentá-los muito melhor.
Fazes bem, eu também não publicava nada e tinha apontamentos espalhados, em cadernos ou no pc, chega ao ponto de não saber por onde andam.

Citar
Por exemplo a minha filha tem um monte de caixinhas de eletrónica feitas comigo ao longo dos anos, mas é quase tudo são coisas simples, lá uma ou outra é algo um pouco mais complexo, alguns apontamentos, como de uma vez que fiz uma caixinha pequena com  um PsoC 4. Que tinha umas pilhas que duravam anos e que tocava uma musica mas que depois tinha uns modos de low power e hibernação muito engraçados e que acordava quando se tocava na mesa de cabeceira comum com único dedo ao de leve pois estava a usar o piezo para mais do que uma finalidade e estava a usar um comparador interno da parte analógica do Psoc 4 para gerar interrupções que o acordavam de hibernação se subi-se acima de um certo nível que correspondia a tocar com um dedo na mesa do outro lado da mesa.
Espero que te tenhas divertido, Psoc 4 parece-me um bom micro de 32b  :)

Citar
Algumas tem alguns apontamentos de coisas assim engraçadas, também fiz umas sequências de vários (acho que foram 5) emissores de AM por software de muito curto alcance 2m e só pela piada , culminado com um em PsoC 4 que fazia mudelação em AM uma voz humana, usando uns truques engraçados do PsoC 4.

Uma vez também tentei fazer um emissor de FM de curtíssimo alcance 2 metros (só como prova de conceito), mas infelizmente nunca o consegui por a oscilar a frequências que o meu rádio conseguisse receber, acredito que tivesse a oscilar a 300 MHz em vez dos 100 MHz.

Também fiz uma board PCB mais complexa para um hackerspace com um colega do altlab que permitia abrir uma porta interna através da introdução de um código num telefone rotativo antigo preto (tipo agente secreto Smarth), em que os números eram detetados e processados por interrupts no IO (devido ao ruído do componente rotativo dos números essa parte tinha uma complexidade louca de timers e de interrrupts com debouncing muito marado e de montes de horas de debug ao osciloscópio), em que tinha um NXP Cortex M0, com uma EEPROM externa onde guardava-mos uma voz comprimida por ADPCM e descomprimida em tempo real para um pequeno amplificador por PWM não me recordo se era ou não um classe D improvisado, que depois saia a voz no speaker do telefone a dizer “Ponha o código s.f.f. !” E que tinha o conceitos de diferentes users com códigos diferentes configurados através de uma aplicação em C# .net.  Não me recordo neste momento dos detalhes, mas acho que tinha um modulo de comunicação também ligado ao NXP M0. Também fiz um projeto durante algum tempo, um protótipo de uma camera acústica feita com 4 microfones e com uma parte analógica maior e com uns algoritmos mais complexos de DSP e com FFT’s que primeiro desenvolvi em Python (até fiz um simulador acústico no PC para os desenvolver e testar, mas isso não está em Open Source) e depois passei tudo para C e os cálculos passaram todos de floating pointe 64 bit’s em aritmética de fixed point.
Também fiz com outro amigo um sistema para medir altura de um liquido num recipiente por ultra-sons com um disco de piezo simples na parte de fora de um recipiente, por dois métodos diferentes, quer por frequências de ressonância, quer por reflexão do eco no topo do nível de água.  E muitas, muitas coisas mais em projetos DIY, quanto mais não seja por piada ou para ensinar, divertir e passar um bom bocado a construir coisas com a minha filha. Depois existiram ainda coisas mais estranhas como uma alta voltagem como speakers de plasma a tocar a tocar a banda AC/DC hehehehe esse foi giro!
Tens-te fardado de trabalhar, não esperava tanto; quando li speakers HV ainda pensei noutros, existem uns altifalantes estáticos, em que uma membrana condutora fica entre duas redes com um diferencial elevado, ao alterar a tensão dessa membrana, ela move-se entre as redes, funcionamento parecido a uma válvula, mas sem vácuo (já experimentei fazer isso, nuns fones, resulta mas os choques desmotivaram-me).

Citar
Depois fiz um monte de projetos pequenos só para testar umas ideias como por exemplo o LED envergonhado que é um LED que está ligado e que quando apontas uma luz para o led ele se desliga, quando retiras a luz ele volta a ligar-se. Ou quando tentei fazer com sucesso um LED que se apaga ao soprar mas que não o fiz com um LED SMD microscópico como é normal mas sim com um LED normal e alguns truques. Ou quando fiz um joystick capacitivo a 3D, ou quando estava a tentar detetar a minha filha a passar no corredor ao lado através da parede usando placas de cartão enormes cobertas por folha de alumínio de cozinha, pela piada da coisa e para ela se divertir. Ou quando fiz com um ESP32 e um algoritmo de Machine Learning implementado do zero ligado aos dados de WIFI para detetar a localização, dentro de que divisão da minha casa estava um ESP32. Um certo ano, no Natal decidi fazer um monte de drawAudios em lápis a partir dos componentes para dar à “miudagem” toda da família. Perto de um aniversário da minha filha quando ela era mais pequena num fim de semana fiz um sistema de luzes para cada divisão da casa de bonecas dela, isto com muitos leds simples e um controlo engraçado para cada divisão. Foram mesmo muitas coisas só pelo gozo. Sabes o meu pai foi técnico de eletrónica durante muitos anos e por isso eu “nasci já dentro de uma oficina de eletrónica”, e o meu pai também me queria ensinar tudo e mais um par de botas quando eu era míudo e o por isso o bichinho acabou por ficar.

Para além disso durante algum tempo e já há alguns anos atrás fiz algumas coisas de hardware mais profissional, mas isso já não eram coisas só pelo gozo da eletrónica e  embebidos :-)
Electrónica tem coisas engraçadas, é sempre bom ter alguém ao nosso lado para nos apoiar e ajudar nas dúvidas mais que muitas.
Fizeste um bom relatório  ::) apresentar vários projectos num único post fico com vontade de perguntar cada pormenor, adoro detalhes  ;D

Fica bem
Paulo

Offline blabla

  • Mini Robot
  • *
  • Mensagens: 258
Re: Clock, Humidity and Temperature Sensor
« Responder #14 em: 09 de Fevereiro de 2022, 18:38 »
Muitas destas coisas já foram feitas já à alguns anos pois acho que já há quase dois anos que não pego em eletrônica e não faço nada de engraçado em eletrónica.

Por exemplo do que me lembro de cabeça do Speaker de plasma, depois acabei por dar a um colega do hackerspace e amigo meu que também fazia coisas em alta voltagem como escadas de Jacob e afins. Não se pode dar uma coisa desta a alguém que não saiba o que está a fazer. Mas de uma forma muito genérica, o speaker de plasma funciona assim, o som sai de um MP3 Player por jack 3.5mm, depois entra dentro de um amplificador de áudio, um LM386, depois tens um circuito com um 555 a oscilar a 40KHz ou algo por aí. Sinal de som inaudível de ultrassons (e é o que a faisca está sempre a tocar quando o áudio está em silêncio) e que depois a oscilação é interrompida (como que “mudelada”) pelo sinal amplificado de som audível a uma frequência mais baixa com a música e é essa que se ouve. O sinal mixado das duas fontes vai à gate de um MOSFET, era um IRF qualquer coisa e depois o FET de tipo N estava a receber 5 A a não me lembro se 12 V ou algo assim e estava a ligar e desligar. O FET no fio que recebia por cima estava enrolado como primário improvisado de num transformador de linhas de uma televisão de cinescópio CRT que depois saia a alta tensão  e o GND para inicialmente e o que eu fiz para dois pregos pregados numa tábua de madeira simples, mas que nesta filmagem já vez com aquela PCB nas pontas dos espigões, onde está a faísca, este filme já foi depois de eu dar o Speaker de Plasma ao meu amigo, e ele fez essa PCB bonita para os espigões, tal como te disse o que eu fiz originalmente tinha já tudo o resto mas estava a funcionar a dar a musica de uma faísca somente entre as pontas de dois dois pregos, mas tudo o resto que vez foi o que eu fiz. Eu para fazer este projeto na altura basei-me em alguns circuitos de alta tensão e depois adaptei e modifiquei tudo para o meu caso e para o que tinha à mão e para os componentes que consegui arranjar.
Mas o final é giro a banda dos AC/DC com o som a sair de uma faísca de alta voltagem.

A ideia de como é gerado o som, também é simples, de cada vez que é gerada um off->on de uma faisca instantaneamente é produzido um arco elétrico que como o ar já está ionizado pela faísca anterior ele segue um path constante. Mas de cada vez que existe um arco é como se o ar explodisse numa micro explosão e aumenta a pressão ao longo da faísca (pensa no traque do mosquito), que quando está em ultrasons não se ouve a 40 Khz, mas quando a frequência é mais baixa (da musica) ouve-se. A micro explosão é o suficiente para fazer mover o ar para fora e depois a pressão atmosférica comprime novamente o ar até chegar uma nova micro-explosão, em ondas de pressão acústica tal como um speaker, só é é terrivelmente ineficiente, tenho a ideia que deveria ser algo como 12 V   5 A ou algo por aí.

Ouve-se baixo, mas o som que se ouve de musica no vídeo seguinte é gravado ao vivo com o speaker de plasma a tocar.

Cumprimentos,
João