Sensores de baixo consumo utilizando MCU 8 bits

[alexandre.mbm]

Este tópico nascera enquadrado na regra 19, como conversação informal sobre um webinário. Movido para a Pizzaria, com as valiosas contribuições técnicas que recebeu em seguida, pôde voltar ao sub-fórum Eletrônica.

 

Este foi o evento de 31/05/2023:

 

Como projetar sensores de baixo consumo utilizando MCU 8 bits – clique!

 

(organizado pelo site Embarcados)

 

Update

 

O link (acima) agora aponta para um memo.

 

  – Gravação: YouTube

  – Apresentação: SlideShare

[.if]

Quase entrei pois num micromomento li 'baixo custo' ... Quem entrar confirme se em algum momento vão dizer algo como: use um pino do mc pra alimentar momentaneamente o sensor - apenas no momento que vai ler.

[alexandre.mbm]

Live foi conduzida por uma pessoa do Embarcados. Durou 1 hora. A aula gravada tinha áudio em inglês com legenda em português. O convidado que falava português era da Artimar.

 

Proposta técnica é fazer desenvolvimento baseado em periféricos, desafogando o software do MCU principal, por exemplo através de mikroBUS.

 

Prototipagem pode ser realizada nas Curiosity Boards:

 

  – Curiosity Nano (standalone)

  – Curiosity Nano Base

        + Click Boards

 

Aplicação "gerador de onda + osciloscópio simples" demonstrou a Curiosity Nano no MAPLAB X IDE.

 

Existe o MAPS, um seletor web de hardware periférico da Microchip. Foi salientado que são produtos robustos, e que trabalharem com 5V, ao invés de 3.3V, fornece uma "margem" para a lida com ruídos.

 

[.if]

Entendi. Achei que iam focar no baixo consumo. Peça autorização para linkar a apresentação no forum pra nós. Fala que fui eu que mandei que eles deixam

[alexandre.mbm]

5 horas atrás, .if disse:

[Baixo consumo?] "use um pino do uC para alimentar momentaneamente o sensor" — apenas no momento que for realizar a leitura

 

Foi mencionado que ter hardware periférico inteligente na placa de sensor — a qual assim se torna "o periférico" por excelência — entrega flexibilidade ao design, pois o desenvolvedor gerenciará dinamicamente a pinagem de MCU conforme a aplicação que estiver carregada.

 

Também foi mencionado, usando outras palavras, que os modos de economia de energia dessas unidades periféricas farão "uma soma econômica" do consumo para um conjunto de sensores.

[.if]

16 minutos atrás, alexandre.mbm disse:

er MCU na placa de sensor

Ah tá... o mc faz parte do sensor e não vai ler o sensor. Se bem que dá na lesma lerda kk

Quando o 'baixo consumo' apareceu na tela imaginei alguns sensores p.ex. pra meteorologia .. algo como um datalogger de temp, pressão, umidade, vento e um monte de etc que tem que operar por meses com baterias.

 

A propósito a ideia de se alimentar um sistema qualquer temporariamente pra não consumir muito foi ideota 100% original de uma era distante. Uma ideota imaginária: se consumir 3.6W por 1 segundo a cada hora o consumo equivale a algo como 1mW. Aumente o intervalo, diminua o consumo

[alexandre.mbm]

3 horas atrás, .if disse:

Ah tá... o MCU faz parte do sensor e não vai ler o sensor.

 

Foi como eu achei que EU tinha entendido. Confundi foi tudo! Assumo que tenho dificuldades em garantir a integridade na apuração de uma apresentação legendada de slides.

 

@.if, saí corrigindo minhas mensagens. Trata-se de hardware periférico através de mikroBUS. Aquela coisa de MCU na placa de sensor foi viagem minha. Mas pode até estar incluído como uma possibilidade de implementação particular.

 

Mesmo usando seus modos de economia de energia, dois uC consumirão mais que um. Óbvio! Não obstante, a noção de modularização em "periféricos que dormem" me parecia interessante, realmente. Eles compartilhariam um barramento e cada um faria seu trabalho desafogando o "dispositivo cérebro". O barramento suportaria múltiplos periféricos. Aliás, o mikroBUS é para viabilizar isso, mas ele não requer "uC periférico", apenas "inteligência periférica".

 

Enfim, o tempo de desenvolvimento com uma "suite" dessas fica muito reduzido. Ou seja, barateia para entregar e barateia para escalar.

 

https://www.microchip.com/en-us/development-tool/AC164162

 

Na live, em algum momento, foi mencionado que engenharia ≠ engenhoca.

 

Existem centenas de Click Boards! E um periférico também pode ser interno ao MCU, um bloco no diagrama arquitetural...

 

@aphawk, você pode validar se agora eu entendi essa coisa da forma correta?

[.if]

Ok.. assim que Paulão entender e traduzir pra nós posso colocar minha visão prática pra ver se aplica a algum projeto que participei/participo/participarei ... se der tempo

[alexandre.mbm]

3 minutos atrás, .if disse:

assim que Paulão entender e traduzir pra nós

 

Chamei ele por pensar que ele já sabe do que trata o termo "periférico" mesmo sem ele ter assistido ao webinário. Ele usa uC 8 bits há um tempo.

[aphawk]

@alexandre.mbm ,

 

Sim, entendeu !

 

A Mikroe desenvolveu essa ideia, existem centenas de periféricos inteligentes, chamados de Click Boards, que compartilham um design e uma pinagem padrão, assim basta você comprar uma placa com o seu microcontrolador predileto ( existem com algumas famílias diferentes, como Pic e Atmega, e compatíveis com a IDE do Arduino ! ) , uma placa de base que tem todos os conectores tipo um BUS, e as placas com os sensores, algumas com processador dedicado.

 

Eu acho uma excelente ideia pois existem bibliotecas prontinhas para tudo isso..... assim os programadores não precisam saber muita coisa sobre o hardware, basta aprender como as bibliotecas funcionam.

 

Mas o preço é o impeditivo, claro que seria boa opção para escolas e faculdades, ainda mais que basta trocar a placa do processador principal e continuar aproveitando todas as outras, mas para desenvolvimento de produto a coisa tem de ser bem mais especializada.

 

https://www.sparkfun.com/categories/tags/MikroElektronika

https://www.microchip.com/en-us/development-tool/AC164162

 

Paulo

 

 

[.if]

2 minutos atrás, aphawk disse:

Mas o preço é o impeditivo, claro que seria boa opção para escolas e faculdades,

Isso me tocou profundamente. Aqui fora o sistema é bruto . E nestes segundos em que li a msg do Paulão não vislumbrei nada prático...

[alexandre.mbm]

1 hora atrás, aphawk disse:

Mas o preço é o impeditivo, claro que seria boa opção para escolas e faculdades, ainda mais que basta trocar a placa do processador principal e continuar aproveitando todas as outras, mas para desenvolvimento de produto a coisa tem de ser bem mais especializada.

 

  – Produtos MIKROE na loja da SparkFun

  – Curiosity Nano Base for Click Boards

 

Você refere-se a esse ecossistema de Click Boards. Eu havia assumido que ele é apenas educacional e para prototipagem. Por isso pendi para colocar a possibilidade de um periférico (projeto próprio) com MCU dedicado na minha interpretação do paradigma. Essas Click Boards certamente são mais "caras" do que módulos de Arduino que não tenham a tal "inteligência periférica".

[aphawk]

@.if ,

 

Bom, eu diria que para você , eu, e outros que somos da velha guarda, isso não nos agrega nada.... mas eu acho que para a nova geração, a que usa até I.A. para fazer programas, isso deve facilitar a vida deles, e permite o uso dos velhos processadores de 8 bits para muitas aplicações onde seria necessário um profundo conhecimento do hardware para conseguir tratar os eventos na velocidade necessária....

 

Eu olhei algumas dessas placas de sensores que tem o seu processador dedicado como um tipo de co-processador, onde ele mastiga a parte mais difícil, e assim permite entregar as informações já mastigadas para os velhinhos de 8 bits, usando esse BUS já padronizado.

 

Tem uma plaquinha de CPU chamada de ATMEGA4809 CURIOSITY NANO que tem recursos de hardware programável por eventos, onde você configura coisas tipo DMA  sem usar interrupção, por exemplo, criar uma tabela de leituras do ADC e guardar ela diretamente em um local da memória, sem usar nenhuma interrupção ! Ou tratar capturas através do comparador analógico, são ideias bem avançadas para os velos 8 bits ..... eu vou comprar uma dessas só para me atualizar kkkkk!

 

Paulo

 

 

[alexandre.mbm]

Em 01/06/2023 às 11:01, aphawk disse:

Tem uma plaquinha de CPU chamada de ATMEGA4809 CURIOSITY NANO que tem recursos de hardware programável por eventos, onde você configura coisas tipo DMA sem usar interrupção, por exemplo, criar uma tabela de leituras do ADC e guardar ela diretamente em um local da memória, sem usar nenhuma interrupção! Ou tratar capturas através do comparador analógico, são ideias bem avançadas para os velos 8 bits...

 

Uma versão PIC18FQ67 da Curiosity Nano foi o objeto da demonstração. Essa coisa do DMA foi explicada com diagramas. Pareceu muito didático.

 

Eles falavam bastante das famílias de MCU compatíveis com a plataforma, o que reforçou em mim aquela noção de MCU conversando com MCU. Mas depois eu vi que o MAPS (catálogo) é um buscador de periféricos que não são "uC". Foi quando ficou evidente que minha apuração estava com lacunas relevantes.

[aphawk]

21 minutos atrás, alexandre.mbm disse:

Por isso pendi para colocar a possibilidade de um periférico (projeto próprio) com MCU dedicado na minha interpretação do paradigma

 

Essa ideia é muito fácil de se fazer, eu já fiz algo assim fazem muitos anos, onde projetei e montei uma plaquinha que continha um display LCD tipo 20x4 , e 8 pinos que você podia escolher se seriam uma matriz 4x3 para um tecladinho, ou 4 entradas e 4 saídas, ou 2 Rotary encoders e 2 pinos de I/O . Tudo por comunicação serial a 115k bits ou 9600 bits.

 

Com o Bascom você pode criar o seu próprio periférico, ele tem uma biblioteca que permite qualquer processador Attiny ou Atmega fazer conversação I2C como um Master ou como um Slave, assim você pode  usar um velho Attiny85 de 8 pinos ligado a um sensor meio complicado, fazer o programa dele para processar o sensor e disponibilizar os resultados para serem repassados quando vier algum pedido pelo I2C !

 

São ideias que ajudam nos desenvolvimentos , e quando você tem para quem vender isso, dá para ganhar um bom dinheiro !

 

 

12 minutos atrás, alexandre.mbm disse:

Mas depois eu vi que o MAPS (catálogo) é um buscador de periféricos que não são "uC"

 

Ele deve ter uma tabela com todos os periféricos possíveis, e ele procura algo que permita identificar o periférico colocado no Bus.

 

Isso é uma ideia que vem dos anos 80, onde a gente usava o famoso S-100 BUS, até disponível no ramo industrial, eu trabalhei com esse padrão usando um hardware baseado no Z80 comum.

 

Algumas placas possuíam um padrão para serem identificadas pelo microprocessador.

 

Segue uma visão do S-100 :

 

https://www.pcmag.com/news/pc-pioneers-the-forgotten-world-of-s-100-bus-computers

 

Paulo

 

 

[alexandre.mbm]

Eu já vinha cogitando que pode ser feito bit-banging em ATtiny13, para serem implementados módulos Arduino que se comuniquem por i²C.

 

Agora eu vejo que poderia chamar um módulo desses de "periférico". Só não estaria no padrão mikroBUS.

 

19 horas atrás, .if disse:

linkar a apresentação no fórum, pra nós

 

Postagem atualizada.

[aphawk]

57 minutos atrás, alexandre.mbm disse:

Eu já vinha cogitando que pode ser feito bit-banging em ATtiny13, para serem implementados módulos Arduino que se comuniquem por i²C.

 

Quase isso mesmo !!  Bit-Banging é algo tipo SPI / SPOUT, que é um padrão de alta velocidade.

 

Para falar I2C no formato SLAVE, que é como os periféricos I2C respondem no Bus a uma chamada de um Mestre, a coisa é bem mais chatinha.... no caso do Bascom tem um ADD-ON para isso, o qual; eu possuo  também.

 

Já emulei um PCF8574 com um Atmega8, no desespero de um fim de semana sem o tal CI kkkk

 

Paulo

[alexandre.mbm]

10 minutos atrás, aphawk disse:

Bit-Banging é algo tipo SPI / SPOUT, que é um padrão de alta velocidade.

 

É acrescentar por software a comunicação serial. ATtiny13 não tem serial na pinagem.

[aphawk]

@alexandre.mbm ,

 

Sim, o SPI / SPOUT é um bit banging por hardware, e pode ser emulado fácilmente por software.  Mas não atingirá uma velocidade absurda porque tem o processamento de algumas instruções envolvidas.

 

No seu caso, é um bit-banging de apenas 8 bits de cada vez para simular o envio de um byte , e alguns bits individuais para emular o protocolo I2C, que é de velocidade bem mais baixa do que um SPI/SPOUT pode atingir.

 

Acredite, fazer isso para conversar com um periférico é bem mais simples do que fazer isso para conversar com outro microcontrolador que age como Master.

 

Paulo

[alexandre.mbm]

17 minutos atrás, aphawk disse:

Acredite, fazer isso [bit-banging] para conversar com um periférico é bem mais simples do que fazer isso para conversar com outro microcontrolador que age como Master.

 

Você tem algum material que aponte para essa distinção?

[aphawk]

@alexandre.mbm ,

 

O próprio protocolo !

 

Segue aqui :

 

https://www.analog.com/en/technical-articles/i2c-primer-what-is-i2c-part-1.html

 

Veja que tem a escrita para um periférico e a leitura de um periférico, sempre a partir do lado do MASTER.

 

Todas as bibliotecas que você vê, tratam a conversa do lado do Master. 

 

Para fazer o tratamento do lado do Slave, você tem de implementar os comandos do protocolo na mão, por exemplo o ACK / NACK, o START, o STOP, comparar o endereçamento e responder de acordo, isso tudo acompanhando o estado da linha SCL a qual é controlada pelo Master apenas.

Tem de ficar monitorando as duas linhas o tempo inteiro e detectar quando o SLAVE precisa responder alguma coisa.....

 

Quando você usa I2C do lado do Master, tudo é fácil, tem tudo prontinho.... já do lado do Slave você tem de gerar a temporização e sinais .

 

Algumas pessoas usam essa biblioteca adicional do BASCOM para inventar um componente dedicado, especializado em um determinado processamento. Por exemplo, um CI que monitora as linhas de uma rede trifásica, fazendo a leitura das 3 linhas , convertendo a tensão em RMS, detectando a sequencia de fases, e repassando esses dados prontinhos quando solicitados, o que libera o processador principal para as outras tarefas do programa.

 

Eu criaria alguns comandos I2C nesse CI especializado : 

 

00 - leitura da fase 1 

01 - leitura da fase 2

02 - leitura da fase 3

03 - leitura da sequencia RST ( por exemplo 312 , ou123, ou 312, etc )

04 - leitura RMS

05 - qualidade da tensão RMS ( o quanto de ruído que tem interferindo nas 3 senóides )

06 - identificação do CI com um determinado numero de resposta

 

fora outros que podemos imaginar ..... O cara usa um Atmega 328 e faz todo esse processamento nele, grava e pronto !

 

Ai poderia vender esse CI em um módulozinho que implemente os divisores de tensão, um pequeno transformador isolador, e ganhar um dinheiro com isso...

 

Paulo

[alexandre.mbm]

Em 01/06/2023 às 11:08, alexandre.mbm disse:

Mas depois eu vi que o MAPS (catálogo) é um buscador de periféricos que não são "uC".

 

Em 01/06/2023 às 11:14, aphawk disse:

Ele deve ter uma tabela com todos os periféricos possíveis, e ele procura algo que permita identificar o periférico colocado no Bus [barramento].

 

Somente agora fui buscá-lo e acessá-lo. O negócio é grande! Editei a mensagem com o link. "MAPS" significa algo como "seletor avançado de peças da Microchip". O título da página HTML nos diz que é uma página de MCUs e MPUs...

 

Achei que valia à pena salientar isso aqui. Afinal, o seletor parece ser um instrumento central para a execução da proposta deles.

 

Update

 

@aphawk, @.if,

 

No hotsite de exposição da família de produtos AVR DB vemos claramente que [também] trata-se de "selecionar a MCU certa, aquela com os periféricos on-chip dos quais precisamos". Pelo que penso estar entendendo, a barganha está em que aqueles serão Core Independent Peripherals (CIPs), ou seja, independentes do núcleo de processamento da unidade. Assim, muitas funções numa mesma MCU, mas sem necessidade de interação com a CPU. Blocos de inteligência em hardware, requerendo menos processamento, menos memória e menos energia do que se estivessem em software.

 

O mikroBUS é, então, a convenção de pinagem para uma salada de protocolos. Nossa Click Board pode requerer tudo, ou deixar pino sem uso. A Base é a substituta enxuta de protoboards.

 

De fato eu já tinha me perguntado como, na indústria, os interessados encontram aquele uC do qual realmente precisam...

[alexandre.mbm]

Em 01/06/2023 às 11:14, aphawk disse:

Isso [mikroBUS] é uma ideia que vem dos anos 80, onde a gente usava o famoso S-100 BUS, até disponível no ramo industrial

 

A Wikipédia lusófona afirma que foi o primeiro barramento de expansão na indústria, e para PC. Em inglês, há uma introdução sobre como ele funcionava. As placas de expansão regulavam os 5V de TTL com reguladores lineares 7805.