Projetos com Avr : Design, Programação em Basic e Assembly

test man*~ · 15 de junho de 2017

@aphawk show... Você é o cara mesmo Paulão... Assim que voltar vou dar uma limpada no código, realmente há várias coisas que podem ser retiradas... O labview está ativado para considerar o cts, inclusive, se ele não for ativado em 1 segundo ele detecta, desconecta e vai para o modo idle...

Eu estava pensando sobre o projeto do código antes de iniciar o mesmo... Padronização para certos trechos e para nomes de variáveis e funções... Para facilitar A programação... vou tentar usar no próximo projeto...

Sou da geração dos preguiçosos Paulão xD... Você falando de uma indústria com z-80 se eu te falar que quase dei um shutdown em uma planta usando um CLP você até me bate hahahhahahgehe

aphawk · 15 de junho de 2017

@test man*~ ,

kkkkkkkkk gostei do "geração dos preguiçosos" !

Bom, se o Labview está mesmo tratando o CTS, não deveria estar ocorrendo esse erro de CRC..... experimente com carinho ver se habilitar a INT na entrada da rotina do Timer não atrapalha o seu programa.

Mas não se preocupe em dar um shutdown numa planta.... eu trabalhei em uma planta em que um compressor de oxigênio puro de alta potência explodiu, dando um prejuízo de alguns milhões de dólares, por que um programador esqueceu de tirar o CLP do modo de programação durante um teste !

Eu me ferrei tanto nessa planta um mês antes, que adorei saber disso !

Mas uma coisa te digo : programar um Hardware Z-80 foi a coisa mais legal em que eu trabalhei... tinha tanta instrução diferente, tanta variação delas, tantos registradores e pares de registradores, que quase dava para usar ele mesmo como memória RAM kkkkkkk ! Na verdade, eu trabalhava quase sempre com 2K de RAM e 8Kb de programa, mas como era tudo em Assembly, sempre sobrava espaço de memória.

O legal é que isso me permite trabalhar com os Atmega usando Assembly também, pois ele me lembra bastante o Z-80, com a vantagem de ser bem mais rápido do que ele.

Qualquer coisa estou por aqui, basta dar um sinal de fumaça ok ?

Paulo

test man*~ · 15 de junho de 2017

Beleza Paulão daqui a duas semanas quando eu voltar eu faço os testes =)

Intrudera6 · 15 de junho de 2017

Eu já brinquei muito com o Z80, com o ASM dele inclusive, mas era hobby apenas, eu ainda era estudante do 2° grau aprendendo a programar e fazendo umas *****s de vez em quanto. Faz um tempo que não mexo no Bascon, acho que estou enferrujando mas ver vocês tirando leite de pedra meio que me atica. Dei também uma parada temporária no Arduino IDE por falta de tempo, acho que depois de voltar da Serra Catarinense (estou indo para Florianópolis em 20 de junho e depois de Florianópolis pretendo pegar umas trilhas em Urubici e vizinhança, torço para pegar neve mas acho que vai ser difícil) devo voltar a botar a mão na massa no ESP8266 e no meu ESP32 (ainda não sei fazer muita coisa nele, mal passei do Hello World).

Até hoje nunca fiz nada com ASM, no Arduino e nem no ESP8266, fiquei preguiçoso, não tenho mais saco para perder noites dando cabeçadas como antigamente, e a falta de um debug no ESP8266 desanima, tentar aprender ASM sem um bom debuger é que nem um cego tentando fazer uma neurocirurgia, difícil, bem difícil. Do meu tempo que eu programava Z80, eu usava até as contantes como variáveis (quando necessário para economizar espaço de memória), dá para fazer o diabo com ASM, nada é impossível ou proibido, mas os bugs são difíceis de depurar mesmo com um bom debuger, sem fica quase impossível.

aphawk · 15 de junho de 2017

@Intrudera6 ,

Opa meu amigo, depois quando você voltar vai ter bastante tempo para brincar, não fique pensando nisso agora... curta suas férias !!!!!

Provavelmente você vai gostar bastante do Assembly dos Atmegas e Attinys, se você se familiarizou com o Z-80 é bem natural , não tem nada daquela maluquice de bancos dos Pics, memória é linear até 64K, e o set de instruções é bem legal, com algumas instruções bem poderosas que já transferem dados entre memória e registradores e incrementam automáticamente os pares de registros que servem como ponteiros de 16 bits...

A IDE que eu recomendo para brincar é o AVR Studio versão 4, antigo mas bem mais simples, e o Bascom serve como simulador tanto em Basic como em Asm, mas eu gosto mesmo é do Proteus, abro as janelas do código-fonte, da memória Ram, da CPU, do conteúdo das variáveis, e vejo o meu código intercalado com os comandos em Basic e as instruções que o montador transformou em Assembly, e posso inserir breakpoints, rodar passo a passo, enfim é o que mais chegou perto do famoso Turbo Debuger , que era uma maravilha de se usar com a linha 8086 !

De quebra, vejo o hardware funcionar, posso interferir nos I/Os, tenho janelas com terminais seriais virtuais, janelas da comunicação I2C, tudo isso ajuda bastante.

Deixa a preguiça de lado, e venha tirar leite de pedra, assim exercita o seu cérebro e contribuirá para uma velhiçe bem mais saudável !

Paulo

Intrudera6 · 15 de junho de 2017

O Turbo Debuger é mesmo uma ferramenta incrível, a melhor de todas, deixa a gente muito mal acostumada, aprendi a programar o ASM 8088 e o 8087 com ele, mas isto já deve ter mais de 20 anos, foi na época que trabalhava com Pesquisa Operacional (PO) na minha empresa. Eu conseguia tirar leite de pedra com o ASM 8088 combinando com o Turbopascal. Fazia a maior parte das rotinas em Pascal e bem no núcleo usava ASM nos loopings para acelerar a execução, com ele é possível fazer coisas que não se consegue com alto nível (com eficiência), rotação de enormes vetores binários por exemplo. Com ASM estas coisas voam, mas em alto nível tem que ser muito criativo para fazer. Foi fazendo isso que acelerei bastante a execução de um pesadíssimo programa de otimização e sequenciamento.

É nessas horas que dá uma saudade dos tempos de escovador de bits, e uma vontade de meter a mão na massa (ASM) de novo, mas naquela época a minha disponibilidade de tempo era outra, agora me falta tempo para fazer isso, mas isto não me impediu de dar uma olhada nos códigos ASM do AVR (não tenho certeza se ele tem instruções de multiplicação, não lembro) e até nos do ESP8266 (por sinal, já fiz isso mas não consegui entender muita coisa). Por exemplo, no velho Z-80 tinha umas instruções interessantes mas não tinha instruções de multiplicação e divisão, no ESP8266 tem apenas de multiplicação, mas no ESP32 já encontrei umas instruções em ASM para fazer divisão (eu acho), e isso realmente me deixou curioso e com vontade de tirar a ferrugem, mas sem um debuger (mas querer um bom como o Turbo Debuger já seria querer demais) fica bastante difícil o aprendizado. Tem tempo demais que não mexo com ASM Z-80 e nem 8088 (e derivados), acho que tem mais de 25 anos pelo menos no Z-80, é tempo demais para minha memória (que sempre foi ruim).

As vezes eu não consigo entender como eu tenho tanta facilidade com linguagens de computador e tanta dificuldade em aprender inglês. Para mim é um martírio, mas agora eu vou até o fim (no inglês), apesar do sofrimento, e muitas vezes falta saco para estudar (mas foi por isso que interrompi o meu aprendizado no ESP8266/ESP32). Mesmo com as dificuldades, acho que consegui evoluir bastante no inglês, mas ainda tenho muito que evoluir para conseguir fluência.Acho que ter inglês fluente é uma ferramenta indispensável para aprendizado em microcontroladores, e o meu curso de inglês me ajudou bastante, mas ainda acho que falta muito para conseguir uma fluência aceitável, ainda é complicado fazer perguntas mais complexas nos fóruns em inglês (e isto faz muita falta).

adicionado 39 minutos depois

3 horas atrás, aphawk disse:

A IDE que eu recomendo para brincar é o AVR Studio versão 4, antigo mas bem mais simples, e o Bascom serve como simulador tanto em Basic como em Asm,

.

.

.

Paulo

Como é que você consegue utilizar o Bascon como simulador em Basic e em ASM ? Este recurso eu não conheço.

aphawk · 15 de junho de 2017

@Intrudera6 ,

Eu usava o Turbo Assembler e o Turbo Linker ( Tasm e Tlink ), que faziam parte do pacote do Turbo Debugger, e para o Z-80 usava o M80 e o L80. Eram ferramentas incríveis !

Sobre o simulador do Bascom, seguem alguns links para você ter uma ideia :

https://avrhelp.mcselec.com/index.html?program_simulate.htm

http://www.qsl.net/pa3ckr/bascom and avr/editor and simulator/index.html

O Bascom permite você escrever direto em Assembler também, no meio do código em Basic, e também tem algumas pseudo-instruções para facilitar ao Assembler o acesso às variáveis do Basic ! Assim , fica muito fácil ..... também posso fixar endereço de qualquer variável se for necessário.

Naquela série de posts que fiz apresentando várias técnicas para se fazer um instrumento, usei várias vezes um mix do Bascom e do Assembly para poder obter bons resultados.

Veja este aqui, por exemplo :

Agora, sobre Inglês.... tem mesmo de aprender o Inglês técnico, sem ele complica bastante uma leitura perfeita.

Paulo

Intrudera6 · 15 de junho de 2017

Eu já consigo entender quase tudo do inglês técnico (às vezes com alguma dificuldade), mas na hora de escrever em inglês o buraco é mais embaixo. Sou assinante da Elektor, leio e entendo (com um certo trabalho) todos os artigos que me interessam em inglês (às vezes com a ajuda do google em algumas palavras). O inglês técnico é até fácil, no inglês coloquial é que complica.

MOR_AL · 28 de junho de 2017

Paulo.

Recomecei a ler sobre a linguagem Assembly do AVR, depois de tempo suficiente para ter que recomeçar mesmo. Me deparei com uma dúvida básica. Esclarece para mim?

A instrução out $18, r16 coloca o conteúdo do registro r16 na porta B. Porque $18 é o endereço da porta B? O endereço não teria offset $25?

MOR_AL

aphawk · 28 de junho de 2017

@MOR ,

Opa meu amigo, desculpe pela demora !

O endereço físico varia conforme a família, por isso essa confusão....

Por exemplo, num Attiny13A, o endereço físico do PortB é o que você citou, $18.

Já em um Atmega328, o endereço físico do PortB é $25 ....

Infelizmente tem de pegar o datasheet do modelo que você quer usar, e "dançar conforme a musica" !

Além disso, existem alguns detalhes de funcionamento que devem ser observados.... algumas instruções podem ter de usar um outro endereço para acessar o mesmo port físico ! Ou seja, dependendo do tipo de instrução, tem de se subtrair um offset para poder acessar o mesmo registro !

Segue abaixo algumas dicas do Atmega328, direto do datasheet :

Veja abaixo os ítens 2 e 4 :

Embora seja um pouco confuso no início, isso permite usar instruções que consomem menos ciclos de clock.

Paulo

MOR_AL · 28 de junho de 2017

@aphawk

Agora entendi.

Estava estudando o manual "Atmel-0856-AVR-Instruction-Set-Manual" e na página 111 consta o seguinte exemplo.

Example:
clr r16 ; Clear r16
ser r17 ; Set r17
out $18,r16 ; Write zeros to Port B
nop ; Wait (do nothing)
out $18,r17 ; Write ones to Port B
Words: 1 (2 bytes)
Cycles: 1

Ao tentar entender o endereço $18, fui consultar o datasheet do 328. Exatamente este que você mostrou.

E lá consta o endereço de offset $25, aí é que deu um nó na minha cabeça.

Acontece que eu não atinei para o detalhe dos uC diferentes da AVR. Ao consultar o manual "Atmel-0856-AVR-Instruction-Set-Manual", reparei que não é mencionado nenhum uC no documento.

Mas valeu pelo esclarecimento.

Estes uC da AVR são mais complexos que os PICs e a gente tem que ler com muita atenção.

Comprei o aplicativo da Bascom já há algum tempo. Cheguei mesmo a estudar o início da sua excelente apostila. Aliás, sinto falta de documentos em português usando o aplicativo Bascom. Há alguns em inglês e muitos documentos em inglês no sítio do Bascom. Tem muitos vídeos em (que língua é essa?), mas aí só dá para acompanhar as imagens do mesmo.

Vamos, aos poucos, avançando. Por hora tem muita tarefa na fila, hehehe.

Valeu.

MOR_AL

aphawk · 28 de junho de 2017

@MOR ,

Hehehe é, eu imaginei exatamente isso que você falou ...

Quanto ao Bascom, existe muita coisa em Alemão e em Sérvio .... realmente eu quando procuro saber mais uso o tradutor de site do google, pelo menos consigo aos trancos entender a coisa...

Existe uma referência de comandos no site do Bascom, e é por aí que eu também me viro.... quando a coisa aperta muito recorro ao Fórum em Inglês mesmo.

Mas isso que você está passando é porque você ainda não resolveu ficar em cima um fim de semana inteiro, escrevendo um programinha ou outro e testando num Arduino Uno. O Assembler dele é bem fácil, como eu sempre digo aqui lembra bastante o jeitão do 8080, e sem a loucura dos bancos dos Pic's.

Logo você estará usando isso tudo de uma maneira bem mais natural, ok ?

Paulo

MOR_AL · 28 de junho de 2017

@aphawk

Grato pelas dicas, Paulo.

MOR_AL

test man*~ · 13 de julho de 2017

Você estava certo mesmo Paulão @aphawk tive que reduzir a velocidade da serial (das duas) para 9600, todos os meus problemas, apareceram outros, foram embora depois que o fiz... Isso fez aumentar a minha vontade de usar os ARM, o DMA é muito show, ele é capaz de enviar dados pela serial sem intervenção da CPU ! Dei uma brincada com o Keil uVision (simulação) e é bem bacana de usar, e possui versão grátis (sem limitações) para os STM32F0 e STM32L0 (ARM Cortex M0), ainda há o coocox (esse é free mesmo) e suporta os ARM Cortex M4...

Enfim... Voltando ao AVR, mais uma parte do robô, dessa vez mostrando o supervisório e ensinando um movimento a ele através do computador, no próximo mostro o ensinamento manual (movendo o robô com as mãos).

aphawk · 14 de julho de 2017

@test man*~

Heheh que bom que resolveu.

Mas ainda insisto que um redesenho do programa, com um bom uso de interrupções que seriam muito rápidas e deixariam todo o trabalho grosso para o loop principal também resolvem os problemas e permitiriam uma velocidade de comunicação serial bem elevada.

Eu gosto muito de usar as interrupções apenas como um tipo de sinalizador ao programa principal, o qual faz o trabalho pesado. Ainda mais em um Atmega2560 que tem várias seriais, todas com interrupção que podem ser bufferizadas pelo Bascom.

Sobre o DMA, é sempre muito bem-vindo quando temos ele em nosso microcontrolador.

Existe a linha AtXmega, a qual possui vários tipos com DMA, mas como eles não existem em formato DIP eu nem me interesso em usar nos meus simples projetinhos... mas é a evolução natural da linha de 8 bits Atmega, com muito recurso extra, como por exemplo 4 canais de DMA, 8 níveis de prioridade de interrupção ( finalmente !!!! ) , 7 USART, 7 timers de 16 bits de alta resolução, um timer gerador de forma de onda, uma interface USB de alta velocidade, um RTC de 16 bits com oscilador separado, 16 canais A/D de 12 bits com velocidade de 2 Msps, 2 canais D/A de 12 bits com velocidade de 1 Msps, 2 interfaces I2C, 3 interfaces SPI, criptografia AES/DES por hardware, interrupção externa em todos os pinos ( !), velocidade de 32 MIPS..... ufa !!!!! É muita coisa junta :

http://www.atmel.com/Images/Atmel-8386-8-and-16-bit-AVR-Microcontroller-ATxmega64A3U-128A3U-192A3U-256A3U_datasheet.pdf

O legal é que o Bascom suporta essa família também !!!

Pena que eu estou ficando velho para trabalhar com esses invólucros TQFP ou TFN, deixo isso para a geração atual !

Paulo

test man*~ · 14 de julho de 2017

20 horas atrás, aphawk disse:

Mas ainda insisto que um redesenho do programa, com um bom uso de interrupções que seriam muito rápidas e deixariam todo o trabalho grosso para o loop principal também resolvem os problemas e permitiriam uma velocidade de comunicação serial bem elevada.

Depois que você falou sobre a diminuição da velocidade eu dei uma analisada no código, atentando-me para a temporização, e percebi que realmente há muitas falhas, não só com a interrupção do Timer, mas também com várias outras coisas como o próprio protocolo criado para comunicação:

$             - Início do pacote
BYTE1 + BYTE2 - Tamanho do pacote
BYTE3 + BYTE4 - Comando
BYTE5 . BYTEn - Dados
[CRC]

Ele pode ser melhorado, ainda não tenho certeza como, tenho algumas ideias, mas não certeza. O microcontrolador fazer todas aquelas verificações para todos os bytes recebidos é meio complicado, deve haver uma forma mais eficiente de fazê-lo, não há necessidade de mudar o protocolo em si, há uma necessidade de mudar como ele é executado no AVR.

Porém, resolvi dar o projeto como concluído, pois para cada coisa que eu implementava apareciam ao menos dois problemas (código mal planejado), é como se o código estivesse no limite da temporização, e se eu continuasse insistindo eu com certeza ficaria até o fim do ano nesse robô. Ex.: era para o AVR perguntar de 3 em 3 segundos se a outra placa, a SSC-32U, estava presente, programei deu certo, porém apareceu um problema em outro lugar (também relacionada com a interrupção do Timer1)...

Assim resolvi concluir, guardar as falhas e tentar corrigi-las nos próximos projetos, de todas elas a maior com certeza foi a falta de um planejamento geral antes de começar a programar, acho que essa foi a maior falha, chegou uma hora que eu perdi o controle do programa de tal forma que o problema aparecia e eu não fazia a mínima ideia de onde atuar para corrigi-lo, foi frustrante ... Um dia (em algum ponto no futuro) pretendo construir outro braço usando motores de passo e imprimindo ou usinando as partes com uma impressora 3D ou uma CNC daí com certeza a comunicação ficará mais rápida (espero)...

Mas é isso ai, o negócio é sempre tentar melhorar, se for comparar o meu primeiro projeto com PIC com esse robô... Vish, nem dá para comparar está em um nível totalmente diferente ... Eu estou meio que querendo parar de usar bibliotecas prontas dos compiladores, como vou ter que ler datasheet (apesar de já ter lido boa parte do ATmega328P) já pulo direto para os ARM...

A propósito, a Universidade do Texas disponibiliza através do Edx (professores doutores Valvano e Ramesh) um curso que usa o M4 da Texas Instruments, se você comprar o kit (de qualquer lugar, pode ser até do Aliexpress) para fazer a parte prática, na conclusão do curso você pode solicitar um certificado registrado (pagando US$50,00 ou US$99,00)...

Valeu aí Paulão @aphawk , ainda coloco outro vídeo ensinando o robô com as mãos, vale lembrar que tudo começou na sua apostila HEHE.

aphawk · 15 de julho de 2017

4 horas atrás, test man*~ disse:

Assim resolvi concluir, guardar as falhas e tentar corrigi-las nos próximos projetos, de todas elas a maior com certeza foi a falta de um planejamento geral antes de começar a programar, acho que essa foi a maior falha, chegou uma hora que eu perdi o controle do programa de tal forma que o problema aparecia e eu não fazia a mínima ideia de onde atuar para corrigi-lo, foi frustrante ... Um dia (em algum ponto no futuro) pretendo construir outro braço usando motores de passo e imprimindo ou usinando as partes com uma impressora 3D ou uma CNC daí com certeza a comunicação ficará mais rápida (espero).

Gostei muito de ler isto agora !

Esse foi o maior aprendizado deste projeto, meu amigo, quando a gente percebe que sofremos muito por uma falta de um melhor planejamento do firmware !

Mas como você mesmo disse, para quem começou quase do zero, chegar onde você chegou é uma bela conquista !

Quanto a bibliotecas, eu prefiro eu mesmo escrever as primitivas para conversar com um CI, assim eu aprendo como ele funciona, e principalmente, como utilizar esse CI. Apenas no caso de displays é que eu uso as prontas, pois é bem complicado fazer as rotinas para displays gráficos coloridos RGB de alta resolução.

Sugiro você fazer mais programas com várias interrupções, para aprender mais técnicas sobre o uso delas como sinalizadoras ao programa principal.

Paulo

test man*~ · 16 de julho de 2017

Em 14/07/2017 às 22:30, aphawk disse:

Sugiro você fazer mais programas com várias interrupções, para aprender mais técnicas sobre o uso delas como sinalizadoras ao programa principal.

Com certeza vou fazê-lo

test man*~ · 1 de agosto de 2017

Agora sim, final verdadeiro do projeto, ensinando movimentos ao robô movendo ele com as minhas mãos. Vou emprestar o robô para que um amigo do serviço leve para o seu filho que acabou de entrar para o grupo de robótica de escola (concorreu com 400 alunos )... Incrível como esse projeto abriu a minha mente, usar um compilador diferente com linguagem diferente foi uma experiência muito boa... Valeu pela iniciativa de publicar a apostila @aphawk...

Ah é, no comentário anterior eu disse que deveria haver alguma forma de melhorar a comunicação... E realmente há... Depois de ler um pouco vi que um Real Time Operating System (RTOS) seria a solução (preguiçosa) para todos os problemas do código HAHAHAHAHA...

Pedacinho do código do labview, só por curiosidade mesmo... Hehe

aphawk · 2 de agosto de 2017

@test man*~,

Legal o video !!!!

E essa tela do LabView também mostra que sempre temos coisas novas a aprender, muito legal de se aprender isso ! Ah... como eu gostaria de ter 20 anos HOJE !!!!!!

E também gostaria de parabenizar esse menino que entrou no curso, é sempre animador ver que existem pessoas que se interessam e estudam de verdade !

Eu estou envolvido com um projeto que será doado para a LABRE SP, que deve ser de baixo custo para ser montado por radioamadores, e para isso estou usando um Atmega16L que custa aqui nas lojas de SP cerca de R$ 14,00.

O problema é que tem de ter duas portas de comunicação, sendo uma de baixa velocidade ( 1200 ) e a outra de alta velocidade ( 57600) . Além disto, tenho um Rotary encoder que funciona por interrupção.

Esse CI tem apenas 1 porta serial no hardware, então estou usando uma segunda porta por software ( o Bascom cria ela para mim sem nenhuma dificuldade ), e aí que a coisa complicou, pois o timing para decodificar via software uma serial a 57600 é muito crítico, sendo que qualquer interrupção tem de ser muito rápida para não atrapalhar. Trato as interrupções em Assembly, inclusive as conversões A/D de 3 entradas sendo que duas usam 2.56V como referência e a outra usa 5V , tensão gerada internamente, e dentro dessa interrupção faço as 3 leituras, espero os tempos necessários para estabilizar a referência de tensão, e ainda trato um sistema que calcula a média das ultimas 4 amostragens de cada canal do conversor, quase tudo em Assembly ( 95% ) para ganhar tempo.

O Bascom tem uma função que trata serial por hardware por interrupt, que me permite criar um buffer de um determinado tamanho, e ela vai recebendo os caracteres e só quando recebe um determinado caractere é que ela me avisa que tem um comando pronto no buffer para que eu possa tomar as providências.

Da mesma maneira, criei também um buffer de transmissão por interrupt, assim posso simplesmente mandar a minha string inteira na saída serial ( ou seja, me libera o programa imediatamente ) e essa função de buffer fica transmitindo caracter a caracter, de maneira automática, assim meu programa não fica parado esperando enviar um monte de dados pela serial a 1200 que é bem lenta.

Resumindo, usando esses buffers, e sinalizando por flags, evito que ocorram interrupções em trechos críticos, o que está fazendo o projeto seguir sem maiores percalços. É o que eu falei acima para você, de saber como usar o hardware, o software, as interrupts, sempre sinalizando por flags que serão tratados adequadamente no loop principal do programa.

Sobre um RTOS, eu e um colega criamos um em 1986, para o Z-80, com funções dedicadas ao controle de processos industriais. Na verdade, meu colega foi o criador, eu apenas codificava as funções do hardware para ele ( ele programava muito bem em alto nível mas se atrapalhava com o hardware ) , e isso facilitou muito todos os projetos que fizemos juntos na empresa. Era simples, pois no Z-80 as interrupções tem prioridades, assim conseguimos tratar com relativa facilidade. Já nos Avrs .... todas tem a mesma prioridade kkkkk ! Aí é bem complicado, mesmo para um RTOS ...

Hoje existem alguns sistemas desse tipo para AVR, eu nunca usei, mas deve ser interessante.

Paulo

test man*~ · 2 de agosto de 2017

19 horas atrás, aphawk disse:

O Bascom tem uma função que trata serial por hardware por interrupt, que me permite criar um buffer de um determinado tamanho, e ela vai recebendo os caracteres e só quando recebe um determinado caractere é que ela me avisa que tem um comando pronto no buffer para que eu possa tomar as providências.

Isso, eu usei essa função "bytematch" para fazer o painel de LEDs, inicialmente o robô também a usava mas tive que mudar por causa do CRC, visto que esse pode ser qualquer caractere de 0 a 255 (CRC8)... Talvez uma solução seria usar um CRC de 7 bits e colocar ele deslocado para a esquerda assim o CRC nunca seria o caractere do bytematch, foi a primeira vez que desenvolvi o CRC e também foi a primeira vez que o usei... Mais pra frente eu com certeza me depararei com esse problema, porém eu já estarei "armado" hehe.

Verificação de erro é muito bom, o código fica muito robusto!!

test man*~ · 9 de outubro de 2017

Ai Paulão @aphawk , quero apenas falar sobre algo que você disse em algum post ai pra trás, foi algo do tipo "[...] você possui um hardware muito poderoso [...]" você falou isso sobre o ATmega2560... Pois bem, você estava certo mesmo, estou no fim do curso Embedded Systems - Shape the World e percebi que a minha forma de programar era completamente errada, lembro de ter falado "[...] perdi o controle, um erro aparece e nem sei onde procurar [...]" e isso se deve a forma incorreta de programar.

Para fechar, realmente o ATmega2560 é um hardware extremamente poderoso... Acabei entrando pro mundo RC/FPV drones (ainda não montei, estou esperando as peças chegarem) e existe um flight controller, hoje um pouco ultrapassado, chamado APM que significa Arduino Pilot Mega e ele usa um ATmega2560, o que esse flight controller é capaz de fazer é impressionante, muito impressionante mesmo, chega a ser inacreditável. Provando o que você havia dito.

Para exemplificar, olha esse código, é um sinaleiro inteligente em um cruzamento com duas vias de mão única, incluindo o sinal para os pedestres e também sensores para presença dos carros e dos pedestres, olha só:

while(1){
  GPIO_PORTB_DATA_R = FiniteStateMachine[CurrentState].OutputForPortB;
  GPIO_PORTF_DATA_R = FiniteStateMachine[CurrentState].OutputForPortF;
  SysTick_Wait10ms(FiniteStateMachine[CurrentState].Time);
  Input = GPIO_PORTE_DATA_R & InputSensorMask;	
  CurrentState = FiniteStateMachine[CurrentState].NextState[Input];
}

Enfim, entrei no curso para aprender sobre microcontroladores ARM e acabei aprendendo, mas ainda não dominando, a forma correta de programar HAHAHA

aphawk · 10 de outubro de 2017

@test man*~ ,

O que vale são as experiências, elas te ensinam muito mais do que qualquer curso !

O mundo do FPV é fantástico, o uso de telemetria é imperativo, e ver como funciona essa troca de informações entre os sistemas de rádio é muito interessante !

Eu fiz uma brincadeira com um Atmega e Bascom que abria o protocolo usado pelos FRSKY, punha tudo num display lcd de 20x4 kkkk e aprendi bastante com isso.

O Pilot Mega é muito legal, tem alguns projetos de hardware feitos para ele que você mesmo monta e implementa, é uma bela diversão.

O conhecimento é acumulativo, você vai sempre aprendendo mais a cada dia, um dia são Atmegas, outro dia são Arms, e quem sabe o que mais virá em alguns anos, não é ?

O que importa é você perceber que o que você fez ontem pode sempre ser refeito de uma maneira melhor hoje, com menos sofrimento e menos tempo perdido !

Paulo

test man*~ · 12 de outubro de 2017

@aphawk Você continua voando? Ou parou?

Vou começar montado um hexacopter com a pixhawk e Gimbal... Minha ideia final para este projeto é controlador os movimentos da camera usando os movimentos da cabeça (dos goggles), especificamente para essa parte eu quero fazer o programa, daí modifico o rádio FS-I6X e vamos ver no que dá (MPU6050 + HMC5883L + HC-05 'transmitir do goggle para o rádio' + stm32f103c8t6 'placa stm32duino')... Vai ser até simples, bom... pelo menos eu espero. Depois desse vou ver se monto um racer.

Detalhe, nem sei pilotar drone UAhuHAuHUahA estou esperando chegar o simulador também.