memoria BOOT

[rcakto]

rapaz... voces não dão nem tempo de pensar... calma calma calma... ja to ficando LOUCOOOOOOO.... vamos fazer o seguinte... o problema mais grave no momento é os sensores... como quero deixar totalmente aberto a qualquer sensor ( acelerometro, barometro, termometro e afins), qual é o melhor barramaneto a se usar?? pois assim mesmo que eu use OS, pode vir aparecer alguma necessidade de usar algum ic que não possa ter esse beneficio.... sem contar que vai demorar a usar linux.... acredito que la para maio eu de meus primeiros pulos nele...

[msamsoniuk]

ah tah, mas se eu fosse fazer algo realmente F*** em 2 dias, partiria para um ARM9 ou ARM11 da freescale com clock na estratosfera para rodar android diretao. agora, se fosse algo mais simples e tivesse mais tempo, certamente eu nao teria problemas em trabalhar diretamente com x11 direto. ateh onde sei, o touchscreen tem uma interface bem parecida com um mouse ou mesa digitalizadora no x11, entao eu acho que nao teria muito segredo (poderia prototipar no PC com um mouse mesmo).

Então, é que eu faria o que ele quer fazer assim:

- Usando linux full, colocaria algo como gtk+directfb ou qtopia pra funcionar, faria os sensores low-level operar e colocaria a interface grafica no meio disso. Em não mais que 1 ou 2 dias teria um prototipo totalmente funcional! :P

Claro que aí eu poderia esbarrar em restrições real-time, dependendo da forma que tivesse que operar o sensoreamento. Mas *eu* contorno isso sem problemas ahueuuhae :P

Tem conhecimento de alguma interface gráfica bastante funcional operando em cima do uclinux? com touchscreen se possível? :D Seria uma informação interessante pro rcackto e pra mim também :P

[]s!

P.S..: eu nao li o link que vc postou dois posts atrás, talvez já tivesse isso q eu perguntei :P

[polesapart]

Você tem que pensar +/- assim:

[sensores] => [cpu] => [atuadores]

Onde exibir uma mensagem na tela ou logar um evento pode ser entendido como um atuador, ou seja, algo que reage diante de um ou mais estímulos (que geralmente são padrões de dados coletados dos sensores).

Quais vão ser teus atuadores? Em quanto tempo e de que forma eles precisam atuar? Por exemplo, você pode querer cortar a alimentação de um sistema caso a temperatura ultrapasse um alvo, etc.

Sem formalizar pelo menos uma mínima especificação global, fica complicado, por que por exemplo, num cenário vc pode simplesmente pendurar tudo em um barramento i2c. Noutros casos você vai ter sensores via SPI. Noutro caso você vai ter ambos, noutro você vai ter que usar um barramentozinho paralelo de 4 bits, noutro vai precisar usar interrupções externas, noutro vc pode ter uma lógica do próprio sensor agindo sobre o atuador (por exemplo, um sensor de temperatura i2c/smbus tipo lm78: ele pode ser configurado pra jogar um nível lógico num pino quando a temperatura chega a um limite, e vc pode usar isso pra comutar a energia, etc.).

Em geral, quanto mais flexível vc quiser teu sistema, mais cabeludo ele vai precisar ser.

Antes de pensar em que barramento ou em que sensores particulares, vc tem que fechar os quesitos mínimos. Aí vc vai atras dos componentes que os atendam.

[rcakto]

pole, eis a questão... exatamente QUAL a usar, achei melhor procurar um barramento a trabalhar e depois verificar nestes o que tem uma melhor resposta...um exemplo é o sensor de temperatura.. o maximo que achei foi com leitura a cada 1,7°C algo que em alguns casos pode ser pouco... mas para trabalhar com folga acho interecante trabalhar entre 25 a 75% dos valores minimos e maximo dos sensores "E" da aplicação que estou monitorando.. em resumo o sensor tem uma gama maior que o maximo e minimo da aplicação.....

[polesapart]

ah tah, mas se eu fosse fazer algo realmente F*** em 2 dias, partiria para um ARM9 ou ARM11 da freescale com clock na estratosfera para rodar android diretao. agora, se fosse algo mais simples e tivesse mais tempo, certamente eu nao teria problemas em trabalhar diretamente com x11 direto. ateh onde sei, o touchscreen tem uma interface bem parecida com um mouse ou mesa digitalizadora no x11, entao eu acho que nao teria muito segredo (poderia prototipar no PC com um mouse mesmo).

Android é uma boa tbm! Aliás, uma ótima, a parte chata já está feita hehehe

[rcakto]

parte grafica:

se possivel ira mostrar cada sensor que estarei trabalhando e seu resultado lido, quando clicar no "nome" aparece uma nova tela para mudar o maximo e minimo

parte interna:

sera monitorado o mais rapido possivel cada sensor;
gravar os dados de alguma forma para feedback posteriormente;
dados serao coletados via sensores, I/Os, e ADCs, pois posso fazer ou precisar de alguma aplicação onde caso ocorra algo pre determinado, envie um sinal para este meu projeto base para simples aviso (alguem abriu a porta que não devia ou deixou ela aberta...e por ai vai...(tenho algumas coisas quimicas aqui e de tempo em tempo meu sobrinho vem aqui em casa) );
os atuadores mesmo serão aplicações externas e que receberao um sinal proveniente do meu projeto base;
os sensores mesmo irao ser monitorados constantemente, ja as I/Os não precisao de monitoramento constante, pode ser a cada 1 a 3s;

acho que é so isso mesmo... so isso ja e o bastante para me sadomasicar por enquanto eu acho...

[msamsoniuk]

em geral se vc precisa de algo veloz e eficiente, tem que ser SPI.

tem varias diferencas entre SPI e I2C:

- SPI eh full duplex, enquanto I2C eh half-duplex
- SPI usa chip-select separado, enquanto no I2C eh parte do protocolo e consome bandwidth
- SPI em geral usa clock mais elevado que I2C (jah vi devices SPI operando a 50MHz)
- SPI em geral possui pino de interrupcao separado (em I2C nao sei afirmar com certeza).
- SPI usa pelo menos 5 fios por periferico (TX, RX, CS, CLK e IRQ), contra 2 fios de I2C (DATA e CLK).

ou seja, com SPI vc tem mais conexoes justamente para aumentar o bandwidth.

enfim, para ter uma ideia da eficiencia de SPI, existem varios controladores ethernet e ADC/DACs de alta velocidade cuja conexao com o microcontrolador eh via SPI! :)

mas com relação aos sensores, qual seria a melhor opcao para a comunicação??

Depende de que tipos de sensores você planeja usar, da quantidade deles, da taxa de amostragem que você precisa ter, precisão/resolução, etc. ...

[msamsoniuk]

com android fica um negocio bem iphone neh, com icones pulando, telas rolando e outras firulas... o ruim eh que consome uns 400MIPS do processador soh nas firulas! e o legal da familia imx da freescale eh que tem aceleracao 3D integrada e, por alguma magica proprietaria e absurda, o linux e o android conseguem usar aquilo. enfim, eh para quem nao quer esquentar a cabeca com nada de software! :)

ah tah, mas se eu fosse fazer algo realmente F*** em 2 dias, partiria para um ARM9 ou ARM11 da freescale com clock na estratosfera para rodar android diretao. agora, se fosse algo mais simples e tivesse mais tempo, certamente eu nao teria problemas em trabalhar diretamente com x11 direto. ateh onde sei, o touchscreen tem uma interface bem parecida com um mouse ou mesa digitalizadora no x11, entao eu acho que nao teria muito segredo (poderia prototipar no PC com um mouse mesmo).

Android é uma boa tbm! Aliás, uma ótima, a parte chata já está feita :P hehehe :D

[rcakto]

Marcelo... sinceramente... se for para usar OS obrigatoriamente tenho de ter acesso total igual a quando roda o linux em um pc.. senao compraria um celular qualquer e fazia um mod como muitos fazem na net... so seria uma **** grana a gastar com o celular....

[fabim]

Cara, faça como eu.
Compra uma dessas.
http://www.indevices.com.br/PMX-1000.htm

E mete a cara, não é tão caro não viu. E pra começar a brincar ta de enorme tamanho.

[rcakto]

fabim.. voce mostrou algo bem perto do que eu procuro fazer... um mini host de sensores e atuadores... para os meus projetos posteriores....

http://www.indevices.com.br/PMX-1000_ar ... age029.jpg

parecido com isso ae so que com a tela LCD

[Sergio38br]

Se quer mesmo partir para algo proximo a um mcu , tem este que é uma SBC com arm..

http://br.mouser.com/ProductDetail/Beag ... rUwg%3d%3d

[ ]'s
Sergio

[rcakto]

fabim so por curiosidade a placa eval e a placa com a cpu ta saindo por quanto??

[msamsoniuk]

parte grafica:

se possivel ira mostrar cada sensor que estarei trabalhando e seu resultado lido, quando clicar no "nome" aparece uma nova tela para mudar o maximo e minimo

o uclinux oferece varias APIs para graficos... varia das mais simples ateh as mais avancadas. a mais simples de toda eh o frame buffer: simplesmente um ponteiro para um monte de bytes onde vc desenha as coisas pixel a pixel. isso eh um tanto quanto chato pq sua aplicacao tem que aprender a desenhar linhas, circulos, poligonos e letras.

uma API melhor eh o X11, que prove todas estas funcionalidades mais basicas, mas X11 nao prove botoes e elementos mais inteligentes. para isso vc precisaria usar bibliotecas QT ou GTK (ou fazer a sua biblioteca, se vc for realmente bom!).

e bom, se vc nao quer perder muito tempo reinventado a roda e quer massacrar, vc pode partir para um android. lembre-se que isso eh interface grafica, ou seja, eh um front-end que roda no dispositivo e a unica funcao dele eh prover uma boa interface entre as aplicacoes de baixo nivel e o usuario.

parte interna:

sera monitorado o mais rapido possivel cada sensor;
gravar os dados de alguma forma para feedback posteriormente;

provavelmente vc vai ter um timer em um device driver e esses dados vao ser guardados em uma queue na memoria. depois as aplicacoes de alto nivel puxam isso usando uma interface entre kernel e aplicacao.

dados serao coletados via sensores, I/Os, e ADCs, pois posso fazer ou precisar de alguma aplicação onde caso ocorra algo pre determinado, envie um sinal para este meu projeto base para simples aviso (alguem abriu a porta que não devia ou deixou ela aberta...e por ai vai...(tenho algumas coisas quimicas aqui e de tempo em tempo meu sobrinho vem aqui em casa) );

os atuadores mesmo serão aplicações externas e que receberao um sinal proveniente do meu projeto base;

os sensores mesmo irao ser monitorados constantemente, ja as I/Os não precisao de monitoramento constante, pode ser a cada 1 a 3s;

acho que vc pode imaginar algo assim:

Código: Selecionar todos

hardware <=> device drivers <=> kernel <=> aplicacao baixo nivel <=> aplicacao alto nivel <=> interface grafica <=> usuario

tem um detalhe importante de arquitetura ae... tem algumas pessoas que preferem colocar os ADCs e IOs na placa principal do sistema e puxar cabos ateh os sensores e atuadores. outras pessoas preferem nao ter nada na placa e ao inves disso puxar barramentos e alimentacao ateh ADCs e IOs que ficam proximos aos sensores.

imagine que vc tem que colocar 20 sensores de temperatura em uma grande area. realmente puxar 20 termopares gigantes eh bem simples comparado a puxar 20 cabos com alimentacao e dados digitais. por outro lado, os termopares vao captar ruido que sera somado no processo de digitalizacao, enquanto que os sinais digitais transportam valores jah digitalizados e imunes a estes ruidos.

cada situacao tem vantagens e desvantagens.

[msamsoniuk]

como eu jah te falei antes, esse PMX eh realmente muito bacana e completo, porem acho que chegou ao mercado um pouco atrasado para essa classe de processador. hoje em dia os concorrentes dele jah estao com interfaces gigabit ethernet, pci-express e DDR3. mas em termos de x86, realmente eh o melhor disponivel. uma coisa bacana nele tb eh que nao eh tao manco em termos de IO como a maioria dos x86: ele fornece SPI, I2C, PWM e GPIO.

Cara, faça como eu.
Compra uma dessas.
http://www.indevices.com.br/PMX-1000.htm

E mete a cara, não é tão caro não viu. E pra começar a brincar ta de enorme tamanho.