Conversão A/D e transmissão Serial com Arduino DUE - Laboratorio de Garagem (arduino, eletrônica, robotica, hacking)2024-03-29T15:58:21Zhttps://labdegaragem.com/forum/topics/convers-o-a-d-e-transmiss-o-serial-com-arduino-due?commentId=6223006%3AComment%3A746684&xg_source=activity&feed=yes&xn_auth=noMinha sugestão (dada a situaç…tag:labdegaragem.com,2020-10-17:6223006:Comment:7642462020-10-17T21:44:14.493ZVitor Augustohttps://labdegaragem.com/profile/VitorAugusto
<p>Minha sugestão (dada a situação atual) é vc implementar o conceito de trigger na amostragem. Faça "packs" em torno do trigger, e envie os "packs".</p>
<p>Neste caso, o circuito pode deixar de fazer amostras enquanto envia o "pack" porque o sinal estará sincronizado no envio do próximo pack pelo trigger. As "perdas" (não amostragem) não irão prejudicar a visualização se a entrada for senóide periódica. Haverá momentos do sinal que não serão registrados, então vc precisa avaliar esta ideia…</p>
<p>Minha sugestão (dada a situação atual) é vc implementar o conceito de trigger na amostragem. Faça "packs" em torno do trigger, e envie os "packs".</p>
<p>Neste caso, o circuito pode deixar de fazer amostras enquanto envia o "pack" porque o sinal estará sincronizado no envio do próximo pack pelo trigger. As "perdas" (não amostragem) não irão prejudicar a visualização se a entrada for senóide periódica. Haverá momentos do sinal que não serão registrados, então vc precisa avaliar esta ideia baseado nas suas necessidades.</p>
<p>Sugiro vídeos no YouTube para entender o que é um trigger.</p> Existem vários projetos de Ar…tag:labdegaragem.com,2020-10-17:6223006:Comment:7643102020-10-17T19:59:08.687ZJosé Gustavo Abreu Murtahttps://labdegaragem.com/profile/GustavoMurta
<p>Existem vários projetos de Arduino Due osciloscopio na web:</p>
<p></p>
<p><a href="http://frenki.net/2013/10/fast-analogread-with-arduino-due/" rel="nofollow noopener" target="_blank">http://frenki.net/2013/10/fast-analogread-with-arduino-due/</a></p>
<p><a href="https://synapse.kyoto/hard/arduino-due-oscilloscope/page001.html" rel="nofollow noopener" target="_blank">https://synapse.kyoto/hard/arduino-due-oscilloscope/page001.html</a> (esta em japones, traduza com o Navegador…</p>
<p>Existem vários projetos de Arduino Due osciloscopio na web:</p>
<p></p>
<p><a rel="nofollow noopener" href="http://frenki.net/2013/10/fast-analogread-with-arduino-due/" target="_blank">http://frenki.net/2013/10/fast-analogread-with-arduino-due/</a></p>
<p><a rel="nofollow noopener" href="https://synapse.kyoto/hard/arduino-due-oscilloscope/page001.html" target="_blank">https://synapse.kyoto/hard/arduino-due-oscilloscope/page001.html</a> (esta em japones, traduza com o Navegador Chrome). </p>
<p><a rel="nofollow noopener" href="https://hmbd.wordpress.com/2017/06/08/an-arduino-due-based-oscilloscope-and-datalogger/" target="_blank">https://hmbd.wordpress.com/2017/06/08/an-arduino-due-based-oscillos...</a></p>
<p><a rel="nofollow noopener" href="https://hackaday.io/project/425-arduino-oscilloscope-688000-samplessec" target="_blank">https://hackaday.io/project/425-arduino-oscilloscope-688000-samplessec</a></p>
<p></p>
<p>e muito mais :</p>
<p><a rel="nofollow noopener" href="https://www.youtube.com/results?search_query=arduino+due+oscilloscope" target="_blank">https://www.youtube.com/results?search_query=arduino+due+oscilloscope</a></p>
<p></p> Boa tarde Thiago,
Não li to…tag:labdegaragem.com,2020-10-17:6223006:Comment:7641212020-10-17T19:40:30.689ZJosé Gustavo Abreu Murtahttps://labdegaragem.com/profile/GustavoMurta
<p>Boa tarde Thiago, </p>
<p></p>
<p>Não li todos os posts, mas parece que você pretende fazer um osciloscópio com o Arduino Due, correto?</p>
<p></p>
<p>"Eu desejo, inicialmente, ler sinais no LabView com uma banda de 0 à 1000Hz. Então pelo teorema de Nyquist, preciso ter pelo menos 2k Sa/s de frequência de amostragem." </p>
<p><strong>Incorreto! A frequência mínima do teorema de Nyquist serve somente se você for medir frequencia. Não serve para amostragem de um…</strong></p>
<p>Boa tarde Thiago, </p>
<p></p>
<p>Não li todos os posts, mas parece que você pretende fazer um osciloscópio com o Arduino Due, correto?</p>
<p></p>
<p>"Eu desejo, inicialmente, ler sinais no LabView com uma banda de 0 à 1000Hz. Então pelo teorema de Nyquist, preciso ter pelo menos 2k Sa/s de frequência de amostragem." </p>
<p><strong>Incorreto! A frequência mínima do teorema de Nyquist serve somente se você for medir frequencia. Não serve para amostragem de um osciloscópio</strong>. </p>
<p></p>
<p>Se você quer entender mais sobre frequência de amostragem, sugiro a leitura desses artigos da Analog Devices:</p>
<p><a rel="nofollow noopener" href="https://www.analog.com/media/en/technical-documentation/application-notes/60452436005220859872700115159829353257206974259641368301086579520703792632610264805090AN282.pdf" target="_blank">Fundamentals of Sampled Data Systems</a></p>
<p><a rel="nofollow noopener" href="https://www.analog.com/media/en/training-seminars/tutorials/MT-002.pdf" target="_blank">What the Nyquist Criterion Means to Your Sampled Data System Design</a></p>
<p></p>
<p><strong>Na realidade se você quer medir um sinal com frequencia máxima de 1000 Hz, precisará de uma frequência de amostragem de 10 a 20 vezes essa frequência, isto é 10 Ksps ou 20Ksps. (kilo samples per second). </strong></p>
<p></p>
<p></p> O Arduino DUE é capaz de faze…tag:labdegaragem.com,2020-10-17:6223006:Comment:7638612020-10-17T15:03:12.619ZRodrigo Corberahttps://labdegaragem.com/profile/RodrigoCorbera
<p>O Arduino DUE é capaz de fazer muito melhor que 200Hz....</p>
<p></p>
<p>Dá uma olhada neste link de um programa que lê a porta analógica e calcula FFT :</p>
<p><a href="https://github.com/dujianyi/ardFFT"></a><a href="https://github.com/dujianyi/ardFFT" target="_blank">https://github.com/dujianyi/ardFFT</a></p>
<p></p>
<p>O Arduino DUE é capaz de fazer muito melhor que 200Hz....</p>
<p></p>
<p>Dá uma olhada neste link de um programa que lê a porta analógica e calcula FFT :</p>
<p><a href="https://github.com/dujianyi/ardFFT"></a><a href="https://github.com/dujianyi/ardFFT" target="_blank">https://github.com/dujianyi/ardFFT</a></p>
<p></p> Olá Elcids, obrigado por toda…tag:labdegaragem.com,2020-10-16:6223006:Comment:7624542020-10-16T01:37:09.726ZThiagohttps://labdegaragem.com/profile/Thiago977
<p><span style="font-size: 14pt;">Olá Elcids, obrigado por toda a ajuda. Desculpe pela demora em responder. Já tive mais avanços com sua ajuda.</span></p>
<p><span style="font-size: 14pt;">Eu desejo, inicialmente, ler sinais no LabView com uma banda de 0 à 1000Hz. Então pelo teorema de Nyquist, preciso ter pelo menos <strong>2k Sa/s de frequência de amostragem.</strong> Gostaria de futuramente utilizar algoritmos para processamento do sinal aquisitado, como medir amplitude, frequência, Trigger…</span></p>
<p><span style="font-size: 14pt;">Olá Elcids, obrigado por toda a ajuda. Desculpe pela demora em responder. Já tive mais avanços com sua ajuda.</span></p>
<p><span style="font-size: 14pt;">Eu desejo, inicialmente, ler sinais no LabView com uma banda de 0 à 1000Hz. Então pelo teorema de Nyquist, preciso ter pelo menos <strong>2k Sa/s de frequência de amostragem.</strong> Gostaria de futuramente utilizar algoritmos para processamento do sinal aquisitado, como medir amplitude, frequência, Trigger e realizar uma FFT (tentando ver o Spectrum em tempo real se possível).</span></p>
<p><span style="font-size: 14pt;">Comecei a fazer os testes com o algoritmo que você me enviou. Vi que o separa em funções, realmente fica muito mais “organizado”.</span></p>
<p><span style="font-size: 14pt;">Inicialmente comecei ajustando o PACK DE AMOSTRAS e o TEMPO DE AMOSTRAGEM, tentando chegar na melhor combinação possível para obter um sinal com uma resolução aceitável e com continuidade para todo o sinal analógico de entrada.</span></p>
<p><span style="font-size: 14pt;">Meu sinal analógico de entrada corresponde de uma senóide, em que vario de 10Hz à 1k Hz.</span></p>
<p><span style="font-size: 14pt;">A melhor combinação que consegui buscando estes parâmetros foi para:</span></p>
<p><span style="font-size: 14pt;">PACK DE AMOSTRAS: 200</span></p>
<p><span style="font-size: 14pt;">TEMPO DE AMOSTRAGEM (us): 100</span></p>
<p><span style="font-size: 14pt;"><strong>Como resposta obtive uma continuidade perfeita e uma boa resolução, mas somente para frequências até 200 Hz</strong>. Acima de 200 Hz começa haver a descontinuidade do sinal e perda de resolução. Pela teoria, considerando todo o sistema perfeito, teria uma frequência de amostragem de 2M SAMPLES por segundo. Descontando a performance do sistema esperava uma faixa de frequência mais alta.</span></p>
<p><span style="font-size: 14pt;">Tentei deixar meu algoritmo no Labview está o mais enxuto possível, e algo que não estou entendendo direito é que ele lê sempre metade do PACK DE AMOSTRAS do Arduino, neste caso 100. Mesmo assim esperava leituras de frequências mais altas. O que poderia está acontecendo Elcids?</span></p>
<p><span style="font-size: 14pt;">Att.</span></p> olá novamente Thiago.
…tag:labdegaragem.com,2020-10-05:6223006:Comment:7531422020-10-05T17:54:23.526ZElcids Chagashttps://labdegaragem.com/profile/ElcidsChagas
<p><span style="font-size: 12pt;">olá novamente Thiago.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Legal que o link te ajudou a ir um pouco mais à frente, permitindo vc receber no <em><strong>LabView</strong> </em>os valores já em "<em><strong>binário puro</strong></em>". Fique atento à questão do "<em><strong>Endian</strong></em>", pois se vc usar um outro Computador não baseado em x86, poderá ter problemas (o código no <em><strong>Due</strong></em> está enviando dados em…</span></p>
<p><span style="font-size: 12pt;">olá novamente Thiago.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Legal que o link te ajudou a ir um pouco mais à frente, permitindo vc receber no <em><strong>LabView</strong> </em>os valores já em "<em><strong>binário puro</strong></em>". Fique atento à questão do "<em><strong>Endian</strong></em>", pois se vc usar um outro Computador não baseado em x86, poderá ter problemas (o código no <em><strong>Due</strong></em> está enviando dados em "<em><strong>little endian</strong></em>", mas caso precise mudar para "<em><strong>big endian</strong></em>", isto é simples e requer apenas uma única linha a mais no código).</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Sobre a questão da <em><strong>continuidade na visualização do Sinal</strong></em>, o que está ocorrendo é bastante claro: são aqueles motivos que te expliquei no chat do LDG. E quando vc "<em>forçou</em>" a <em><strong>frequência</strong></em> do <em><strong>Sinal</strong></em> (que no caso vc relatou sendo <em><strong>1.7 kHz</strong></em>), vc fez coincidir o <em><strong>período do Sinal</strong></em> com o período do ciclo da atual <em><strong>Taxa de Amostragem</strong></em> do seu Sistema (que na verdade não estava "imposta", mas sim "correndo livre"). Isto não é adequado e nem bom, porque vc está dependente do próprio sinal pra garantir a continuidade.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Veja o que vc precisa fazer: deve determinar qual a <em><strong>frequência máxima de sinal</strong></em> vc deseja visualizar no <em><strong>LabView</strong></em>, com uma certa "qualidade" na visualização. Então deve escolher um <span style="text-decoration: underline;"><em><strong>tamanho</strong></em></span> do "<em><strong>Pack de Amostras consecutivas</strong></em>" adequado. Para isso, deve determinar o <strong><em>tempo</em> </strong>que o "<em><strong>Native USB</strong></em>" gasta para enviar esse <em><strong>Pack</strong></em>, e esse tempo <span style="text-decoration: underline;"><em>deve</em></span> estar de acordo com o <em><strong>total de amostras dentro de um único ciclo do Sinal</strong></em> na <em><strong>máxima frequência</strong></em> que vc determinou no início. Sei que pode parecer confuso, mas leia com atenção o que acabei de escrever e vc irá entender. Mas de fato, isto não é tão fácil de explicar aqui em poucas linhas de texto.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Eu preparei um código que faz o "básico" do que descrevi acima. Vc pode usá-lo para testar com o <strong>LabView</strong>, exatamente como fez com o seu último código para o "<em><strong>Native USB</strong></em>". Então, analisando o comportamento e a forma como isso funciona, vc pode expandir a coisa de forma a conseguir resultados melhores e que te atendam.</span></p>
<p><span style="font-size: 12pt;"> <span style="text-decoration: underline;"><em><strong>Veja</strong></em></span>: para isto dar certo do jeito que está implementado neste código, é preciso que o Mecanismo de recepção dos Packs no lado do Computador (ou seja, no lado do <em><strong>Labview</strong></em>) esteja eficiente e consiga receber e processar as amostras rápido o bastante. Se isso estiver ok, vc verá sinais contínuos na tela gráfica do LabView. Claro há um limite na frequência do Sinal, e isso depende da "qualidade" que vc quer ver na tela (uma vez que atualmente vc está plotando as amostras brutas, <span style="text-decoration: underline;"><em>sem aplicar</em></span> <em><strong>Processamento de Sinal</strong></em>). Em um cálculo bruto, eu acredito que sinais de até uns <em><strong>4 kHz</strong></em> poderão ser observados com relativa "qualidade", usando o código que preparei.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> É este código: <a href="https://storage.ning.com/topology/rest/1.0/file/get/8004143272?profile=original" target="_blank" rel="noopener">"<em><strong>ADC_DUE_Native_USB_02.zip</strong></em>"</a> </span></p>
<p></p>
<p></p>
<p><span style="font-size: 12pt;"> <span style="text-decoration: underline;"><em>Um detalhe importante</em></span>: no seu código vc estava usando a quantidade errada para o <em><strong>tamanho de um Pack</strong></em> enviado via "<em><strong>Native USB</strong></em>". Lá vc enviou "<em><strong>512</strong></em>" bytes, e este é mais um motivo para descontinuidade, porque vc estava aquisitando <em><strong>2000 bytes</strong></em>, ou seja, <em><strong>1000 amostras contínuas</strong></em>. Mas vc estava enviando apenas as primeiras <em><strong>256 amostras</strong></em> (512 bytes) do seu Pack aquisitado. Claro, corrigir isso não irá resolver o problema da descontinuidade, mas de fato vc estava enviando Packs incompletos e isso já provoca uma descontinuidade "forçada".</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Por favor, leia com atenção todo o texto, e também os comentários no próprio código, pois irão ajudar. E mantenha seu código organizado, evitando algumas vícios que não são considerados "boa prática de programação" (eu encontrei alguns no seu código).</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Abrçs,</span></p>
<p><span style="font-size: 12pt;"> Elcids</span></p> Olá Elcids, tive alguns avanç…tag:labdegaragem.com,2020-10-04:6223006:Comment:7524092020-10-04T19:44:26.771ZThiagohttps://labdegaragem.com/profile/Thiago977
<p>Olá Elcids, tive alguns avanços na transmissão USB do Arduino DUE para o LabView. Adaptei o programa de transmissão USB daquele link que vc me enviou, para o meu programa. Consegui realizar a transmissão para o LabView via USB, mas encontrei as seguintes respostas. Apliquei senóides no conversor AD com frequências de 1kHz, 1.6kHz, 1.7kHz e 5kHz. Notei que ainda há descontinuidades em intervalos aparentemente constantes, mas para a frequência de 1.7kHz a senóide se encaixou perfeitamente e…</p>
<p>Olá Elcids, tive alguns avanços na transmissão USB do Arduino DUE para o LabView. Adaptei o programa de transmissão USB daquele link que vc me enviou, para o meu programa. Consegui realizar a transmissão para o LabView via USB, mas encontrei as seguintes respostas. Apliquei senóides no conversor AD com frequências de 1kHz, 1.6kHz, 1.7kHz e 5kHz. Notei que ainda há descontinuidades em intervalos aparentemente constantes, mas para a frequência de 1.7kHz a senóide se encaixou perfeitamente e consigo vê-la perfeitamente no gráfico. Quando vou variando a frequência parece que há um desencaixe e a descontinuidade aparece novamente. Acho que o problema agora não é devido a "lentidão" da transmissão. Estou colocando meu código em anexo, acho que deva ser alguma configuração errada que eu esteja fazendo. Em seguida segue as imagens dos gráficos das senóides que aquisitei de 1.6k e 1.7k respectivamente:</p>
<p><a href="https://storage.ning.com/topology/rest/1.0/file/get/7999580253?profile=original" target="_blank" rel="noopener"><img src="https://storage.ning.com/topology/rest/1.0/file/get/7999580253?profile=RESIZE_710x" class="align-center"/></a></p>
<p><a href="https://storage.ning.com/topology/rest/1.0/file/get/7999582266?profile=original" target="_blank" rel="noopener"><img src="https://storage.ning.com/topology/rest/1.0/file/get/7999584878?profile=RESIZE_710x" class="align-center"/></a></p> olá Thiago.
Sobre a im…tag:labdegaragem.com,2020-09-29:6223006:Comment:7470402020-09-29T05:12:01.235ZElcids Chagashttps://labdegaragem.com/profile/ElcidsChagas
<p><span style="font-size: 12pt;">olá Thiago.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Sobre a implementação usando o "<em><strong>Native USB</strong></em>" do <em><strong>Due</strong></em>, é algo até simples de fazer. Mas tem alguns detalhes técnicos como a questão do "<strong><em>Endian</em></strong>", que deve estar de acordo com quem recebe os dados (no seu caso, o <em><strong>LabView</strong></em>, executando provavelmente em <em><strong>x86</strong></em>, e neste caso…</span></p>
<p><span style="font-size: 12pt;">olá Thiago.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Sobre a implementação usando o "<em><strong>Native USB</strong></em>" do <em><strong>Due</strong></em>, é algo até simples de fazer. Mas tem alguns detalhes técnicos como a questão do "<strong><em>Endian</em></strong>", que deve estar de acordo com quem recebe os dados (no seu caso, o <em><strong>LabView</strong></em>, executando provavelmente em <em><strong>x86</strong></em>, e neste caso usando "<em><strong>little endian</strong></em>"). Mas em suma é tranquilo.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Sobre a questão de aumentar o <em><strong>Buffer</strong></em> do <em><strong>TX</strong></em>, não perca tempo com isso, pois não irá adiantar. A questão mesmo é <em><strong>reduzir o tempo de envio do Pack de Dados</strong></em>, e então casar o <em><strong>Ciclo de Amostragem</strong></em> conforme esse tempo. Isso também é algo simples, mas não dá pra explicar por texto aqui neste post, pois demoraria um tanto. Então irei te explicar sobre isso via Skype e depois postamos resultados e conclusões.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Como eu disse anteriormente, neste momento acho que vc deve continuar com o <strong>Due</strong>, pois ele tem condições de fazer isso, se for usada a técnica adequada. E o problema nem é tanto a performance da <em><strong>CPU</strong></em>, mas sim o tempo de transmissão dos dados. O <em><strong>Teensy</strong> <strong>3.2</strong></em> é mais rápido que o <em><strong>Due</strong></em>, mas essa velocidade adicional <span style="text-decoration: underline;"><em>não</em></span> terá impacto na velocidade de transmissão dos dados.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Sobre usar o "<em><strong>Native USB</strong></em>" do <em><strong>Due</strong></em>, encontrei um post no fórum do "arduino.cc", onde algumas pessoas fizeram isso, e postaram código e algumas dicas importantes sobre como implementar isso, e que podem ajudar muito (inclusive tem gente lá que também usou o <em><strong>LabView</strong></em>). D</span><span style="font-size: 12pt;">ê uma olhada pois ajudará no processo. É esse aqui: <a rel="nofollow noopener" href="https://forum.arduino.cc/index.php?topic=379897.0" target="_blank">"<em><strong>DUE Native USB communication</strong></em>"</a></span></p>
<p></p>
<p><span style="font-size: 12pt;"> Abrçs,</span></p>
<p><span style="font-size: 12pt;"> Elcids</span></p> Olá Elcids, vc descreveu perf…tag:labdegaragem.com,2020-09-28:6223006:Comment:7466842020-09-28T21:13:37.845ZThiagohttps://labdegaragem.com/profile/Thiago977
<p>Olá Elcids, vc descreveu perfeitamente o que está acontecendo.</p>
<p>Estou tentando entender mais sobre o funcionamento do comando Serial.write(), desta forma poderia enviar minhas amostras como bits conforme vc mencionou.</p>
<p>Há alguma forma de eu aumentar o BUFFER do Tx, talvez isso poderia desafogar um pouquinho. </p>
<p>Essa porta NATIVE USB do DUE poderia ser a salvação mesmo pois a transmissão USB é muito rápida. Eu teria que estudar como poderia ler essas amostras pelo LabView via…</p>
<p>Olá Elcids, vc descreveu perfeitamente o que está acontecendo.</p>
<p>Estou tentando entender mais sobre o funcionamento do comando Serial.write(), desta forma poderia enviar minhas amostras como bits conforme vc mencionou.</p>
<p>Há alguma forma de eu aumentar o BUFFER do Tx, talvez isso poderia desafogar um pouquinho. </p>
<p>Essa porta NATIVE USB do DUE poderia ser a salvação mesmo pois a transmissão USB é muito rápida. Eu teria que estudar como poderia ler essas amostras pelo LabView via USB.</p>
<p>Sobre outros microcontroladores, o que vc acha do Teensy 3.2, será que com ele ficaria mais fácil a fluidez da transmissão?</p>
<p>Att. </p> olá Thiago.
Fiz mediçõ…tag:labdegaragem.com,2020-09-26:6223006:Comment:7448262020-09-26T16:36:18.348ZElcids Chagashttps://labdegaragem.com/profile/ElcidsChagas
<p><span style="font-size: 12pt;">olá Thiago.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Fiz medições usando seu código, e pude confirmar na prática o que eu havia deduzido pela avaliação das LIBs do <em><strong>Due</strong></em>.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> De fato o problema é por causa do <em><strong>Queue</strong></em> da <em><strong>Serial</strong></em>, que fica "entupido" por um bom período, o que acaba causando descontinuidade na…</span></p>
<p><span style="font-size: 12pt;">olá Thiago.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Fiz medições usando seu código, e pude confirmar na prática o que eu havia deduzido pela avaliação das LIBs do <em><strong>Due</strong></em>.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> De fato o problema é por causa do <em><strong>Queue</strong></em> da <em><strong>Serial</strong></em>, que fica "entupido" por um bom período, o que acaba causando descontinuidade na aquisição.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Mas independente disso, conforme te expliquei no chat aqui no LDG, mesmo que vc aumentasse em 10x a velocidade da Serial, ainda assim iria ocorrer descontinuidade (por motivos técnicos que não descrevo agora aqui porque demoraria muito e consumira uma boa quantidade de texto).</span></p>
<p><span style="font-size: 12pt;"> Então para tratar isso, é preciso usar outras técnicas. Mas como vc está usando o <em><strong>MathLab</strong></em>, isso já ajuda bastante, pois há algumas possibilidades adicionais (uma delas por exemplo, é enviar os dados na forma de "<em><strong>binário puro</strong></em>", ao invés de enviar <em><strong>strings ASCII</strong></em> como está sendo feito no seu código atual).</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Lá pelo contato via Skype, te auxiliarei de forma mais eficiente, e então depois podemos postar os resultados aqui.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Sobre o gráfico que vc postou, é exatamente como eu tinha imaginado. Quando fizemos o cálculo do número de ciclos visualizados para uma senóide de 40kHz, eu considerei que o loop de aquisição não demorava mais que 1us em cada passagem, pois o <em><strong>ADC</strong></em> do <em><strong>Due</strong></em> tem taxa de 1MHz e considerei que o <em><strong>Compilador C++</strong></em> gerou um código bem otimizado. Porém ao fazer as medições, revelou-se que está demorando <em><strong>1.5us</strong></em>, o que significa que o código gerado pelo <em><strong>Compilador C++</strong></em> não está tão otimizado (já que a taxa do ADC ainda é 1MHz e a conversão AD está programada para ser automática, e isto ocorre em paralelo com a execução do código). Como são 1000 amostras, então cada ciclo completo de aquisição demora <em><strong>1,5 ms</strong></em>, e você terá um pouco mais de ciclos da senóide que o valor que calculamos inicialmente (neste caso o número de ciclos será <em><strong>60 = 1.5ms * 40KHz</strong></em>).</span></p>
<p><span style="font-size: 12pt;"> A posição da descontinuidade no gráfico é aleatória, uma vez que o tempo de transmissão dos caracteres via Serial irá variar (mas em média são aqueles 6000 caracteres conforme demonstrei anteriormente), resultando em "gaps" de duração ligeiramente flutuantes. E também devido ao "desincronismo" entre aquisição e exibição.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Bem, agora é preciso aplicar as técnicas adequadas para tratar isso. Mas uma delas me ocorreu de repente, e ao consultar a documentação do <em><strong>Due</strong></em> vi que era uma possibilidade. É sobre usar o "<em><strong>Native USB</strong></em>" do Due (que é <em><strong>USB "HiSpeed"</strong></em>, ou seja <em><strong>480Mbps</strong></em>), ou seja, é uma <em><strong>Serial</strong></em> efetivamente <em><strong>Virtual</strong> </em>em ambas as extremidades (<em><strong>Due</strong></em> e <em><strong>PC</strong></em>). Mas aí dependerá também do código executado no PC ter buferizações e temporizações adequadas). Assim que possível te explico melhor.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> <span style="text-decoration: underline;"><em><strong>Importante</strong></em></span>: eu já tinha olhado inúmeras vezes as <em><strong>LIBs</strong></em> da implementação <em><strong>Serial</strong></em> no <em><strong>Arduino</strong></em>. Mas nunca me atentei para analisar com mais cuidado a questão do "entupimento" do <em><strong>Queue</strong> do</em> <em><strong>TX</strong></em> (porque eu quase sempre tomo os cuidados para evitar isso no código). Mas agora depois de ter visto o comportamento no <em><strong>Due</strong></em>, fiquei curioso sobre se a implementação da <em><strong>LIB Serial</strong></em> no <em><strong>AVR</strong></em> (<em><strong>UNO</strong></em>, <em><strong>Mega</strong></em>, <em><strong>Nano</strong></em>, etc) teria o mesmo comportamento. Então fui olhar isto. E advinha: na implementação para o <strong><em>AVR</em> </strong>ocorre o mesmo comportamento. Isto significa que quando enviamos uma "tonelada" de dados via <em><strong>Serial</strong> </em>causando o "entupimento" do <em><strong>TX</strong></em>, nenhum dado deixará de ser transmitido, mas também por consequência a função de envio (<em><strong>print</strong></em>, <em><strong>println</strong></em>, <em><strong>write</strong></em>, etc) "trava" o processamento aguardando que o <em><strong>Queue</strong></em> do <em><strong>TX</strong> </em>fique pelo menos um byte livre, mas <span style="text-decoration: underline;"><em>efetivamente</em></span> o processamento do código acabará ficando "travado" dentro das funções de envio <em><strong>até que todos os bytes tenham sido transmitidos</strong></em>. Então é aconselhável ter ciência disto. Para o <em><strong>ESP32</strong> </em>eu não analisei, mas lá também são "<em>dois cores</em>", o que pode significar que esta "limitação" <em>talvez</em> não ocorra.</span></p>
<p></p>
<p><span style="font-size: 12pt;"> Abrçs,</span></p>
<p><span style="font-size: 12pt;"> Elcids</span></p>