Elektroda.pl
Elektroda.pl
X
Arrow Multisolution Day
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[atmega8] zawieszenie - zabezpieczenie przed utratą danych

herszt 02 Mar 2011 11:42 4677 36
  • #1 02 Mar 2011 11:42
    herszt
    Poziom 18  

    Witam!

    Chciałem zasięgnąć rady bardziej doświadczonych kolegów. Sprawa wygląda następująco - skonstruowałem dość proste urządzenie, które jest licznikiem impulsów (z licznika energii elektrycznej). Oczywiście w dalszej perspektywie będzie miało nieco więcej funkcji niż zliczanie impulsów. Problem tkwi w tym co zrobić ze zmienną przechowującą liczbę impulsów podczas zawieszenia układu? Układ ma za zadanie odpowiadać innemu urządzeniu przez TWI, gdy zostanie zapytany o liczbę dotychczas zliczonych impulsów. Czasem podczas komunikacji dochodzi do zwieszenia - układ przestaje odpowiadać po TWI i pomaga jedynie manualny reset, ale wtedy niestety zaczyna zliczać od nowa. Żeby nie musieć resetować go ręcznie pomyślałem sobie że w miejscu gdzie jest kod odpowiedzialny za odpowiadanie użyję watchdoga, który jak coś sam zajmie się resetem, ale wtedy tak czy inaczej tracę dane. Odrębnym problemem jest też utrata zasilania (brak prądu). Może jakieś pomysły jak się przed tym zabezpieczyć - chciałbym aby licznik zliczał "ciągle"? Myślałem nad wbudowanym EEPROMem, ewentualnie jakąś zewnętrzną pamięcią, ale zapisywanie po każdym impulsie danych do tej pamięci dość szybko może ją unicestwić (ewentualnie zapis co kilka impulsów?). Poniżej przedstawiam fragment kodu odpowiedzialny za odpowiadanie po TWI (okrojony o zbędne w tym przypadku rzeczy i bez wspomnianego watchdoga, którego umieszczę jak zlokalizuję kłopotliwe miejsce):

    Kod: cpp
    Zaloguj się, aby zobaczyć kod


    z góry dzięki
    pozdrawiam
    herszt

    0 29
  • Arrow Multisolution Day
  • #3 02 Mar 2011 12:15
    piotrva
    Moderator na urlopie...

    a ja mam inny pomysł
    dajesz na płytce duży kondensator podtrzymujący, za pomocom ADC badasz stan zasilana, jeśli zasilanie zaniknie to układ pracuje na kondensatorze i:
    1. rozumiem, że brak prądu = brak impulsów więc
    2. zapisujesz dane do eepromu
    3. usypiasz układ i czekasz na powrót zasilania

    0
  • #4 02 Mar 2011 12:23
    herszt
    Poziom 18  

    avatar napisał:
    Zapisywac co np 200 imp zmienna do wew. eproma. Pytanie jest tylko czemu i jak ci sie ten uC zawiesza ?


    Nie miałem okazji jeszcze sprawdzić co dokładnie jest przyczyną zwieszenia. Podejrzewam, że wiesza się gdzieś w okolicy którejś pętli while podczas transmisji TWI, ponieważ nie odpowiada potem w ogóle na zapytania. Ciężko to jednoznacznie zweryfikować bo wiesza się mniej-więcej raz na tydzień/dwa ciągłej pracy (testuję to już jakiś czas). Muszę podłączyć to do jakiegoś urządzenia rejestrującego. Ale wydaje mi się, że watchdog i tak będzie chyba najbezpieczniejszym rozwiązaniem. Chciałem się właśnie zabezpieczyć jakoś przed zawieszeniem i ewentualnym brakiem zasilania. Nawet jak stracę kilka impulsów to raczej nie będzie wielkiej straty, ale 200 w niektórych przypadkach to może być jednak za dużo (zależy od samego licznika, jak często generuje taki impuls) - ale tu już można dostosować ilość indywidualnie. Tylko zastanawiało mnie co będzie najlepszym "medium" do przechowywania wartości.

    piotrva napisał:
    a ja mam inny pomysł
    dajesz na płytce duży kondensator podtrzymujący, za pomocom ADC badasz stan zasilana, jeśli zasilanie zaniknie to układ pracuje na kondensatorze i:
    1. rozumiem, że brak prądu = brak impulsów więc
    2. zapisujesz dane do eepromu
    3. usypiasz układ i czekasz na powrót zasilania


    Ciekawy pomysł - nigdy nie robiłem niczego podobnego. Jaki to powinien być najlepiej kondensator ("zwykły"/jakiś specjalny do podtrzymywania napięcia, jak go poprawnie podłączyć do układu), abym zdążył wszystko zrobić? Chętnie bym skonstruował taki układ, chociażby do testów.

    -[Edit]----------------------------------
    Tak chwilę jeszcze pomyślałem nad pomysłem Kolegi @piotrva i się zastanawiam czy od razu trzeba zaciągać do pracy przetwornik ADC. Nie można tego rozwiązać jakoś prościej, powiedzmy sprawdzając stan zasilania mniej-więcej jak to tak na szybko narysowałem na schemacie? Czy to ma szansę działać poprawnie (ewentualnie można by to podpiąć do przerwań, aby reagowało na zbocze opadające)? Oczywiście za diodą byłby "zapasowy" układ zasilania.


    z góry dzięki
    pozdrawiam
    herszt

    0
  • Pomocny post
    #6 02 Mar 2011 13:29
    avatar
    Poziom 35  

    A w jaki sposob jest zasilany uC ? Trafo czy uklad beztransfrmatora ? Staramy sie mierzyc napiecie tam gdzie ono najszybciej zniknie (czyli tam gdzie sa male pojemnosci) a "dalej" w ukladzie dajemy jakis magazyn energii w postaci np 10000uF/6V. W schemacie wyzej narysowanym uC raczej nie zdarzy zrobic operacji zapisu do eproma z braku zasilania , predzej BoD go wylaczy. Tylko czy to rozwiaze problem zawieszania sie ukladu albo blednego programu ? Watpie

    0
  • #7 02 Mar 2011 13:43
    herszt
    Poziom 18  

    avatar napisał:
    A w jaki sposob jest zasilany uC ? Trafo czy uklad beztransfrmatora ? Staramy sie mierzyc napiecie tam gdzie ono najszybciej zniknie (czyli tam gdzie sa male pojemnosci) a "dalej" w ukladzie dajemy jakis magazyn energii w postaci np 10000uF/6V. W schemacie wyzej narysowanym uC raczej nie zdarzy zrobic operacji zapisu do eproma z braku zasilania , predzej BoD go wylaczy. Tylko czy to rozwiaze problem zawieszania sie ukladu albo blednego programu ? Watpie


    Aktualnie układ zasilany jest zasilaczem impulsowym 5V. Tak jak pisałem za diodą w schemacie chciałem dać jakieś "awaryjne" zasilanie, które wystarczyłoby jedynie na czas zapisu (lecz przyznaję - nie wiem jakie, np. zaproponowany przez Kolegę kondensator?). Abstrahując już od samego błędu w kodzie, który oczywiście należy wyeliminować, bardziej chciałem się tu skupić na zapobieżeniu utraty danych (tej jednej konkretnej wartości), bez względu na przyczynę restartu układu. Tylko teraz dyskusja nasunęła mi nieco więcej pytań i wątpliwości... Oczywiście przy braku zasilania należy użyć zapewne układu o którym aktualnie rozmawiamy (nadal jestem ciekaw jak to poprawnie zbudować). Ale co w takim razie z resetem poprzez watchdoga (nadal nie patrząc na przyczynę)? Czy przed restartem mogę wymusić na kontrolerze jakąś czynność (zapis)? Czy tak jak wcześniej pad pomysł - najlepiej zapisywać na bieżąco, co kilka impulsów?

    z góry dzięki
    pozdrawiam
    herszt

    0
  • Arrow Multisolution Day
  • Pomocny post
    #9 02 Mar 2011 14:04
    piotrva
    Moderator na urlopie...

    możesz zrobić przerwanie z timera + programowy "watchodg" który sprawdzi co jakiś czas czy procesor działa. Jeśli nie (bo wartość w programowym watchdogu jest zbyt duża) to wtedy taka sekwencja:
    0. sprawdzenie flagi "gotowy" - jeśli ustawiona to czekaj na reset z WD - nie rób nic
    1. reset wd
    2. zapis do eeprom
    3. ustawienie flagi "gotowy"
    cóż, słyszałem też, choć sam mam w tym względzie marne doświadczenie i nawet nie jestem tej kwestii pewny (dlatego proszę bardzoej doświadczonych o weryfikację tej wiedzy), że można wyłączyć inicjlaizację zmiennych na początku programu (czyli po resecie z WD komórka ze zmienną w pamięci RAM nie powinna zostać zmieniona). Dodatkowo można też wykryć, że przerwanie spowodował WD

    0
  • #10 02 Mar 2011 14:12
    herszt
    Poziom 18  

    piotrva napisał:
    cóż, słyszałem też, choć sam mam w tym względzie marne doświadczenie i nawet nie jestem tej kwestii pewny (dlatego proszę bardzoej doświadczonych o weryfikację tej wiedzy), że można wyłączyć inicjlaizację zmiennych na początku programu (czyli po resecie z WD komórka ze zmienną w pamięci RAM nie powinna zostać zmieniona). Dodatkowo można też wykryć, że przerwanie spowodował WD


    To ja również proszę o weryfikację tej informacji. To by rozwiązało jak najbardziej mój problem - po sprawdzeniu co było powodem resetu mógłbym albo pobrać wartość zmiennej z pamięci RAM (WD) lub z EEPROM (po wcześniejszym zapisie przed zanikiem napięcia zasilającego - tylko by pozostała kwestia układu który by to podtrzymał na czas zapisu).

    z góry dzięki
    pozdrawiam
    herszt

    0
  • Pomocny post
    #12 02 Mar 2011 14:24
    dondu
    Moderator Mikrokontrolery Projektowanie

    Nie czytałem całości tematu, ale ....

    GDZIE PRZYCZYNA ZAWIESZANIA ?

    Szukasz rozwiązania problemu w niewłaściwy sposób. Najpierw znajdź przyczynę zawieszania.
    Co rozumiesz przez :

    herszt napisał:
    Czasem podczas komunikacji dochodzi do zwieszenia - układ przestaje odpowiadać po TWI i pomaga jedynie manualny reset.

    Czy jesteś pewien, że procesor przestaje realizować program, czy może po prostu wchodzi w jakiś fragment, który działa niepoprawnie?
    W zależności od odpowiedzi na powyższe pytanie należy szukać przyczyny.


    herszt napisał:
    Odrębnym problemem jest też utrata zasilania (brak prądu). Może jakieś pomysły jak się przed tym zabezpieczyć - chciałbym aby licznik zliczał "ciągle"?

    To akurat jest, co najmniej proste. Wystarczy akumulatorek lub bateria.
    Skoro Atmega ma zliczać impulsy, to zapewne ma sporo niewykorzystanego czasu, w którym można ją uśpić przez co będzie pobierać niewiele prądu z akumulatora.

    Prosty układ oparty o 2 diody + np. bateria litowa, spełni Twoje wymagania. Jeżeli będziesz zainteresowany wkleję schemat.
    Możesz także zrobić to na akumulatorku z automatycznym ładowaniem, ale to nieco bardziej skomplikowane.

    0
  • #13 02 Mar 2011 14:57
    herszt
    Poziom 18  

    Ciężko będzie znaleźć przyczynę, gdyż zdarza się to bardzo rzadko - raz na tydzień/dwa. Jednak teraz podłączę układ do komputera chodzącego 24h/7dni i sprawdzę w którym miejscu się zwiesza. Schemacik układu podtrzymywania mile widziany. Co do usypiania procesora - może to faktycznie dobry pomysł, jeśli układ będzie pracował na podtrzymywaniu bateryjnym (po zaniku zasilania).

    Choć nadal jestem zaintrygowany tym co powiedział Kolega @piotrva. Jestem ciekaw czy faktycznie istnieje taka możliwość.

    z góry dzięki
    pozdrawiam
    herszt

    0
  • #14 02 Mar 2011 15:59
    dondu
    Moderator Mikrokontrolery Projektowanie

    To rozwiązanie polecane przez Microchip:

    [atmega8] zawieszenie - zabezpieczenie przed utratą danych

    Proponuję, abyś wkleił schemat lub fragmenty odpowiadające za zasilanie procesora oraz sposób w jaki procesor podłączony jest do licznika (w wersji, która się zawiesza).
    Podaj także parametry sygnału z licznika.

    A konkretnie, o co chodzi w przypadku Piotrva?

    0
  • Pomocny post
    #15 02 Mar 2011 16:18
    janbernat
    Poziom 38  

    Takie kondensatory robi np. panasonic i nazywa goldcup capacitor.
    Pojemność do kilku F.

    0
  • #17 02 Mar 2011 18:32
    herszt
    Poziom 18  

    dondu napisał:

    Proponuję, abyś wkleił schemat lub fragmenty odpowiadające za zasilanie procesora oraz sposób w jaki procesor podłączony jest do licznika (w wersji, która się zawiesza).
    Podaj także parametry sygnału z licznika.

    A konkretnie, o co chodzi w przypadku Piotrva?


    W miejscu zaznaczonym na czerwono podpięty jest licznik - działa na zasadzie zwarcie/rozwarcie wywołując przerwanie (w momencie zwarcia jest tam stan wysoki - do jednej z końcówek jest podpięte napięcie zasilania). A resztę chyba już "standardowo" podpiąłem :)

    Kolega @piotrva wspomniał, że po resecie wywołanym przez WD może nie ulegać wymazaniu pamięć ze zmiennymi i być może można dalej z nich korzystać w takiej formie jak przed resetem. Poza tym można wykryć sposób w jaki procesor został zresetowany (o tym akurat wcześniej słyszałem, ale zawsze się zastanawiałem jak to można sprawdzić :)).

    z góry dzięki
    pozdrawiam
    herszt

    0
  • #19 02 Mar 2011 19:18
    dondu
    Moderator Mikrokontrolery Projektowanie

    Aby się upewnić: :)
    Vcc procesora to inne Vcc niż te przy liczniku (nie są połączone galwanicznie)?
    To samo pytanie dotyczy obu mas.


    Układ wygląda na prawidłowo zaprojektowany.
    Ewentualne zakłócenia mogą być na poziomie płytki PCB i połączeń oraz rozmieszczenia kondensatorów filtrujących i/lub kwarcu - temat rzeka i są bardziej doświadczeni koledzy, w tym temacie ode mnie.

    Co do wartości zmiennych w SRAM to patrząc na datasheet,:

    datasheet napisał:
    Watchdog Reset.
    The MCU is reset when the Watchdog Timer period expires and the Watchdog is enabled.


    a patrząc co wchodzi w skład definicji MCU przez Atmela:

    [atmega8] zawieszenie - zabezpieczenie przed utratą danych

    ... czyli SRAM także (?), ale pewności nie mam ponieważ nie miałem takiej potrzeby, ani odwagi, by po resecie próbować wykorzystywać dane z SRAM.

    co zgadzałoby się ze wstępem do działu dot resetów :

    datasheet napisał:
    System Control and Reset
    During Reset, all I/O Registers are set to their initial values, and the program starts execution from the Reset Vector.
    ...


    Dodano po 10 [minuty]:

    A patrząc na schemat resetu:

    [atmega8] zawieszenie - zabezpieczenie przed utratą danych

    można zauważyć, że reset z Watchdog-a jest tak samo traktowany jak Brown Out Detection, czyli przypadek związany z zakłóceniami na zasilaniu, stąd mój wniosek (może mylny), że wartości w SRAM mogą być, co najmniej niepewne, o ile nie całkowicie czyszczone - możesz spróbować, bo jak pisałem wcześniej nie mam pewności.

    0
  • #20 02 Mar 2011 19:20
    herszt
    Poziom 18  

    dondu napisał:
    Aby się upewnić: :)
    Vcc procesora to inne Vcc niż te przy liczniku (nie są połączone galwanicznie)?
    To samo pytanie dotyczy obu mas.


    To (niestety?) to samo Vcc i GND. A to ma jakieś szczególne znaczenie w tym przypadku, nawet jeśli został zastosowany kondensator na zasilaniu przy procesorze?

    z góry dzięki
    pozdrawiam
    herszt

    0
  • Pomocny post
    #21 02 Mar 2011 19:37
    dondu
    Moderator Mikrokontrolery Projektowanie

    A co do usypiania - to stosuj jak najczęściej, nawet pracując na zasilaniu innym niż bateryjne - to dobry nawyk który ułatwi Ci pisanie kodu, gdy oszczędzanie będzie niezbędne. Generalnie - wykonaj, co masz i idź spać :)

    Dodano po 1 [minuty]:

    herszt napisał:
    To (niestety?) to samo Vcc i GND. A to ma jakieś szczególne znaczenie w tym przypadku, nawet jeśli został zastosowany kondensator na zasilaniu przy procesorze?

    :D:D:D toś mnie zaskoczył
    Dobrze, że zadałem tak wydawałoby się oczywiste pytanie.

    Zaraz napiszę w czym rzecz tylko herbatkę zrobię.

    Dodano po 9 [minuty]:

    Inwestuj szybko w tę książkę http://atnel.pl/wydawnictwo
    bo podstaw Ci brakuje :)

    Po to masz transoptor (na Twoim schemacie), by oddzielić galwanicznie (elektrycznie) obwód licznika i procesora. To właśnie ma załatwić odporność układu na zakłócenia z zewnątrz.
    Innymi słowy Vcc+masa po stronie licznika, musi być inne, niż Vcc+masa po stronie procesora.

    W Twoim przypadku zakłócenia elektryczne z licznika mogą przenosić się na procesor - tutaj możesz szukać przyczyny wieszania się Twojego procesora.

    Dodano po 5 [minuty]:

    Kondensatory, o które pytasz, to zabezpieczenie, które może nie wyłapać wszystkich zakłóceń z układu licznika.

    0
  • #22 02 Mar 2011 19:57
    herszt
    Poziom 18  

    dondu napisał:
    A co do usypiania - to stosuj jak najczęściej, nawet pracując na zasilaniu innym niż bateryjne - to dobry nawyk który ułatwi Ci pisanie kodu, gdy oszczędzanie będzie niezbędne. Generalnie - wykonaj, co masz i idź spać :)

    [...]

    Po to masz transoptor (na Twoim schemacie), by oddzielić galwanicznie (elektrycznie) obwód licznika i procesora. To właśnie ma załatwić odporność układu na zakłócenia z zewnątrz.
    Innymi słowy Vcc+masa po stronie licznika, musi być inne, niż Vcc+masa po stronie procesora.

    W Twoim przypadku zakłócenia elektryczne z licznika mogą przenosić się na procesor - tutaj możesz szukać przyczyny wieszania się Twojego procesora.

    Dodano po 5 [minuty]:

    Kondensatory, o które pytasz, to zabezpieczenie, które może nie wyłapać wszystkich zakłóceń z układu licznika.


    Ok. To po kolei. Odnośnie spania - skoro to dobry nawyk to powinienem go chyba zacząć stosować. Jak najlepiej wybudzać procesor wtedy co jakiś czas? Timerem?

    Odnośnie osobnego zasilania - faktycznie przy głębszym zastanowieniu w takiej formie w jakiej jest to teraz to transoptor nie ma chyba większego znaczenia. Powiedzmy, że mam dostępne tylko jedno zasilanie, czy powinienem je jakoś "odseparować" (zabezpieczyć? rozdzielić?) dla każdej z części? Chodzi mi o to czy mogę to jakoś "ulepszyć" :)

    Chyba się trochę główny wątek rozjechał, na nieco boczne tory, ale dobrze się czegoś nowego dowiedzieć :)

    z góry dzięki
    pozdrawiam
    herszt

    0
  • #23 02 Mar 2011 20:02
    dondu
    Moderator Mikrokontrolery Projektowanie

    Zacznę od zasilania.

    herszt napisał:
    Odnośnie osobnego zasilania - faktycznie przy głębszym zastanowieniu w takiej formie w jakiej jest to teraz to transoptor nie ma chyba większego znaczenia.

    Poprawny wniosek.

    herszt napisał:
    Powiedzmy, że mam dostępne tylko jedno zasilanie, czy powinienem je jakoś "odseparować" (zabezpieczyć? rozdzielić?) dla każdej z części? Chodzi mi o to czy mogę to jakoś "ulepszyć" :)

    O to poprosimy innych kolegów, fachowców w tej dziedzinie.

    o spaniu za chwilę ....

    0
  • Pomocny post
    #24 02 Mar 2011 20:17
    janbernat
    Poziom 38  

    Nie ma zasilania na AVCC- a musi być.
    Nie ma drugiego GND- a musi być.
    Musi też być drugi kondensator ceramiczny 100nF między nimi.
    Powinien być kondensator 100nF równolegle do R6.
    Te kondensatory i R6 powinny być jak najbliżej procesora.
    Masy i zasilanie prowadzi się w "gwiazdę".
    Od masy stabilizatora każda masa prowadzona oddzielnie do każdej masy układów na płytce.
    Zasilanie- tak samo.
    Oczywiście bez przesady- jeśli na płytce jest rozlana duża powierzchnia masy a ścieżki do zasilania są możliwie szerokie to można podpinać się do tej rozlanej masy.
    Stosując przy każdym podpięciu dodatkowy kondensator od masy do zasilania.

    0
  • #25 02 Mar 2011 20:20
    dondu
    Moderator Mikrokontrolery Projektowanie

    ... spania cd.

    Generalna zasada:

    1. po włączeniu zainicjuj niezbędne funkcjonalności, zmienne, itp.
    2. wejdź do pętli głównej
    3. zrób, co w danej chwili trzeba
    4. śpij
    5. idź do pkt 3.

    ... a co się da, rób na przerwaniach.

    Prosty algorytm, ale możliwe są jego modyfikacje zależnie od potrzeb.

    Timery i komunikacja powinny budzić procesor za pomocą przerwania gdy jest potrzebny.

    Ponieważ używasz TWI a jego obsługa na przerwaniach jest nieco trudniejsza (wiele warunków i pojedynczych kroków) stąd możesz stosować pulling (po pobieżnej analizie Twojego kodu chyba tak robisz). Po wykonaniu procesor uśpi się w pętli głównej. Tutaj pomocne jest ustawianie flagi tak jak wspominali koledzy wcześniej.

    Jeżeli oprócz tych czynności potrzebujesz budzić procesor cyklicznie by np. sprawdzić stan klawiszy, czy mrugnąć LEDami lub LCD, to tak jak pisałeś ustawiasz następny timer na określoną częstotliwość i włączasz jego przerwanie.

    I to właściwie cała magia, a zysk wielki zarówno po stronie procesora jak i Twojego doświadczenia. Ale musisz poczytać o trybach usypiania, bo jest ich kilka.

    Dodano po 1 [minuty]:

    janbernat napisał:
    Nie ma zasilania na AVCC- a musi być....

    No i fachowiec podpowiedział :)

    0
  • #26 02 Mar 2011 20:54
    herszt
    Poziom 18  

    janbernat napisał:
    Nie ma zasilania na AVCC- a musi być.
    Nie ma drugiego GND- a musi być.
    Musi też być drugi kondensator ceramiczny 100nF między nimi.


    Jest, tylko trochę uciąłem rysunek. Ale za AVCC przyjąłem to samo VCC co wszędzie i GND też jest wspólne.

    pozdrawiam
    herszt

    0
  • #27 02 Mar 2011 21:26
    janbernat
    Poziom 38  

    Jakieś mam dziwne wrażenie że kod który teraz widzę jest inny niż widziałem przedtem.
    Teraz jest TWCR |= (1<<<<
    A przedtem to chyba była konfiguracja rejestru przerwań w przerwaniu.
    Ale może sie mylę.

    0
  • #28 02 Mar 2011 22:07
    herszt
    Poziom 18  

    janbernat napisał:
    Jakieś mam dziwne wrażenie że kod który teraz widzę jest inny niż widziałem przedtem.


    Też odniosłem takie wrażenie... dopiero jak wyłączyłem BBcode to wygląda to tak jak było. Nie wiem dlaczego...

    pozdrawiam
    herszt

    0
  • #29 02 Mar 2011 22:30
    janbernat
    Poziom 38  

    No tak- ale teraz nie jest w

    Code:

    Mimo że jest.
    Co to jest transoptor_p620?
    Nic z podłączenia tego transoptora nie rozumiem.
    No i kompletnie nie rozumiem dlaczego w przerwaniu ISR (TWI_vect) jest ustawianie rejestru TWCR- czyli zezwolenie na obsługę przerwania i dlaczego to przerwanie jest takie długie.

    0
  • #30 02 Mar 2011 23:18
    herszt
    Poziom 18  

    Jak włączam BBcode to właśnie jakieś krzaczki mi się robią - nie mam pojęcia dlaczego.

    Co do transoptora - miała to być swego rodzaju izolacja, ale chwilowo jak już wcześniej zostało wspomniane wszystko jest na wspólnym VCC i masie, więc równie dobrze mogłoby go nie być.

    Co do długości obsługi przerwania - czy argument, że krócej się nie dało zrobić jest wystarczająco przekonujący (choć pewnie jakby się postarać to byłoby to możliwe)? :)

    Co do fragmentu kodu:

    Kod: cpp
    Zaloguj się, aby zobaczyć kod


    to o ile dobrze pamiętam - to ustawia to TWI tak, żeby reagowało po tym jak zakończy obecną transmisję (warunek STOP).

    z góry dzięki
    pozdrawiam
    herszt

    0