ASM51

Boa noite, colegas.
Na epoca do bom e velho DOS o acesso as portas era via hardware e não via software como no windows, que o sistema é empreendido, muito ruim, no passado conseguia ler na porta paralela a cada 20 microsegundos fixos, hoje entre 250 a 400 microsegundos. Minha pergunta é o linux trabalha a nivel de hardware como o DOS no passado ou como o windows. Pois estou pretendendo desenvolver um sistema de captura para usar no desktop. Caso o linux tenha o processamento a nivel de hardware, excelente.

Agradeço pela atenção.

Na boa, esquece isso. use um microcontrolador vagabundo para ler ou controlar seus sinais, e depois mande via serial para o computador usando o sistema que voce quiser.

O problema maior dos computadores é a praga da multitarefa que nao existia no MSDOS, No DOS como em teoria rodava um unico processo por vez, vc podia ter precisao nas leituras ou entrega de sinais pq o processador era seu, todo seu (em tese por causa dos TSRs).

Hoje em dia com a multitarefa nos processadores e nos computadores, vc nao pode desperdicar tempo num processo que fica a cada 20ms fazendo alguma coisa, o sistema nao pode te dar sempre isso pois outros processos estao concorrendo fatias de tempo do processador.

Minha sugestao é voce escolher um microcontrolador que fica encarregado de ler e controlar seus dados e depois enviar para o PC o resultado.

A porta paralela é um problema sério nos dias de hoje e esta em desuso. a USB por exemplo voce pode ler e gravar dados a cada 1ms. procure um chip FTDI ou um microcontrolador com USB se ainda quiser ficar lendo e recebendo dados tao rapidos pelo processador.

jvanderleym,

No windows NT/2000/XP, vc não pode acessar a porta diretamente como no windows 95/98. A tarefa de acessar a I/O fica a cargo do Kernel, o programa acessa a porta via kernel do windows.
No Linux até que daria para acessar com baixo tempo, mais seria trabalhoso. Teria que fazer um driver modular que seria parte do kernel, para acessar a porta, mais ainda ficaria com o tempo de acesso determinado pelo kernel. Se vc conhece como compilar e modificar o kernel dá pra experimentar abaixar o tempo do ciclo das tasks.
O linux acessa a porta como o windows, isto é o programa que vc faz neste ambiente tb acessa a porta pelo kernel do linux.
O melhor é fazer como a Wagner sugeriu. Use um microcontrolador, com um cache de memoria e envie os dados via serial ou USB para o PC. Assim fica mais facil.
Continuando com o windows, vc pode usar placas da National que fazem captura de dados com velocidade, mas vai sair caro.

Se voce ainda é escravo do Windows, voce pode usar a USB.


Eu sei que a porta USB tem leituras a cada 1ms. Voce pode fazer captura de dados por um PIC ligado a USB e envia-las para o PC.

Bom, dizem que é rapido. mas ainda nao testei ainda. Mas se USB pode enviar e receber audio para e do PC, alem de ser tambem osciloscopio, pode ser uma alternativa atual e atrativa.

Eu estou longe do Linux e gostaria de voltar e talvez desenvolver alguma coisa no linux, mas estou sem tempo.

Poderia descrever melhor que tipo de projeto tem em mente?

Asssim, quem sabe possamos fazer alguma coisa.

Na USB 2.0 no modo HID pode-se receber pacotes de 64 bytes a cada 1 ms ou 64KB/s. Já no modo ping-pong pode-se receber 384KB/s.

nao precisa ser via kernel, em uma aplicacao normal vc pode usar a paralela diretamente no linux:

#define DATA 0x378
#define STATUS (DATA+1)
#define CONTROL (DATA+2)

ioperm(DATA,8,1);

e entao vc tem controle da porta. basta usar:

value = inb(STATUS);
outb(value,DATA);
outb(value,CONTROL);

para ler valores do registro de status e escrever nos registros de dados e controle. eu consigo ateh 500KB/s de taxa de transferencia, mas, como o wagner disse, as transferencias aparecem como bursts durante os time-slices que a task esta rodando. se vc roda qq outro programa ao mesmo tempo, vc vai ter bursts a 500KB/s se alternando com espacos vazios a uma cadencia de 50Hz, pq qdo outra task esta rodando a interface fica morta...

isso vem do fato que a porta paralela eh sempre controlada por software. uma solucao para isso seria utilizar um canal de DMA, daih sim, independente da multitarefa, o fluxo de dados permanece constante.

de fato, isso eh o que diferencia a usb e ethernet da paralela e serial no PC: DMA... apesar q eu acho a interface USB o maior fake da historia, deve ter sido projetada por um faxineiro na intel, se eh que tem algum engenheiro lah que seja mais inteligente que um faxineiro.

se vc utilizar DMA, a paralela vai ser tao boa quanto qq outra interface, tirando as limitacoes de performance da porta: mesmo com DMA acho que o limite eh algo em torno de 2MB/s, pq no fundo tem q manter compatibilidade com a centronics original q nao passava de portas TTL normais (duas 74374 para saida e uma 74244 para entrada).

novamente, como o wager falou, a melhor solucao seria usar um mcu ligado via usb, serial ou ethernet, daih realmente nao tem drama.

Tome cuidado se tiver mais perifericos ligados a USB. Se estiverem em funcionamento simultaneo, mesmo ligado por portas diferentes, pode haver atraso na comunicação dos dados. Ja tive problemas com alguns perifericos como Gravador de DVD externo e Scanner, que em funcionamento dava uma pequena congelada no mouse USB.
Melhor opção é um MCU com RAM de buffer. Assim vc não perde nada e pode determinar o tempo de aquisição.
Já fiz um osciloscopio via porta paralela, usando o windows98 e um ADC0808. Digo que funcionou bem sem interrupções. Mas não tentei passar o software para as versões win2000 e XP. Acho que não daria certo.
Bom tb seria fazer uma placa PCI32, com acesso DMA, mas quem se habilita???hehe

Só complementando o comentário do Marcelo, para usar o ioperm, o programa tem que rodar pelo root ou através de sudo, o kernel não dá permissão ioperm prá usuário. Dependendo do tipo do programa que se deseja desenvolver, isso pode ser chato.

eu nunca boto muita feh em USB nao... para segurar a barra de um IO cavalar, o negocio eh partir direto para fast-ethernet

Só complementando o comentário do Marcelo, para usar o ioperm, o programa tem que rodar pelo root ou através de sudo, o kernel não dá permissão ioperm prá usuário. Dependendo do tipo do programa que se deseja desenvolver, isso pode ser chato.

Aproveitando a deixa, pergunta basica, ha maneira de permenecer como super usuario sempre? tipo, eh um saco ter que abrir um gerenciador de arquivos como super usuario tudo vez que quero fazer coisas simples como mover um arquivo.

eu nunca boto muita feh em USB nao... para segurar a barra de um IO cavalar, o negocio eh partir direto para fast-ethernet Smile

Mcus de 8 bits, corram do tio marcelo, ele eh do mal.

eu logo em todas as minhas maquinas como root direto, afinal eu sou o dono... soh entro como usuario nas maquinas que nao sao minhas hehehe

mastk escreveu:

Só complementando o comentário do Marcelo, para usar o ioperm, o programa tem que rodar pelo root ou através de sudo, o kernel não dá permissão ioperm prá usuário. Dependendo do tipo do programa que se deseja desenvolver, isso pode ser chato.

Aproveitando a deixa, pergunta basica, ha maneira de permenecer como super usuario sempre? tipo, eh um saco ter que abrir um gerenciador de arquivos como super usuario tudo vez que quero fazer coisas simples como mover um arquivo.

eu nunca boto muita feh em USB nao... para segurar a barra de um IO cavalar, o negocio eh partir direto para fast-ethernet Smile

Mcus de 8 bits, corram do tio marcelo, ele eh do mal.

Mastk, é possível sim, mas é mais ou menos como deixar as portas da tua casa sempre destrancadas, porque é um saco usar a chave toda vez.
Porém, assim como você não tranca as portas de dentro de tua casa sempre que está lá dentro, você deve ter pastas de usuário para arquivos do usuário, e pastas root para arquivos do sistema. Se você fica fuçando em arquivos do sistema o tempo todo, o que é estranho, daí loga direto como root e rode tudo como root. Mas o melhor é mesmo manter as coisas organizadas, e cada um no seu quadrado...

xultz escreveu:Só complementando o comentário do Marcelo, para usar o ioperm, o programa tem que rodar pelo root ou através de sudo, o kernel não dá permissão ioperm prá usuário. Dependendo do tipo do programa que se deseja desenvolver, isso pode ser chato.

Ou chown root binario && chmod u+s binario

Mas a menos que o programa faça o que tenha que fazer e abra mão dos privilégios de root depois (posso postar uns trechos de código pra fazer isto se alguém quiser), isto costuma ser tão ruim quanto escrever a senha de root num post-it e colar no monitor de uma escola publica

opa! chmod +s realmente eh bem inseguro!

eu recomendaria vc pode criar um processo tipo parallel_server rodando no inittab como root e acessar ele atraves de mensagens ipc ou sockets, usando um parallel_cliente que roda como usuario nao-privilegiado.

note que *eu* rodar as coisas como root na minha maquina nao quer dizer que tudo ou todos rodam como root! eu sou eu, os outros sao os outros e cada um fica no seu quadrado! hahaha

polesapart escreveu:

xultz escreveu:Só complementando o comentário do Marcelo, para usar o ioperm, o programa tem que rodar pelo root ou através de sudo, o kernel não dá permissão ioperm prá usuário. Dependendo do tipo do programa que se deseja desenvolver, isso pode ser chato.

Ou chown root binario && chmod u+s binario

Mas a menos que o programa faça o que tenha que fazer e abra mão dos privilégios de root depois (posso postar uns trechos de código pra fazer isto se alguém quiser), isto costuma ser tão ruim quanto escrever a senha de root num post-it e colar no monitor de uma escola publica

Marcelo Samsoniuk escreveu:opa! chmod +s realmente eh bem inseguro!

eu recomendaria vc pode criar um processo tipo parallel_server rodando no inittab como root e acessar ele atraves de mensagens ipc ou sockets, usando um parallel_cliente que roda como usuario nao-privilegiado.

Isto poderia não daria muito certo se o cara realmente quer baixa latência e se o programa dele for meio interativo (precisar trocar muitas mensagens entre os processos). Mesmo que o processo fazendo ioperm e i/o esteja rodando com prioridade de tempo real, cada troca de mensagens entre os processos pode ficar numa média em torno de 1,x ms. Claro que se ele enviar uma mensagem grande e o processo de alta prioridade consumir direto enviando byte a byte (e/ou recebendo) diretão eliminaria em grande parte o problema da latência, embora não fosse muito estável.

A verdade é que pra maioria dos casos comuns isto funciona perfeitamente, mas pra essas necessidades bizarras o linux realmente não se comporta como um microkernel de um rtos

Eu gostei da sugestão anterior da thread, de usar um µC dedicado