PIC16F690 MikroC Strul med att läsa bitar från DS18B20

[laserlars]

Hej!

Tänkte köra några DS18B20 sensorer till en PIC16F690.

Jag har allt körandes med en sensor. Jag vill dock kunna scanna av sensorer vid uppstart då jag tänkte köra flera på samma 1-wire buss.
Tidgare använde/använder jag MikroC's OneWire library med OW_Read, OW_Reset, OW_Write funktionerna och det fungerar hur bra som helst.

Dock för att göra en sökning (0xF0 kommandot mot bussen) så behöver jag göra bitoperationer för att matcha svaren.

Jag slängde ihop följande funktioner men jag får dem inte att fungera som de ska:

// port och pin använder jag inte för tillfället. Bussen sitter på PIC'ens RB6 port.

Kod: Markera allt

unsigned short read_bit(unsigned short *port, unsigned short pin)
{
    unsigned short temp = 0;
    TRISB.F6 = 0;
    PORTB.F6 = 0;
    Delay_us(5);
    TRISB.F6 = 1;
    Delay_us(9);
    temp = PORTB.F6;
    Delay_us(55);
    return temp;
}

när jag använder ovanstående så returnerar den alltid 1 från databussen.

jag har även provat att ersätta mina tidigare Ow_Read calls med att läsa in bitarna med ovan men får samma problem. den ger mig bara 1.

Är det Delay_us som inte fungerar som den ska? Tankar och funderingar på vad som kan vara galet?

Mvh

[JimmyAndersson]

Välkommen till forumet.

Som det är nu så väntar den bara en stund tills den förväntar sig att det ska komma något från 1wire-sensorn.
Det är inte alls säkert att datan kommer just då. Tiden som 1wire-komponenter behöver på sig
beror på på bl.a kabellängder och spänning. Har man otur så kan det skilja flera hundra millisekunder
mellan olika avläsningar.

Sedan hänger jag inte riktigt med på hur du har gjort för att "anropa" (nollställa/söka, kan göras på olika sätt) sensorn.
Gör man inte det rätt så får man inget svar överhuvudtaget.


Mitt förslag är alltså att du först försäkrar dig om att du "anropar" sensorn på rätt sätt, se databladet för DS18B20.
Görs inte "sökningen" rätt så hamnar det ju inget på porten överhuvudtaget.
Dessutom bör du definitivt byta delayerna mot interrupt-triggad avläsning av pinnen.


Ett tips är att använda oscilloskop, om du har möjlighet.
Det blir så enormt mycket lättare när man faktiskt ser vad som händer på sensorns data-pinne.

[sodjan]

1-Wire är väl generellt lite tidskritiskt.
Så det kan vara bättre att antingen använda en C-miljö
där det finns färdiga/testade 1-Wire-libbar eller skriva egna funktioner
i assembler för själva 1-Wire hanteringen. Jag är inte alls säker att
man får till det bra med timingen direkt från C, speciellt inte med
de där "delay" funktionerna i det hela...

[laserlars]

Tack för svar!

Trevligt att vara här på forumet!

Jag ska ta en titt på om jag kan få igång någon lösning med interrupts. Har dock inte sett någon liknande lösning i övrig kod jag tittat på.

Jag skickar iväg kommandot till sensorerna med:
Ow_Reset(&PORTB, 6);
Ow_Write(&PORTB, 6, 0xF0);

SEARCH ROM [F0h]
When a system is initially powered up, the master must identify the ROM codes of all slave devices on
the bus, which allows the master to determine the number of slaves and their device types. The master
learns the ROM codes through a process of elimination that requires the master to perform a Search ROM
cycle (i.e., Search ROM command followed by data exchange) as many times as necessary to identify all
of the slave devices. If there is only one slave on the bus, the simpler Read ROM command (see below)
can be used in place of the Search ROM process. For a detailed explanation of the Search ROM
procedure, refer to the iButton® Book of Standards at http://www.maxim-ic.com/ibuttonbook. After every
Search ROM cycle, the bus master must return to Step 1 (Initialization) in the transaction sequence.

Andra kommandon jag använder fungerar bra, tex för att identifiera endast en så skickar jag 0x33 och då ger den 8 bytes som svar som jag kan läsa in utan problem med hjälp av
OW_Read kommandot.

Jag har tyvärr inget oscilloskop. Är det generellt svårt att Delay'a i låga mikrosekunder på en 8Mhz Pic?

Det som jag finner märkligt är att att jag inte får dataförändringar om jag byter ut andra OW_Read's jag gör mot loopar av read_bit.

Jag har även provat read_bit med en vanlig switch och den ger korrekt svar.

Ska även ta en titt på alternativa kompilatorer och se om de har lite roligare bibliotek. Helst hade jag velat titta inne i MikroC's OW_Read metod men det verkar vara ett färdigkompilerat lib.

[JimmyAndersson]

"Är det generellt svårt att Delay'a i låga mikrosekunder på en 8Mhz Pic?"

"Låga" som i "korta"?
Det ska inte vara några problem alls.
Däremot vet jag att korta delayer (ca 100ms och kortare) med delay_ms() kan ge
en väldigt konstig assemblerkod som i sin tur inte alltid ger önskat resultat.


Jag får inte riktigt ihop din kod.

"SEARCH ROM [F0h]"

Var i din kodsnutt finns detta?
Jag ser bara att du skickar 0 hela tiden.
Men F0h är 11110000, som ju ska skickas bit för bit.

Översatt till svenska blir din kodsnutt ungefär:
PORT.F6 som utgång.
"Skicka" 0.
Vänta 5µs.
PORT.F6 som ingång.
Vänta 9µs.
"Läs" PORT.F6 och spara i temp.
Vänta 55µs och returnera temp.


Visa gärna hela koden så blir det lättare att se hur du använder koden i ditt första inlägg ihop med Ow_Reset() och Ow_Write().

[sodjan]

> Jag ska ta en titt på om jag kan få igång någon lösning med interrupts.

Jag kan inte direkt minnas att jag har sett en 1-Wire implementering som
är byggd kring interrupts. Normalt är det så pass korta tider (och kritiska)
så man "timar" helt enkelt det hela i koden. Jag tror också fortfarande att
det är bättre att skriva "low-level" delarna av 1-Wire koden i assembler, men
om man har bra koll på vad man gör i C så går antagligen det med.

> Helst hade jag velat titta inne i MikroC's OW_Read metod...

Jag har för mig att Mikroelektronikas rutiner finns som källkod någonstans.
Men jag kan minnas fel...

> Är det generellt svårt att Delay'a i låga mikrosekunder på en 8Mhz Pic?

Nej. Ju kortare delay ju enklare är det, i alla fall i assembler.

[laserlars]

Låga som i korta vet inte vad som hände med huvudet när jag skrev där.

Kod: Markera allt

    //unsigned char bits;
    Ow_Reset(&PORTB, 6);
    Ow_Write(&PORTB, 6, 0xF0);
    do {
      bit_test = read_bit(&PORTB, 6) << 1;
      bit_test |= read_bit(&PORTB, 6);

      if(bit_test == 3) {
        ROM[0] = 0xFF;
        ROM[1] = 0x00;
        ROM[2] = 0xFF;
        break;
      } else {

Ovan är koden jag försöker få igång. bit_test resulterar alltid i 3 vilket innebär fel.

I min main kör jag även:

Kod: Markera allt

     ANSEL = 0;
     ANSELH = 0;
     //PORTC = 0;
     C1ON_bit = 0;
     C2ON_bit = 0;

Andra har gjort tex.

Kod: Markera allt

unsigned char owreadbit(void)
{
	unsigned char result;
	DQ=0;
	delay_us(6);
	DQ=1;
	delay_us(9);
	result=portb.0;
	delay_us(55);
	return result;
}

http://ghmicro.com/index.php?option=com ... mitstart=1

Börjar fundera på om det är pull-up resistorn som meckar till det. Har ca ganska exakt 5kOhm. Enligt spec'arna vill ska det vara runt 4.7kOhm.
Men samtidigt vill det inte heller fungera när jag byter ut vanliga Ow_Read mot att läsa in med read_bit. hmm.

Just nu kör jag med ovanstående kod utkommenterad och läser av två DS18B20 med följande:

Kod: Markera allt

     while (1) {
           Ow_Reset(&PORTB, 6);
           Ow_Write(&PORTB, 6, 0xCC);
           Ow_Write(&PORTB, 6, 0x44);
           //Delay_us(120);
           Delay_ms(750); // max 750 ms for converting
           for(i = 0; i < 2; i++) {
             Ow_Reset(&PORTB, 6);
             //Ow_Write(&PORTB, 6, 0xCC);
             Ow_Write(&PORTB, 6, 0x55);
             for(j = 0; j < 8; j++) {
                   Ow_Write(&PORTB, 6, ROMS[i][j]);
             }
             Ow_Write(&PORTB, 6, 0xBE);
             temp = Ow_Read(&PORTB, 6);
             temp = (Ow_Read(&PORTB, 6) << 8) + temp;
             //bits = PORTB.F7;
             //bits = read_bit(&PORTB, 7);
             //ShortToHex(bits, buffer);
             //Lcd_Out(1, 6, buffer);
             display_temperature(i+1,temp);
           }
           //Delay_ms(100);
     }

Inga problem alls!

[sodjan]

OK, något skilljer uppenbarligen mellan ow_read och din egen kod.
Se även:
http://www.mikroe.com/forum/viewtopic.php?t=23395
http://www.mikroe.com/forum/viewtopic.php?f=13&t=22625
och eventuella andra trådar där.
Men de där trådarna har du ju så klart redan sett, eller hur ?

[barbarossa]

Jag har för mig att Mikroelektronikas rutiner finns som källkod någonstans.
Men jag kan minnas fel...

Från MikroC FAQ:
"Can I get your library sources ? I need to provide all sources with my project.

It is our company's policy not to share our source code."