Många använder ju 1-Wire® för lite olika ändamål, så också jag fast då bara för temperaturmätning.

Jag stör mig på timingen, inte att skulle ge de korta '1' (1µs) pulser men de "långa" '0'-pulser och timingen med läsningen.

Jag sätter en ära i att INTE använda delay och att använda interrupt så långt det går i mina projekt varför denna "primitiva" timing är besvärlig rent mentalt och ställer till problem med interruptprioriteter.

För tillfället fungerar min mjukvara så att den tar en bit åt gången och detta synkroniseras med en timer-interrupt så en läsning av t.ex. en DS18B20 tar ett par sekunder - men utan att låsa upp µC'n till detta.

Jo, jag vet att det finns kretsar att köpa för detta ändamål (DS2480, DS2482, DS2484 osv.) men det blir ytterligare en komponent att ha liggande. Jag brukar ha ett par transistorer mellan 1-Wire® bus och µC, det har fungerat riktigt bra och jag vinner inte så mycket mer vid att skulle prata med sensorerna via UART/I²C.

Men timingen kan vara bättre anser jag...
Det gör ONT i min svarta själ att ha en 32 bitars µC som kör med 50MHz till att vänta 90µs för "Presense pulse" efter en Reset, 100µs för att skriva '0' och 30µs för att läsa status från slavenhet. Ja, jag vet att det är lyxproblem men ändå!

Så i nästa batch mönsterkort jag ska beställa (på måndag antar jag) har jag bytt från 2 portpinnar till 2 andra portpinnar med UART på. Min tanke är att använda dom i synkront läge och strunta i klock-pulserna. Då ställer jag in deras hastighet till "lagom" (50000 bps kanske) och kan då kommunicera med 1-Wire® bussen vid att skicka t.ex. en 0x80 för den kortaste '0'-puls som behövs och ett antal 0x00 efter det för att läsa svaret.

Då kan jag lägga in hela detta system i en interrupt-kedja och plötsligt kan jag gå från att ha högsta prioritet på 1-Wire® systemet till att ha "normal" prioritet. Jag kommer att hålla de två transistorer mellan µC och 1-Wire® bussen kvar som "isolering" då jag ALDRIG (utom vid proof-of-concept) drar ut µC pinnar direkt ur kretskortet.

Jag har redan välfungerande mjukvara för att läsa, skriva och hitta serienummer på den bus och jag ser inte hur det blir bättre med en DS2484 till 12:- + moms, den ska ju ändå ha I²C kommunikation vilket betyder ett antal interrupts ovanpå ändå.

Visst går det att programmera en µC enbart för detta ändamål och sedan låta den prata på ett vettigt sätt men igen: jag har i grunden rikligt med datorkraft och kan jag använda den hårdvarutimingsmöjlighet som redan finns inbyggd är det ju billigt och bra.

Jag funderar dock på att fixa ett program till PIC som kan göra de funktioner och kommunicera med UART. Min tanke är att den ska kunde hitta enheter automatisk, läsa DS18B20 (och liknande samt andra efter behov) och rapportera de lästa värden i klartext via ett fastställd protokoll - men det är en senare fråga.

Har du något emot att köra ett RTOS?

På vilket sätt skulle det ändra timingen?

Jag har i mångt och mycket ett RTOS i systemet även om att det inte har ett overhead med dynamisk allokering osv.

Tänkte bara att det skulle förenkla för dig angående timing, typ ha ett minimalt interrupt för timing som bara ändrar en semafor som "skicka-processen" använder exempelvis.
Men kör på UART för 1-wire om det passar ditt tänk bättre (jag tänkte bara på hur jag själv skulle vilja göra ). Och det finns lite app notes om att använda just UART för 1-wire om man söker lite, så det borde väl vara en rätt bra idé.

Det bör väl gå att köra timern och ställa om timeout "on the fly" (det är väl en Renesas du kör)
Har du även capture på pinnen som ingång så kan du mäta om det är 30uS eller 100uS vid omslaget
och då även klara dig med läger interrupt prioritet om catpuren ändå sparar värdet åt dig
och kan bearbetas några us senare

Skrev en till 18B20 i veckan på en xmega där jag endast ställde om capture på timern.....

Swech

ahlsten: Ett RTOS löser inget rörande med sättet att skicka pulserna. Jag har inget problem med interrupts, bara med att vissa av pulserna tar en "för lång" delay för min smak.

Swech: Jupp, med capture kan man skicka pulserna utan problem. Tyvärr är alla capture-ingångar upptagna med annat.

Sedan ska pulserna skickas också, det betyder en timer utgång. Visst, de hänger ofta ihop men jag har mycket få kvar i projektet så det är svårt.

Men definitivt en bra lösning.

UART är väl ett utmärkt sätt att generera diverse alltmöjligt man vill ha timing på!
Varför inte!

Kör med en 1W host via SPI eller i2c.
Med rätt processor har du HW-stöd för både I2C och SPI.
Då slipper du alla timingproblem.

TomasL: det är just för att undvika att klämma dit en extra krets jag har vald denna lösning.

Jo, men det blir bättre än mjukvaruhandskakning

Nja... "Bättre" är ett farligt ord, precis som "Exakt".

Men jag har just (dålig sömn i natt) gått igenom lediga pinnar på µC'n och jag hittade faktisk en ledig timer-pinne till att skicka pulser ut med samt en capture-pinne på en ledig capture-enhet för Rx-delen.

Vid att köra timern som en 1-shot kan jag enkelt skicka en puls av valfri längd (mellan 80ns - 167,12ms). Vid att växla pinnens funktion (Timer out/Portpinne) kan jag använda timer-interrupten till att skapa reset-puls osv.

Med Capture som mottagare kan jag fixa läsningen ytterst enkelt.

Slutresultatet är att jag ska flytta 1 ledning på mönsterkortet och jag kan sedan köra 1-Wire® bussen på "högsta hastighet" utan att låsa µC'n med delay() i någon form - vilket ju är det viktiga.

En ISR ska ju exekveras snabbt och effektivt, helt utan delay() i någon form. Det kan kräva lite omtanke men sedan fungerar helheten riktigt bra.