PIC converter programa criado para arduino para pic

[Marcos Sanches]

Boa tarde mestres,

Estou com uma duvida que não achei respostas na net, eu tenho vários programas que criei para Arduíno que usam apenas 2 portas digitais e uma analógica,

queria portá-los para usar em Pic devido ao custo e dimensão do componente, portanto queria saber se isso é possível e como fazer,

acredito que minha duvida é meio ***** porque geralmente quando não se acha nada na net é porque é muito simples mais eu não tenho ideia de como fazer.

Desde já agradeço a quem ajudar.

[DELPITEC]

Sim. É muito fácil. Basta configurar os registradores de ADC e saída digital do PIC e usar o código Arduino como base. Claro, também deverá desenhar o hardware do PIC.

 

Se precisar de algum auxílio, estou a disposição por e-mail para algum contato profissional:

 

[email protected]

[aphawk]

@Marcos Sanches ,

 

Você pode usar apenas o Atmega328P e gravar o código gerado pela IDE do Arduino nele.

 

E também pode usar um Attiny85 , de 8 pinos, pesquise sobre isso na Internet.

 

Paulo

[.if]

14 horas atrás, Marcos Sanches disse:

para usar em Pic devido ao custo e dimensão do componente

Ledo engano. O avr é mais barato, mais potente, menor e se acha que este...

... é grande d+ pro seu projeto, tem ainda menor... sério!! Tão pequeno que nem achei rapidão (*) na net pra te mostrar a foto. Comprei alguns destes - encapsulamento udfn-8

https://www.digikey.com/en/products/detail/microchip-technology/ATTINY10-MAHR/2357300

... no começo do ano. Devido a tradicional coincidência surreal, quase sinto vontade tirar foto em frente ao seu tópico pra provar kk

(*) achei... mas parece que não aparece direto na página

https://microcontroller.com/news/Atmel_smallest.asp

Assim sendo, meu voto vai pra Paulão @aphawk

[aphawk]

@.if ,

 

Esses são tão pequenos que eu nem consigo mais soldar eles kkkkkk

 

Para facilitar a compatibilidade com o Arduino tem coisa nova bem legal. porém com um pouco mais de pinos :

 

https://create.arduino.cc/projecthub/john-bradnam/using-the-new-attiny-processors-with-arduino-ide-612185

 

Paulo

[.if]

11 horas atrás, aphawk disse:

são tão pequenos que eu nem consigo mais soldar eles

Então é melhor você voltar pras válvulas kk. É o que dá envelhecer meu velho amigo. Eu consigo soldar ele com um ferro machadinha, debaixo dágua com um escafandro e com luva de boxe. kk...

 

Há alguns anos meio que desisti da linha avr e parti pra st. Mais barato, mais recursos e mais etc.

Olha este cujo preço é imbatível e muita memória e muito etc...

https://www.digikey.com/en/products/detail/stmicroelectronics/STM8L001J3M3TR/10414704

um pouco + barato...

https://www.mouser.com/ProductDetail/STMicroelectronics/STM8S001J3M3TR/?qs=BZBei1rCqCCkSCp2R%2B87EA%3D%3D

Ok... pra hobistas e principiantes nem tanto mas como sempre digo, aqui fora o sistema é bruto e precisamos nos adequar e adequar os custos se não fico sem emprego kk.

Com relação à pequenez das peças, eu tenho um truque: peço pra um trôxa que enxerga e solda bem soldar pra mim kk.

abç

 

 

 

[Thiago Miotto]

Eu posso criar um programa com a  IDE do arduíno, usando só alguns pinos, claro, e compilar e jogar dentro desse attiny?

 

Googleeie e vi, posso mesmo. Será que o attiny toca um display LCD via I2c?

[.if]

Sim claro... google i2c bit banging. Há uma grande possibilidade das libs arduinas pra isso sejam gulosas em termos de memória. P.ex. pode engolir o tadinho do mc de 1k numa mastigada só. Mais um (01) motivo pelo que migrei pros st de 8K e mais barato .  Portanto sugiro que simplesmente crie suas próprias funções i2c em c mesmo diretamente na ide arduina.

Olha que fofo...

https://www.embeddedrelated.com/showcode/334

Eu (eu) trocaria isso...

for(outBits = 0; outBits < 8; outBits++) 
	{
	    if(data & 0x80)
		    I2C_DATA = 1;
		else
		    I2C_DATA = 0;

por...

for(outBits = 0; outBits < 8; outBits++) 
	{
	I2C_DATA = data>>7;
	

 

E aí? Mudou sua vida pra caramba né?

[aphawk]

@Thiago Miotto ,

 

Em teoria, sim.

Mas .... como bem dito pela @.if , as Libs do Arduino são bem gulosas ...  e você tem apenas 32 bytes de RAM naquele Attiny10.

 

Mas você pode usar um Attiny um pouco mais poderoso, como os Attiny45 ou 85 que tem muito mais recursos de memoria.

 

Eu comprei um monte (50) de Attiny85 quando eles custavam menos de Us$ 2 .... hoje aqui no Brasil pedem uma fortuna .....

 

Paulo

5 horas atrás, .if disse:

Sim claro... google i2c bit banging. Há uma grande possibilidade das libs arduinas pra isso sejam gulosas em termos de memória. P.ex. pode engolir o tadinho do mc de 1k numa mastigada só. Mais um (01) motivo pelo que migrei pros st de 8K e mais barato .  Portanto sugiro que simplesmente crie suas próprias funções i2c em c mesmo diretamente na ide arduina.

Olha que fofo...

https://www.embeddedrelated.com/showcode/334

Eu (eu) trocaria isso...

for(outBits = 0; outBits < 8; outBits++) 
	{
	    if(data & 0x80)
		    I2C_DATA = 1;
		else
		    I2C_DATA = 0;

por...

for(outBits = 0; outBits < 8; outBits++) 
	{
	I2C_DATA = data>>7;
	

 

E aí? Mudou sua vida pra caramba né?

 

Não entendo muita coisa de C... mas onde está a temporização ? Por exemplo tenho dispositivos que não suportam velocidades acima de 100k e outros que suportam 400K .... num clock de 16 MHz esse bit bang fica muito rápido !

 

Paulo

[Thiago Miotto]

Resolvi jogar no google para ver a questão preço.

Numa rápida pesquisa, o attiny85 está 20 reais, enquanto eu achei o attmega328 por 30 .........

Pior que se pensarmos em preço dólar de agora, 2 dólares é 10, 12 reais... acho que hj não vale a pena montar o projeto no attiny, a não ser que o problema seja espaço ou consumo


Sobre o uso de lcd no attiny, segue link dele com o attiny85 - https://www.instructables.com/Using-an-I2C-LCD-on-Attiny85/
Justamente ele fala em uso de biblioteca enxuta

[aphawk]

@Thiago Miotto ,

 

A implementação que a @.if postou usando bit bang é a melhor opção.... só falta implementar os delays necessários caso use um cristal de alta velocidade, como os 16 Mhz padrão do Arduino.

 

Vai ficar bem pequena, basta criar um delay básico que permita atingir um clock de 400 Khz , ou seja, alguns ciclos de máquina de delay quando em nível alto, e os mesmos ciclos de máquina quando em nível baixo.

 

Se eu fosse chutar, eu tentaria em vez de 400 Khz fazia algo em torno de 100 Khz, que garante o funcionamento em quase todos os periféricos I2c. 

 

Assim, após mudar o nível dos pinos do I2c, usaria um delay de (16 *10 / 2 afinal estamos a 16 Mhz certo ?) 80 ciclos de máquina ( será que tá certo isso ??? ) e assim conseguiria a temporização correta, um total de 160 ciclos de máquina a 16 Mhz que corresponde a uma frequência de 100 Khz.

 

Em Assembler, uns 25 bytes devem ser o suficiente para esse delay.

 

Menor implementação do que esta, acho bem difícil ....

 

Paulo

[.if]

Em 31/01/2021 às 19:10, aphawk disse:

mas onde está a temporização ?

Meio que depende das otimizações do compilador. No meu (meu) caso ...

I2C_DATA = data>>7;

ele leva um tempinho pra deslocar 7x ou dividir por 128 (o que nem quero saber). Assim sendo, penso que se dá a temporização correta pra maioria dos mc's

53 minutos atrás, aphawk disse:

Em Assembler, uns 25 bytes devem ser o suficiente para esse delay.

1/2 muito. Em c, um delay minimalista e programável - carrega um argumento -  custa bem menos que isso. P.ex.
 

void delay(char dl)
{
while (dl--);
}

Deve ocupar (nunca vi) uma meia dúzia de bytes ou menos... depende do compilador. Pra ajuste da precisão costumo colocar asm ("NOP")... a única coisa útil do assembly

void delay(char dl)
{
while (dl--) {asm("NOP") ...asm("NOP");}//microajustes
asm("NOP"); microajuste final
}

Isso resolve a questão...

Em 31/01/2021 às 19:10, aphawk disse:

num clock de 16 MHz esse bit bang fica muito rápido !

Me lembro que tive que fazer estes microajustes numa comunicação 1wire cuja temporização era o cerne do protocolo. Já o i2c num tem esta frescura pois opera com freq baixa devendo respeitar só a máxima.

[aphawk]

@.if ,

 

Deslocar 7x para a direita consomem 7 ciclos de clock apenas .... daria algo bem acima de 1 Mhz...

 

Sim, sabendo de antemão o clock, fiz o delay  em 6 bytes sem pensar muito. Falei uns 25 de chute mesmo kkkk !

 

Mas tem de fazer o ajuste no bit bang do I2C, senão a velocidade do clock vai ficar muito acima dos 400 Khz padrão.

 

Por exemplo esses adaptadores de display LCD 16x2  para I2C, muitos falham a 400 Khz, mas todos funcionam muito bem a 100 Khz.

 

Paulo

 

[.if]

4 horas atrás, aphawk disse:

fazer o ajuste no bit bang do I2C, senão a velocidade do clock vai ficar muito acima dos 400 Khz

Qual parte do NOP você não entendeu?

https://pt.wikipedia.org/wiki/NOP

 

4 horas atrás, aphawk disse:

Por exemplo esses adaptadores de display LCD 16x2  para I2C, muitos falham a 400 Khz, mas todos funcionam muito bem a 100 Khz

Por segurança, converse a 10Khz que já é uma baita velocidade pra este display 16x2

[aphawk]

13 minutos atrás, .if disse:

Qual parte do NOP você não entendeu?

Kkkkk

Disso eu entendo bastante kkk desde 1982 usando NOP dá para aprender bem viu kkk...

 

A 10Khz dá para ver a escrita feita letra a letra kkkkk !

 

Paulo

[.if]

1 hora atrás, aphawk disse:

A 10Khz dá

~1000 letras por segundo num dispositivo com 32 letras ... 32mS por letra. Troca a tela toda 33 vezes num segundo. Se não for rápido o bastante e você conseguir ver cada escrita, você só pode ser parente do chuck noris kk.

O que me fez lembrar... quando digitava o comando 'catalog' no apple ou 'dir' no cp/m , a gente quase via de fato os caracteres impressos um a um na tela. Algo me diz que te lembra disso

[aphawk]

@.if  ,

 

Esse I2c de display nada mais é do que um conversor de níbble serial para para paralelo, além de acionar os pinos de controle do chip do display.

Se você levar em conta todos os comandos que tem de serem enviados ao display para ir escrevendo em sequência, a velocidade final da escrita cai bastante.. 

 

Me lembro sim do "dir" do Cp/m ... aliás toda a escrita no vídeo do Cp/m era tão lenta que foi o motivo de reescrevermos toda a Eprom da Vídex.

 

Mas eu me lembro de algo que era mais lento ainda :

Escrever na tela do Sinclair Zx-80 ...

 

Paulo

[vtrx]

Citação

Mas eu me lembro de algo que era mais lento ainda :

Escrever na tela do Sinclair Zx-80 ...

O mais engraçado era o modo 'fast',que fazia a tela piscar.

Mas verdade seja dita,acho que foi a arquitetura mais complexa que se poderia fazer usando uma única CPU comum de 8 bits/4mhz para todo o sistema.

[Thiago Miotto]

12 horas atrás, .if disse:

~1000 letras por segundo num dispositivo com 32 letras ... 32mS por letra. Troca a tela toda 33 vezes num segundo. Se não for rápido o bastante e você conseguir ver cada escrita, você só pode ser parente do chuck noris kk.

A parte dos 32 caracteres, não é tão mãmão com açúcar....
 

o display pode ter várias configurações, podendo correr os caracteres na memória.
Se não me falha a memória, com a visualização fixa é assim: memória 1 a 16 é a 1ª linha. Memória 41 a 56, visível na 2ª linha
Então, o controlador tem que fazer este controle

 

 

 

[.if]

4 horas atrás, aphawk disse:

levar em conta todos os comandos que tem de serem enviados ao display para ir escrevendo em sequência, a velocidade final da escrita cai

... um pouco e nada suficiente pra dar pra ver as letras rolando kk. Na 'real' ninguém fica o tempo todo olhando pra este display e ninguém (além de você kk) iria dar bola pra velocidade da impressão. Portanto, penso ser isso nada importante. A não ser um eco que me veio agora do passado (pra variar) ...

Certa feita há looong time ago vi um projetinho de um japonês que me esqueci o nome que fazia um display deste como osciloscópio! Sério! era com pic mixuruco e 100% c. A princípio precisava mesmo escrever rapidão. E também tinha vários projetos top dele. Outro que me lembro e tem relação com nosso "momento" era um gerador de caracteres e relógio pra tv também com pic xinfrim. Preciso lembrar e linkar pro 6 pois era muuuuito bacana mesmo.

 

1 hora atrás, Thiago Miotto disse:

A parte dos 32 caracteres, não é tão mãmão com açúcar....

Só se você estiver programando em hexadecimal kk. Mas de fato é bem simples. Também apelando pra memória, a 1ª linha fica no endereço 0x80 e a 2ª no 0xc0. Portanto um resumo: basta você enviar o caractere 0x80 com entrada RS em 1 pra ele entender que o próximo comando com RS esteja em 0 vai ser o código asc-ii do caractere que deve ser impresso na 1ª linha. Há também um macete simples pra posicionamento de coluna que não vem ao caso, a não ser que insistas muito .

[aphawk]

@.if ,

 

O vídeo abaixo foi feito com a comunicação I2C com esses adaptadores comuns  a 100 Khz :

 

https://www.youtube.com/watch?v=rKYEyugX9pA&feature=youtu.be

 

Impressionante né ?

 

Mas eu já sofri bastante com a velocidade de escrita, uma vez montei um analisador de espectro de áudio usando um display 16x2 , tive de alterar o programa para ficar checando o status do display antes de escrever, a velocidade aumentou bastante e ficou bem legal.

A maioria das bibliotecas usa um delay fixo na escrita para evitar ficar consultando o status, basta perceber se o sinal R/W está fixo no GND e nesse caso é com delay fixo kkkkkk ....

 

Paulo

[.if]

Boa Paulão. Nunca mexi com display i2c mas suponho que o pacotinho de bits é o mesmo que os pinos dele, não?

 

Vamos escovar alguns bits? Pra brincadeira tá tudo certo. De fato checar o status torna as coisas mais rápidas. Elevando pra outro nível, há alguns cuidados a se tomar. P.ex. esta porcaria de display não raramente sofre interferências externas. Olha isso de agora há pouco...

 

Na melhor das hipóteses o display só fica maluco mas o mc continuaria trabalhando. No caso de se ler o status, há o risco de travar o sistema pois o display não responde e não deixa continuar (pra variar, o guri não retornou pra contar pra gente). Assim sendo, pro sistema ficar mais robusto há a necessidade de se implementar um timeout: "não responde? tenho mais o que fazer". Ok, o display não vai funcionar mas o respirador ainda vai continuar ajudando o paciente a respirar... (puts apelei kk).

No caso de delay fixo nem precisaria implementar a segurança acima. Nos 2 casos (display fica doido) uma robustez adicional é reinicializar e reescrever/redesenhar o display de vez em quando. Claro, cada caso .. um caso.

 

Obs: no caso do garoto do post que orientei é mais simples pois é o próprio sistema que gera o ruído, portanto controlável com as dicas que lhe dei. O bruto é quando a interferência vem de fora - p.ex. em teste de homologação em laboratórios quando emite um forte sinal de rádio - o que me faz lembrar que aqui fora o sistema é bruto kk

 

[Thiago Miotto]

31 minutos atrás, .if disse:

pra variar, o guri não retornou pra contar pra gente

off topic.....
Isso me fez lembrar que o 1º tópico que fiz no forum tb nunca foi respondido por mim. Mas foi por falta de tempo para voltar ao 1º projeto. Acho que está na hora de revisitar o negócio lá, dar uma solução e deixar registrado para a eternidade (ou enquanto os servidor do cdh estiverem funcionando)

 

 

[aphawk]

@.if ,

 

Sim, o pacotinho são todos os bits, normalmente 4 de dados e 3 de controle.

 

Já ví esse problema de display várias vezes ....sempre causado por ruído e filtragem ruim na plaquinha do LCD... eu costumava soldar capacitores de 47 uF  nos pinos de VCC e resistores  de pullup de 2k2 em todos esses pinos do display para abaixar a impedância deles, isso melhorava bastante a imunidade a ruídos. E na minha rotina eu detecto que o display não está mais respondendo por timeout, e aí abandono as escritas, mas sinalizava em um buzzer que algo estava errado.

 

Na época eu propus usar um pequeno relé para desligar e ligar novamente o display, mas acharam que o custo não compensava ....

 

Na vida real, ambiente industrial, tudo tem de ser levado em conta, até blindagens de cabeamento de sinal.... 

 

Um projeto que fiz fazem uns 7 anos eu Montei uma placa com um Atmega que ficava soldada direto no display, igual esses módulos I2C .... ela tinha suporte para um rotary encoder, um teclado matricial 4x4, um buzzer, e 4 leds .... e toda a conversa era feita via RS232 a 115K ou a partir de 300 bauds para casos de longos comprimentos ou ruidos muito altos.... criei comandos para ler teclado, ler encoder, acionar Leds, acionar Buzzer, e enviar esses resultados pela serial.

 

Ficou muito legal, fabriquei 100 plaquinhas , vendi para o clientwe e fiquei 6 meses na boa kkkkkk

 

Paulo

 

 

 

@.if ,

 

Sim, o pacotinho são todos os bits, normalmente 4 de dados e 3 de controle.

 

Já ví esse problema de display várias vezes ....sempre causado por ruído e filtragem ruim na plaquinha do LCD... eu costumava soldar capacitores de 47 uF  nos pinos de VCC e resistores  de pullup de 2k2 em todos esses pinos do display para abaixar a impedância deles, isso melhorava bastante a imunidade a ruídos. E na minha rotina eu detecto que o display não está mais respondendo por timeout, e aí abandono as escritas, mas sinalizava em um buzzer que algo estava errado.

 

Na época eu propus usar um pequeno relé para desligar e ligar novamente o display, mas acharam que o custo não compensava ....

 

Na vida real, ambiente industrial, tudo tem de ser levado em conta, até blindagens de cabeamento de sinal.... 

 

Um projeto que fiz fazem uns 7 anos eu Montei uma placa com um Atmega que ficava soldada direto no display, igual esses módulos I2C .... ela tinha suporte para um rotary encoder, um teclado matricial 4x4, um buzzer, e 4 leds .... e toda a conversa era feita via RS232 a 115K ou a partir de 300 bauds para casos de longos comprimentos ou ruidos muito altos.... criei comandos para ler teclado, ler encoder, acionar Leds, acionar Buzzer, e enviar esses resultados pela serial.

 

Ficou muito legal, fabriquei 100 plaquinhas , vendi para o clientwe e fiquei 6 meses na boa kkkkkk

 

Paulo

 

 

 

[.if]

Eu já tinha entendido na 1ª vez ...

 

14 horas atrás, aphawk disse:

usar um pequeno relé para desligar e ligar novamente o display, mas acharam que o custo não compensava

Não ia dar certo mesmo. No caso do lcd 16x2 tradicional, não basta só desligar/ligar... tem que inicializar .. obs: sei que você sabe disso. Mas quem lê o lance do relé, talvez não... mas relé? Fala sério... Na época não tinham inventado um simples bc327 não?

 

 

12 horas atrás, aphawk disse:

cadê o botão EDITAR ????

 

O meu tá ativo e fazendo uso dele..:..

12 horas atrás, aphawk disse:

problema era o consumo do backlite

backlight né chico bento. kk.

Péra que vou resolver seu passado ... a perda mínima de 0.5v ou menos do transistor saturado não incomoda nenhum backlight mesmo o do passado distante. Também tenho dúvida se ele consome mais que 1W que pra um led é luz placar alho o que um bc327 como chave daria conta. Por segurança coloque um bc636 ou bd136

Passado sempre presente kk