logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

AVR32 / AT32UC3A1 - TWI/I2C - otwarty dren

Zbig T. 17 Lip 2011 14:20 1501 4
REKLAMA
  • #1 9728019
    Zbig T.
    Poziom 10  
    Cześć

    Może ktoś będzie potrafił wyjaśnić moje wątpliwości w sprawie trybu open-drain w kontrolerach AT32UC3A.

    Otóż, w dokumencie doc32058.pdf (rozdz. 22.1) czytam:

    Cytat:
    Each I/O line of the GPIO features:
    ...
     Open Drain mode enabling sharing of an I/O line between the MCU and external components.


    Następnie (24.2):
    Cytat:
    To enable the TWI, the programmer
    must perform the following steps:
     Program the GPIO controller to:
    – Dedicate TWD and TWCK as peripheral lines.
    – Define TWD and TWCK as open-drain.


    I tutaj zaczyna robić się dziwnie, bo w pliku gpio.c (używam AVR Studio 5 i bibliotek ASF) czytam:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    a funkcja gpio_enable_pin_open_drain jest wyłączona.

    Ponadto, w pliku uc3a1512.h:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Sam rejestr ODMER w GPIO zdaje się być "atrapą" tylko do odczytu z wartościami zafiksowanymi na 0 - żadnych efektów nie daje ani pisanie do niego z poziomu kodu ani klikanie myszą na bitach w trybie debug AVR Studio.

    Wracając do dokumentu w PDF, rozdz. 8.3:
    Cytat:
    TWI pins
    When these pins are used for TWI, the pins are open-drain outputs with slew-rate limitation and
    inputs with inputs with spike-filtering. When used as GPIO-pins or used for other peripherals, the
    pins have the same characteristics as PIO pins.


    W erracie nie wyczytałem niczego co sugerowałoby, że tryb otwartego drena nie działa, za to w release notes do ASF czytam:

    Cytat:
    This patch removes accesses to the non-existing pull-down and
    open-drain registers on AVR UC3 L0 devices. This patch also removes
    the implementation of the buskeeper feature since it is not supported by
    the AVR UC3 L0 devices. Modified files: avr32/drivers/gpio/{gpio.c,
    gpio.h}.


    Co ciekawe, testowy kod wykorzystujący TWI działa a zegarek Dallasa "pinguje się" prawidłowo - wywołanie twi_probe(AVR32_TWI_ADDRESS, 0x68) wraca z sukcesem a sniffer I2C pokazuje z pozoru prawidłową komunikację ACKowaną przez slave'a. Czyli w zasadzie niby działa, ale nie jestem pewien czy prawidłowo. Mam wątpliwości, czy nie zaistniała przypadkiem sytuacja, w której piny AVRa są wysterowywane jak przy "normalnym" I/O a Dallasowi udaje się po prostu zwierać wyjścia do masy, tak że napięcie spada poniżej progu logicznej jedynki, co oczywiście byłoby sytuacją niepożądaną.

    I teraz nie wiem, czy może po przełączeniu funkcji pinów na TWI tryb open-drain włącza się automatycznie czy też może slave I2C "siłuje się" z aktywnie wysterowywanymi pinami AVRa, dopóki się coś nie upali a wzajemnie sprzeczne fragmenty oficjalnej dokumentacji nijak nie pomagają w rozwiązaniu dylematu. Niezły mają burdel w tym Archeo. Czy walczył ktoś z tym i może podzielić się spostrzeżeniami?

    Pozdrawiam
    Zbig
  • REKLAMA
  • Pomocny post
    #2 9728074
    janbernat
    Poziom 38  
    A na str.49 na samej górze...
  • REKLAMA
  • #3 9728090
    Zbig T.
    Poziom 10  
    janbernat napisał:
    A na str.49 na samej górze...


    Haha! Tego nie zauważyłem, dzięki :) Co za partacka dokumentacja. Zaraz sprawdzę, czy pod kilkudziesięciostronicowym opisem modułu TWI nie wyczytam, że "TWI module is not available for this device due to the non-functional ODMER register" :D
  • REKLAMA
  • #4 9728105
    janbernat
    Poziom 38  
    To jest "preliminary"- czyli lista marzeń...
REKLAMA