Felipe Electronic

hahahahahah! Me lembrou a turma do laboratorio de sistemas integraveis da USP, vou te dar uma boa noticia então, da pra fazer com um único PIC toda a implementação de uma ECU, inclusive algumas turmas da graduação lá conseguiram implementar e rodar com o carro. Mas vamos ao seu projeto, ainda acho muito usar um FPGA para isso (embora eu tenha vontade de fazer uma ECU toda descrita em hardware), um algoritmo muito simples que usamos para sincronismo, é comparar constantemente a medida da porta CCP (sim ela que é usada para essa medida) com uma um valor de referência (no caso 2x o tempo, ja quea roda de 60 dentes possui na verdade 58 com dois dentes "falhados"), esse tipo de algoritmo nao serve para você? pois uma vez detectado o dente 0 (PMI) rodar o ciclo otto pode ser feito por contas e estimativa de acordo com um trigger vindo da interrupção da CCP, cada trigger incrementa o numero de dentes, quando ultrapassar 58, zera e começa de novo. O ponto de sincronismo que considero mais critico é o do avanço de ignição, onde além de respeitar o ponto de geração de faisca com antecedencia ao PMI, voce tem de lavar em conta o tempo de carga da sua bobina (voce tem o modelo matematico e elétrico dela?) chamado de dwell time. Bem, é um assunto de muita discussão, se puder compartilhar mais do projeto com a gente, podemos ajudar bem mais. Abs.

Precisa mesmo? Veja que a maioria do trabalho do teu sistemas é feito via hardware. Como disse antes, os PICs de 40 pinos como o jurássico 16f877A ou um mais recente como o 18f4550, possuem 3 portas CCPs, permitindo você fazer o que quer. Qual o atraso máximo permissível entre comparação das frequências e ajuste? Abs.

@Matheus_LPS, isso funciona ja até usei o artificio, o grande problema é o erro acumulado, pois se gasta ciclos para congelar a leitura do timer, além de tratar o vetor de interrupção, no caso da porta CCP, o resultado é congelado no exato momento de ocorrência da borda. Sobre a dúbvida, é possivel desde que voce tenha dois modulos CCPS independentes, pois o PWM usa o TIMER2 para base de tempo, ao passo que a Captura usa o timer1 para efetuar a captura do evento. Abs.

Rafaela, que assunto bruto hein. Mas vamos por partes, equações diferenciais em um primeiro momento você não calcula em tempo real dentro de um microcontrolador (ainda mais um PIC que nem multiplicar sabe, rs), voce pode utilizar as mesmas para obter o comportamento de um determinado fenômeno fisico, a partir desse comportamento você pode obter parâmetros para atuar sobre ele ou mensurar através de sensores. Em sistemas embarcados em geral, a partir de um modelo gerado por um conjunto de equações diferencias, você determina se irá controlar (controle PID, compensadores avanço e atraso de fase), se irá estimar (estimadores, modelos de markov, filtros kalmman), ou modificar (filtros digitais e transformadas), esses tópicos você irá para uma representação digital de equações diferenciais chamadas de equações de diferenças que são basicamentes, polinômios. Se esta querendo algum modelo matemático, eu sugiro que não invente e use ferramentas especiais para isso como o Matlab e versões abertas como scilab e Octave, com ele voce tera possibilidae de modelar sistemas além de simular em dominios continuos e discretos (esse ultimo tem tudo a ver com processamento digital de sinais). Seguem alguns tutoriais para apreciação dessas ferramentas: http://web2.clarkson.edu/class/ma571/Xeno-MATLAB_guide.pdf http://mars.uta.edu/mae3183/simulation/SciLab_for_Dummies.pdf Agora sobre cáculos matemáticos, como seno, cosseno e outros, se esta a programar em C, o compilador fornece em conjunto com a sua libc o header math.h, que realiza essas funções em ponto flutuante, se memoria e velocidade não for seu problema maravilha, senão vais ter que apelar para algoritmos otimizados para seu microcontrolador (e olha otimizar qualquer coisa pra PIC é uma baita tarefa). Veja a referencia das funções que math.h te oferece: http://www.nongnu.org/avr-libc/user-manual/math_8h.html E para ajudar, segue uma boa biblioteca em ponto fixo: https://savannah.nongnu.org/projects/fixmath Espero que tenha esclarecido um pouco as suas duvidas. Abs

Só um toque crianças. Quando for fazer média de leituras em microcontrolador como o PIC, prefiram coletar um numero de amostras cujo o valor seja uma potencia de 2, pois uma divisão no PIC não ocorre por hardware ou seja o compilador vai la e coloca uma subrotina para isso que vai demorar váaaaaaaarios ciclos de clock, ao passo que usar uma potencia de 2 a coisa é muito mais rápido pois a divisão pode ser feita com shifts para direita nativo do set de instruções do PIC. POr exemplo, nao façam assim: uint8_t i;uint16_t acumuladorMedia = 0;for ( i = 0; i < 30 ; i ++) //30 nao e uma potencia de 2{ acumuladorMedia += read_adc();}acumuladorMedia = acumuladorMedia/30; //e agora faça o pobre do PIC suar para calcular essa div Prefiram isso: uint8_t i;uint16_t acumuladorMedia = 0;for ( i = 0; i < 32 ; i ++) //32 e uma potencia de 2, 2^5{ acumuladorMedia += read_adc();}acumuladorMedia = acumuladorMedia >> 5; //basta fazer um numero de shifts pra direita igual ao expoen // te da potencia de 2 outra coisa, cuidado na hora de escolher o tamanho da variavel que servirá de acumulador, usem uma variavel que possua no MINIMO um numero de bits igual ao valor das leitura + 1, sempre sem exceção, pois no pior cenário, com as leituras dando valores muito altos voce pode estourar a variavel. Claro pra ponto flutante ou double nao se aplicadiretamente a mesma regra. Abs.

@Projetos_afg Uma sugestão, dê uma pesquisada no code-lite IDE, ele foi feito em cima da plataforma wxwidgets. Ultimamente tenho focado em levar minhas workbenches para desenvolvimento nativo no meu MAC, e estou progredindo a portar toolchains de micros de 8 e 16bits para o XCode. Também gostei bastante do uso do Visual Studio para microcontroladores, o unico problema que a IDE reclama pouco inclusive quando o compilador faz besteira na hora de compilar. Sobre o Eclipse, tenho pouco a comentar, nao sei se é opinião, mas acho uma boa IDE,sobre estabilidade tive poucos problemas mantendo os updates em dia e não sei se por habito, mas acho simples de portar alguma toolchain para ela. Ja tentou usar o VIM + um bom pacote de plugins para transforma - lo numa simples, mas poderosa IDE? Asb.

Hehehehe: typedef union{ uint32_t Register; uint8_t bit0:1; . . . uint8_t bit31:1;}Register_t;//Vamos usar:Register_t var32;//Setando um bit:var32.bit0 = 1; Tenho quase certeza que o código C produzido pelo GNU-Avr para fazer isso é mais eficiente que o do Bascom, fora que é cusotmizável . Abs.

Tem só um problema na ideia de usar ultra som. Pararam pra pensar que se a pessoa com o objeto estiver atrás do sensor o sistema para de funcionar? E aqui entra minha dúvida, como a pessoa vai se mexer perante ao sensor fixo? De forma radial ou seja em qualquer ponto em relação o sensor precisarei medir? Acredito que não 1 sensor de ultra som, mas sim com um array de sensores desses, e um circuito de beamforming para "acoplar" todos os sinais e só então realizar o cálculo de distancia. É possível sim, fazer sem microcontrolador, claro envolvendo mais componentes discretos, mas nada de outro mundo, afinal sensor de distância usado em automoveis, muitos, fazem o processamento de sinal sem um processador. Se teu inglês estiver legal para leitura, comece com essa ideia do PICLIST: http://www.piclist.com/images/www/hobby_elec/e_srm1_4.htm Faz exatamente medição de distância, porém possui um valor limitado de angulo de abertura, acredito que a partir dessa ideia serial legal começar a pensar numa matriz de sensores usando um circuito de beamforming para aplicar no circuito acima. Abs.

Pra quem tiver com o inglês em dia, tem esse curso de Introduction to Power Electronics oferecido pelo Coursera, é de graça: https://www.coursera.org/courses?search=power%20electronics Achei muito interesssante os tópicos a serem abordados, além disso tem até uma aula com o projeto dos controladores e dinâmica de conversores. Circuitos flybacks são legais, mas ainda prefiro o uso de conversores ressonantes para projetos de fontes de alta potência, dada a elevada eficiência, fora que fica bem compacta e permite o uso de técnicas de soft-switching como ZVS. Abs.

Tem uma infinidade, como o pulso é de 5 milissegundos, sugerir mosfet não resolve muito, vai consumir corrente do 555 do mesmo jeito, minha sugestão use transistores darlingtons que possuem ganho elevado, com isso com uma pequena corrente do latch do 555 você poderá acionar cargas de moderado valor de corrente. Deixo o TIP122 de sugestão, eis o datasheet: https://www.adafruit.com/datasheets/TIP120.pdf Sguestão de montagem de cada drive pode ser vista na figura a seguir: Abs.

Datasheet do LM317T: http://pdf.datasheetcatalog.com/datasheet2/1/03cgthpfat4t4ly5kfp5lpwladfy.pdf Veja a página 15, tem exatamente o que você precisa. Abs.

Só pra complementar, essa interface física, se parece muito com o controle I2S, dependendo da distribuição de linux que você esteja a rodar na RPi, pode procurar por um device driver para operação de dispositivo I2S, assim basta abrir o DD como se fosse um arquivo e escrever (ou ler) os dados que desejas. Para uma outra interface série (como um algum derivado da SPI) o processo é o mesmo, só não acho que seja possível fazer de forma deterministica utilizando bit-banging (ou seja acionando os GPIOS do chip manualmente por sw) como seria possivel num microcontrolador de 8bits da vida dado o não determinismo do linux tanto para escrita no dispositivo quanto para execução de threads. Abs.

Buck-Boost? qual seria a aplicação dessa fotocélula? O fato é que o algoritmo MPPT como ja dito pelo amigo @MOR vai solicitar energia de forma otimizada da tua fotocélula de forma que você consegue retirar máxima potência dela, porém o que vai se obter na saída são valores de tensão não regulados (até estáveis), assim um estágio regulador suplementar (buck ou boost) devera ser conectado a saída do MPPT da tua fotocélula. Teu inglês tá legal pra leitura? A Microchip tem um application note sobre esse assunto, inclusive explicando como implementar os algoritmos para geração de MPPT. http://ww1.microchip.com/downloads/en/AppNotes/00001521A.pdf Abs.

O que você ja fez na parte do software do PIC, posta ai pra gente ver. Acho que um diagraminha de blocos do TCC cairia muito bem pra gente poder te ajudar. E outra coisa, como é o protocolo de comunicação dentre transmissor e receptor? Abs.

Não, essa placa (aliás tem sido praticas comuns nesses kits de baixo custo) ja possui o proprio programador e debugger na placa, basta apenas configurar a ferramenta no ambiente de desenvolvimento que está a usar. Em específico das Freedom, tem a IDE baseada em eclipse fornecida pela própria Freescale, o code warrior e, recentemente, a Freescale libreou um release de uma IDE sem custo baseada no compilador GCC que é o Kinetis Studio, suporta exclusivamente os micros ARM dela, pra quem nao está com saco de compilar e montar o ambiente GCC do zero é uma boa pedida. Abs.

Isso voce pode verificar lendo o datasheet do fabricante, mais precisamente o parametro DC-Pulsed Current, ela ajudar a determinar um duty-cicle máximo seguro para que você acione o LED-RGB, dispensando assim o resistor limitador, mas veja que tal parametro é dependente da largura do pulso de corrente, o que vai influir na hora de selecionar uma frequência de portdadora adequada para o PWM operar. Veja esse part number de exemplo, um Cree X Lamp: http://www.cree.com/~/media/Files/Cree/LED%20Components%20and%20Modules/XLamp/Data%20and%20Binning/XLampXML_Color.pdf para usar 3 leds, a coisa ja complica um pouco, o modulo ccp do PIC, nao é nada flexivel e oferece, na maioria dos casos apenas 1 canal PWM por modulo, assim voce precisaria de 3 ccps, porém o 877A so tem 2, uma solução seria o uso de um software PWM baseado no estouro de um timer, porém a resolução será baixa, além da frequênia de operação que seja bem limitada. Nao existe uma possibilidade de usar um led driver controlado por I2C que nem esses caras ( a fabricante ainda fornece amostras): http://www.nxp.com/documents/data_sheet/PCA9633.pdf Espero que o ajude. Abs,

Outra coisa, é comum unificação do mapa de memória entre arquiteturas, de forma que por exemplo o PIC tenha capacidade para endereçar ate 8K de memoria, mas nao significa que toda essa localização é de programa ou RAM, podem existir endereços especiais que estão dentro do mapa de memoria, porém servem para proposistos de configuração como o exemplo citado pelo @vtrx. Essa solução é bem usada quando o micro possui por exemplo um controlador de memoria externa. Dependendo da ferramenta voce consegue configurar no trecho de codigo a configuração do processador, e esses valores sao colocados na imagem final onde o programador (ou software de gravação) os irá ler programar e enfim fazer o download da imagem para a memoria de programa. espero que ajude Abs.

O problema talvez nao seja seu codigo meu caro, mais uma vez é o CCS, Infelizmente o registrador TRISIO nao é definido no header file do microcontrolador, detalhe que de toda ferramenta de desenvolvimento pra micro que você usar essa é a unica que faz essa lambança. Minha sugestão é que use a API OutputBit(pino, nivel) para transferir os valores dos bits, escrever direto nas constantes o CCS nao suporta, alias PIC no CCS, voce so acessa os perifericos atraves das APIs, nao existe escrita direta. Espero que esclareça. Abs.

Boa @victhor393, além do seu comentário existe um porém, o critério de Nyquist so é válido quando o sinal é constuiído por uma senoíde, nesse caso nao existe perda de informação, porém no mundo real isso praticamente nao existe, o que faz com que precisemos de taxas de amostragens bem maiores que a máxima banda desejada, além de um bom filtro anti-aliasing. O fato da frequênncia da portadora nao ser audível é critério necessário, mas não suficiente para correta amostragem ou reconstrução de um vetor de dados, veja que uma frequência de amostragem menor que a necessaria vai causar no processo de reconstrução o efeito de aliasing do sinal que pode cair em banda audível e por fim prejudicar a qualidade final da gravação. vale lembrar que cada instante do periodo do sinal de PWM representa 1 ponto no sinal amostrado, e se o periodo do PWM for muito grande no momento em que ocorrer uma transição brusca de amplitude, o proprio filtro de reconstrução nao irá fazer com exito o efeito de averaging entre um ponto e outro do sinal de audio, causando aquele efeito de metalização no som. Para soluções baseadas em streams de 1bit eu prefiro utilizar conversao sigma delta, com ela é possivel utilizar taxas de amostragem, além disso o procedimento sigma-delta faz com que todo ruido fora da banda de interesse seja deslocado para banda de amosragem, milhoes de vezes superior, sem contar que como o stream de dados tem uma frequência máxima muito maior, o filtro de reconstrução fica muito mais simples de projetar. http://www.ti.com/lit/an/slyt076/slyt076.pdf Ai em cima, uma nota de aplicação da TI, que ensina passo a passo como fazer, eu particularmente prefiro fazer esse tipo de coisa em assembly. Abs.

Mais simples sim, mas vamos a algumas considerações, para um som com qualidade razoavel o ideal é que a a frequência da portadora do PWM seja bem superior a máxima frequência do sinal de voz que voce queira reproduzir, tipicamente usa - se uma frequência cerca de 10x superior, por exemplo, se quiser reproduzir um sinal de voz amostrado a 8KS/s (ou seja 4KHz a bem grosso modo) teras que usar um PWM com frequencia de portadora de pelo menos uns 80KHz. Vale lembrar que além da frequência e portadora, resolução do PWM também é importante, de nada adiante tem a portadora altissima, se teu pWM conegue representar 30 niveis de tensão média (apos passagem pelo filtro passa baixas), reprodução de voz fica excelente quando se tem 16bits disponiveis, no caso do PIC a porta CCP so consegue oferecer 10bits com uma frequência relativamente baixa, ou seja é bom estudar o uso de um DAC para a economia nao acabar saindo cara (considerar o uso de um DAC serial como o MCP4921, também é boa opção). Para processadores com desempenho menor como 8bits, eu prefiro o uso de D/A paralelos, em circuitos integrados, ou implementados em montagens como o ponderado usado pelo amigo @eletronicav ou o R-2R apresentado pelo colega @MOR, a vantagem é que você pode trabalhar com uma frequência de portadora proxima a taxa de amostragem do teu sinal, demandando menos processamento, ou mesmo gasto desnecessario de um timer que poderia servir para temporizar o a amostragem do conversor A/D. É comum ver projetistas usando esse D/A mas esquecendo - se de conceitos importantes sobre processamento numerico de sinais, em especial na hora da reconstrução, fazendo com qu o uso desse tipo de conversor tenha desempenho sofrível. Para melhor desempenho, após o conversor D/A é importante; - Fonte ratiométrica, ou seja a fonte da tensão de referencia do D/A tem que ser a mesma de toda a cadeia de processamento do sinal; - Desacomplamento da fonte usada para alimentar o microcontrolador da fonte usada para alimentar o D/A (um capacitor tanque local, perto do pino de fonte do D/A ja da uma grande diferença). - Esse é mais critico, um bom filtro após do D/A, esse filtro é tomado por filtro de reconstrução, é um filtro passa baixas, mas se bem projetado o mesmo, deve eliminar do espectro do sinal a portadora da taxa de amostragem, além disso, esse filtro ajuda na remoção de grande parte de ruído de quantização que todo e qualquer D/A possui, de forma que as transições entre duas amostras são suavizadas, termino esse post com um pouco de literatura sobre reconstrução de sinais digitais para analogico: http://www.qsl.net/py4zbz/teoria/recons.htm http://pessoal.utfpr.edu.br/janeczko/index_files/pds/capitulo2.pdf http://www.ni.com/white-paper/3016/pt/ Abs

"Pizeiros" que me desculpem, mas a BeagleBone Black é quase o mesmo preço, oferece um SoC melhor e com mais documentação, alem da mesma quantidade de memória RAM. https://www.adafruit.com/products/1876 Além disso existem outros single board computers baratos com SoCs bem superiores, como a Viola da Toradex, que tem um Vybrid (ARM Dual Core, Cortex - A5 ou CA5 + Cortex M4). Abs.

@Rafaela-Sama. Pelo que entendi voce esta com problemas em escalar o valor medido para o banco de capacitores certo? Usar ponto flutuante é ruim demais no PIC, mas talvez o uso de aritmetica de ponto fixo de 32bits lhe ajude com os cálculos. Seu sistema me parece uma planta de malha fechada, você lê a tensão no potenciometro, atua sobre o banco pelos SCRs e em seguida realimenta o sistema com base no valor corrente lido pela entrada analogica é isso? Se for porque não pensar em codificar o PIC para trabalhar como um controlador do tipo proporcional? Além disso você não precisa trabalhar no controle com os valores escalados para volts,visto que perante a saida do A/D seja um sinal de 190V escalado para 5V ou seja um sinal vindo do potenciometro de 0 a 5V ambos irão retornar um valor compreendido entre 0 e 0x3FF (1023). Assim basta adicionar os limites superior e inferior do sistema que no seu caso são 190V e 30V respectivamente certo? Vou te mostrar como ficaria simples isso em codigo usando um controlador tipo P, mas antes vamos mapear seus valores: a tensão no banco de capacitores deve ficar compreendida entre 30 e 190V certo? Agora usamos uma regra de tres simples para mapear isso num range nao de 0 a 5V mas um range dentro deles, é bom evitar o uso de toda a escala do A/D pois isso pode gerar nao linearidades que vão causar mau comportamento na hora da conversão, optarei pela seguinte forma: 190V = 4.0V, Ok? assim: 190 ----- 4.0 30 ------ x Logo 30V esta para : 0.631V Otimo, agora vamos mapear isso para o valor digital apos a conversao: Sabemos que a tensão em volts dado um valor digital do A/D é calculado por: V = VRef * (A/D/Resolucao) queremos o valor binario para os dois ranges, logo queremos o valor do codigo A/D dado a tensão de entrada: A/D = V * Resolucao / VRef, Fazendo Vref = 5,0V tensão de alimentacao do PIC e Resolucao usando os 10Bits temos: A/D = V * 1023 / 5,0 Otimo, agora podemos mapear a tensão do barramento dos capacitores como simples valores digitais, sem nos preocuparmos se estão no bus ou no potenciometro, vamos definir os limites, Superior: A/D = 4 * 1023 / 5,0 = 818 Inferior: A/D = 0.631 * 1023 / 5,0 = 129 Portanto, se tivermos 190V na entrada o A/D ira retornar 818 na hora de usar a funcao ReadADC(), e quando estiver em 30V o mesmo ira retornar 129. O mesmo vale para o potenciometro, que ja esta escalado para 0 - 5V. Agora pensando em código, um controle malha fechada tem que ser executado de forma periodica e a base de tempo deve ser razoavelmente estavel. O que proponho, configure um timer para interromper a cada 1ms, e dentro da interrupção execute o controle em malha fechada, no seu caso é um ON-OFF, acredite ele nao é um controle muito bom, mas ira conseguir colocar o sistema de forma estavel por um tempo: Assim: #include <stdint.h> //para usar os tipos padrãovoid ControlaCapacitores(uint16_t SetPoint, uint16_t Sensor){ //Variaveis auxiliares: int16_t Erro; //Pode ser inteira mas deve ser sinalizada //Calcula o erro entre valor desejado e lido: Erro = (int16_t)( SetPoint - Sensor); //Checa se saturou: if(Erro > 818) Erro = 818; // passou de 190V, mantem aqui if(Erro < 129) Erro = 129; // Menor que 30V, mantem aqui //Erro, igual a 0? if(Erro > 0) { //Se for diferente de zero, aciona o SCR: AcionaSCR(); //sua funcao de acionamento } else { DesacionaSCR(); //desliga o SCR } }//Rotina de interrupcao do timer0:#int_timer0void T0_ISR(void) //Essa rotina ocorra 1 vez a cada 1ms.{ //Variaveis auxiliares: uint16_t Potenciometro; uint16_t Capacitores; //Primerio le o setpoint desejado: //Nessa linha aqui coloque sua funcao para mudar o canal do A/D Potenciometro = readADC(); //Nessa linha aqui coloque sua funcao para mudar novamente o canal do A/D Capacitores = readADC(); //Computa o loop de controle: ControlaCapacitores(Potenciometro, Capacitores); //Fim da subrotina.} Tem coisas que voce precisa implementar como a forma correta de ler o A/D, trocar de canal para potenciometro e capacitores. Espero ter sido claro mas se tiver mais, duvidas nao hesite em perguntar. Abs.

Mas nunca disse que isso poderia ser feito a nivel profissional, aliás para nível profissional existem outras e numerosas opções. As que citei são formas de avaliar e desenvolver seus projetinhos por hobby apresentada pela comunidade open source. Existe um certo misticismo que me preocupa no aprendizado de sistemas embarcados, e isso faço questão de quebrar, é o que tudo é difícil ou complicado, veja que essencialmente o entusiasta não precisa ser um az da computação, ele tem que gostar de pensar, e é isso que muitos aspirantes não gostam ou sentem preguiça, ainda por cima liderados na faculdade ou curso técnico por professores que mais desencorajam do que incentivam o aprendizado, ai cai sempre na tradicional abordagem, começa com PIC ou 8051, depois ve que com o Arduino é fácil subir um webserver com meia duzia de linhas de código, mas na hora que o led nao pisca, puf! O candidato a ser mais uma pessoa feliz brincando com embarcados em casa pega tudo taca numa caixa, pois se do modo fácil nao funcionou, é errado perder tempo aprendendo pelo modo difícil. Nisso eu concordo, mas iniciante por iniciante, não temos entusiastas aos baldes investindo em Arduinos e shields que nunca vão usar? Acho que nesse ponto pouco podemos fazer, vai do bom senso de cada um. Isso é um ponto que quero desmistificar, sabe aquele conteudo visto em faculdade, pro pior e mais esquisito que ele nos é apresentado, sempre existe uma forma de tornar a abordagem fácil, sendo que a primeira é remover logo de cara da cabeça do iniciante que estrutura de dados por exemplo é pra experts (sabe explicação de como funciona memória como gaveteiro de meias, pois é algo do genero). Por isso sou obrigado a discordar que o uso de um projetinho com microcontrolador baseado em um sistema operacional não exige mutio mais conhecimento, alias grande parte dele ja é entendido pelo entusiasta que se mata pra sincronizar todos os eventos de um projeto que desenvolve. Quem disse? Como disse, sistemas embarcados são formadas por diversas áreas de conhecimento, não apenas microcontroladores, lembra o caso do codigo assembly? Ali naquela discussão daria pra explicar de uma vez por todas para alguem como funciona um ponteiro, ponteiros? sim constituem muito sobre o estudo de estrutura de dados, que são base para formar blocos de controle de um sistema operacional. Entende o que digo, está tudo ligado e nao superficialmente, nao que tal conhecimento serve pra fulano mas nao pra sicrano. Ou seja acho que todo mundo do forum pode contribuir, lembra do topico sobre DSP? Ta la paradinho, aguardando a proxima ideia para terminarmos o projeto do analisador. Espero ter expressado melhor o que quis dizer no post anterior mestre. Abs.

Vamos com calma mestre @aphawk Pelo contrário, se encaixaria bem sim, aliás é mais uma ramificação no aprendizado de sistemas embarcados, o RaspPi no caso poderia ser programado em bare-metal, se a broadcom (empresa que fabrica a SoC usada) fornecesse um manual mais decente dele. Mas ate onde sei algumas informações sobre o chip são fechadas. Fazer um programinha para ele essencialmente nao muda o ciclo de design, voce pensa no algoritmo, escreve compila tira os bugs, so que em vez de gravar na memoria flash do micro, voce coloca ele junto a imagem do linux como um módulo estático (ja compilado, so o binario) ou como extensão e linkagem dinamica (a famosa .so presente no linux) onde voce coloca o output gerado pelo seu compilador e o proprio dispositivo compila (ja que a imagem do linux acompanha o toolchain). Além disso, no mundo de sistemas operacionais embarcados, existe diversas distribuições com apenas ferramentas essenciais e o kernel da imagem linux, simplificando o trabalho de embarcar. patchs para que o scheduler do linux rode em tempo real também existe, e tudo isso em grande parcela com codigo aberto, bem feito que você pode modificar e distribuir ao seu gosto. E quem disse que microcontroladores rodam SEMPRE sem um sistema operacional? Veja, um sistema operacional com recursos basico não é nada de outro mundo, prova disso são o FreeRTOS, ucOS-II e outros kernels para microcontroladores de 8 a 32 bits, eu mesmo nos ultimos projetos que estive envolvido, desenvolvi microkernels multitarefa com serviços basicos de um sistema operacional. Programar de forma concorrente e multitarefa é produtivo, expande a visão do projetistas, ajuda na sincronização de serivços ( sabe aquele seu analizador lógico? Perfeitamente factivel usando um sistema operacional de tempo real, e olha só, existe port do FreeRTOS para AVR e ocupa proquissimos recursos de memoria flash e RAM, só que está em C, mas nada impede um estudo em estruturas de dados, escalonamento de tarefas e algoritmos para que voce possa fazer o seu em Basic @aphwak). Minha opinião pessoal do RaspPI, acho legal a iniciativa de ensinar jovens aspirantes a programar sem usar framworks, sim brincar de escrever código, tanto que a PI foi o gatilho para a invasão de mini-computadores embarcados open source baratos e poderosos (Ahhh os Vybrid601x da Freescale). Porém acho seu processador (o nome convieniente é SoC, System on a Chip) bem obsoleto e seu hardware fechado, pelo preço você tem opções mais interessantes com tudo disponivel para voce customizar seu sistema. Particularmente eu paguei mais caro, e comprei uma ZYBO Board, em que sua SoC é um ARM dual core em conjunto com uma FPGA, mais programável impossível. http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1198&Prod=ZYBO Sou a favor de expandir mais o assunto de microcontroladores do forum, e inclusive a fixação de um tópico sobre computadores embarcados como esse. Abs.

Não desistam de conseguir a placa. Eu nunca fui fã de usar o email corporativo para algo que você está pedindo pra si. Em todo caso, usei meu email do gmail e fui respondido em minutos, o caso é que soube da promoção bem no começo, mas agora a demanda está bem grande, o que pode ocasionar a demora. Minha sugestão é para que vocês chequem seus emails pelo menos diariamente ok? @vtrx Só eu achei essa placa general purpose, e interessante para experiência de programar x86 em eesquema bare-metal ou com RTOS? @victhor393, O que realmente me incomoda na Pi é a SoC obsoleta (um ARM11) e o fato de seu hardware ser fechado, assim voce fica limitado ao BSP fornecido para ela e ao manual capenga fornecido pela Broadcom. Estou querendo usar essa Galilleo justamente para portar o FreeRTOS para ela ou mesmo escrever um pequeno kernel multitarefa, e fazer operações em tempo real com esse brinquedo Abs