Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[ATMega8][TWI][24C128][c] I2C na przerwaniach + EEPROM

dondu 21 Dec 2010 12:49 8328 43
  • Helpful post
    #31
    mirekk36
    Level 42  
    dondu wrote:
    Ciekawa dyskusja rozwinęła się na AVRFreaks w temacie, który podałem powyżej:
    http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=101394

    Spierają się zwolennicy TWI na przerwaniach lub bez i jak zwykle każdy ma trochę racji.


    No widzisz, ciekawa dyskusja i związana z tym o czym pisałem w mailu ;) Stąd część zwolenników korzystania z TWI na przerwaniach ale tylko gdy się robi SLAVE. Jeśli chodzi o MASTER'a to już nie jest to takie istotne.

    Ale nie piszę tego po to żeby się spierać, bo każdy zrobi jak mu pasuje. Mnie natomiast zastanawia to co pisałeś tam na formum, że dla ciebie zastosowanie przerwań w tym przypadku jest ważne z uwagi na Power Saving.

    Możesz wyjaśnić o co ci tutaj chodzi?
  • #32
    dondu
    Moderator on vacation ...
    mirekk36 wrote:
    Możesz wyjaśnić o co ci tutaj chodzi?

    Mój projekt ma na celu uczenie się AVR-ów i podlega ciągłym zmianom wraz z poszerzającą się codziennie moją wiedzą.
    Postawiłem sobie kilka celów, a jednym z nich jest próba oszczędzania energii w każdym możliwym miejscu i pisaniu kodu tak aby móc go wykorzystać w przyszłości na innych (np. znacznie szybszych procesorach Atmela).

    Dlatego też postanowiłem usypiać scalaka kiedy tylko się da i jak najgłębiej jak w danej chwili można. Dlatego też rozwiązanie TWI na przerwaniach jest dla mnie ważniejsze niż czas jaki poświęcę na opracowanie kodu w stosunku do metody czekania w pętli na kończenie poszczególnych rozkazów TWI.

    Czy o to Ci chodziło?

    Dodano po 3 [minuty]:

    Czy ta druga metoda nazywa się POOLING?

    Dodano po 2 [minuty]:

    Jak na razie zapisywanie do eeprom na przerwaniach już działa.
    Teraz robię odczyt.
  • Helpful post
    #33
    LordBlick
    VIP Meritorious for electroda.pl
    dondu wrote:
    Tutaj nie pisze, że muszę ustawiać TWIE w czasie wysyłania START bo jest zerowane po wyzerowaniu TWINT
    TWIE ma być cały czas ustawiony i tyle. Jeśli cokolwiek zapisujesz do rejestru TWCR z zamiarem obsługi na przerwaniu, to nie możesz pominąć tego bitu, bo najzwyczajniej sobie go kasujesz, czyli wyłączasz przerwanie. Nie jest prawdą, że TWIE się kasuje samoczynnie podczas startu, to tylko jest wynikiem jego pominięcia w sposób opisany w poprzednim moim zdaniu...
  • #34
    dondu
    Moderator on vacation ...
    Light-I wrote:
    TWIE ma być cały czas ustawiony i tyle. Jeśli cokolwiek zapisujesz do rejestru TWCR z zamiarem obsługi na przerwaniu, to nie możesz pominąć tego bitu, bo najzwyczajniej sobie go kasujesz, czyli wyłączasz przerwanie. Nie jest prawdą, że TWIE się kasuje samoczynnie podczas startu, to tylko jest wynikiem jego pominięcia w sposób opisany w poprzednim moim zdaniu...

    Tak, już to zrozumiałem, dzięki.
  • Helpful post
    #35
    mirekk36
    Level 42  
    dondu wrote:

    Dlatego też postanowiłem usypiać scalaka kiedy tylko się da i jak najgłębiej jak w danej chwili można. Dlatego też rozwiązanie TWI na przerwaniach jest dla mnie ważniejsze niż czas jaki poświęcę na opracowanie kodu w stosunku do metody czekania w pętli na kończenie poszczególnych rozkazów TWI.

    Czy o to Ci chodziło?


    Tak o to chodziło, i tak tylko podpowiadam (nie negując oczywiście organizacji tego na przerwaniach w ramach zdobycia doświadczeń ;) ), że czy polling czy przerwania w tym przypadku to nie ma najmniejszego znaczenia.

    Jeśli uważasz, że ma to napisz dokładniej dlaczego? W którym miejscu wydaje ci się, że zaoszczędzisz? (bo na pewno w ten sposób nie skrócisz czasu komunikacji z pamięcią EEPROM)
  • #36
    dondu
    Moderator on vacation ...
    Załóżmy, że na ten moment projekt jest urządzeniem, które zlicza obroty wiatraczka. Czasami wiatr jest a czasami nie. Gdy wiatr zaczyna wiać urządzenie zlicza obroty wiatraka, a gdy przestanie wiać (np. przez 5 sek) zapisuje do EEPROMu cykl pomiarowy złożony z:

    - godziny rozpoczęcia wiatru.
    - godziny zakończenia
    - ilości obrotu wiatraka
    - największej prędkości jaka była

    Ot takie proste zadanie realizowane w miejscu gdzie nie ma zasilania i musi pracować przez wiele lat na baterii :)

    Zakładam, że jest to procesor ATMega8 pracujący z max zegarem 16MHz, ale może się okazać, że wsadzę tam znacznie szybszy procesor, który generalnie będzie się baaaardzo nudził.

    Komunikacja na 100kHz, a nie 400kHz (załóżmy że mam wolny eeprom).

    Załóżmy że miejsce gdzie stoi wiatrak jest szczególnie niestabilne i wiatr wieje przez 10-20 sek po czym 10 sek nie wieje i tak w kółko. Biorąc pod uwagę okres kilku lat to sporo operacji zapisu eeprom się zbierze. A żeby było jeszcze ciekawiej załóżmy, że bateria wytrzyma 20 lat :D a eeprom mam odpowiednio duży.

    Oczywiście mógłbym dobrać inny procesor a warunki opisane powyżej to prawie fikcja, ale podkreślam że to projekt do nauki, a nie wersja ekonomiczna :D

    Kombinuję tak:
    - czas komunikacji z EEPROM nie ma dla mnie znaczenia,
    - skoro muszę oszczędzać baterię scalak ma spać snem niedźwiedzim, a czasami lekko drzemać.
    - skoro gość jest bardzo szybki w porównaniu z 100kHz na TWI to uśpię go w co najmniej IDLE MODE (drzemka) na czas zapisu po TWI, a później POWER DOWN (gdy nie wieje).
    - wiatr budzi z POWER DOWN przez INT wyzwalany poziomem

    Dodano po 6 [minuty]:

    Czyli uważam, że oszczędzam na energii nie czekając w pętli, tylko śpiąc w co najmniej IDLE MODE w czasie transmisji TWI.
  • #37
    mirekk36
    Level 42  
    Oj! ...

    Quote:

    Idle Mode When the SM2..0 bits are written to 000, the SLEEP instruction makes the MCU enter Idle
    mode, stopping the CPU but allowing SPI, USART, Analog Comparator, ADC, Two-wire Serial
    Interface, Timer/Counters, Watchdog, and the interrupt system to continue operating. This sleep
    mode basically halts clkCPU and clkFLASH, while allowing the other clocks to run.


    Nie będziesz miał transmisji TWI w trakcie IDLE MODE albo inaczej, nie będziesz miał IDLE MODE w trakcie transmisji TWI.

    Widzisz, to jest tak - IDLE MODE jest po to, że np jeśli masz TWI SLAVE to układ master może wybudzić twój układ SLAVE właśnie poprzez nadawanie czegoś do niego po TWI (I2C) i wtedy przerwania są nieodzowne.

    Podobnie zewnętrzne układy mogą wybudzić za pomocą takich interfejsów jak USART czy SPI. Dzięki czemu transmisja może być dalej kontynuowana najszybciej jak to tylko możliwe. Przecież w pełnym POWER DOWN nie miałbyś takiej możliwości. A dzięki temu że pozostaną włączone różne "zegarki" napędzające wewnętrzne moduły transmisyjne.

    Ale nie ma tak dobrze - że ty sobie w IDLE MODE zorganizujesz "jakieś tam bliżej nieokreślone transfery" . Toż żeby one mogły działać potrzebny byłby ci co najmniej CPU CLK ;) a tymczasem zostajesz go pozbawiony - pomyśl nad tym teraz - czy w tym przypadku będzie różnica pomiędzy pollingiem a transmisją na przerwaniach?

    (ale nie traktuj, po raz kolejny powtórzę, że zniechęcam cię do transmisji na przerwaniach, po prostu może się coś dodatkowego wyjaśni)
  • #38
    dondu
    Moderator on vacation ...
    W dokumentacji pisze:

    Quote:

    IDLE MODE
    When the SM2..0 bits are written to 000, the SLEEP instruction makes the MCU enter Idle
    mode, stopping the CPU but allowing SPI, USART, Analog Comparator, ADC, Two-wire Serial
    Interface, Timer/Counters, Watchdog, and the interrupt system to continue operating. This sleep
    mode basically halts clkCPU and clkFLASH, while allowing the other clocks to run.

    This sleep mode basically halts clkCPU and clkFLASH, while allowing the other clocks to run.


    Ja rozumie to tak, że gdy wysyłam bajt po TWI i natychmiast robię SLEEP to CPU staje a TWI idzie dalej aż zakończy operację.
  • #40
    dondu
    Moderator on vacation ...
    mirekk36 wrote:
    Widzisz, to jest tak - IDLE MODE jest po to, że np jeśli masz TWI SLAVE to układ master może wybudzić twój układ SLAVE właśnie poprzez nadawanie czegoś do niego po TWI (I2C) i wtedy przerwania są nieodzowne.

    Podobnie zewnętrzne układy mogą wybudzić za pomocą takich interfejsów jak USART czy SPI. Dzięki czemu transmisja może być dalej kontynuowana najszybciej jak to tylko możliwe. Przecież w pełnym POWER DOWN nie miałbyś takiej możliwości. A dzięki temu że pozostaną włączone różne "zegarki" napędzające wewnętrzne moduły transmisyjne.


    Tak to znam.


    mirekk36 wrote:
    ... (ale nie traktuj, po raz kolejny powtórzę, że zniechęcam cię do transmisji na przerwaniach, po prostu może się coś dodatkowego wyjaśni)

    Spoko, nie traktuję tak. Dzięki, że mi pomagasz!

    Dodano po 4 [minuty]:

    mirekk36 wrote:
    No ale co z następnym bajtem w kolejce? ;)


    Jak wiemy cykl zapisu składa się z:
    - wysłanie sekwencji START
    - wysłanie bajtu adresu układu pamięci na magistrali (DEV SEL) z bitem R/W w stanie niskim (zapis)
    - wysłanie starszego bajtu adresu komórki pamięci w uprzednio zaadresowanym układzie pamięci
    - wysłanie młodszego bajtu adresu komórki pamięci w uprzednio zaadresowanym układzie pamięci
    - wysłanie bajtu danych przeznaczonego do zapisu
    - wysłanie sekwencji STOP
    źródło: http://radzio.dxp.pl/eeprom/24c32-24c512.htm


    Po wywołaniu przerwania sprawdzam status TWI i jeżeli nie ma błędu to wykonuję następny krok z cyklu zapisu aktualnie zapisywanego bajtu do eeprom lub przechodzę do początku cyklu zapisu następnego bajtu do eeprom jeżeli mam coś jeszcze do zapisania.

    Śpię w IDLE MODE zawsze pomiędzy poszczególnymi krokami z cyklu a po zakończeniu zapisu wszystkich bajtów idę w POWER DOWN.
  • #42
    dondu
    Moderator on vacation ...
    Dodam jeszcze, że budzenie z przerwania TWI z IDLE MODE jest CHYBA(?) w tej tabelce jako OTHER I/O:

    [ATMega8][TWI][24C128][c] I2C na przerwaniach + EEPROM

    Dodano po 1 [godziny] 39 [minuty]:

    Po zaimplementowaniu zapisu i odczytu wszystko gra i buczy :)
    Procesor śpi gdy TWI śmiga.


    WNIOSKI KOŃCOWE
    - 24C128 IS27 oznacza kość z 2,7V czyli działającą na wyższym zakresie napięcia zasilającego do 5,5V, a SI18 na 1.8V czyli do 3,6 Vcc.
    - TWINT zerujemy przez wpisanie 1
    - TWIE trzeba włączać przy każdym rozkazie zapisywanym do TWCR który według dokumentacji wywołuje przerwanie.
    - można usypiać procesor do IDLE MODE (tylko idle mode) podczas gdy on wysyła lub odbiera dane
    - gdy dobrze się rozplanuje bibliotekę to wychodzi z tego niezłe bardzo uniwersalne narzędzie do obsługi TWI na przerwaniach.
    - na forum AVRFreaks warto pytać bo tam także są ludziska z doświadczeniem.


    Dodano po 1 [godziny] 51 [minuty]:

    JAK TESTOWAĆ?

    Zastanawiam się jak sztucznie wygenerować błędy podczas komunikacji przez TWI, by sprawdzić poprawność opracowanej biblioteki?

    Na razie przyszedł mi do głowy taki pomysł aby sztucznie robić odstępy (delay) pomiędzy poszczególnymi krokami i w tym czasie np. odłączać zasilanie lub linię SCL czy SDA w trakcie takich przerw. Ale czy to załatwi wszelkie możliwe do wystąpienia błędy? Pewnie nie.

    Zawsze może nastąpić jakiś konflikt z innym urządzeniem. Macie jakieś pomysły?
  • #43
    rpal
    Level 27  
    dondu wrote:
    Załóżmy, że na ten moment projekt jest urządzeniem, które zlicza obroty wiatraczka. Czasami wiatr jest a czasami nie. Gdy wiatr zaczyna wiać urządzenie zlicza obroty wiatraka, a gdy przestanie wiać (np. przez 5 sek) zapisuje do EEPROMu cykl pomiarowy złożony z:

    Mi sie bardzo podoba to właśnie założenie że wiatr będzie wiał z przerwami czyli od czasu do czasu. Na moje oko to założenie jest z gruntu błędne bo przyjmuje że coś bedzie tak się działo jak sobie to założył autor. A co jeśli wiart będzie wiał caly czas do końca Świata ? Masz wpływ na przyrodę ? Wówczas twój eeprom nie bedzie zapisany bo ma to robić tylko w przerwach między powiewami.
    Kolejnym błędnym zalożeniem jest to że starczy pamięci, bo jedynym słusznym jest to że jej właśnie zabraknie zwłaszcza przy wymaganiu że bateria starczy na 20 lat :) Może zamiast drastycznie oszczędzać energie pokusić sie o jej produkowanie podczas powiewów wiatru i doładowywanie tej 20-letniej baterii?
  • #44
    dondu
    Moderator on vacation ...
    To był tylko przykład w celu wyjaśnienia dlaczego dążę do przerwań, dlatego pisałem:

    dondu wrote:
    Załóżmy, że na ten moment projekt jest urządzeniem, które zlicza obroty wiatraczka.
    ...
    Oczywiście mógłbym dobrać inny procesor a warunki opisane powyżej to prawie fikcja, ale podkreślam że to projekt do nauki, a nie wersja ekonomiczna :D



    rpal wrote:
    A co jeśli wiart będzie wiał caly czas do końca Świata ?

    To właśnie jest przykład fikcyjnego przypadku :D podobnie jak ja założyłem fikcyjny projekt.