Olá,
Neste post eu vou contar um pouquinho da minha pequena aventura com a KwikStik, uma plaquinha de desenvolvimento da Freescale para o microcontrolador Kinetis K40X256, um Cortex-M4 com inúmeros periféricos, dentre eles interface USB OTG, controlador de LCD, módulo sensor de toque e muitos, muitos outros.
O kit em si é bastante interessante, podendo ser utilizado sozinho ou na plataforma TOWER da Freescale. Ele possui um display LCD com 306 segmentos, interface JTAG Segger USB (para depuração e gravação) integrada, interface USB (ligada ao MCU), comunicação IR, conector para cartão MicroSD, microfone, buzzer e amplificador de áudio e saída P2, seis pads que funcionam como sensores de toque e conectores de expansão.
Após receber o kit, constatei que o mesmo não veio com a aplicação de demonstração gravada na flash do MCU, consultei o DVD que acompanha o mesmo e descobri que o software necessário não estava lá! Como eu já uso (e gosto) o Codewarrior 10.1 para programar os micros da linha HCS08 e Coldfire v1, decidi utilizar a mesma ferramenta com o Kinetis. Ahhh, esqueci de dizer: rodo o CW 10.1 em uma VM do Windows XP utilizando o VMWare Player 4.0.1!
Primeiramente instalei o MQX, um sistema operacional de tempo real disponibilizado pela Freescale e que é utilizado pela aplicação de demonstração do kit. Após isso tentei instalar o patch do MQX para o kit e descobri que o mesmo somente funciona com o MQX 3.7 e eu havia baixado o MQX 3.8, que é a versão disponível no site da Freescale.
Desinstalei o MQX 3.8 e após procurar localizei rapidamente o MQX 3.7 e baixei o mesmo. Aí então instalei o patch com sucesso. Agora bastaria compilar o programa e pronto… Pronto? Não, infelizmente eu não consegui compilar o programa. Aparentemente o mesmo ocupa mais memória que a minha licença free do CW 10.1 me permite compilar… 🙁
Depois desta desilusão, lembre que havia visto que existia uma versão do BRTOS, um sistema operacional de tempo real e código aberto genuinamente brasileiro, portada para o Kinetis K40 e inclusive adaptada para a KwikStik!
Após baixar o demo, compilá-lo com sucesso e gravar no Kinetis, finalmente pude ver a minha KwikStik ganhar “vida”!
O demo implementado pelo pessoal do BRTOS utiliza alguns dos recursos da KwikStik, permitindo reproduzir sons WAV gravados em um cartão MicroSD, além de apresentar alguns dados no LCD e implementar um terminal serial USB que aceita comandos para interagir com o programa!
Brinquei um pouquinho com o demo e decidi modificar o programa para rodar um pequeno código Hello World…
A idéia era basicamente remover as tarefas que o programa demo criava e criar apenas uma tarefa para apresentar o famoso “Hello World” no LCD.
Pois bem, removi as tarefas, criei uma tarefa “LCD_Task” mais simples e modifiquei o arquivo “main.c” para instalá-la… Dei um BUILD no projeto e após dezenas de pedidos de licença do compilador (todos devidamente cancelados), nenhum erro (ufa!), baixei o programa para o MCU, mas ao executar a aplicação iniciava e subitamente parava numa ISR default. Após estudar o código percebi que aquela função (isr_default) é chamada por todas as interrupções não definidas no MCU (e são MUITAS)… Após estudar o programa demo, percebi que a tarefa “System_Time” fazia uma chamada a função RESET_WATCHDOG… Hmmm, então será que o watchdog do MCU estava ativo e causando um reset na minha aplicação?
O primeiro teste que fiz foi desativar o watchdog via define no arquivo BRTOSConfig.h, mas o problema persistiu… Nesta altura eu já havia vasculhado todo o código a procura de alguma interrupção de periférico que estive habilitada, mas não achei nada.
Decidi então criar uma segunda tarefa, dedicada apenas a fazer a manutenção do watchdog. A nova tarefa (que eu chamei de IDLE_Task) possui o seguinte código:
void IDLE_Task(void) { for(;;) { RESET_WATCHDOG(); DelayTask(10); } }
A inclusão desta tarefa finalmente corrigiu o problema e permitiu que a aplicação fosse executada corretamente… Ufa!
Bom, o código desta simples aplicação encontra-se abaixo.
Alguns comentários finais:
1- É uma pena mas a Freescale ainda não disponibiliza amostras dos Kinetis! 🙁
2- Seria interessante corrigir o BRTOS para que ao definir o watchdog como desativado, isto realmente ocorresse, mas este é realmente um detalhe que deve ter passado despercebido. O problema ocorreu porque, apesar de apagar o watchdog no loop da tarefa do LCD, as chamadas a DelayTask() feitas dentro do loop da mesma tarefa acabam provocando o estouro do watchdog…