Lab. Microprocessadores PCS2031 Curso Cooperativo prof. Jorge Kinoshita. 2. quadrimestre 2010. Esse calendário contém as datas referentes das aulas para as turma de quinta-feira. Para a turma de sexta, a aula ocorre no dia seguinte. Aulas turma1: Quinta 8:20-12:00H, turma2: Quinta 14:00-17:40H, turma3: Sexta 14:00-17:40H 1. Introducao a microprocessadores, com ênfase ao ARM. referência: ARM Laboratory Exercises, cap. 1 13/5 www.ee.ic.ac.uk/t.clarke/arch/lectures/Part1.ppt www.ee.ic.ac.uk/t.clarke/arch/lectures/Part2.ppt 2. Programming Basics (cap2) + Data Processing Operations (cap3). 20/5 3. Loads and Stores (cap4) 27/5 4. Conditional Executiong Loops (cap5). 10/6 5. Subroutines (cap6) 17/6 6. Memory Mapped Peripherals (cap7). 24/6 www.ee.ic.ac.uk/t.clarke/arch/lectures/Part3.ppt 7. excessoes seguindo a partir de 7.5.12, interrupcao de botao. 1/7 8. Semihosting (cap10) Floating-point Computation (cap9) . 15/7 9. KinOS - criar um mecanismo de troca de mensagens entre processos, através de mensagens sem buffer. 22/7 Criar 1) send(processo_destino, tipo_mensagem, mensagem), 2) receive(processo_origem, tipo_mensagem, mensagem) 3) sendrec(processo_destino, tipo_mensagem, mensagem) 4) notify(processo_destino). onde tipo_mensagem e mensagem sao words; processo_origem/destino é o número do processo. A mensagem é definida pelo tipo_mensagem e pode ser um inteiro, um ponteiro para uma string, etc. send, receive, sendrec e notify devem ser chamadas através de SWI. Veja como as system calls foram implementadas através das SWI no item 3.6 da monografia - projeto de formatura. Em particular veja como o fork foi implementado usando SWI. Veja também os estados em que um processo pode estar. Estude como colocar um processo em estado bloqueado ao enviar ou receber uma mensagem. Dependendo do caso, o processo que faz SWI é bloqueado até trocar mensagem com outro processo. Se as mensagens enviadas forem armazenadas em um buffer, então é possível que o send envie a mensagem e o processo não fique bloqueado; pelo menos enquanto houver buffer. Porém, isso causa uma complexidade maior que é o gerenciamento do buffer. A fim de não termos esse problema, vamos fazer como no minix: o processo que faz send fica bloqueado esperando o processo destino fazer receive; ou o processo destino primeiro faz o receive ficando bloqueado até que o outro processo execute o send. Ao enviar uma mensagem, em alguns casos, não queremos que o originador da mensagem fique bloqueado. Nesse caso, vamos criar o notify(processo_destino). O notify vai ser usado pelo kernel quando o kernel enviar uma mensagem para um processo devido, por exemplo, a uma interrupcao de botao. O notify é mais simples que o send. Mesmo que o processo_destino não tenha executado um receive, o notify não bloqueia o processo (ou kernel) que envia a mensagem porque vamos simplesmente criar um bitmap informando que um determinado processo ou o kernel enviou um notify. O bitmap é uma estrutura interna do núcleo e você pode definir como quiser (no minix, existe um bitmap que explica a causa da interrupcao, mas no nosso caso, podemos adotar que a causa eh o botao). Quando o processo recebe uma mensagem originada por um notify, adote uma mensagem e um tipo padronizados. Fazer com que a interrupcao de botao gere um mensagem para um determinado processo. Criar a calculadora de um digito usando a troca de mensagens: 1. um processo p1 fica continuamente while(1) { receive(kernel, tipo, msg); soma = soma + (le_dipswitch); send(p2, t, soma); } Um processo p2 fica continuamente while (1) { receive(p1, t, soma); apresenta soma nos 7 segmentos; } sendo que quando ocorre a interrupcao de botao eh feito o notify(p1). Trocar o p2 por um processo que apresente o resultado nos leds. 10. KinOS - troca de mensagens entre processos / semáforos. 29/7 Vamos criar as operacoes down e up sobre semaforos como ela foi implementada num trabalho do minix. A system call down ou up será feita através do sendrec para o processo sema (o "servidor de semaforos"). O processo sema faz continuamente: aguarda uma mensagem executando o up ou o down e retarda a resposta no caso em que o down deva bloquear o processo. 11. Linux driver. http://www.pcs.usp.br/~jkinoshi/2008/Exp8_revisada_13_08_07.doc 5/8 12. Linux driver paralela. http://www.pcs.usp.br/~jkinoshi/2007/2031e9.doc 12/8 13. qemu ou gnuarm - Projeto livre: 1) transportar código do Lab. Exercises para o gnuarm. 2) rodar linux em um ARM emulado: http://www.aurel32.net/info/debian_arm_qemu.php - deve ser possivel entrar nas rotinas de interrupcao do codigo emulado. 3) É possível se ter simuladores onde seja fácil de visualizar as rotinas de interrupcao? 4) transportar o KinOS para o gnuarm. 19/8 Avaliacao: (E1+E2+E3+E4+E5+E6+3*E7+E8+3*E9+3*E10+E11+2*E12+5*E13)/24 Avaliação por experiência: - Penalidade = -1 por atraso de 15 minutos - Penalidade = -4 por atraso de 1 hora. Ao término de cada experiência enviar código para o professor. Referências: 1) ARM Laboratory Exercises - apostila - http://courses.cs.tamu.edu/rabi/cpsc617/resources/ARM%20Lab%20Mannual.pdf 2) ARM Assembly Language Fundamentals and Techniques, William Hohl, CRC Press 3) ARM System-on-Chip Architecture (2nd Edition), Steve Furber 4) ARM System Developer’s Guide Designing and Optimizing System Software; Andrew N. Sloss, Dominic Symes, Chris Wright; Elsevier 5) KinOS: http://code.google.com/p/arm7linux/downloads/list 6) Projeto do Alison, Guilherme, Keila coop10 de pcs2031.