From 011e01175af4c8945361a857eaa7c362b9b04159 Mon Sep 17 00:00:00 2001 From: Renan Augusto Starke Date: Tue, 19 Dec 2023 15:29:20 -0300 Subject: [PATCH] Updated to relative figure links. --- peripherals/onewire/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/peripherals/onewire/README.md b/peripherals/onewire/README.md index 2d5ce2ec..7a03d3b4 100644 --- a/peripherals/onewire/README.md +++ b/peripherals/onewire/README.md @@ -8,7 +8,7 @@ A temporação utilizada neste projeto foi baseada na documentação do sensor D Para implementarmos esse protocolo foi criada a seguinte máquina de estados, representada na figura abaixo. -![](https://raw.githubusercontent.com/ericreis27/riscv-multicycle/master/peripherals/onewire/figures/diagram_onewire.png) +![](./figures/diagram_onewire.png) O protocolo one-wire segue temporizações rigorosas para que os dados possam ser transmitidos de forma correta. Abaixo iremos descrever o funcionamento do protocolo em paralelo com a máquina de estados criada. @@ -16,21 +16,21 @@ O protocolo one-wire segue temporizações rigorosas para que os dados possam se No protocolo OneWire, a inicialização começa quando o mestre (o dispositivo controlador) envia um pulso de reset para a linha de dados. Durante a inicialização, o mestre envia um pulso de reset por um determinado periodo de tempo e espera a resposta de algum dispositivo no barramento de dados, esse processo ocorre entre os estados __RESET, SAMPLE DEVICE RESPONSE e DEVICE RECOVERY RESPONSE__. Caso dentro de uma janela específica de tempo algum dispositivo não puxe o barramento de dados para o GND sinalizando sua presença, a máquina de estados volta para o estado IDLE e reinicia o processo de inicialização buscando novamente por um dispositivo. Caso obtenha a resposta de algum dispositivo, a máquina prossegue para a fase de escrita no barramento. A figura a seguir demonstra a temporização e como funciona esse procedimento. -![](https://raw.githubusercontent.com/ericreis27/riscv-multicycle/master/peripherals/onewire/figures/initialization_onewire.png) +![](./figures/initialization_onewire.png) ### WRITE Durante a escrita, desejamos enviar algum comando para que o dispositivo nos responda com os dados requisitados. Esse envio é feito seguindo um protocolo restrito de temporização para o envio de cada bit do comando. Abaixo segue as especificações de temporização utilizadas para o envio de um bit. -![](https://raw.githubusercontent.com/ericreis27/riscv-multicycle/master/peripherals/onewire/figures/write_time_slot.png) +![](./figures/write_time_slot.png) O envio dos bits é feito entre os estados __MASTER WRITE, MASTER WRITE SLOT E MASTER WRITE RECOVERY__, onde será iterado em cada um dos bits do comando de escrita e serão enviados para o dispositivo. Após o envio do comando entramos num estado __MASTER POST WRITE DELAY__ antes de iniciarmos o processo de leitura. ### READ Da mesma forma que a escrita, a leitura da resposta do dispositivo segue temporização rigorosa. Abaixo seguem dois diagramas detalhando melhor as especificações utilizadas durante o processo de leitura. -![](https://raw.githubusercontent.com/ericreis27/riscv-multicycle/master/peripherals/onewire/figures/read_time_slot.png) +![](./figures/read_time_slot.png) -![](https://raw.githubusercontent.com/ericreis27/riscv-multicycle/master/peripherals/onewire/figures/recommended_read_timings.png) +![](./figures/recommended_read_timings.png) Durante o processo de escrita iremos ciclar entre os estados __MASTER READ, MASTER AWAIT READ SAMPLE E MASTER READ RECOVERY__, atuando de forma cíclica extremamente similar a como fazemos o processo de escrita, porém trabalhando com temporizações diferentes. Após a leitura de todos os bits de resposta do dispositivo finalmente vamos para um estado de recuperação __MASTER POST READ DELAY__ e finalmente chegamos no fim da implementação do protocolo no estado __DONE__.