Hoje trabalhei menos que os outros dias, mas o dia foi produtivo, finalmente os dados foram enviados via socket!
O que foi fetio hoje:
Hoje o ZigBee teimou em fazer o seu mistério de não capturar dados e disponibilizar para o Nios II. Na verdade não consegui descobrir ainda a origem desse mistério (por isso é um mistério dâaaa)... O problema tanto pode ser do módulo zigbee quanto da FPGA com o Nios. O que acontece é que os dados não são recebidos e mostrados no terminal. Da ultima vez que isso aconteceu eu iniciei do início fazendo um software chamado teste_01 com a arquitetura 5. Com relação aos testes que necessitavam ser realizados hoje, fiz apenas um que foi colocando o tx_wr_pos para receber o buffer mas o mistério começou e tive que parar novamente. Tentei com o teste_01 e deu errado também, só saíram zeros mas ao tirar o zigbee da placa e colocar de novo ele voltou a funcionar, é como se algum buffer enchesse por causa que o nios não está recebendo ou algo do tipo.
Vamos agora aos testes novamente:
Teste para ver quantos são impresos:
Por volta de 134 valores foram recebidos e enviados para o socket. Depois disso o terminal nios deixa de mostrar os dados que foram enviados para o socket mas o mesmo continua imprimindo como se fosse algum lixo e depois começa a mostrar o lixo de memória.
Teste limpando o buffer com a variável tx_wr_pos:
Depois de conseguir colocar o zigbee para funcionar tentei novamente com a variável tx_wr_pos fazendo ela receber tx_buf. Deu certo, o socket permaneceu recebendo os dados por tempo indeterminado. Enretanto, após um certo tempo os valores começaram vir aleatórios, acho que isso ocorre porque a thread de escrita no socket executa mais rápido que a de aquisição de dados do zigbee. Se aumentar o TK_Sleep também parece não dar certo mas faltam alguns testes. O extranho é que quando dá esse erro ficam vindo valores muito altos e mesmo ao parar e executar o software de novo, os valores altos vêm logo no início.
Metas para Amanhã:
Testes com o sistema para saber de onde vem esse erro dos dados com valores altos e testas a aquisição através do código em java para saber se dessa vez não irá imprimir o lixo de memória também.
Vamos agora aos testes novamente:
Teste para ver quantos são impresos:
Por volta de 134 valores foram recebidos e enviados para o socket. Depois disso o terminal nios deixa de mostrar os dados que foram enviados para o socket mas o mesmo continua imprimindo como se fosse algum lixo e depois começa a mostrar o lixo de memória.
Teste limpando o buffer com a variável tx_wr_pos:
Depois de conseguir colocar o zigbee para funcionar tentei novamente com a variável tx_wr_pos fazendo ela receber tx_buf. Deu certo, o socket permaneceu recebendo os dados por tempo indeterminado. Enretanto, após um certo tempo os valores começaram vir aleatórios, acho que isso ocorre porque a thread de escrita no socket executa mais rápido que a de aquisição de dados do zigbee. Se aumentar o TK_Sleep também parece não dar certo mas faltam alguns testes. O extranho é que quando dá esse erro ficam vindo valores muito altos e mesmo ao parar e executar o software de novo, os valores altos vêm logo no início.
Metas para Amanhã:
Testes com o sistema para saber de onde vem esse erro dos dados com valores altos e testas a aquisição através do código em java para saber se dessa vez não irá imprimir o lixo de memória também.
Nenhum comentário:
Postar um comentário