memoria BOOT

[polesapart]

ehhehehe quando vc dominar bem os conceitos de multitarefa vc mesmo responde essa

Achei um artigo ruim, e tá em português de portugal, mas é melhor q nada:
http://pt.wikipedia.org/wiki/Multitarefa

Tou indo dormir, amanhã a gente troca mais umas figurinhas ...
Boa sorte!

[rcakto]

polesapart, tipow.. ja vi codigos de aplicações que achei na net usando ARM onde eles fazem varias chamadas diferenciadas das i2c mas como trabalhava com 70Mhz (T= 1,4285714285714285714285714285714e-8) tudo acontecia muito rapido, e ficava em um loop do inicio do codigo ate o final fazendo as leituras... MAS para que possa realmente funcionar em tempo real, assim podendo adcionar novas funcionalidades onde essas não irão interferir no tempo de execução, devem acontecer em tempo real...

dizem que a ethernet e a usb tem essas funções programando pelo KEIL.. mas como realmente isto funciona, se é que funciona.....


boa noite pole.. amanha atrde eu volto... tenho trampo pela manha...acho meio dificil aparecer por aqui cedo entao...

[msamsoniuk]

hmmm... melhor comecar a aprender ingles! :D

marcelo, eu tava querendo saber mais sobre o uclinux, sabe me informar onde posso aprender desde o basico sobre ele, em portugues se possivel, to com preguica de traduzir.... XD

[rcakto]

saber eu sei.. so to com preguica hj.... tive de ler uns datasheets o dia todo hj.... por falar nisso... uma duvida de PLL.. em alguns casos eu reparei que o datasheet tem um valor para o Fcco diferente do user manual.. qual devo seguir?? datasheet ou user manual??


fuiz... vou dormir...

[msamsoniuk]

se vc for pensar nisso do zero, vai quebrar a cabeca a toa, visto que o uclinux faz justamente todo este gerenciamento. a grosso modo, os perifericos de comunicacao transmitem e recebem atraves de interrupcoes e dma, formando buffers e queues. as aplicacoes, por sua vez, rodam como processos concorrentes que se alterna sucessivamente no tempo. assim, a aplicacao que desenha na tela nao toma 100% do tempo de processamento pq o sistema operacional permite que outras aplicacoes se alternem e rodem quando as interrupcoes ocorrem.

ta... blz... agora entendi... ?????????????? f****.... olha a pergunta que passou na minha cabeca.. se eu estou trabalhando em gerar os pixels no LCD, como é que eu vou fazer para receber os dados das I2Cs, I/Os, e ADCs, tudo em tempo real igual no pc, onde da pra deixar uma porrada de coisa aberta e vai alterando os dados tudo sozinho ( winamp, msn, firefox....tudo aberto...).....

[msamsoniuk]

esqueca keil!

se vc tiver memoria suficiente para o uclinux, vc faz tudo funcionar redondo sem se preocupar com nada. e detalhe, uclinux eh completamente opensource e gratis! jah tem a maioria dos device drivers prontos, aplicacoes e APIs... daih fica facil neh! :)

mas se vc nao tiver memoria suficiente... bom, tem que sofrer com keil! hehehe

polesapart, tipow.. ja vi codigos de aplicações que achei na net usando ARM onde eles fazem varias chamadas diferenciadas das i2c mas como trabalhava com 70Mhz (T= 1,4285714285714285714285714285714e-8) tudo acontecia muito rapido, e ficava em um loop do inicio do codigo ate o final fazendo as leituras... MAS para que possa realmente funcionar em tempo real, assim podendo adcionar novas funcionalidades onde essas não irão interferir no tempo de execução, devem acontecer em tempo real...

dizem que a ethernet e a usb tem essas funções programando pelo KEIL.. mas como realmente isto funciona, se é que funciona.....


boa noite pole.. amanha atrde eu volto... tenho trampo pela manha...acho meio dificil aparecer por aqui cedo entao...

[rcakto]

a ta... agora eu sei pq existem as chamadas de interrupções pelo usuario...

ve se eu to certo:

ex.:

inicio
...
fica mudando os pixels e pegando os dados na eeprom...
...
timer1 dura x tempo...
estouro, vai pra interrupcao...
...
interupção... faz uma varredura nas i2c e guarda os valores na eeprom...
...

isso ae teoricamente daria um ar de tempo real, não??? é so ter a sorte de conceguir vazer a varredura a cada 10 a 50 ns exatos... em muitas aplicações de monitoramento que eu vou fazer isso e tempo suficiente para ler e atuar... e quase impossivel fazer algo em casa onde acima de 100ns alguma coisa vai pegar fogo... sem contar que muitas aplicações nunca coloca para trabalhar a 100% nos primeiros teste.. sempre deixamos com uma margem de segurança....

fuiz.. agora realmente vou dormir.. flw a todos... e obrigado pela paciencia...

[msamsoniuk]

tente imaginar como isso funcionaria em um PC. vc pode inclusive criar rotinas que simulam determinados perifericos, por exemplo, a eeprom vc pode criar funcoes do tipo read_eeprom() e write_eeprom(), gravando e lendo um array mesmo. depois quando migrar para o embarcado, vc troca pelas rotinas de verdade que acessam o periferico.

neste caso, vc teria uma aplicacao mais ou menos assim:

Código: Selecionar todos

main()
{
  unsigned char data[];

  int fb = init_display();
  int fd = init_eeprom();

  while(1)
  {
    read_eeprom(fd,data,sizeof(data));
    draw_display(fb,data,sizeof(data));
  }
}


e no kernel vc teria um device driver ativado pela interrupcao de timer que usa write_eeprom() para gravar os tais dados vindos do i2c, o que poderia ser feito por uma funcao i2c_read(), por exemplo. bom, eu acho meio curioso e estranho passar dados de um device driver para uma aplicacao usando uma eeprom. tem algum motivo especial para isso?

outro detalhe eh a escala de tempo: vc fala em ler um sensor i2c periodicamente em um tempo de 10 a 50 ns. mas para 10 ns estamos falando em 100 milhoes de acessos por segundo! soh que i2c nao eh projetado para trabalhar nem com 1/1000 disso, afinal eh um bus half-duplex e com overhead.

imagino que vc usou ns (nanosegundos) por engano.

a ta... agora eu sei pq existem as chamadas de interrupções pelo usuario...

ve se eu to certo:

ex.:

inicio
...
fica mudando os pixels e pegando os dados na eeprom...
...
timer1 dura x tempo...
estouro, vai pra interrupcao...
...
interupção... faz uma varredura nas i2c e guarda os valores na eeprom...
...

isso ae teoricamente daria um ar de tempo real, não??? é so ter a sorte de conceguir vazer a varredura a cada 10 a 50 ns exatos... em muitas aplicações de monitoramento que eu vou fazer isso e tempo suficiente para ler e atuar... e quase impossivel fazer algo em casa onde acima de 100ns alguma coisa vai pegar fogo... sem contar que muitas aplicações nunca coloca para trabalhar a 100% nos primeiros teste.. sempre deixamos com uma margem de segurança....

fuiz.. agora realmente vou dormir.. flw a todos... e obrigado pela paciencia...

[rcakto]

marcelo, agora lendo o que voce escreveu, sim realmente eu exagerei nos nanos.... mas seria constante a leitura, assim caso o valor passe do limite pre-selecionado algumas acoes seriam aplicadas automaticamente, ex. caso a temperatura passe de 90° envia um sinal na portx e que este sinal ira atuar uma aplicação onde corta a alimentação do aparelho que estou monitorando.....
os valores serão salvos para posteriormente criar um grafico para feedback.. talvez com isso possa identificar fatores que devem ser abordados para melhorias, e iria ser gravados na eeprom pois não sei ainda se posso utilizar o C/C++ para criar um arquivo txt com os valores, pois no C da, agora como irei criar e gravar em um cartao ou usb não faco ideia... ainda...

[msamsoniuk]

bom, se for soh para transferir dados entre uma aplicacao e outra, realmente vc nao precisa de eeprom. o uclinux possui interfaces melhores e mais eficientes entre kernel e aplicacao. minha sugestao eh vc dar uma olhada neste exemplo de aplicacao que acessa interface i2c no uclinux:

http://www.pragmatec.net/Produits/White ... 3C44B0.pdf

quanto ao exagero, nao que o uclinux nao aguente o tranco, mas a interface i2c realmente eh muito mal projetada para chegar a uma velocidade tao grande (basta dizer que foi a philips que fez neh). se usar um hardware avancado orientado a pacote, como ethernet, o uclinux consegue atingir um throughput realmente elevado.

marcelo, agora lendo o que voce escreveu, sim realmente eu exagerei nos nanos.... mas seria constante a leitura, assim caso o valor passe do limite pre-selecionado algumas acoes seriam aplicadas automaticamente, ex. caso a temperatura passe de 90° envia um sinal na portx e que este sinal ira atuar uma aplicação onde corta a alimentação do aparelho que estou monitorando.....
os valores serão salvos para posteriormente criar um grafico para feedback.. talvez com isso possa identificar fatores que devem ser abordados para melhorias, e iria ser gravados na eeprom pois não sei ainda se posso utilizar o C/C++ para criar um arquivo txt com os valores, pois no C da, agora como irei criar e gravar em um cartao ou usb não faco ideia... ainda...

[polesapart]

Rcackto, você pode ter uma tarefa de baixa prioridade que fica enviando interrogações a um (ou mais) sensor(es), e analisando a resposta (o valor do sensor), e quando ela sair da faixa de operação normal, você dispara um evento. Voce pode ter outra tarefa que analisa estes eventos, e toma atitudes baseadas neles.

Dependendo do número de sensores, esta técnica começa a ficar inviável, se você tem que monitorar um número muito grande deles de tal forma que precise capturar o evento *e* responder a ele num intervalo de tempo muito pequeno. De qualquer forma, o número de sensores de um mesmo modelo que você consegue por num barramento I2C é limitado.

Eu recomendo que você adquira um bom livro e comece do começo, uma boa dica é um que trate de RTOS. Pro que você quer, a dica do Marcelo do uclinux é uma boa. Eu iria direto pro Linux full mesmo, num arm9 ou algo maior, mas se o teu compromisso é aprender mais a fundo (sem no entanto entrar pro livro dos recordes como o maior masoquista do mundo), o ucLinux vai ser um ótimo caminho

[msamsoniuk]

mas o uclinux eh muito melhor para embarcados! :)

dah uma olhada nessa comparacao de performance entre uclinux e linux:

http://sparcs.kaist.ac.kr/~gangster/pub ... x_fall.ppt

aqui tem uma apresentacao bem moderna sobre o uclinux:

http://free-electrons.com/doc/uclinux_introduction.pdf

e aqui tem a apresentacao que eu fiz em 2001 na universidade federal fluminense quando o assunto ainda era novidade no pais:

http://framework.sourceforge.net/pics/uclinux/

por sinal, eu lembro que nessa epoca eu e o alex (polesapart) passavamos madrugadas nos botecos bebendo e discutindo sobre paginacao e copy on-write! hehehe

Rcackto, você pode ter uma tarefa de baixa prioridade que fica enviando interrogações a um (ou mais) sensor(es), e analisando a resposta (o valor do sensor), e quando ela sair da faixa de operação normal, você dispara um evento. Voce pode ter outra tarefa que analisa estes eventos, e toma atitudes baseadas neles.

Dependendo do número de sensores, esta técnica começa a ficar inviável, se você tem que monitorar um número muito grande deles de tal forma que precise capturar o evento *e* responder a ele num intervalo de tempo muito pequeno. De qualquer forma, o número de sensores de um mesmo modelo que você consegue por num barramento I2C é limitado.

Eu recomendo que você adquira um bom livro e comece do começo, uma boa dica é um que trate de RTOS. Pro que você quer, a dica do Marcelo do uclinux é uma boa. Eu iria direto pro Linux full mesmo, num arm9 ou algo maior, mas se o teu compromisso é aprender mais a fundo (sem no entanto entrar pro livro dos recordes como o maior masoquista do mundo), o ucLinux vai ser um ótimo caminho :P

[polesapart]

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!

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

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

[]s!

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

[rcakto]

opa, disso eu não sabia, e a minha intenção e totalmente em monitorar sensores e atuar o mais rapido possivel... não so em aplicações onde esteja trabalhando no momento, mas tambem em aparelhos que eu trabalho diariamente, um exemplo é um amplificador velho que eu ganhei, que não posso deixalo 5 min ligado direto senao queima os transistores e como mal da para ver os valores nos componentes, se queimar ja era.... agora com relação ao uclinux, realmente vai ser dificil usalo... ele parece um sistema BEM rustico com o intuito de aprimorar aplicações para ter retorno de processamento mais rapido... se eu chegar a usar um OS vou tentar algo mais completo.. depois e so fazer minha aplicações em delphi, algo que ja estou mais familiarizado a fazer ou mesmo em php como alguem aqui do forum indico...

mas com relação aos sensores, qual seria a melhor opcao para a comunicação?? ate hj so trabalhei com i2c e Vref dos pics.. mas Vref so da para um unico sensor entao nem rola... quero algo do genero i2c onde pode colocar varios ics juntos no mesmo barramento.... e nem tenho conhecimento no momento para trabalhar com envio de dados via ethernet.. e acho que ira sair mais caro pois sera necessario mais componentes por sensor...... vou acaber tendo de fazer aplicações menores por sensor, e uma central para receber os dados para monitoramento e "controle", pois as aplicações com sensor que realmente irão atuar em tempo real....

[polesapart]

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. ...