Notes - MCS
Reverse Engineering
Notes - MCS
Reverse Engineering
  • Reverse Engineering
  • Introduction to Reverse Engineering
    • What is Reverse Engineering (RE)
    • RE Concepts
    • When do we have RE activities?
    • Why RE is Relevant and Required
    • Limitations of RE
    • Legal Framework
    • What RE Recovers?
    • Software Reversing
    • Low-level languages
  • Files and Filetypes
    • Files
    • File extensions
    • File Signature
    • Content Type Obfuscation
  • Android – Static Analysis
    • Java Language
    • Application Entry Points
    • Application Structure
    • AndroidManifest.xml
    • Exercise 1
    • Exercise 2
    • Exercise 3
    • Exercise 4
    • Native Applications
    • Java Native Interface
    • Android Native Development Kit (NDK)
    • Android binary libraries
    • JNI Dynamic Linking
    • JNI Static Linking
    • Exercise 5 and 6
    • Web and Hybrid applications
  • Android – Dynamic Analysis
    • Dynamic Analysis
    • Logs
    • Network MiTM
    • Certificate Pinning
    • Dynamic Code Instrumentation
    • Dynamic Binary Instrumentation
    • FRIDA
  • Binary Analysis
    • Binary Objects
    • Executable Symbols
    • What is inside an Object File?
    • ELF Files
    • ELF Program Headers
    • Dynamic Linker
      • Example
    • Binary Analysis Process
    • Function detection
    • Calling Conventions
    • Common Logic Structures
    • C++ code
  • Emulation and Instrumentation
    • Dynamic Binary Analysis
    • Considerations
    • Processes
    • Dynamic Binary Instrumentation (DBI)
    • DBI with Qiling
  • Obfuscation Techniques
    • Obfuscation Techniques
    • Content Type Obfuscation
    • Code Obfuscation
  • Serial Communication
    • Comunicação paralelo
    • Comunicação série
    • Sincronização entre transmissor e recetor
    • Sincronização de relógio
    • Transmissão de dados
    • Topologias de comunicação série
    • Elementos de uma ligação série
  • A interface RS-232C
    • RS-232C
    • Estrutura da trama
    • Camada física
    • Taxa de transmissão (baudrate)
    • Receção de dados
    • Identificar parâmetros de comunicaçãoIdentificar parâmetros de comunicação
    • Encontrar a UART
    • Captura de sinais
  • Norma SPI
    • Introdução
    • Descrição geral
    • Operação
    • Simulação do master SPI
    • Arquiteturas de ligação
    • Tipos de transferências
    • Configuração de um master SPI
    • Procedimento para identificação dos sinais
    • Exemplo
  • Norma I2C
    • Introdução
    • Caraterísticas básicas
    • Exemplo de interligação num barramento I2C
    • Terminologia
    • Masters e Slaves
    • Sinalização
    • Endereçamento
    • Transferência de dados
    • Clock stretching
    • Múltiplos masters
    • Arbitragem
    • Endereços reservados
Powered by GitBook
On this page
  1. Norma I2C

Múltiplos masters

Last updated 10 months ago

Dois (ou mais) masters podem iniciar uma transmissão num barramento livre (isto é, após um STOP) ao mesmo tempo

Tem de estar previsto um método para decidir qual dos masters toma o controlo do barramento e completa a transmissão – arbitragem de acesso ao barramento

O master que perde o processo de arbitragem retira-se e só tenta novo acesso ao barramento na próxima situação de "barramento livre"

Na gestão do acesso ao barramento é necessário:

  1. garantir que os relógios dos masters estão sincronizados

  2. um processo que defina qual o master que ganha o acesso ao barramento, i.e., que controla a linha SDA (arbitragem)

A sincronização de relógios e a arbitragem são baseados na técnica bit dominante/bit recessivo:

  • Nível lógico "0" – bit dominante

  • Nível lógico "1" – bit recessivo (é anulado por um bit dominante)

Sincronização de relógio

Quando a linha SCL passa de '1' -> '0' todos os masters colocam a '0' os seus relógios

Os masters mantêm o seu relógio a '0' até o seu tempo a '0' ter chegado ao fim

Quando um master termina a contagem do tempo a '0' do seu relógio liberta a linha SCL (permite que esta passe a '1')

Se SCL se mantém a '0' comuta para um estado de "wait", ficando a aguardar que a linha SCL passe a '1'

Logo que SCL passe a '1' inicia a contagem do tempo a '1' do seu relógio

O primeiro master a terminar o seu tempo a '1' força a linha SCL a '0'

O sinal SCL fica sincronizado com um tflowt_{flow}tflow​determinado pelo master com maior tflowt_{flow}tflow​ e um thight_{high}thigh​ imposto pelo master com menor thight_{high}thigh​