1 Wire communication


Polynomial was X8 + X5 + X4 + X0 geloof ik.

Als ik daarmee de CRC uitreken over $66 of $CC, $66 kom ik op $B8 of $41 uit.

Bij beide waardes krijg ik onjuiste data terug.

EricP

mét CE

Polynomial was X8 + X5 + X4 + X0 geloof ik.

Geloven doe je in de kerk. Zo je wilt moskee. Als je software bakt, dan WEET je dingen. Ofwel: datasheet lezen en de juiste polynoom pakken.
Overigens schijnt dit chippie niet zoveel met CRCs te doen.

Geen zin om pic-ding code door te gaan spitten, maar... 3 tellen door de datasheet heen browsen zegt dat je moet beginnen met een reset, ding antwoordt met een PRESENCE pulse. Dan doe je een SKIP ROM (of een MATCH ROM met identificatie als dat je beter past). Dan kun je een READ STATUS doen. Waarna je een KEY, 0x00, schijnt te moeten sturen. Daarop krijg je je status register terug.
Ik zie nergens staan (dat kan ook betekenen dat ik eroverheen lees :) ) dat je ergens zelf CRCs moet genereren. De checks zou ik waar mogelijk maar ff laten zitten tot je het min of meer draaiend hebt. Niet teveel 'uitdagingen' tegelijk.

Bedankt voor de reacties:)

Deze chip werkt toch met een CRC voor het opvragen van het status register.

Als ik de CRC over het commando $66 bereken komt er $B8 uit.

Als ik deze CRC meestuur krijg ik ook data terug. Iedere keer als ik een onjuiste CRC meestuur is het resultaat wat ik terug krijgt allemaal 1.

Echter, met het commando $CC, $66, $B8 krijg ik alleen maar nullen terug.

Iemand een idee wat ik verkeerd kan doen?

EricP

mét CE

Op het gevaar af dat ik nu een draai om m'n oren krijg omdat jij de DS blijkbaar wel helemaal doorgespit hebt en ik niet :+ : waar staat dat??
Als ik op CRC zoek in de door jou gelinkte datasheet, dan kom ik dat vooral in de hoek van de 64-bit-ROM tegen. Verder eigenlijk nergens...

Dus om de discussie weer ff synchroon te trekken (dat praat zoveel makkelijker): waar staat dat?

Klopt Eric.

Echter in de sensoren die ik wil uitlezen zit een ASIC chip die voor de communicatie het dallas ds2430a protocol gebruikt.

De datasheets zijn nagenoeg hetzelfde op een paar kleine vershillen na.

Eerder in dit topic heb ik een blokschema gestuurd. Hierbij nog enkele stukjes die over het uitlezen van het Status register gaan.

Handig, als na twee weken blijkt dat het helemaal niet om de chip gaat die je opgaf, maar een compleet andere!... :(
(beter meteen aangeven welke chip je gebruikt, dat voorkomt nodeloze en verkeerde posts...)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Arco,

Denk dat het niet nodig is om jezelf hier kwaad om te maken.

Ik heb bijna geen documentatie over deze sensoren, bijna alles moet ik dus zelf uitzoeken. Geen probleem, dat is juist het mooie er aan.

Tot een paar dagen geleden dacht ik ook dat het met de validation key moest gebeuren zoals aangegeven in het datasheet van de DS2430A.

Iedere dag word ik hier wat wijzer over, echter loop ik op het status register nu echt vast. Daarom kan ik alle hulp van jullie gebruiken.

Excuus voor de foute info.

EricP

mét CE

Check. Vandaar de verwarring. Leuk, zo'n ASIC uitspitten. Zeker als de documentatie onvolledig is en je maar moet hopen dat het ding doet wat er gespecificeerd is...

Afijn, als je een ongeldige CRC stuurt, zegt je spec dat het ding in idle gaat. Aangezien 1-Wire met een pull-up iets werkt, zou je dan allemaal eentjes verwachten. Dat lijkt correct te zijn.

In deze context zou mijn insteek zijn (zeker als je weet wat de waarde die je terug krijgt zou moeten zijn): probeer 256 verschillende CRCs. Dan weet je gelijk welke wat zinnigs opleveren. Beetje reverse engineering dus...

Dat dacht ik dus ook.

Heb ik gedaan en ben er op het moment vrij zeker van dat de juiste CRC B8 moet zijn.

Heb nu de code zo gemaakt:

pic basic code:

Dim Bdata as bit
OWrite DQ, 1, [SkipRom, ReadStatus, CRC]
            While 1 = 1
            ORead DQ, 4, [Bdata]
            HRSOut Bin1 Bdata,","
            Wend

Ik verwacht 43 bits data van het status register.

Als ik nu kijk wat ik serieel terug krijg zijn de eerste 43 bits 0 en alles wat daarna kijkt 1.

Lijkt alsof hij dus wel iets doet met de 1e 43 bits maar ze zijn allemaal 0.

Nogmaals, het uitlezen van de EEPROM gaat goed en stabiel. Ik weet dus niet goed waar ik het probleem moet zoeken.

EricP

mét CE

Ja, en wat gebeurt er met de andere 255 mogelijkheden voor CRC? Leveren die alle 255 alleen maar 'eentjes' op??

Verder zie ik in je spec nog wat met een 'pulse train'. Geen idee wat het doet en hoe je dat genereert, maar het lijkt erop dat het chippie minstens 12mS 1.8432MHz wil zien op z'n 1-Wire line. Geen idee waarom, hoezo enz. Maar dat is mijn interpretatie. Ik kan me voorstellen als daar wat rammelt, je status register niet geset is en je dus alleen maar 0-en terug krijgt. Ik zie niks terug wat dat doet in je code (en het is geloof ik ook niet echt 1-Wire standaard, maar wie ben ik om dat te roepen?)

Ik denk dat je gelijk hebt Eric.

Ik ben nu een leeg Status register aan het uitlezen vandaar dat alle waarden 0 zijn.

Eerst moet ik het commando geven om een conversion te starten.

Hoe kan ik in PicBasic een mooie pulse train van 1.8432MHz genereren?
Ben nu met het Freqout commando aan het stoeien maar krijg nog geen mooie frequenties.
Heb ergens gelezen dat dit commando maar max 32KHz kan realiseren.

Hoe kan ik in PicBasic een mooie pulse train van 1.8432MHz genereren?

Dat kan niet, is veel te hoog. Zeker niet met zo'n oude pic op 4MHz)
Wel kunnen sommige pics de oscillatorfrequentie / 4 geven. Dan moet je dus een 7.3728MHz kristal gebruiken.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Bedankt Arco!

Ga nu kijken of het mogelijk is om dit softwarematig in Proton te doen.
Anders is het wellicht hardware-matig mogelijk.

Softwarematig kan nooit; je kunt uit een 4MHz klok natuurlijk nooit een 1.8432MHz klok maken. (omdat ze niet deelbaar zijn door elkaar)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Nee dat begrijp ik.
Heb het 7.3728Mhz kristal in bestelling staan.

Hardwarematig een component zoeken wat de klokfrequentie kan delen is dan de volgende stap.

EricP

mét CE

Hmz... Beroerde interfacing. Ik vind het in elk geval een raar concept.
Er zal wel ergens wat mee geclocked worden.

Als je nou gewoon eens lomp doet... ze speccen (minimaal) 12mS op die frequentie... Als je nou eens telt hoeveel cycles dat zijn en daar (op een lagere) frequentie eens ruim boven gaat zitten... En dan eens kijkt wat er gebeurt? Ja, je zit buiten spec, maar het zou me niks verbazen als het gewoon werkt. Niet prima voor productie (tenzij je meer van die ASIC weet en dus kan concluderen dat het zo ook kan), maar wel prima voor engineering / experimentje.

Ik heb nog steeds gen antwoord op wat de andere CRC opleveren. We *denken* nu wel te weten wat er aan de hand is, maar je kunt je zelf aardig het bos in redeneren als je iets aanneemt en dat niet op z'n minst 'pi maal duim' controleert.

Ik weet niet hoe het in pic-ding-basic kan, maar je kunt natuurlijk iets klussen met een 1.8MHz Xtal en een hardware switch die de 1-Wire ff op dat Xtal hangt (ofwel: 1-Wire is al pull-up, dus als je het pic-ding eraf laat blijven en de ASIC blijft er ook af, dan kun je 'm met een open collector (open drain) achtig iets wel laag krijgen en laten pulsen). Nog iets verzinnen met het juiste moment zodat je geen hele korte puls in het begin krijgt, maar dat lijkt me wel te doen.

Eric,

Een lagere frequentie is zeker het proberen waard.
Uiteindelijk zal ik de snelheid wel zo hoog mogelijk willen hebben. Maar dan kan ik in ieder geval al wat proberen.

Wat de CRC's betreft, ik heb alle CRC's die ik kon bedenken geprobeerd en bij allemaal was het resultaat 1111111111.
De CRC B8 was de enige waarbij het resultaat afweek (0000000000).

Ga er dus even van uit dat deze juist is. Kan dit verder niet bewijzen omdat het toch veel uitzoeken en proberen is zonder complete datasheets.

EricP

mét CE

Ik denk ook wel dat je gelijk hebt hoor. Maar ik heb met me ook wel eens suf zitten zoeken naar zoiets, dus ik neem het niet meer zo makkelijk aan. Dat heeft al veel te vaak veel te veel uren gekost.
Controle is natuurlijk niet zo heel moeilijk in deze: maak een loopje waarin je alle CRC probeert en laat je software ff uitspugen waar wat anders dan 0xFF terug komt. Het pic-ding doet het werk en jij kunt koffie leuten :).

Snelheid zo hoog mogelijk, ach... hoe vaak wil je een status register uitlezen? Is het de moeite waard? - aangenomen dat het OK is om buiten spec van het chippie te werken.

Nou is 1-Wire ff te lang gelden voor mij, maar aangenomen (en dat mag jij dus controleren! :) ) dat je de most significant bit eerst op de lijn zet: idle is de bus 'hoog', elke 0x55 die je stuurt heeft 8 bits en daarmee 4 cylces. Je 1.8MHz voor 12mS zou volgens mijn natte vinger iets van 22000 cycles moeten zijn (je mag het zelf precies uitrekenen). Per 0x55 die je TXed doe je er 4. Waarop diezelfde natte vinger zegt dat je dat 5500 keer moet doen. Het was minimaal 12mS, het is de natte vinger, dus doe het eens 5700x... (of je rekent het netjes uit :) ) en kijk wat er dan gebeurt.
Het is lomp en buiten spec. Je krijgt natuurlijk geen mooie, regelmatige blokgolf - daarvoor zal de software implementatie wel voor zorgen, maar je hebt wel al je cycles. En wellicht is het 'good enough' om in elk geval te kunnen testen (en later te zien hoe je het netjes oplost).

Ten eerste bedankt voor alle feedback! Denk dat ik er bijna ben

Heb nu als test een programmatje geschreven die met het Freqout commando 1,5 seconde lang 25Khz op de lijn zet.

In plaats van alleen maar nullen krijg ik nu een logisch resultaat!

Volgende stap word om uit te zoeken hoe ik het beste een 1.8432Mhz signaal op de lijn krijg voor 12ms.

Heb een aantal datasheets van PIC controllers doorgelezen en de sheets van de 18F1220 staat bijvoorbeeld dat als je een EC (external clock) gebruikt dat de Fosc/4 vrijkomt op de Clock out pin van de microcontroller.

Iemand hier ervaring mee?

Dat klopt, dat hebben de meeste pics. Sommige kunnen zelfs (binnen grenzen) een clock met een instelbaar deeltal genereren...
Als die sensor fantom voeding gebruikt, is die clockpuls trein nodig om 'wakker te worden' en op te starten...

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Maar als ik het goed lees kan ik er dan geen kristal meer over zetten toch?
Ik zal een extern klok circuit op de Clock in pin moeten zetten.
Of zie ik dit verkeerd?

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
EricP

mét CE

Zo'n oscillator... Hmz.. Ja, het kan. Maar als je het netjes wilt doen, dan moet je (denk ik) ook op het juiste moment schakelen.

Met een AVR zou ik denk ik een stukje inline assembly maken. Iets met een toggle pin, decrease var, jump-non-zero weer naar het begin. Dat moet je met een handje vol cycles rond krijgen. Evt. een NOP erbij. En dan een handige clock kiezen. Enige nadeel is dat je in die tijd geen interrupt moet krijgen, dus je code moet het wel toelaten.

Verder kun je je nog ff afvragen of die frequentie belangrijk is - dat is dus erg afhankelijk van je ASIC design. Het kan heel goed zo zijn dat ze oorspronkelijk een ander iets als interface-hardware hadden, waarbij die frequentie heel logisch was, maar dat het enige doel is dat er wat aan die poot gerammeld wordt. Ik weet niet of je er meer over te weten kunt komen, danwel door meer documentatie, danwel door reverse engineering (of omdat je die ASIC aardig door begint te krijgen en een goede slag kunt slaan naar hoe het zou moeten zitten en dat gaan controleren).

Mooi dat het werkt. Succes!

Heren,

Met dank aan jullie hulp lukt het me nu om de sensor uit te lezen!

Stuur een constant HPWM signaal naar een line driver/buffer die ik kan enabelen om de frequentie een bepaalde tijd op de data lijn te zetten.
Heb gemerkt dat het voor het resultaat niet uitmaakt hoelang ik dit doe als het maar langer dan 12 ms is.

Nu moet ik de waardes die ik krijg nog om kunnen rekenen.
Als ik een bepaalde sensor uitlees via een extern systeem zie ik dat de Z waarde waar ik naar opzoek ben 88 moet zijn.

Op de fotos Kun je de resultaten zien die ik terugkrijg van de sensor.
Het lukt me niet om op de 88 uit te komen. Kan iemand mij hier veder mee helpen?

Het is gelukt!

Ik hebt het voor elkaar om mijn sensoren netjes uit te lezen :)
Dank voor alle hulp.

Krijg nu een bijvoorbeeld een waarde die schommelt tussen de 98 en 102.

Als laatste stap wil ik nu dat het display in stappen van 5 waardes afbeeld.

Zodat er bijvoorbeeld bij alle waarden tussen de 97,5 en 102,5 gewoon 100 wordt afgebeeld.
Is de waarde 103 dan springt het display naar 105 etc.

Is dit mogelijk in de proton compiler?