Osciloscópio Digital Remoto com Espectrómetro para PC Usando

Transcrição

Osciloscópio Digital Remoto com Espectrómetro para PC Usando
Universidade de Coimbra
Departamento de Engenharia Electrotécnica e de Computadores
Sistemas de Tempo Real
Trabalho Prático No 4
Osciloscópio Digital Remoto com Espectrómetro para PC Usando Linux-RTAI
1
Introdução
Pretende-se desenvolver um programa para implementar um osciloscópio digital em ambiente Linux-RTAI. As
funcionalidades a implementar serão todas as que foram especificadas nos enunciados dos trabalhos práticos 2
e 3. O RTAI [18] é um sistema que se adiciona ao kernel do Linux [8] de modo a fornecer-lhe um conjunto de
funcionalidades de tempo real, incluindo capacidades de tempo real duro [4].
2
Apresentação do Trabalho
O osciloscópio é composto por um PC local e um PC remoto. Tanto o PC local como o PC remoto contêm
uma placa PCL-841 [3] que permite comunicar através de um barramento CAN. Os PCs local e remoto podem
ser o mesmo PC ou PCs distintos. O PC local (resp. remoto) está ligado ao barramento CAN através do porto
1 (resp. porto 2) da sua placa PCL-841. Colocada no PC remoto, existe uma placa PCL-818L [2], [1] que faz
a amostragem dos canais analógicos a um ritmo ditado pelos contadores do intel i8254, gerando interrupções
para o PC remoto. Os dados resultantes das conversões são enviados do PC remoto para o PC local através do
barramento CAN. O PC local recebe os dados e desenha os gráficos do osciloscópio no écran. Para desenhar os
gráficos do osciloscópio será usada a livraria Qwt 0.4.1 [14] que necessita da livraria Qt [12], [13].
A frequência de refrescamento do écran do osciloscópio será fixa. Em cada refrescamento serão desenhados
os dados correspondentes à janela temporal mais recente que perfaça um écran completo recebido do PC remoto, e obedeça às seguintes condições de elegibilidade. Se o trigger estiver ligado, só são elegı́veis para serem
desenhadas, as janelas temporais que verifiquem a condição de trigger no seu inı́cio. Se o trigger estiver desligado, esta condição torna-se indiferente, pelo que são elegı́veis para serem desenhadas todas janelas temporais
correspondentes a um écran completo.
3
Interface com o Utilizador
O interface com o utilizador é composto por um interface gráfico (Secção 4) e por um conjunto de comandos que
podem ser fornecidos ao programa através do teclado. A lista de comandos que o programa deverá implementar
é a seguinte (nota: para cada comando, deverá também ser aceite a correspondente letra maiúscula):
• “0” e “1” - efectuar amostragens dos canais 0 (zero) e/ou 1 (um) consoante a selecção do utilizador,
usando “pacer ” e interrupções, e ligando ou desligando a visualização da(s) correspondente(s) onda(s) no
écran.
• “a” e “z” - aumentar ou diminuir o valor da tensão correspondente a uma divisão da escala vertical, para
o canal 0.
• “s” e “x” - aumentar ou diminuir o valor da tensão correspondente a uma divisão da escala vertical, para
o canal 1.
• “n” e “m” - aumentar e diminuir o perı́odo de amostragem (multiplicando-o ou dividindo-o por 10).
• “d” - comutar entre a utilização, ou não, da funcionalidade disparo (trigger , “ON” por defeito).
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 1/7
PC k
PC (k + 1)
Monitor, teclado e rato
Monitor, teclado e rato
User space
User space
osc user
osc user -r
ou
osc user -u
qwt
Linux kernel + RTAI
Linux kernel + RTAI
osc kern
osc kern
FR
FL
FR
FL
PCL-818L
PCL-841
P1 P2
PCL-818L
PCL-841
P1 P2
CAN (k − 1)
CAN (k + 1)
CAN k
Canais analógicos
Canais analógicos
Figura 1: Arquitectura de software do osciloscópio. Nesta figura os “PC k” e “PC (k + 1)” estão a actuar como
PC local e PC remoto, respectivamente. Legenda: FL = Funcionalidade Local; FR = Funcionalidade Remota;
P1 = Porto 1; P2 = Porto 2.
• “v” - o programa deve pedir para que o utilizador introduza uma nova configuração da tensão e vertente
de disparo no formato “Vertente Valor”, em que “Vertente” pode ser o caracter “a” ou “d” e “Valor” é o
nı́vel da tensão de disparo. Por exemplo, para um disparo em -1.5V na vertente ascendente o utilizador
deve introduzir “a -1.5” e para um disparo em 2.2V na vertente descendente introduzir “d 2.2”. Se for
introduzido apenas um <Return> a configuração deverá ficar inalterada. O valor do trigger por defeito
deverá ser de 0.5V.
• “l” - mostrar o gráfico do canal 1 (Y) versus o canal 0 (X), isto é, Y=função(X), permitindo visualizar
as figuras de Lissajous.
• “f” - visualizar o espectro do sinal de entrada do canal de menor número que estiver seleccionado.
• “t” - repor o funcionamento normal, em função do tempo.
• “q” - terminar o programa.
4
Desenvolvimento e Funcionamento
Arquitectura e Componentes: A arquitectura de software do osciloscópio a desenvolver está ilustrada na
Figura 1. O programa a ser desenvolvido deverá ser composto pelas seguintes duas componentes que têm que
estar a executar simultaneamente para o osciloscópio funcionar:
• Um módulo de kernel (kernel space), designado osc kern.ko, que funcionará em tempo real tirando
partido das funcionalidades do RTAI. Para o osciloscópio funcionar, existirá uma cópia do osc kern.ko a
executar no PC local e outra a executar no PC remoto. O osc kern.ko será internamente composto por
duas partes: uma funcionalidade local (FL) e uma funcionalidade remota (FR).
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 2/7
• Um programa de utilizador (user space), designado osc user, que apenas será responsável pelo interface
com o utilizador (incluindo a visualização dos gráficos do osciloscópio no écran). O único comando que o
utilizador precisará de executar para pôr o osciloscópio a funcionar será este programa.
RTAI e módulos de kernel: Os módulos de kernel são partes do kernel que podem ser dinamicamente
inseridas e removidas durante o funcionamento do sistema. Parte do RTAI está presente num kernel de arranque
do sistema que tenha sido devidamente compilado para o efeito. Outra parte do RTAI está implementada em
módulos que se devem inserir ou remover dinamicamente consoante as necessidades. Para inserir e remover
módulos pode o administrador (root) usar os comandos insmod e rmmod. Os ficheiros fornecidos incluem os
scripts de shell ldmod2, remod2, ldmod3 e remod3. O utilizador “str” tem disponı́veis os seguintes comandos
nas máquinas do LSRC:
• sudo /sbin/ldmod2 - inserir um certo conjunto de módulos de base para funcionamento do RTAI;
• sudo /sbin/remod2 - remover um certo conjunto de módulos de base do RTAI;
• sudo /sbin/ldmod3 modulo.ko - inserir apenas o módulo “modulo.ko” (e.g. o módulo da aplicação a
desenvolver, ou os módulos do RTAI isoladamente);
• sudo /sbin/remod3 modulo - remover apenas o módulo “modulo”.
Lançamento e terminação: Tanto o lançamento como a terminação do osciloscópio envolvem a realização
de operações tanto no PC local como no PC remoto. Estas operações são em seguida especificadas e descritas.
Lançamento do osciloscópio no PC local: O lançamento será efectuado executando (apenas) o programa
osc user sem mais nenhum argumento de linha de comando. Neste caso, uma das primeiras operações que o
osc user terá que realizar será verificar se o módulo osc kern já está inserido. Se ainda não estiver, então esse
módulo deverá ser inserido. Em seguida deverá activar a FL do osc kern. Uma das funções da FL será usar a
placa PCL-841 e o barramento CAN para realizar o interface de comunicação entre o osc user do PC local e a
FR do osc kern do PC remoto. Se a FR não estiver activada num dado PC, então o software deverá funcionar
correctamente mesmo que esse PC não possua uma placa PCL-818L.
Lançamento do osciloscópio no PC remoto: O lançamento será efectuado executando (apenas) o
comando “osc user -r”. Neste caso, uma das primeiras operações que o osc user terá que realizar será
verificar se o módulo osc kern já está inserido. Se ainda não estiver, então esse módulo deverá ser inserido.
Em seguida deverá activar a FR do osc kern. Uma vez terminadas estas operações, o osc user terminará.
A FR gerirá a aquisição de dados através dos canais analógicos da placa PCL-818L. Outra função da FR será
usar a placa PCL-841 e o barramento CAN para realizar o interface de comunicação entre si própria e a FL do
osc kern do PC local.
Terminação do osciloscópio no PC local: será desencadeada premindo a tecla ‘q’ (cf. Secção 3) no
osc user do PC local. Antes de sair, o osc user deverá desactivar a FL do osc kern do PC local. Se a FR
desse osc kern também estiver desactivada então deverá des-inserir esse osc kern.
Terminação do osciloscópio no PC remoto: será desencadeada executando (apenas) o comando
“osc user -u” no PC remoto. Antes de sair, o osc user deverá desactivar a FR do osc kern do PC remoto.
Se a FL desse osc kern também estiver desactivada então deverá des-inserir esse osc kern.
Hipótese: supõe-se que não serão geradas situações de contenção na inserção e des-inserção do módulo
osc kern, e na activação e desactivação das suas funcionalidades (FL e FR), por mais do que um osc user que
estejam a correr simultaneamente no respectivo PC.
Controlo das Placas PCL-841 e PCL-818L: Tanto a aquisição dos canais analógicos com a placa PCL818L, como a transmissão e recepção de dados (ou outras possı́veis funcionalidades usadas) com a(s) placa(s)
PCL-841, serão controlados por interrupções e não por outro método (e.g. polling, DMA).
Configuração da BIOS: Deve ser efectuada de forma a que computador disponibilize as linhas de interrupção IRQ-3, IRQ-5 e IRQ-7 para utilização pelo barramento ISA. As linhas IRQ-3 e IRQ-7 serão usadas
respectivamente pelos portos 1 e 2 da placa PCL-841. A linha IRQ-5 será usada pela placa PCL-818L. Esta
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 3/7
configuração tem também o resultado necessário de impedir o kernel do Linux de atribuir as IRQ-3, IRQ-5 e
IRQ-7 a outro(s) dispositivo(s) (e.g. existente(s) no barramento PCI).
Linguagens de programação: O programa deverá ser desenvolvido de acordo com as duas regras seguintes:
1. Para o desenvolvimento (kernel space e user space) apenas poderá ser usada a linguagem de programação
C [7], sem prejuı́zo da regra seguinte.
2. A linguagem de programação C++ [31] poderá ser utilizada, mas apenas o mı́nimo possı́vel. Especificamente, a utilização de C++ ficará limitada ao mı́nimo estritamente necessário para implementar a parte
de interface gráfico (user space) que é feito por aplicação da livraria Qwt [33].
Temporização: Sempre que for necessário aplicar mecanismos de temporização, medição e gestão do tempo,
deverão ser usadas as funcionalidades do RTAI [15], e não outras (como por exemplo do Linux, ou das livrarias
Qwt ou Qt).
Interface gráfico: O interface gráfico de visualização a desenvolver deve, como primeira aproximação,
desenhar correctamente os sinais presentes nos canais de entrada do osciloscópio, bem como permitir ao utilizador uma boa e correcta compreensão dos mesmos. Só num passo posterior, e após estarem as capacidades
fundamentais do osciloscópio (tempo real, etc) a funcionar bem, se valoriza também (com menor peso e prioridade) a qualidade do interface em termos do seu grau de aproximação ao écran de um osciloscópio real. Uma
aproximação já razoável será do tipo da que resulta do código exemplo do Trabalho Prático N o 2.
Versões de software: Será usando o kernel linux-2.6.8.1 com o RTAI 3.1 disponı́vel na página disciplina.
Rede CAN: Supõe-se que cada segmento da rede CAN só tem ligadas duas placas PCL-841. Por este
motivo os jumpers das placas devem estar configurados de forma a ligar as resistências de terminação.
Teste do Programa: na versão final, o programa deverá poder ser testado nas três possı́veis situações
seguintes:
1. Um único PC faz simultaneamente os papeis de PC local e de PC remoto. Neste caso a comunicação
CAN estabelece-se entre os dois portos de uma única placa PCL-841 colocada no PC. Esta situação serve
apenas para facilitar o desenvolvimento do osciloscópio usando apenas um PC. O objectivo principal do
trabalho é o funcionamento na situação seguinte.
2. Dois PCs: o PC local e o PC remoto são distintos. Neste caso a comunicação CAN estabelece-se entre
o porto 1 da placa PCL-841 do PC local e o porto 2 da placa PCL-841 do PC remoto. Nesta situação o
software deverá funcionar correctamente mesmo que não exista uma placa PCL-818L no PC local.
3. N (> 2) osciloscópios em operação simultânea usando (N + 1) PCs: um PC local, um PC remoto e N − 1
PCs funcionando simultaneamente como PC local e como PC remoto. Da maneira como o sistema foi
estruturado, esta situação deverá também ser possı́vel. No entanto, o objectivo principal do trabalho é o
teste na situação anterior.
5
Documentação e Recursos
Documentação principal: Considera-se que a documentação principal para apoio à realização deste trabalho
prático é constituı́da pelas seguintes referências:
• RTAI: [15].
• Placa PCL-818L: [2].
• Placa PCL-841: [3], [28], [11]. A referência [11, Secções 1-4] torna-se particularmente útil após consultar
[3] e [29].
• Livraria Qwt: [33].
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 4/7
Podem também ser úteis os exemplos existentes no RTAI showroom [23], bem como os seguintes quatro
documentos sobre interrupções em RTAI [21], [19], [9], [22] (notar no entanto que não será usado lxrt). Na
página da disciplina existe um conjunto de outra documentação e recursos com potencial utilidade. Listam-se
de seguida alguns recursos e documentação adicionais:
• Controladores CAN PCA82C200 [28] e SJA1000 [30], [29]. O placa PCL-841 contém dois PCA82C200.
No seu modo BasicCAN, o SJA1000 é praticamente compatı́vel com o PCA82C200 (cf. [29]). A referência
[30], por conter a especificação completa do SJA1000, pode ser útil como complemento da referência [11].
• Linux kernel: [8], [26].
• RTAI: [18], [16].
• Documentação sobre o RTAI: [15], [10], [6], [20], [27], [21], [19], [9], [22].
• Recursos sobre RTAI: [23], [24], [17].
• Linux I/O port programming mini-HOWTO: [25].
• Livraria Qwt e documentação: [14], [33], [34].
• Funções de C: inb(), outb(), mlockall(), mlock().
• Comandos de Linux: insmod, rmmod, dmesg.
• Ficheiros “/proc/iomem”, “/proc/interrupts” e “/proc/modules” (e.g. “cat /proc/interrupts”).
• Threads - referência rápida: [32].
6
Preparação
1. Analise e teste os ficheiros e o código exemplo. Veja também o resultado do comando dmesg.
2. Analisando o ficheiro /usr/src/linux-2.6.8.1/include/asm/io.h desenvolva e apresente o código fonte
de duas maneiras diferentes para, no interior do kernel do Linux, efectuar os seguintes dois passos: escrita
do byte 0x5B para o endereço de memória 0xDA000 mapeado no barramento ISA do PC, seguida da leitura
de um byte a partir do mesmo endereço para uma variável do programa com o tamanho de um byte.
3. Considerando as caracterı́sticas da placa PCL-818L, qual seria a taxa máxima de refrescamento do écran
do osciloscópio que se poderia atingir? Suponha que se poderia atingir o caso extremo em que, a frames
sucessivas do écran osciloscópio, correspondiam intervalos temporais adjacentes.
4. Desenvolva uma estimativa para o limite superior que se poderia atingir na taxa de refrescamento do écran
do osciloscópio tendo em conta a restrição na velocidade de comunicação através do barramento CAN.
5. Será necessário enviar mensagens CAN do PC remoto para o PC local? Se achar que sim, diga que dados
terão que ser transportados por essas mensagens.
6. Será necessário enviar mensagens CAN do PC local para o PC remoto? Se achar que sim, diga que dados
terão que ser transportados por essas mensagens.
7. Faça uma listagem das várias entidades e agentes envolvidos no trabalho (tarefas, funções, dados, interrupções, recursos, etc . . . ) descritos detalhadamente. Elabore um esquema onde sejam visı́veis os tipos de
relações entre as diversas entidades incluindo os fluxos de dados. Escreva o pseudo-código do programa a
desenvolver. Estruture o programa de forma modular.
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 5/7
7
Trabalho de Implementação
8. Escolha o valor da frequência de refrescamento do écran do osciloscópio. É desejável que a taxa seja
elevada, mas que seja possı́vel de implementar pelo software (módulo de kernel e programa de utilizador)
que corre no PC local sem falhas esporádicas de refrescamento (devidas a sobrecargas transitórias do
sistema). A taxa escolhida deve também ter em conta as estimativas obtidas nos pontos 3 e 4.
9. Implemente o osciloscópio de acordo com a descrição efectuada neste documento.
8
Relatório
Faça um relatório que descreva a estruturação do trabalho e onde constem todas as opções que tiver tomado.
Explique as suas opções detalhadamente. Responda às questões dos passos 1 a 9.
Notas: (1) Deve ser entregue uma versão do relatório em papel. (2) O relatório deve incluir listagens dos
programas desenvolvidos. (3) Deve ser enviado por email um único ficheiro em formato zip que deverá conter
todos os ficheiros relevantes que tenham estado envolvidos na realização do trabalho (*.h, *.c, *.cpp, *.o,
*.ko, *.pro, executáveis, makefiles, scripts eventualmente utilizados para algum fim, etc) bem como a versão
electrónica do relatório (em formato pdf). O email deverá ser enviado para [email protected] no caso de
grupos das Turmas 1 e 2 (Segunda-feira) ou para [email protected] no caso de grupos da Turma 3 (Quinta-feira).
O assunto da mensagem e o nome do ficheiro zip nela incluı́do deverão ser “tXgYrZ-str06.zip”, onde “X”, “Y”
e “Z” são algarismos que representam os números da turma, do grupo e do trabalho prático, respectivamente.
(4) A data limite para o envio deste email é a mesma que a da entrega do relatório em papel.
Bibliografia
[ 1]
Advantech. PCLD-8115 Wiring Terminal Board, September 1994.
[ 2]
Advantech. PCL-818L High-Performance DAS Card with Programmable Gain, October 1995.
[ 3]
Advantech. PCL-841 Dual Port CAN Interface Card, May 1996.
[ 4]
Rui Araújo. Sistemas de Tempo Real: Apontamentos Teóricos (Partes I e II). Departamento de Engenharia
Electrotécnica e de Computadores, Universidade de Coimbra, 2000.
[ 5]
Rui Araújo. Sistemas de Tempo Real: Apontamentos do Laboratório. Departamento de Engenharia Electrotécnica e de Computadores, Universidade de Coimbra, 2004.
[ 6]
E. Bianchi, L. Dozio, and P. Mantegazza. DIAPM-RTAI - Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano Real Time Application Interface (for Linux): A Hard Real Time support for LINUX.
Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano, Milan, Italy, 2000.
[ 7]
Brian W. Kernighan and Dennis M. Ritchie. The C Programming Language. Prentice-Hall, Inc, Englewood
Cliffs, New Jersey, USA, Second edition, 1988.
[ 8]
Linux Kernel Homepage. Disponı́vel em: http://www.kernel.org/ ou ftp://ftp.kernel.org/.
[ 9]
Paolo Mantegazza.
Help!...Confused About How rt request global irq Works.
https://mail.rtai.org/pipermail/rtai/2003-April/003105.html.
Disponı́vel em:
[10] Paolo Mantegazza, E. Bianchi, L. Dozio, Mike Angelo, David Beal, Pierre Cloutier, Stuart Hughes, Gabor
Kiss, Tomasz (Tomek) Motylewski, Steve Papacharalambous, and David Schleef. DIAPM RTAI Programming Guide 1.0. Lineo, Inc, Lindon, Utah, USA, September 2000.
[11] Peter Hank and Egon Jöhnk. SJA1000 Stand-alone CAN Controller. Philips Semiconductors, December
15 1997. (Application Note AN97076).
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 6/7
[12] Qt Library and tools. Trolltech AS, Norway. Disponı́vel em: http://www.trolltech.com/.
[13] Qt Reference Documentation (Free Edition) - Qt 3.3.3. Trolltech AS, Norway, 2004.
[14] Qwt project. Disponı́vel em: http://sourceforge.net/projects/qwt/.
[15] RTAI. RTAI API Documentation 3.1-test4, July 2004.
[16] RTAI CVS Homepage. Disponı́vel em: https://gna.org/cvs/?group=rtai.
[17] RTAI Documentation Project. Disponı́vel em: http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/.
[18] RTAI Homepage. Disponı́vel em: http://www.rtai.org/.
[19] [RTAI] ISR [Interrupt Service Routines]. Disponı́vel em: http://www.rtai.dk/cgi-bin/gratiswiki.pl?ISR.
[20] RTAI Mailing List Archives. Disponı́vel em: https://mail.rtai.org/pipermail/rtai/.
[21] [RTAI] Parallel Port Interrupt Kernel Module Examples,
http://www.captain.at/programming/rtai/.
October 2004.
[22] RTAI Parallel Port Interrupt LXRT Example,
October
http://www.captain.at/programming/rtai/parportintlxrt.php.
2004.
Disponı́vel em:
Disponı́vel
[23] RTAI Showroom.
Disponı́vel em:
http://cvs.gna.org/viewcvs/rtai/showroom/
http://www.isr.uc.pt/~rui/str/showroom.tgz.
em:
e
em
[24] RTAI.dk. Disponı́vel em: http://www.rtai.dk/.
[25] Riku Saikkonen. Linux I/O port programming mini-HOWTO. Helsinki University of Technology, 1997.
Disponı́vel em: http://yolinux.com/MINI-HOWTO/IO-Port-Programming.html.
[26] Peter Jay Salzman, Michael Burian, and Ori Pomerantz. The Linux Kernel Module Programming Guide
[ver 2.6.0], May 15, 2004.
[27] Pasi Sarolahti. Real-time application interface. Technical report, University of Helsinki, Department of
Ccomputer Science, Helsinki, Finland, February 2001.
[28] Philips Semiconductors. PCA82C200 Stand-Alone CAN-Controller, October 1990. (Data Sheet).
[29] Philips Semiconductors. Upgrading Note 82C200 -> SJA1000 Version 1.1, February 19 1999.
[30] Philips Semiconductors. SJA1000 Stand-alone CAN Controller, Jan 04 2000. (Data Sheet).
[31] Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley Longman, Inc, Reading, MA, USA,
Third edition, 1997.
[32] Threads - Referência Rápida. Disponı́vel em: http://www.isr.uc.pt/~rui/str/thread ref.pdf.
[33] Josef Wilgen. Qwt - Qt Widgets for Technical Applications 0.4.1, May 2002.
[34] Josef Wilgen. Qwt User’s Guide Reference Manual 0.4.1, May 2002.
Sistemas de Tempo Real - 2005/2006 - Trabalho Prático No 4 - pág. 7/7