quarta-feira, 28 de fevereiro de 2007

Placa adaptadora para cartões

Layout para a placa adaptadora para cartões. Os LEDs de Alimentação e "Chip Select" ficaram nesta placa.

Com um pouco de habilidade acho que é possível instalar o leitor de cartões internamente ao Hotbit, e instalar esta plaquinha de forma que o cartão seja inserido entre as teclas SELECT e F1/F6.

Biblioteca para o soquete do cartão

Os conectores de cartão que comprei na Farnell chegaram Já fiz um biblioteca em formato "Eagle". Imprimi sobre o papel para conferir. Parece estar bem ajustada. No papel, pelo menos, ficou legal.

Vou imprimir uma plaquinha para usar com meu protótipo.

Coloquei a biblioteca neste link aqui

segunda-feira, 26 de fevereiro de 2007

HB-7000: Mais testes com o "driver" de escrita

Terminei de debugar parte de escrita do "driver" do leitor/gravador de cartões, que apesar de estar funcionando, estava me intrigando, pois a interface parecia receber 2 bytes a mais entre a transmissão do CRC do bloco, e o recebimento da resposta ("acknowledge") do cartão.

A causa era a falta de um NOP entre as instruções OUT que escreviam o CRC "dummy", e as intruções IN logo em seguida.

É que as instruções de entrada/saída automática (INI, OUTI, INIR, OUTIR) demoram alguns ciclos de clock a mais que as instruções IN e OUT, dando tempo da interface transferir automaticamente os 8 bits. No caso da instrução IN e OUT eu tenho apenas o tempo entre a borda de subida do sinal IORQ da instrução anterior e a borda de descida deste mesmo sinal na próxima instrução.Pelas minhas contas até dava, mas vou ter que estudar isso mais a fundo depois.

O fato é que nos testes que eu fiz, o NOP realmente fez a diferença, e resolveu o problema.


Segue abaixo o trecho de código que foi corrigido:

LD A,0FFH
OUT (C),A ; DUMMY CRC
NOP
OUT (C),A ; DUMMY CRC
NOP
IN A,(C) ; DESCARTA
NOP
IN A,(C); TRANSF RESPOSTA
AND 01FH
CP 05
JP NZ,ERROR


Uma sutileza no funcionamento da interface, é que quando se faz uma leitura, o valor lido é o que foi recebido na transferência anterior. Por isso a leitura da primeira instrução IN logo após a transferência do CRC é descartada. Este primeiro IN também poderia ser um OUT, pois serve apenas para iniciar a transferência do byte seguinte.

O código atual, capturado da porta da impressora, encontra-se neste link.

Status do Projeto

Eis um status atualizado, e comentado, do status do projeto, do ponto de vista dos requisitos estabelecidos.


Requisitos de Hardware:
O hardware...

-Deverá utilizar o espaço de endereçamento de I/O do Z80, dentro do padrão MSX (abaixo de 040h);
Cumprido. O circuito foi projetado para funcionar nas portas 12 e 13 do endereçamento de I/O do Z80. Os drivers do programa utilizam endereçamento relativo, via registrador C e suportam operação em quaisquer 2 portas consecutivas, sem necessidade de adaptação do código.

-Deverá utilizar o clock do Z80 como fonte de clock;
Cumprido. Comprovação pelo próprio projeto.

-Deverá suportar um clock (do Z80) de até 7,16MHz;
Teste a 3.5MHz ok. Simulação até 8MHz .

-Deverá ser capaz de gerar um clock numa frequência inferior a 400KHz, para inicialização do cartão;

Cumprido. O circuito possui um sinal de clock alternativo. A frequência do sinal de clock alternativo é definida por software, alternando-se o tempo em que o sinal de clock alternativo fica em nível alto e nível baixo.

-Deverá realizar a transferência de dados de forma bidirecional, conforme padrão SPI (transmite e recebe ao mesmo tempo);

Cumprido.

Deverá realizar uma transferência de blocos através de instruções de I/O de bloco (INI, INIR, OUT, OTIR), tão rápido quanto possível para o Z80;

Cumprido.

- Deverá realizar transferência de bytes num tempo igual ao do MSX para fazer acessos consecutivos de I/O;

Cumprido.

- Deverá ser possível implementar a interface sem a necessidade de chips de lógica programável, utilizando apenas componentes comuns no mercado: chips TTL, resistores e capacitores de famílias padrão;

Cumprido.

- Deverá haver um LED indicador de acesso ao cartão.

Em estudo. O Acesso é tão rápido que um LED conectado ao pino /CS do cartão fica frações de segundo aceso, não permitindo que se veja quando o cartão está sendo acessado.

- Deverá haver um LED indicador de que a alimentação do cartão está ativa.

Ainda não implementado.

- Deverá suportar Inserção/Remoção/troca do cartão sem necessidade de se desligar o computador.

Cumprido.

- Deverá possuir um conversor para alimentar o cartão MMC/SD, fornecendo uma tensão entre 2,8V e 3,6V, com capacidade de pelo menos 100mA;

Cumprido. Mas está sendo estudada a possibilidade de alternativa para o conversor atual. Uma boa possibilidade é a transferênica deste conversor para para uma placa auxiliar, cuja ligação com a placa principal se dará por apenas 4 fios. Esta placa auxiliar pode conter várias alternativas (BJT, JFET, LDO, chaveados, etc), dependendo da disponibilidade de componentes de quem for montar o projeto.

-O circuito deve ser projetado de forma a consumir pouca energia.

Cumprido. O circuito utiliza chips de tecnologia HCT e HC. O consumo ainda não foi medido.


-Todos os diagramas e "lay-outs" devem ser disponibilizados;

Em andamento. O protótipo 2 está sendo reformulado para refletir as alterações sofridas durante os testes e experimentações.

-A placa de circuito impresso da versão final deve ser projetada de forma a permitir a montagem caseira (refs [1] [2] [3]);

Em andamento. aguardando o circuito chegar à versão final. Mas todas as placas de protótipo até o momento foram construídas utilizando este método, em placas de face simples.


-Deverá possuir suporte para um relógio de tempo Real I2C;

Em andamento. Módulo já construído.

-Deverá possuir circuitos de teste auxiliares, montados em placa externa, para auxiliar no teste dos vários blocos que compõem o circuito, de forma a suportar a construção e teste gradual da interface;

Cumprido. Uma sonda lógica foi projetada especialmente para auxiliar na montagem deste circuito.

-Deverá possuir um guia de montagem que suporte a construção e o teste gradual da interface;

Em andamento. Pendente revisão do guia após definida versão "release" de hardware.


Requisitos de Software:

-Todo o código fonte será disponibilizado sob licença GPL;

Em andamento. Drivers básicos SD/MMC em estágio avançado de desenvolvimento. Drivers I2C precisam ser reescritos e testados, para suportar o relógio de tempo real.

-Deverá haver um software de testes que suporte o teste dos vários blocos que compõem o circuito, de forma a suportar a construção e teste gradual da interface;

O guia de montagem e teste substitiu tal software. Entretanto, 2 programas de teste necessitam ainda serem escritos; um para SD/MMC e outro para I2C.

-Deverão ser implementadas as rotinas de baixo nível destinadas à inicialização e identificação do cartão, bem como à leitura, escrita e apagamento de blocos de memória;

Rotinas de inicialização e de leitura prontas. Rotina de escrita em andamento. Rotinas de identificação e pré apagamento ainda não escritas.

-O software deverá suportar cartões MMC e SDC;

A rotina de inicialização prevê ambos os tipos. Testado em um cartão SD. Ainda não testado com um cartão MMC.

-Deverão ser implementadas as rotinas de baixo nível para acesso ao relógio de tempo real;

Drivers I2C precisam ser reescritos e testados, para suportar o relógio de tempo real

sábado, 24 de fevereiro de 2007

30 Minutos

Só pra registrar... até o presente momento, de "Save" em "Save", já gastei 30 minutos do lado A da fita cassete no desenvolvimento do "driver" pro leitor/gravador de MMC/SD!!

O bom e velho HB-2400 não me deixa na mão :) !

HB-7000: Sucesso nos testes de gravação

Efetuei hoje, com sucesso, os primeiros testes de gravação.

A velocidade de escrita quando se escrevem blocos diferentes, é compatível com a velocidade de leitura (128KBytes/segundo), o que sinceramente me surpreendeu. Eis um link para o vídeo.

Quando se escreve repetidamente sobre o mesmo bloco, a velocidade de gravação cai para uns 10Kbytes/segundo. Isso me confundiu a princípio, mas depois repeti os testes, alternando entre gravar sempre no mesmo bloco, ou em blocos diferentes, e o resultado sempre foi o mesmo.

Neste site (link) tem um benchmark com resultado semelhante.

Mas uma coisa que tenho que investigar é que o cartão não está enviando a resposta logo em seguida ao pacote de dados, e sim, após receber mais 16 pulsos de clock. Eu coloquei um "loop" na minha rotina de escrita para aguardar a resposta do cartão. isso resolveu o problema, mas ainda vou fazer mais testes, para averiguar qual a razão, antes de finalizar a rotina de escrita.

sexta-feira, 16 de fevereiro de 2007

Layout para o adaptador de mouse

Um amigo meu me falou que ia montar o adaptador de mouse PS/2 que viu na página do Luciano (MSXpro) e eu fiz um layout pra ele, pra colocar dentro de uma caixinha de Trident Mini (aquela bala de menta/canela que vem numa caixa arredondada).

O arquivo com o diagrama, máscara de componentes, layout em formato Eagle, EPS e GIF, encontra-se neste link.

Abaixo uma figura e como ficou. Já corroí as plaquinhas. Quando o Igor terminar de montar vou pedir a ele pra testar e mandar algumas fotos.


Esta é a caixinha de Trident Mini. :)

quinta-feira, 15 de fevereiro de 2007

Mais 2 testes.

Fiz mais 2 testes com o software do cartão.

Um deles foi forçar a inicialização pelo comando ACMD41. Tive que forçar, pois o cartão SD que eu tenho consegue ser inicializado pelo comando CMD1. A conclusão é que a rotina de inicialização já é capaz de aceitar tanto cartões MMC quando SD.

O outro teste foi para ver se a rotina de tratamento de erro da função de leitura de bloco estava funcionando bem. Eu mandei ler um bloco ilegal, e o comando retornou um erro, ou seja. também está legal.

Para terminar a rotina falta otimizar o laço de leitura, usando um "loop" de vários INI em vez de um INIR, e implementar 2 ponteiros. Um para o endereço de memoria que vai receber os dados, e outro para o endereço do bloco do cartão que vai ser lido.

Depois será a vez de implementar as rotinas de escrita.

HB7000: 128Kbytes/s . Bem dentro do esperado.

As rotinas básicas de acesso ao cartão já estão bem adiantadas.

A rotina de inicialização e o tratamento de erro possuem até um "flag" de "verbose", pra ajudar no desenvolvimento.

Notei que em determinados momentos, o cartão não inicializava corretamente. Felizmente consegui isolar o problema, que foi corrigido com um "delay"entre o momento em que a fonte de 3V3 é acionada e o momento em que se começa a inicialização do cartão, aplicando-se 80 pulsos de "clock".

As rotina de leitura ainda está simples, mas já utiliza o modo de geração automática de "clock" para a instrução IN. O bloco de 512 bytes está sendo lido por 2 comandos INIRs em sequência, mas ainda dá para melhorar a velocidadade.

Mesmo assim a velociadade ficou dentro do esperado. O programa utilizado para estimar a velocidade, inicializa o cartão, e em seguida imprime o caractere "!". Depois lê 256 vezes um bloco de 512bytes, ou seja, 128Kbytes. Ao final, o programa imprime o caractere "*"

O tempo gasto para a transferência dos 128Kbytes foi de aproximadamente 1 segundo, ou aproximadamente 128Kbytes/segundo. Eis o link para o vídeo.

terça-feira, 13 de fevereiro de 2007

Fazendo Contas

Tomando por base uma maquina msx padrão, que insere um "wait state" a cada
ciclo M1, temos os seguintes tempos de execução (em ciclos de máquina):

INI,OUTI 16 ciclos +4 Wait states
INIR,OTIR 21+5 / 16+4
DJNZ 13+3 ou 10+2 na última iteração

Considerando então a transferência de 512 bytes (1 bloco) temos duas alternativas

Alternativa 1 - Loop automático (inicia com B=0):

inir [256*(26)-6] ciclos
inir [256*(26)-6] ciclos

Total: [256*(26)-6]*2 = 13300 ciclos para transferir 512 bytes (1/2Kbyte)

Muma máquina rodando a 3,579MHZ, temos:

Taxa = 3,5MHz * 1/2 / 13300 ciclos = 134,5KBytes/seg (~1,08 MBits/s)

Alternativa 2 - Loop semi automático (inicia com B=16):

b=16
loop:
INI
INI
...
INI (32 instruções INI seguidas)
DJNZ loop

[32*20+16]*16-4 = 10492ciclos, ou seja 170,6 kBytes/s (1,33 MBits/s)

Alternativa 3 - Loop semi automático (inicia com B=8):

b=8
loop:
INI
INI
...
INI (64 instruções INI seguidas)
DJNZ loop

[64*20+16]*8-4 => 172,66 kBytes/s (1,35 MBits/s)

(nota: 1Mbit=1024bits)

Conclusões:

A taxa de transferência esperada da interface HB-7000 para uma máquina MSX1 padrão
rodando a 3,579MHz gira em torno de 170kbytes/segundo.

Esta velociadade é praticamente a mesma das uma instruções de movimento de
memória LDI,LDIR (que consomem os mesmos tantos ciclos de máquina que os seus
paralelos para IO - INI/OUTI, INIR/OTIR)



Somente para complementar o assunto:


Assim que o cartão é energizado, ele deve receber pelo menos 74 pulsos de clock numa frequência máxima de 400KHz. A rotina abaixo é utilizada para gerar estes pulsos.


INI1: LD A,ALTCKH (2+7)
OUT (C),A (3+12)
LD A,ALTCKL (2+7)
OUT (C),A (3+12)
DJNZ INI1 (3+13, para b<>0)


O número de pulsos de clock gastos em cada instrução está entre parêntesis. Como uma máquina MSX padrão gera um "Wait State" a cada ciclo M1, o primeiro número corresponde àos ciclos de clock extras.

Temos então um total de 9+15+9+15+16=64 ciclos de clock gastos no loop. Isso resulta em uma frequência de Fpulsos=Fclk/64.

Então temos para:

Fclk= 3,579MHz, Fpulsos=55,9KHz

Fclck=8MHz. Fpulsos=125KHz.

Logo, esta rotina não precisa de ajuste para trabalhar em 8MHz.

segunda-feira, 12 de fevereiro de 2007

HB-7000: Código de inicialização

Segue abaixo uma amostra do código, capturado via circuito de captura de listagem de impressora. Ainda falta definir algumas constantes, e completar uma ou duas subrotinas, mas vamos em frente.


10 ; Leitor de MMC/SD
20 ;
30 ORG 0A000H
40 ;
50 INIT:
60 LD A,(SPIBASE)
70 LD C,A
80 INC C
90 ;
100 ; Inicia Hardware
110 LD A,ENARDA
120 OUT(C),A
130 LD A,ENAWRA
140 OUT(C),A
150 LD A,ALTCKL
160 OUT(C),A
170 LD A,CSLO
180 OUT(C),A
190 LD A,P3V3ON
200 OUT(C),A
210 LD A,DISDIN
220 OUT(C),A
230 ;
240 LD HL,(DLINIT)
250 LD B,80
260 ;
270 INI1:
280 LD A,ALTCKH
290 OUT (C),A
300 CALL DELAYHL
310 LD A,ALTCKL
320 OUT (C),A
330 CALL DELAYHL
340 DJNZ INI1
350 ;
360 LD A,ENADIN ;Habilida saida dados
370 OUT (C),A
380 LD A,CSLO
390 OUT (C),A
400 DEC C ; restaura C=SPIBASE
410 ;
420 ;Envia CMD0 (comum MMC/SD)
430 LD HL,CMD0
440 CALL SNDCMD
450 LD E,ECMD0
460 JP C,ERROR
470 LD E,ERSP0
480 CP 01
490 JP NZ,ERROR
500 ;
510 ;CALL PRTHEX
520 ;
530 ;Neste ponto CMD0 aceito
540 ;Agora tenta CMD1 ou ACMD41
550 ;
560 ;Tenta CMD1. Se rejeitado
570 ;ou timeout, tenta ACMD41
580 ;
590 LD B,255
600 ;
610 INI2:
620 LD D,B ; salva B
630 LD HL,CMD1
640 CALL SNDCMD
650 LD B,D ; restaura B
651 ;
660 JR C,INI4 ; Timeout? tenta ACMD41
670 BIT 2,A ; Comando ilegal?
680 JR NZ,INI4 ; Sim, tenta ACMD41
690 ;
700 CP 01 ; Ainda em IDLE?
710 JR NZ,INI3 ; Nao. Entao continua
720 DJNZ INI2 ; Sim, tenta novamente
730 ;
740 INI3:
750 OR A ; cartao respondeu OK?
760 LD E,ERSP1
770 JP NZ,ERROR ; Nao. sinaliza erro
780 JP INIOK ; Sim. Termina rotina
790 ;
800 INI4:
810 LD B,255
820 ;
830 INI5:
840 LD D,B ; salva B
850 LD HL,CMD55
860 CALL SNDCMD
870 LD B,D ; restaura B
871 ;
880 LD E,ECMD55
890 JP C,ERROR
900 CP 01
910 LD E,ERSP55
920 JP NZ,ERROR
930 ;
940 LD D,B ; salva B
950 LD HL,CMD41
960 CALL SNDCMD
970 LD B,D ; restaura B
980 LD E,ECMD41
990 JP C,ERROR ;timeout? sinal. erro
999 ;
1000 CP 01 ; ainda em IDLE?
1010 JR NZ,INI6 ; nao. prossegue
1020 DJNZ INI5 ; sim. tenta de novo
1030 ;
1040 LD E,ECMD41 ;nao saiu de idle
1050 JP ERROR ;entao sinal. erro
1060 ;
1070 INI6:
1080 OR A ; resposta OK?
1090 LD E,ERSP41
1100 JP NZ,ERROR ; nao. sinaliza erro
1110 ;
1120 INIOK:
1130 LD D,A ; D=resposta R1
1140 INC C ; C=SPIBASE + 1
1150 LD A,CSHI
1160 OUT (C),A ; desabilita CS
1170 DEC C ; retorna C=SPIBASE
1171 ;
1180 LD A,INITOK
1190 LD (STAT),A ; atualiza status
1200 ;
1210 XOR A
1220 LD E,A ; E= sem erro
1230 RET


Abaixo a saída do Simple Assembler, com as linhas onde os "labels" estão indefinidos.



<< Simple ASM Ver 2.1 Coral >> PAGE 1

60 U A000 3A0000 LD A,(SPIBASE)
110 U A005 3E00 LD A,ENARDA
130 U A009 3E00 LD A,ENAWRA
150 U A00D 3E00 LD A,ALTCKL
170 U A011 3E00 LD A,CSLO
190 U A015 3E00 LD A,P3V3ON
210 U A019 3E00 LD A,DISDIN
240 U A01D 2A0000 LD HL,(DLINIT)
280 U A022 3E00 LD A,ALTCKH
300 U A026 CD0000 CALL DELAYHL
310 U A029 3E00 LD A,ALTCKL
330 U A02D CD0000 CALL DELAYHL
360 U A032 3E00 LD A,ENADIN ;Habilida saida dados
380 U A036 3E00 LD A,CSLO
430 U A03B 210000 LD HL,CMD0
440 U A03E CD0000 CALL SNDCMD
450 U A041 1E00 LD E,ECMD0
460 U A043 DA0000 JP C,ERROR
470 U A046 1E00 LD E,ERSP0
490 U A04A C20000 JP NZ,ERROR
630 U A050 210000 LD HL,CMD1
640 U A053 CD0000 CALL SNDCMD
760 U A064 1E00 LD E,ERSP1
770 U A066 C20000 JP NZ,ERROR ; Nao. sinaliza erro
850 U A06F 210000 LD HL,CMD55
860 U A072 CD0000 CALL SNDCMD
880 U A076 1E00 LD E,ECMD55
890 U A078 DA0000 JP C,ERROR
910 U A07D 1E00 LD E,ERSP55
920 U A07F C20000 JP NZ,ERROR
950 U A083 210000 LD HL,CMD41
960 U A086 CD0000 CALL SNDCMD
980 U A08A 1E00 LD E,ECMD41
990 U A08C DA0000 JP C,ERROR ;timeout? sinal. erro
1040 U A095 1E00 LD E,ECMD41 ;nao saiu de idle
1050 U A097 C30000 JP ERROR ;entao sinal. erro
1090 U A09B 1E00 LD E,ERSP41
1100 U A09D C20000 JP NZ,ERROR ; nao. sinaliza erro
1150 U A0A2 3E00 LD A,CSHI
1180 U A0A7 3E00 LD A,INITOK
1190 U A0A9 320000 LD (STAT),A ; atualiza status




Conector de cartões SD/MMC

Apesar de ter improvisado um conector para o cartão SD, resolvi comprar um conector específico para este cartão. Acabei comprando um baratinho na farnell, modelo SDAMB-01215BT00.

HB-7000: Rotinas básicas

Continua o trabalho de reescrever as rotinas para acesso ao cartão.

A rotina de inicialização do cartão agora trabalha no modo nativo da interface, ou seja, tanto a leitura quanto a escrita na porta SPI causam a transferência de um byte.

Foi adicionada ainda a capacidade de inicialização tanto de cartões MMC quando SD. Isso é feito da seguinte maneira: Logo após o cartão responder positivamente ao comando CMD0, envia-se repetidamente o comando CMD1, até que o cartão responda, ou que aconteça um "timeout". Se houver um "timeout" ou se o cartão responder com o bit de "illegal command" ativo, então o processo é repetido usando-se o comando ACMD41, que é na realidade o par de comandos CMD55 e CMD 41 enviados consecutivamente. Desta vez, caso haja um "timeout" a rotina retorna erro.
Esse procedimento é necessário, pois nem todos os cartões SD respondem ao comando CMD1.

quinta-feira, 8 de fevereiro de 2007

Sonda Lógica

Eis a sonda lógica que montei para ajudar no desenvolvimento do protótipo do leitor de MMC.


O diagrama da sonda pode ser visto na figura abaixo


O arquivo completo, contendo diagrama e "layout" em formatos eps, gif e eagle encontra-se neste link.

quarta-feira, 7 de fevereiro de 2007

Leitor de SD/MMC: Testado com sucesso!!!

Fiz mais alguns testes, e os resultados foram positivos e animadores.

Eis abaixo os últimos bytes lidos do setor 1, onde fica a MBR. Detalhe nos dois últimos bytes, que são a assinatura da MBR.




Abaixo, a captura de imagem com os bytes recebidos pelo cartão.



Os byte são a resposta aos comandos, e significam:
INIT OK, mensagem escrita pelo programa, assim que o cartão aceitou o comando de entrar no modo SPI
00 Resposta (tipo R1) ao comando de leitura. Nenhum bit setado significa tudo ok.
FF FF FF Bytes enviados pelo cartão enquanto processave o comando de ler o setor (busy)
FE "data token" emitido pelo cartão assim que está pronto para enviar dados. Os 512 dados subsequentes são os bytes de dados.

Apenas como comparação, a tela abaixo é de um comando que foi enviado com endereço de leitura ilegal. O bit 5 significa "illegal address".




A escrita ainda não foi não foi testada, como ela se baseia simplesmente na comunicação com o cartão, que já se provou plenamente funcional, não vejo problemas para que esta funcione. Além disso, até este ponto, os testes principais são de "hardware".

Mas, já dá pra afirmar que o hardware está 100% funcional, e que o leitor rápido de MMC/SD já é uma realidade para o MSX.


Próximos passos:
- Terminar o guia de montagem e instalação;
- Reescrever as rotinas de leitura/escrita, utilizando as instruções automáticas do Z80;
- Personalizar os drivers I2C para ler o módulo de relógio;
- Atualizar o cumprimento dos requisitos do projeto.

segunda-feira, 5 de fevereiro de 2007

Catão SD inicializou corretamente

Eu consegui hoje inicializar o cartão SD. Pelo menos, ele respondeu corretamente ao comando de inicialização.

Mas antes disso, tive que matar antes mais um "bug" na alimentação do cartão, pois mesmo com os resistores de 10K em série com os terminais de entrada do 74HC125, a tensão subia para quase 5 volts quando a fonte era desativada, pois a corrente que o 74HC125 consome é irrisória. Deu para resolver com um resistor de 1k5 em paralelo com a saída, o que levou a tensão para 0,7 Volts, quando o comando manda a fonte desligar.

Para o teste, adaptei uma rotina que lê o cartão em modo "bitbang", mas mudei o modo de acesso para byte a byte, com "clock" automático disparado pela escrita no registrador de deslocamento. Vou me basear nestas rotinas para os testes iniciais.

Concluí também a montagem do relógio de tempo real. Fotos abaixo. Não testei ainda, mas já tenho os "drivers" para I2C escritos e testados, em "hardware" semelhante.



Segue ainda, a foto do adaptador de cartão improvisado com um conector de drive de 5 1/4". Ficou bacana mas posteriormente vou usar um soquete de SD/MMC que vi que no site da farnell (modelo SDAMB-01215BT00, cod farnell 9186140)