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

DS18B20+ zepsuty, naprawa?

JulianM87 05 Sty 2010 17:19 3456 37
  • #1 05 Sty 2010 17:19
    JulianM87
    Poziom 11  

    Witam,

    Posiadam 4 czujniki ds18b20 z czego 3 są zepsute. Zaraz po włączeniu zasilania wysyłam reset i odczyt temperatury (nie robię wcześniej polecenia konwersji, bo chcę otrzymać wartość domyślną). Zamiast otrzymać temperaturę 85°C (tabela 2 strona 4 instrukcji) otrzymuję na dwóch 125, a na jednym 117. Wartości te są cały czas te same, nie zmieniają się (czyli czujnik nie wariuje, tylko mocno trzyma się swego ).
    Przy normalnym mierzeniu temperatury w tych 3 czujnikach temperatura spada wraz z zwiększeniem temperatury czujnika (podgrzanie ręką). Wygląda to tak, jak gdyby wewnętrzny czujnik temperatury działał, ale temperatura była źle tłumaczona.
    Termometry pokazują dla danej temperatury urządzenia zawsze tą samą temperaturę.

    Może ktoś spotkał się z podobnym problemem i wie jak to naprawić, bo trochę szkoda 20zl wydane na czujniki.

    0 29
  • #2 05 Sty 2010 17:27
    Kuniarz
    Moderator Projektowanie

    Sprawdzałeś na 100 % jakimś PEWNYM przykładem (np. z książki Wiązani) w sensie montaż w/g schematu (banalny) i program w Bascomie (też banalny) ? Przewinęło mi się przez ręce kilka-kilkanaście DSów i nie trafiłem jeszcze uszkodzonego.

    0
  • #3 05 Sty 2010 17:40
    atom1477
    Poziom 43  

    A te 4 czujniki to masz na jednej szynie?
    Podłączaj po jednym i zobacz. Może masz konflikt na szynie.

    0
  • #4 05 Sty 2010 20:12
    JulianM87
    Poziom 11  

    Sprawdzałem oddzielnie każdy czujnik po kolei, programem napisanym w C. 1 czujnik daje poprawną temperaturę 23 stopnie (bo tyle mam w domu), a trzy pozostałe uruchomione tym samym programem, w tych samych warunkach pokazują błędy o których napisałem w 1 poście.
    Jeśli miałbym konflikt na szynie, to żaden by nie działał. Dodatkowo wywołuje czujnik z opcją SKIP ROM 0xF0.

    0
  • #5 05 Sty 2010 20:23
    asembler
    Poziom 32  

    Wyrzuc nowy kosztuje 4 zł a oszczedzisz nerwy

    0
  • #6 05 Sty 2010 20:37
    JulianM87
    Poziom 11  

    Nerwów już sporo straciłem :) u mnie w okolicy najtaniej 5.60, założyłem temat licząc się z tym, że i tak kupie nowe. Ale to był pech 75% wadliwych mi się trafiło

    0
  • #7 05 Sty 2010 20:47
    atom1477
    Poziom 43  

    Ale to nowe ze sklepu tak mają?
    Może to jakieś inne niż DS18B20+.

    0
  • #8 05 Sty 2010 20:51
    tmf
    Moderator Mikrokontrolery Projektowanie

    Niekoniecznie pech - zmien dostawce, niestety na rynku jest mnostwo podrobek i badziewia, przeciez taki lokalny sklep nie kupuje u renomowanych dystrybutorow (bo drogo), a nie kupuje tez tyle, zeby brac bezposrednio od producenta.
    BTW, CRC danych sie zgadza? Probowales zapisac wewnetrzny EEPROM i go odczytac? Moze uzyte przez ciebie procedury nie maja dobrych timingow i czasami czyta prawidlowo, a czasami nie.

    0
  • #9 05 Sty 2010 21:16
    wacek1974
    Poziom 12  

    Sprawdź zależności czasowe w programie , sprawdź czy przerwanie nie powoduje konfliktów .

    0
  • #10 05 Sty 2010 21:40
    JulianM87
    Poziom 11  

    Śmieszne, ale termometry otrzymałem prosto od producenta - Maxima w antystatycznych foliach z żółtymi plombami...
    Termometry nie są zepsute, one po prostu działają w inny sposób niż powinny z dokładnością 100%. Są tak jakby przestawiono. Sprawny działa zawsze tak samo dobrze, a te niesprawne zawsze tak samo "źle". Podgrzewam, ostudzam i sprawdzam temperaturę pokojową i za każdym razem ta sama temperatura.
    Te termometry źle wewnątrz siebie temperaturę zapisują w tych 2 bajtach, bo inaczej miałbym różne wyniki wraz z upływem czasu, a wyniki są powtarzalne w 100%.
    Proszę nie dopatrywać się mojej winy softwarowej, bo funkcje są na 100% dobre i sprawdzone. Wina leży po stronie urządzenia 1-wire, jak znajdę czas, to napiszę do Maxima, żeby mi wyjaśnili tą sytuację.

    0
  • Pomocny post
    #11 05 Sty 2010 21:48
    tmf
    Moderator Mikrokontrolery Projektowanie

    Zbyt duzo razy widzialem zapewnienia, ze "wina w 100% nie lezy po mojej stronie", aby w nie uwierzyc :) Byc moze tak jest, pokazanie nam swojego kodu nie zaszkodzi, a moze ktos cos zauwazy niewlasciwego.
    No i nie napisales, czy inne funkcje (zapis/odczyt wewnetrznego EEPROM) dzialaja poprawnie.

    0
  • #12 05 Sty 2010 22:05
    JulianM87
    Poziom 11  

    http://mikrokontrolery.net/avr_c_10.htm z tego korzystałem, z tego korzystał kolega, jemu działa, mi działa, wielu innym działa (dla 1 czujnika). Zapisu do eeprom i pamięci ds18b20 jeszcze nie napisałem.

    Code:
    #include <avr/io.h>
    
    #include <util/delay.h>
    #include <avr/interrupt.h>
    //#include <avr/signal.h>

    #define DQ 7

    #define SET_DQ DDRA &= ~_BV(DQ)
    #define CLR_DQ DDRA |= _BV(DQ)

    #define IN_DQ PINA & _BV(DQ)


    //void czyt_temp1();

    //char znaki[17] = {192,249,164,176,153,146,130,248,128,144};
    //char wysw = 0;
    //unsigned char d1, d2;
    unsigned char temp1[3];
    unsigned char ROM_NO[8]; //to store rom


    //////////////////////
    /// start 1 wire

    // procedura reset
    void ow_reset(void)
    {
    CLR_DQ; // stan niski na linii 1wire
    _delay_us(480); // opóźnienie ok 480us
    //delay(1);
    SET_DQ;// stan wysoki na linii 1wire
    _delay_us(480); // opóźnienie ok 480 us
    }
    // procedura zapisu bitu na linię 1wire
    void ow_write_bit(char b)
    {
    asm("cli"); // zablokowanie przerwań
    CLR_DQ; // stan niski na linii 1wire
    _delay_us(10); // opóźnienie 10us
    if(b) SET_DQ; // jeśli parametr jest niezerowy to ustaw stan wysoki na linii
    _delay_us(100); // opóźnienie 100us
    SET_DQ; // stan wysoki na linii 1wire
    asm("sei");  // odblokowanie pzrerwań
    }
    char ow_read_bit(void)
    {
    asm("cli");
    CLR_DQ;
    _delay_us(3);
    SET_DQ;
    _delay_us(15);
    asm("sei");
    if(IN_DQ) return 1; else return 0;
    }
    unsigned char ow_read_byte(void)
    {
    unsigned char i;
    unsigned char value = 0;
    for (i=0;i<8;i++)
    {
    if(ow_read_bit()) value|=0x01<<i;
    _delay_us(9);
    }
    return(value);
    }
    void ow_write_byte(char val)
    {
    unsigned char i;
    unsigned char temp;
    for (i=0; i<8; i++)
    {
    temp = val >> i;
    temp &= 0x01;
    ow_write_bit(temp);
    }
    _delay_us(8);
    }

    // End 1 wire
    ////////////////////////


    void czyt_temp1() //reads temperature and write it into temp1[] global variable
    {
    unsigned char d1, d2;
    char msb, lsb, temp;
    //char zda[4];
    //zda[3]=0;
    ow_reset();
    ow_write_byte(0xCC);
    ow_write_byte(0x44);
    _delay_ms(250);
    _delay_ms(250);
    _delay_ms(250);
    ow_reset();
    ow_write_byte(0xCC);
    ow_write_byte(0xBE);
    lsb = ow_read_byte();
    msb = ow_read_byte();
    //printLCD(msb);
    //printLCD(lsb);
    lsb = lsb >> 4;
    msb &= 0x07;
    msb = msb << 4;
    temp = lsb | msb;
    //printLCD(temp);
    d2 = temp / 10;
    d1 = temp % 10;
    temp1[0]=d2+48;
    temp1[1]=d1+48;
     //////////////////
    }

    0
  • Pomocny post
    #13 05 Sty 2010 22:25
    BoskiDialer
    Poziom 34  

    Na pewno wysyłanie bajtów jest złe - opóźnienie pomiędzy SET_DQ na końcu wystawienia jednego bitu a CLR_DQ przy następnym bicie - jest (a właściwie go nie ma) zdecydowanie za małe. Odczyt też zresztą jest niepoprawny - na jeden bit powinno przypadać dla bezpieczeństwa 60us, tutaj jest 18us w funkcji ow_read_bit oraz kolejne 9 w ow_read_byte - nawet 30us nie ma.

    Na szybko napisany kod według mojego stylu dopasowany do twojego szkieletu:

    Code:
    // uniwersalna funkcja transferu na 1wire
    
    unsigned char ow_transfer_byte(unsigned char val)
    {
       unsigned char i;
       for (i=0; i<8; i++)
       {
          asm volatile("cli"::);
          // wymuszenie stanu niskiego
          CLR_DQ;

          // opóźnienie podstawowe
          _delay_us(7);
          // wystawienie bitu - jeśli 1 to zakończenie wymuszania
          if(val & 1)
             SET_DQ;
          val >>= 1;

          // opóźnienie odczytu
          _delay_us(7);
          // odczyt
          if(IN_DQ)
             val |= 0x80;

          // opóźnienie dodatkowe
          _delay_us(70);
          // zwolnienie linii
          SET_DQ;
          asm volatile("sei"::);
          _delay_us(5);
       }
       return val;
    }
    unsigned char ow_read_byte(void)
    {
       return ow_transfer_byte(0xFF);
    }
    void ow_write_byte(unsigned char val)
    {
       ow_transfer_byte(val);
    }

    Jak to nie będzie działać, to poszukaj innego kodu.

    0
  • Pomocny post
    #15 05 Sty 2010 23:10
    Klima
    Poziom 30  

    Jakoś tego nie widzę, żeby ci Maxim wysłał trefne próbki. Może sam je jakoś uszkodziłeś, źle podłączyłeś czy coś takiego?
    Sprawdź rezystor pullup, może trzeba zmienić wartość? Pamiętaj też, że każdy egzemplarz jest inny i zawsze będzie trochę wolniej/szybciej odczytywał. Dodaj opóźnienia o których pisze Boskidialer i sprawdź raz jeszcze.

    0
  • #16 05 Sty 2010 23:40
    JulianM87
    Poziom 11  

    Ech, jak by to powiedzieć, ale ja głupi byłem, że nie sprawdziłem dokładnie kodu, tylko uwierzyłem kumplowi i wkleiłem go. Przyczyną błędu były za małe opóźnienia. Jedynie jeden z 4 wyrabiał się w tak małych czasach.
    Serdecznie dziękuję i zamieszczam poprawiony kod:

    Code:
    Poprawiony kod w moim następnym poście...

    0
  • #17 06 Sty 2010 00:08
    tmf
    Moderator Mikrokontrolery Projektowanie

    To ciagle nie jest idealne. Na szybko - w procedurze odczytu bitu czekaj az magistrala sama wroci do 1 i dopiero wtedy wracaj - opoznienia masz krotkie i ciagle przy bitach rownych 0 mozesz za szybko odczytywac kolejne. Po reset pulse czekaj na presence, przy zapisie 1 niski poziom skroc z 6us do 1-2, niektore DS probkuja szyne juz w 15us i w zaleznosci jak kompilator to przetlumaczy i predkosci zegara to moze wyjsc na granicy.

    0
  • #18 06 Sty 2010 00:24
    JulianM87
    Poziom 11  

    Nie wiem, czy to taka pora późna, ale mam problemy, żeby to teraz ogarnąć. To co teraz mam na pewno nie jest idealne, no ale od czegoś trzeba zacząć. Jutro do tego wrócę i poprawię, jak na razie dostosowałem opóźnienia do standardu 1-wire.
    Do tego doszedłem. Nie wykrywa 'presence' (gdzieś tam jest, ale jeszcze nie umiem go złapać),tak więc będę musiał jeszcze sporo popracować nad tym.

    Code:

    //////////////////////
    /// start 1 wire

    //-----------------------------------------------------------------------------
    // Generate a 1-Wire reset, return 1 if no presence detect was found,
    // return 0 otherwise.
    // (NOTE: Does not handle alarm presence from DS2404/DS1994)
    //
    int OW_Reset(void)
    {
            int result = 0;
          int i=0;

          ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
            {

            CLR_DQ; // Drives DQ low
            _delay_us(500);
            SET_DQ; // Releases the bus
            _delay_us(15);  //od 15us do 60us presence

       // Sample for presence pulse from slave, max 120us. Worst case 60us taken for presence.
          for(i=0; i<60; i++)
          {
            if(!(result = IN_DQ))
            {
              _delay_us(1);
              if(!IN_DQ){
               result = 0;
                break;
               }
              }
            else
              _delay_us(2);
          }
          if(!IN_DQ)
          {
           for(i=0; i<60; i++) //presence trwa max 240us, wiec 300us to nawet za duzo
           {
             _delay_us(4);
              if(IN_DQ){
               result=1;
               break;
              }
           }
          }

          }
           //else _delay_us(200);  //nie wiem czy potrzebne, skoro nie bylo presence pulse

           return result; // Return sample presence pulse result




    }

    // procedura zapisu bitu na linię 1wire
    void ow_write_bit(char b)
    {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    {  // zablokowanie przerwań z opcja przywrocenia ustawien w sreg (odnosnie glob.int)

    if(b){
      CLR_DQ; // stan niski na linii 1wire
      _delay_us(2); // opóźnienie 2us - powinno byc 1-15, zalecane 6
      SET_DQ; // stan wysoki na linii do konca slotu
      _delay_us(98); // opóźnienie 110us caly cykl
     }
    else {
      CLR_DQ;
      _delay_us(90);
      SET_DQ;
      _delay_us(10);

    }
    }  // odblokowanie pzrerwań
    }
    char ow_read_bit(void)
    {
    char temp = 0;
    //int i;

    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    {

      CLR_DQ;
      _delay_us(6);
      SET_DQ;
      _delay_us(20);  //standardowo 9 (w sumie powinno byc 15us w tym momencie)

       temp = IN_DQ;
       if(!temp){
       while(!IN_DQ);}
       else
        _delay_us(90);

    }
      return temp;
    }
    unsigned char ow_read_byte(void)
    {
      unsigned char i;
      unsigned char value = 0;
      for (i=0;i<8;i++)
      {
      if(ow_read_bit()) value|=0x01<<i;
      _delay_us(3);
      }
      return(value);
      }
      void ow_write_byte(char val)
      {
      unsigned char i;
      unsigned char temp;
      for (i=0; i<8; i++)
      {
      temp = val >> i;
      temp &= 0x01;
      ow_write_bit(temp);
      _delay_us(3);
      }
      _delay_us(8);
    }

    // End 1 wire
    ////////////////////////


    void czyt_temp1() //reads temperature and write it into temp1[] global variable
    {
    unsigned char d1, d2;
    char msb, lsb, temp;
    //char zda[4];
    //zda[3]=0;
    OW_Reset();
    ow_write_byte(0xCC);
    ow_write_byte(0x44);
    //_delay_ms(95); //dla 9-bitow.
    //_delay_ms(250);
    //_delay_ms(250);
    //_delay_ms(250);
    OW_Reset();
    ow_write_byte(0xCC);
    ow_write_byte(0xBE);
    lsb = ow_read_byte();
    msb = ow_read_byte();
    lsb = lsb >> 4;
    msb &= 0x07;
    msb = msb << 4;
    temp = lsb | msb;
    d2 = temp / 10;
    d1 = temp % 10;
    temp1[0]=d2+48;
    temp1[1]=d1+48;
     //////////////////
    }
    void OW_ROM()
    {
      int i= 0;
      OW_Reset();

      //LCD_WriteData((OW_Reset()+48));   //!!!!!!!!!!!
     
        ow_write_byte(0x33);

        for(i=0; i<8; i++)
       {
          ROM_NO[i] = ow_read_byte();
        }

         for(i=0; i<8; i++)
        {
          printLCD(ROM_NO[i]);
        }

    }

    Jeszcze raz dziękuję za pomoc.

    EDIT: dopracowałem OW_Reset() według zaleceń, dodatkowo wspierałem się AN162 aby funkcja była jak najbardziej uniwersalna, bo nie posiadam w domu oscyloskopu.
    Poprawiłem blokowanie przerwań i resztę funkcji dostosowałem. U mnie działa na wszystkich czujnikach. Przy opóźnieniu mniejszym niż 2us na początku wysyłania/odbierania bitu są problemy a według Dallasa wartość ta powinna wynosić od 1 do 15us, ja użyłem 2us dla zapisu i 6us dla odczytu. Komentarze w kodzie mogą być miejscami bez sensu, bo często zmieniałem opóźnienia i eksperymentowałem...

    0
  • Pomocny post
    #19 06 Sty 2010 10:16
    tmf
    Moderator Mikrokontrolery Projektowanie

    W OW_Reset po wyslaniu RESET_PULSE (ktory zreszta powinien trwac 480us, a nie 450) za dlugo czekasz pomiedzy koncem RESET_PULSE a poczatkiem badania PRESENCE_PULSE. Kolejna rzecz - po wykryciu PRESENCE_PULSE nie dawaj stalego opoznienia tylko probkuj magistrale az wroci do "1" - oczywiscie z zabezpieczeniem przed zwarciem do "0" - zeby program sie nie petlil w nieskonczonosc. W ow_red_bit jesli musisz blokowac przerwania to w dyrektywach asm dodaj volatile, inaczej kompilator moze sprobowac przemiescic te instrukcje, a najlepiej uzywac dedykowanych do tego celu makr - ATOMIC_BLOCK. Jesli wykorzystujesz przerwania to zapomniales analogicznie je blokowac w procedurze wysylania bitu.

    0
  • #20 07 Sty 2010 01:23
    JulianM87
    Poziom 11  

    A wiecie dlaczego w funkcji OW_ROM() użytej w funkcji main programu gdy zwracam wartość z funkcji OW_Reset() zamiast 1 jest jakaś inna liczba, która zostaje wyświetlona jako znak "-" na lcd... Zakomentowałem ją, ale zauważyłem, że często mam tego typu problemy i nie wiem za bardzo dlaczego.

    0
  • #21 07 Sty 2010 09:40
    tmf
    Moderator Mikrokontrolery Projektowanie

    Z tego powodu:
    if(!(result = IN_DQ))

    Jesli nigdzie pozniej IN_DQ nie jest rowny zero to twoja funkcja wraca z result ustawionym w tym miejscu - poniewaz jak przypuszczm 1-wire nie masz na pinie 0, wiec result zawiera zamiast 1 jakas potege dwojki.

    0
  • #22 07 Sty 2010 15:32
    JulianM87
    Poziom 11  

    Ale przecież nadpisuję result wartością 1 lub 0 jeśli był presence pulse, a niemożliwe, żeby reset nadal nie wyłapywał presence_pulse.

    Edit:
    Jednak nadal nie wykrywa reset_pulse i już na prawdę nie wiem jakie timingi tam mają być, bo te podane przez Dallasa skorygowanie Waszymi podpowiedziami nie działają.

    Code:
    int OW_Reset(void)
    
    {
            int result = 0;
          int i=0;

          ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
            {

            CLR_DQ; // Drives DQ low
            _delay_us(480);
            SET_DQ; // Releases the bus
            _delay_us(15);  //od 15us do 60us trwa stan wysoki

       // Sample for presence pulse from slave, max 120us. Worst case 60us taken for presence.
          for(i=0; i<120; i++)
          {
            if(!IN_DQ) //jesli jest 0
            {
              _delay_us(1);
              if(!IN_DQ){  //jesli byl presence pulse
               result = 0x01;
                break;
               }
              }
            else
              _delay_us(1);
          }
          if(!IN_DQ) //byl presence pulse
          {
           for(i=0; i<60; i++) //presence trwa max 240us, wiec 300us to nawet za duzo
           {
             _delay_us(2);
              if(IN_DQ){
               //result=1;
               break;
              }
           }
          }

          }
           //else _delay_us(200);  //nie wiem czy potrzebne, skoro nie bylo presence pulse

           return result; // Return sample presence pulse result
    }


    W moim przypadku wysyłam stan niski przez minimum 480us, po 15us próbkuję przez max 120us czy nie ma stanu niskiego, który powinien trwać 60-240us.
    Jeśli był wykryty Presence_Pulse od urządzenia slave, to próbkuję 1-wire do momentu wykrycia 1, czyli zakończenia resetu. W przeciwnym wypadku skoro nie było obecności 1-wire kończę od razu.

    0
  • Pomocny post
    #23 07 Sty 2010 15:48
    asembler
    Poziom 32  

    Moze dam ci program w ASM dzialający bez wzgledu na jakies tam timingi i sprawdzisz sobie bo teraz to wyglada na to ze to tylko sprawa programowa.
    Co ty na to? ja juz to przerabialem w 90% przypadków wystarczyło dobrze okreslic wartosc kwarzu wprogramie lub dobrze pomierzyc albo zastosowac zewnetrzny.

    0
  • #24 07 Sty 2010 15:54
    JulianM87
    Poziom 11  

    Dziękuję, ale w asemblerze też są opóźnienia, tylko zrealizowane w pętlach. U mnie reset działa, tylko nie umiem wyłapać kiedy to występuje presence pulse. Chyba będę musiał sprawdzić to na oscyloskopie.

    0
  • Pomocny post
    #25 07 Sty 2010 16:00
    asembler
    Poziom 32  

    Kto ci powiedzial ze w asemblerze opoznienia są w pętlach?
    U mnie akurat wszsytko jest zrobione na bazie przerwan tak zeby program głowny nie odczuwal zadnycg opoznienień.
    Na oscyloskopie? tez mazna ale lepiej to pomierzyc programowo.

    0
  • #26 07 Sty 2010 16:16
    JulianM87
    Poziom 11  

    No można też wykorzystać licznik atmegi. Wydaje mi się, że te funkcjie _delay_us miały być dosyć dokładne, asembler w jaki sposób można to zmierzyć programowo?

    0
  • Pomocny post
    #27 07 Sty 2010 16:25
    asembler
    Poziom 32  

    Sposob pomiaru długosci impulsow wyglada w w sposib nastepujacy:
    Dołaczam wyjcie/wejscie równolegle do wjecie INT0 lub INT1 i przy kazdym zboczu opadającym,zapisuje stan licznika nr1 w pamieci. Wartosci mozna sobie wyswietlic na LCD i przeanalizowac.
    Inna sprawa ktora mi sie nasunęla to to ze są dwa systemy odczytu dallasów low speed i high spped i trzeba by to sprawdzic. oczywiscie trzeba licznik nr1 uruchomic z odpowiednim preskalerem.
    Pozdrawiam

    0
  • #28 07 Sty 2010 17:13
    tmf
    Moderator Mikrokontrolery Projektowanie

    Chyba prosciej do generacji i odbioru na 1-wire zaprzac RS232 z odpowiednim prescalerem. Na nic nie trzeba czekac, liczyc itd. A jesli jest niedostepny to wykorzystac timer i jego piny wyjsciowe do generacji impulsow i capture mode do detekcji co nadeszlo. Tyle, ze to wyzsza szkola jazdy.
    Jesli Julian chces zmoge dac ci moje kody dla ATMegi128 w C++, przerobienie ich na c jest raczej banalne.

    0
  • #29 07 Sty 2010 17:41
    asembler
    Poziom 32  

    Chyba pierwsze słysze RS232 doodbioru 1-wire? Niby sie wszystko da zrobic ale co wtedy z komunikacja z innymi prockami na 1-wire? Pomysł z rodzaju sc.
    Przybliż jakby to mialo wygladac?

    0
  • #30 07 Sty 2010 17:49
    tmf
    Moderator Mikrokontrolery Projektowanie

    Normalnie, jesli polaczysz TxD i RxD i na TxD dasz impuls ujemny inicjujacy transmisje 1-wire to jednoczesnie zainicjuje to odbior danych po RS, ktory zgodnie z ustawionym bitrate bedzie samplowal magistrale, kolejne probki wpisujac do rejestru danych. Jak skonczy to zglosi przerwanie, wystarczy w jego obsludze wybrac interesujacy bit (odpowiadajacy czasowi, ktory nas interesuje) i juz. Albo kilka bitow - co daje nam uniezaleznienie w pewnym stopniu od szumu. Przeciez tak sie robi standardowo implementacje 1-wire na RS, znane od lat.
    Co znaczy "co wtedy z komunikacja z innymi prockami na 1-wire?"?

    0