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

[VHDL]Spartan2 i termometr 1Wire DS1820

12 Mar 2007 22:19 6468 20
  • Poziom 11  
    Witam!

    Problem mam jak w temacie. Otóż, próbuję za pomocą języka VHDL oraz układu Spartan 2, komunikować się z termometrem cyfrowym DS1820…
    Czy ktoś próbował już czegoś podobnego, czy jestem pierwszy?
    Generalnie, usiłuję zbudować układ, który dogada się z termometrem w najprostszej konfiguracji (z osobnym zasilaniem, z jednym czujnikiem na linii) oraz wyświetli temperaturę na wyświetlaczu siedmiosegmentowym.

    Problem transmisji 1-Wire, usiłuję rozwiązać za pomocą tzw. One Wire Master, którego kod źródłowy (w VHDL'u) dostałem od Dallas Semiconductor.

    Czy ktoś robił coś takiego? Z jakim skutkiem? Dziękuję z góry za odpowiedź
  • Computer ControlsComputer Controls
  • Poziom 16  
    Czesc,

    Gdzie jest problem? Masz juz kosc, FPGA to wez sobie zasilanie z FPGA, mozesz nawet uzyc jednego pina z FPGA i ustawic go w jedynke i uzyc go do zasilenia tego termometru. Do tego mase podlacz do masy FPGA i zasilanie gotowe. Pin danych od tego termometru kabelkiem do FPGA i w FPGA ustaw na tym pinie wewnetrzny pull up resistor a jak Ci sie nie chce to zawsze mozesz podpiac zewnetrzny pull up 4.7k do zasilania. I tyle. Wszystko da sie na pajaka zrobic. Ja tak dwa tygodnie temu uruchomilem z tej samej firmy termometr ale z 3-wire. Do testow wystarczylo i nie mialem kodu od dallasa a Ty masz wiec nic wiecej nie musisz robic. Wystarczy, ze uzyjesz tego IP cora od nich.

    Do tego wyswietlacz 7 segmentowy to zwykly multiplexer wiec problemu nie ma.

    W zasadzie to roboty na pol godziny razem z cieciem kabelka ;)

    Pozdrawiam,
    tony_tg
  • Poziom 11  
    :cry:
    No to chyba cos jest ze mna nie tak...
    ..kwestie, zasilania i kabla do DS1820 i podpiecia go do plytki ze Spartanem 2 mam wykonana....

    Wyswietlacz 7 segmentowy, przemiatany sekwencyjnie mam zrobiony...

    Problemem jest zachecenie ds'a do wspolpracy...

    ...nie potrafie przebrnac przez obsluge tego wszystkiego...
    ...generalnie odpowiedz w stylu, ze jest to na pol godziny roboty nic mi nie daje, ale dzieki :P

    Napisalem potezna maszyne stanow, ktora steruje 1WireMasterem, wysyla odpowiednie dane do konfiguracji, potem juz do samego czujnika, i nic...
    Ni holery, nie umiem tego zrobic,
    ...moze ma ktos jakies wskazowki, przyklad??
  • Poziom 16  
    Czesc,

    Nie wiem czy masz jakiekolwiek doswiadczenie z FPGA i HDL'ami.
    Przesymulowales sobie Twoja maszyne? Na sieci mozesz znalezc modele symulacyjne do tego termometru wiec podlacz go sobie w testbenchu i zobacz co Twoja maszyna robi i czym odpowiada termometr.
    Mozesz sie postepowac po kodzie i zobaczyc jak on dziala i stwierdzic czy maszyna poprawnie ustawia sygnaly kontrolne na wejsciu tego 1Wiremaster.
    I zacznij od czegos prostszego jak przeczytanie np. statusu tego termometra i skup sie na uruchomieniu tego zanim zaczniesz podlaczac cos wielkiego. Inaczej masz za duzo niewiadomych i nie bedziesz wiedzial gdzie jest problem.

    Jak juz bedziesz mial ten status dzialajacy w symulacji to zaimplementuj to sobie w FPGA i bedziesz wiedzial czy bloki IO poprawnie sa skonfigurowane (napiecia, pullupy itd). Wszystko na pajaka zanim zaczniesz plyte montowac.

    Pozdrawiam,
    tony_tg
  • Poziom 11  
    Czesc!
    Sory za mojego poprzedniego posta… ale trochę się załamałem przez tego Dallasa… nie będę się może chwalił, ile czasu już nad nim siedzę…
    Więc, odpowiadając na Twoje pytanie o moje doświadczenie z FPGA, to… hmm jakie może mieć student po 45 godzinach zajęć…
    Wczoraj zacząłem składać projekt od nowa, no i okroiłem maszynę stanów, do kroków, ustaw dzielnik zegara dla „1WireMaster”, ustaw InteruptRegister, i wyslij do CommandRegister komendę Reset na magistrali…
    No i ku mojemu zdziwieniu: Moja maszyna działa… gada z 1WireMasterem, wysyła do niego i odbiera dane w postaci pojedynczych bajtów. Problemem jest, ze po resecie na magistrali, czujnik nie odpowiada pulsacją, bo po przeczytaniu rejestru przerwań w 1WireMasterze, mam tylko info o pustych buforach nadawczym i odbiorczym, że 1WM jest NotBusy, i że nie wykryto czujników na magistrali…
    Więc prawdopodobnie w tym miejscu tkwił problem od samego początku…
    Generalnie, moje pytanie sprowadza się w takim razie do…
    -czy dobrze podłączyłem czujnik?
    Zasilanie mam 3,3V podciągnięte z płytki ze Spartanem, GND analogicznie.
    Linię danych skonfigurowałem początkowo w ucf’ie tak:
    NET "DQ" PULLUP;
    NET "DQ" LOC="P43";
    Niestety tak nie działa :/
    Niedawno znalazłem w ApplicationNote’cie od Xilinx’a (xapp198) że pullup do lini danych można podpiąć przez komponent PULLUP… tylko, że oni tam wyraźnie napisali że ten rezystor ma 13kOhm, i że to jest więcej niż wymaga DS. (swoją drogą przykład nie dotyczył czujnika temperatury..)
    Podążając dalej kwestią rezystora podciągającego, …zastosowałem rozwiązanie „czysto” sprzętowe, udałem się do sklepu po rezystor… no i tu kolejna kwestia… Albo mam problemy z odróżnianiem kolorów, albo sprzedawca wcisnął mi rezystor 470 Ohm…
    Więc, pytanie… czy ten rezystor ma aż tak istotne znaczenie?
    No dobra, to tyle. Dzięki jeszcze raz za jakie kolwiek wskazówki, bo niestety nie mam z kim o tym pogadać.
    Pozdrawiam
  • Poziom 16  
    Ds lubi byc zasilany z 5v... a rezystorek moze być nawet 470om jezeli mikrokontroler da rade wymusić logiczne zero na nim.. :)
    Ja stosuje 4,7km i mam z głowy zmartwienia :)
  • Computer ControlsComputer Controls
  • Poziom 11  
    Witam ponownie...
    Więc, znalazłem i rozwiązałem kilka problemów.
    Pierwszym była niewłaściwa/nieaktualna dokumentacja do 1WireMastera od Dallasa, pdf ze strony jest bardzo nieaktualny i dotyczy jednej z pierwszych wersji. Dlatego 1WM nie komunikował się z czujnikiem bo źle konfigurowałem rejestr dzielnika częstotliwości zegara.
    Zmieniłem trochę moje podejście do problemu, a więc zacząłem od wywołania resetu na magistrali i sprawdzenia czy czujnik odpowiada pulsacją. Tutaj bardzo pomocny jest rejestr przerwań 1WM'a.
    Podążając dalej tym tropem (korzystając z przerwań) udaje mi się wysyłać komendy do DS'a. Niestety problemem jest odczyt ponieważ gdy rejestr konfiguracyjny przerwań ma ustawione kilka przerwań jako źródło stanu wysokiego na linii INTR, wówczas pojawiają się schody i musiał bym do mojego układu dopisać jakiś blok kombinacyjny który sprawdzał by jakie przerwanie wystąpiło i czy to było to przerwanie na które czekam... Ale oprzedłem to inaczej... początkowo ustawiam sobie aktywne przerwanie na PresenceDetect Result, wywołuję Reset magistrali i czekam na przerwanie. Następnie wpisuję w rejestr konfiguracji przerwań aktywne przerwanie TransmissionShiftRegisterEmpty, i po każdym wysłaniu bajtu-komendy wiem kiedy wysłać następną. Tak podążam do momentu przesłania 0xFF. Poczym czekam 500 ms i udaje mi się odczytać przysłany przez DS'a bajt (poki co odczytałem w ten sposób nr seryjny :) )
    Walcząc dalej zacząłem składać klocki do przesłania zestawu komend Reset, CC, 44, Reset, CC, BE, FF i tu bym się spodziewał po chwili dostać bajt TL temperatury :/
    Przeglądając dokumentację do czujnika doszedłem że potrzebuje on około 750ms na pomiar temperatury, więc po 44 czekam 1s.
    Niestety nadal nic, dzisiaj dam sobie juz chyba spokój, bo albo nie widze błędu w mojej maszynie stanów, albo program do rysowania maszyn stanów po "optymalizacji" wysypuje moją maszynę :/
  • Poziom 16  
    Wylącz optymalizację... Moze to pomóc ale niekoniecznie...
  • Poziom 11  
    Witam ponownie po krótkiej przerwie…
    Niestety w dalszym ciągu, nie mogę sobie z tym moim termometrem poradzić. Nie wiem, czy to ja jestem głupi czy może gdzieś w tym kodzie źródłowym od Dallasa jest błąd?
    Generalnie mam do Was pytanie, czy macie może jakieś przykłady, jak …”dogadać” się z czujnikiem 1820, bądź jakim kolwiek innym po szynie 1-Wire, w VHDL’u?
    Z góry dziękuję
  • Poziom 20  
    Witam,

    nie wiem jakim napięciem zasilasz Spartana ale coś mi się wydaję że chyba poniżej 3V, w nocie katalogowej DS18B20 a i zapewne podobnych minimalne napięcie zasilania to 3V. Sprawdź też poziomy napięć dla stanu Hi i Lo dla czujnika.
    Być może problem nie jest programowy tylko sprzętowy.

    Pozdrawiam.
  • Poziom 16  
    Czesc,

    Wlasnie bawie sie tym 1-wire od Dallasa bo interfejsuje sie do DS2406 ale patrzylem na dokumentacje do 1-wire do tego vhdl'a i tam przykladowe kody C sa dla DS1820.

    Patrzac na to co robisz to zdaje sie, ze zle wydajesz komendy dla tego termometru. Przerwania sa pomocne bo sama komunikacja jest bardzo wolna a ja mam cpu z ktorego obsluguje ten 1-wire. Kody dallasa sa u mnie peryferalem wiec wysylam cos tam do ich kontrolera i cpu robi cos innege a jak przyjdzie przerwanie to wysylam nastepny krok.
    W kazdym razie jak sie komunikujesz z tym termometrem to zrob to tak:

    w punkcie 1 adres jest 0 (command register) a reszta adres 1 (receive/transmit buffer)

    1. data=0x01, Reset na linie 1-Wire; Czekaj na przerwanie
    2. data=0x55, Match ROM (bedziesz adresowal urzadzenia na magistrali); Czekaj na przerwanie
    3. Wysylasz 8 bajtow adresu twojego termometru w petli: wyslij bajt, czekaj na przerwanie itd az wyslesz caly adres 64 bitowy
    4. data=0xBE, Read Memory; Czekaj na przerwanie
    5. data=0xFF, Czytasz bajt LSB; czekaj na przerwanie, odbierz bajt z bufora
    6. data=0xFF, Czytasz bajt MSB; czekaj na przerwanie, odbierz bajt z bufora

    Po ostatnim przerwaniu masz odczytane 2 bajty temperatury.

    Jak nie wiesz jaki jest adres twojego termometru to musisz wydac komende Search ROM i termometr poda Ci swoj adres a potem mozesz go uzyc. Tzn, przeczytaj sobie w dokumentacji (Book of DS19xx iButton Standards jest tutaj najlepsza) jak to sie dzieje, ze mozna zapytac o adres obojetnie ile ukladow jest podpietych do magistrali 1-wire.


    Daj znac jak masz dalej problem. Ja popatrzylem sobie na kody i ciekawe jest to, ze udostepniaja wersje w Verilogu i w VHDL'u i nie moge powiedziec aby to byla tylko translacja. Dla mnie te dwie wersje maja troche inna architecture. I faktycznie nikt nie napisal w dokumentacji, ze bit 7 w rejestrze dzielnika czestotliwosci jest najwazniejszy bo jak go nie ustawisz to wewnetrzny zegar jest wylaczony :) Najlepsze, ze zaznaczyli ten bit jako nie uzywany w dokumentacji :)

    Pozdrawiam,
    tony_tg
  • Poziom 11  
    No hej!
    Więc miło że ktoś poruszył temat tego „badziewia” od Dallasa…

    Wszystko robię mniej więcej tak jak napisałeś… tzn. póki co nie bawię się numerami seryjnymi.
    Co do różnych przykładów dostępnych na stronach Dallasa, to też z nimi walczyłem… ale do sedna.
    Udało mi się odczytać pierwszy bajt numeru seryjnego mojego czujnika, 0x28, co potwierdza że mam czujnik DS18B20 
    Co do odczytu temperatury to próbowałem zrobić to w następujący sposób:
    1) 0x01 na adres Command Registra
    2) 0x33 na transmit buffer
    3) 0xFF na transmit buffer
    4) odczyt z transmit buffera.

    Taki sposób transmisji działa więc podążając tym tropem usiłowałem odczytać temperaturę wysyłając 0xCC a następnie 0xBE. Wiem że pominąłem krok pomiaru temperatury, ale z dokumentacji czujnika wynika, że domyślnie w rejestrach TL i TH siedzi temperatura 85 st. C…
    Co do przerwań, to wywnioskowałem że są bardzo przydatne :D i od początku zakładałem żeby z nich skorzystać… Więc postępowałem tak jak wyczytałem w App Notach od Dallasa (APPLICATION NOTE 120 Communicating through the 1-Wire Master) Ustawiam rejestr konfiguracji przerwań na opróżnienie bufora rejestru nadawczego i na zakończenie resetu 0x09. No i tu zauważyłem problem! Otóż, gdy wysyłam komendę reset i dostaję przerwanie to wszystko mi się „jakby” wysypuje, tzn. przerwanie które dostaję chyba nie jest od resetu…
    Problem obszedłem w prosty sposób: ustawiam najpierw rejestr konfiguracji przerwań na zakończenie resetu, potem przed rozpoczęciem wysyłania komend, ustawiam przerwanie na opróżnienie bufora rejestru nadawczego.
    W ten sposób udaje mi się odczytać numer seryjny.

    Teraz co do rejestru dzielnika zegara… miałem problem z tym rejestrem… ponieważ początkowo bawiąc się tym źródłem od Dallasa, korzystałem z dokumentacji (PDF’a) ściągniętego z ichniej strony… tam jest ten rejestr opisany inaczej niż w dokumentacji którą dostałem razem ze źródłami w VHDL’u i VERILOG’u. Generalnie jest tam jeszcze kilka innych różnic np. w rejestrze konfiguracji przerwań…

    No dobra, to tyle chyba póki, co… posiedzę nad tym jeszcze trochę w spokoju… chociaż ciężko mi to już wychodzi ze względu że walczę z tym od początku roku i nic mi praktycznie nie wychodzi :/
  • Poziom 16  
    Czesc,

    Ja odpalilem te kody Dallasa (vhdl) i moge gadac z moim ds2406 poprawnie. Nie obylo sie bez symulacji tego badziewia i przeprojektowania czesci ich kontrolera aby troche go dopasowac do reali FPGA. (Oryginalne kody sa projektowane na ASIC'a, i do tego jak juz zaznaczylem, architektura tego co jest w vhdl'u jest troszke inna niz tego co jest w Verilogu).

    Postaram sie napisac co zrobilem jakbys chcial sobie to zmienic.

    Zaczynajac od dokumentacji, to polecam wywalic ja i zajac sie przesymulowaniem tego ustrojstwa i przeanalizowaniem co on tak wlasciwie to robi tam. Czesc rzeczy juz znalazles jak np. bit.7 w rejestrze zegara ktory jest globalnym enable dla tego kontrolera i jak nie jest zapalony to nie ma zadnego zegara i wszystko siedzi nieruchomo. Do tego znajdziesz nowy rejestr ktory nie jest opisany w dokumentacji pod adresem 5 (nastepny za rejestrem zegara). Ten modyfikuje troche timingi i ma zaimplementowane kruczki dla dlugich lini magistrali etc. Ale nie potrzebujesz tego wiec tylko nie pisz do tego rejestru przypadkowo :)

    Nie wiem czy zauwazyles ale caly kontroler oprocz interfejsu zewnetrznego jest taktowany zegarem 1 us. Z zewnatrz podajesz mu zegar systemowy i konfigurujesz rejestr zegara i zapalasz bit 7. To powoduje, ze prescaler i clock divisor sie odpala i zaczyna generowac wewnetrzny zegar clk_1us (nazwa tego sygnalu). Zauwaz tez, ze to nie jest clock enable dla procesow tylko zegar! To pierwsza rzecz ktora zmienilem. U mnie zegar systemowy jest duzo szybszy niz 1us wiec zamiast uzywac clk_1us jako zegar, wstawilem sobie dwa przerzutniki i bramke i wykrywam zbocze narastajace na tym sygnale i uzywam tego jako enable dla wszystkich procesow. Teraz calosc jest taktowana moim zegarem systemowym a enable pojawia sie co 1us na jeden cykl zegara systemowego. To bylo Ok w ASIC'ach ale dla FPGA oznacza gated clock i problemy Xilinx'a z poprawnym routowaniem tego ustrojstwa. (osobiscie nie lubie wielu domen zegarow w moich systemach jesli nie mam dobrego powodu aby ich uzywac, pozatym zegar jest teraz automatycznie global a nie local).

    Ten zegar 1us oznacza tez, ze przerwania sa wystawiane na tym zegarze i jak odczytasz rejestr przerwan co powinno wyzerowac przerwanie, stanie sie dopiero jak nastepny clk_1us tiknie!!) Jak Twoj uklad jest za szybki to jak przeczytasz rejestr przerwan to nie mysl sobie ze linia int pojdzie w stan nieaktywny natychmiast!! to sie stanie dopiero jak ten clk_1us tiknie wiec Twoj uklad ma duze szanse na zareagowanie na przerwanie ponownie (wyzwalanie na poziom). To w zasadzie druga rzecz ktora zmienilem. W pliku machine masz procesy ktore ustawiaja przerwania i zeruja je.
    Ja zrobilem tak, ze przerwania sa ustawiane jak clk_1us tiknie ale zerowane sa w momencie czytania z rejestru przerwan. W ten sposob zapewniam sobie, ze jak czytam z tego rejestru to linia przerwan jest fizycznie zerowana i reszta systemu nie wzbudzi mi sie jeszcze raz. Przerwanie jest po prostu OR'em wszystkich flag wiec nie mozesz reagowac na zbocze na lini przerwan.

    Po tych dwoch zmianach wrzucilem wszystko do FPGA i zadzialalo jak powinno.

    Jest jeszcze jeden trik z flagami w rejestrze przerwan. Nie mozesz polegac na fladze TBE. To cos co bede poprawial dzisiaj bo mnie zdenerwowalo :) W zasadzie to ona dziala ale jest jeszcze flaga transmit shift register empty/full ktora miesza tutaj.

    W kazdym razie numer jest taki, ze zamiast reagowac na TBE, czekaj na RBF (Receive buffer Full). To dziala jak powinno. Mozesz to robic bo kontroler dziala tak, ze aby odczytac cos z magistrali musisz zapisac cos do bufora danych. Jak chcesz odczytywac to piszesz 0xFF a wiedzac, ze linia danych jest open-drain na urzadzeniu a ty masz IO ustawione z pullupem na FPGA, to wysylajac 0xFF oddajesz kontrole lini Twojemu termometrowi i to od bedzie sobie pisal zera albo nic na linie. Flaga RBF zapali Ci sie w momencie transferu ostatniego bitu plus clk_1us :)

    Wiec ja to robie tak. Jak wysylam reset to ustawiam przerwanie na reset i presence detect. Potem jak dostane przerwanie to ustawiam w rejestrze interrupt enable flage erbf plus interrupt polrity a reszta nieaktywna i jak cokolwiek pisze albo czytam to czekam na ta flage i jak mi sie zapali przerwanie to odczytuje rejestr przerwan i odczytuje bufor danych aby wyzerowac przerwanie rbf. Zawsze te dwie rzeczy w obsludze przerwania. Czy uzyje danych czy nie to zalezy od kontekstu (np. w resecie ignoruje odebrane dane)

    Mam nadzieje, ze to Ci cos pomoze.

    Pozdrawiam,
    tony_tg

    PS. Jak chcesz sie dowiedziec dokladnie jaki numer seryjny jest Twojego termometra, to musisz znalezc kogos z czytnikiem iButton albo z legalna kopia jakiegos software'u z EDA z kluczem sprzetowym (np. ModelSim). Ten klucz sprzetowy to parallel port adapter od Dallasa (takie czarne ustrojstwo ktore musi byc podpiete do portu drukarki w kompie a po obu stronach ma takie okragle dolki wygladajace jak gniazda na okragle baterie). Moze na uczelni maja ModelSima albo cos innego zabezpieczonego kluczem sprzetowym?
    W kazdym razie te "gniazda" to czytniki iButton czyli 1-wire. Na zewnetrzny pierscien podpinasz mase a do srodka linie danych 1-wire Twojego termometru. Instalujesz 1-wire driver ze strony dallas'a i mozesz odczytac numer seryjny Twojego termometru plus wewnetrzna pamiec etc. Znajac numer seryjny mozesz sie bawic kontrolerem Dallas'a az bedziesz mogl poprawnie odczytac caly 48 bitowy numer. To bedzie dla Ciebie oznaka, ze rozumiesz sie z kontrolerem wiec bedziesz poprawnie interpretowal temperature. Tylko ostroznie bo znajomosc numeru seryjnego i zawartosci pamieci klucza sprzetowego niejednego popchnela na ciemna strone mocy ;)

    Tutaj jest zdjecie tego klucza:
    http://www.maxim-ic.com/products/ibutton/ibuttons/blue_dot.cfm#parallel
  • Poziom 11  
    No hej!
    Więc zrobiłem tak jak pisałeś, wszystkie procesy popędzam głównym zegarem, natomiast sygnał clk_1us robi za sygnał „enable” w procesach. Podłączyłem go przez „one_shota” więc trwa jeden takt zegara głównego. Przy okazji pozbyłem się „warningów” pt. „Gated clock”.

    Hmm… reszty o przerwaniach nie zrozumiałem… Tzn. rozumiem dlaczego miałem wrażenie że wywołanie resetu na magistrali, powoduje że dostałem kilka przerwań… po prostu INTR był aktywny przez 1us a ja popędzam swoją maszynę zegarem 80ns. Teraz przyszło mi do głowy, żeby sygnał INTR też dać na one_shota…
    Przyznam się, że nie jestem na tyle biegły w te vhdl’owe klocki, żeby trafić w proces kasujący stan aktywny na INTR’ze..

    Nie rozumiem też wykorzystania przerwania RBF (Receive Buffer Full)… w sytuacji transmisji danych do czujnika? Jeżeli wysyłam mu komendę a nie FF ?

    No, to póki co tyle, bo już dzisiaj mam problemy ze skupieniem się nad tym…
    Dzięki jeszcze raz wielkie, za pomoc i rady :D

    Dodano po 1 [godziny] 51 [minuty]:

    To znowu ja...
    Policzyłem troche, po analizowałem i chyba znalazłem potencjalny problem, który motywuje mnie do puszczenia linii INTR na oneshota...
    Ponieważ mam dwie "swoje" maszyny stanów które załatwiaja zapis i odczyt rejestrów OWM'a (timingi z tymi wszystkimi flagami EN, RD, WR, ADS) każda maszyna ma 8 stanów. Maszyny i cała reszta jest popędzana CLK =12 MHz. Natomiast stan na linii INTR jest tam 1us=0,00001s
    , tak? Wnioskuję że skoro piszę do transmit buffera, to trwa to ok. 0,0000064 s. Dostaję flagę INTR (TransmitBufferEmpty). Wysyłam kolejną komendę i ... mam stan wysoki na linii INTR...(z poprzedniego przerwania)...
  • Poziom 16  
    Czesc,

    Zmiana tego na one-shot bedzie dosc klopotliwa, ja tez o tym myslalem przez chwile ale to nie jest takie proste. ( nie mowie, ze jest niemozliwe, ale ja chcialem tylko miec dzialajacy uklad a nie wglebiac sie w przepisanie polowy kontrolera ).
    Glowny problem jest taki, ze calosc zostala zaprojektowana na aktywny poziom. Jak bedziesz reagowal na zbocze to zauwaz, ze czytanie z dwoch roznych rejestrow zeruje rozne flagi. Wiec po przerwaniu okaze sie ze wyzerujesz jedna flage a druga moze zawisnac Ci w stanie aktywnym i nie bedziesz o tym wiedzial. Wiec musialbys troche pogrzebac w kodach i pozmieniac pare rzeczy aby przerwanie bylo poprawnie wysylane.

    W kazdym razie powiem Ci co ja zrobilem bo modyfikacja jest dosc prosta aby wysylac przerwania na clk_1us a zerowac je gdy czyta sie z tych rejestrow.

    W pliku async_interface masz procesy ktore pisza i czytaja z rejestrow. W procesie ktory czyta rejestr danych i rejestr przerwan dodalem dwa sygnaly. Oba sa zero na resecie. Jak przychodzi Rd_bar to jesli czytam rejestr danych, zapalam moj sygnal, ze czytam ten wlasnie rejestr. To samo robie z drugim sygnalem jak czytam rejestr przerwan. Zeruje te sygnaly gdy Rd_Bar idzie w stan nieaktywny. U mnie to wystawia mi puls o dlugosci jednego zegara bo tyle mi trwaja rd_bar i wr_bar. W kazdym razie to robie w tym pliku a bede potrzebowal tego w machine.

    Teraz w machine masz pare procesow, ktore zapalaja flagi roznych przerwac. Mi byly potrzebne PD (po wydaniu komendy reset) i rbf.
    Obie flagi maja wlasne procesy wiec w obu zostawilem to co robia i dodalem else do na koncu (zakladam ze jak juz powiedziales masz jednego if clk_1us='1') w ktorym dla flagi pd zeruje ja gdy mam pulse z czytania rejestru przerwan (zeruje sygnaly pd i pd_set). Dla rbf, zeruje ja gdy mam czytanie z rejestru danych. Do tego w taki sam sposob zeruje jeszcze jeden sygnal kontrolny. slave_int zeruje gdy czytam z rejestru przerwan przerwan.

    Na koniec masz proces ktory ustawia activate_intr. tutaj kod jest prosty :
    Code:

    If clk_1us='1' Then
        If (set_interrupts = '1') Then
            activate_intr <= '1';
        End If;
    ElsIf set_interrupts='0' Then
        activate_intr <= '0';
    End If;


    plus oczywiscie domyslny reset.

    Teraz masz przerwania wystawiane na clk_1us i zerowane jak tylko odczytasz wlasciwy rejestr. Dalej sa aktywne poziomem wiec jak flagi sie zapala dla obu rejestrow a odczytasz tylko jeden to drugi dalej bedzie trzymal linie przerwan bo set_interrupts nie zgasi sie.

    Z ta flaga rbf, to ja jej uzywam bo mi dziala a nie zalezy mi na czasie jak rozmawiam z urzadzeniami 1-wire. (moge sobie pozwolic na wysylanie/czytanie jednego bajtu i czekanie az zostanie on calkowicie wyslany/odczytany bez zadnego triku w stylu pipeline uzywajac buforow i flag tbe etc)

    Proponuje odpalenie tego uzywajac flagi rbf a jak juz bedziesz mial wszystko dzialajace mozesz rozgryzc co jest grane z tbe ;)

    Pozdrawiam,
    tony_tg

    PS. Jedyny sposob aby odebrac bajt od urzadzenia jest wyslac cos na linie. Wiec ten kontroler w zasadzie TYLKO wysyla cokolwiek jest w buforze. Juz to powiedzialem ale to w zasadzie tlumaczy dlaczego przyczepilem sie tej flagi rbf ;)
  • Poziom 11  
    No hej!
    Sory, że dopiero teraz, ale miałem trochę spraw na głowie...
    Więc, udało mi się w końcu zachęcić 1WM'a i DS'a do współpracy ze Spartanem 2 :D
    Nie próbowałem jednak przerabiać procesów od INTR'a... problem z długo trwającym stanem aktywnym na tej linii obszedłem dodając do maszyny stanów, stany w których czekam na stan nieaktywny :D
    Teraz udało mi się odczytać temeraturę domyślną 85*C, oraz temperaturę zmierzoną. Wszystko z wykorzystaniem przerwania TEMT (transmit shift register empty).
    Więc ... DZIĘKI OGROMNE ZA POMOC!!
    Teraz mogę dalej walczyć z resztą projektu :D
  • Poziom 9  
    Witam , gdzie mozna znalesc symulator dla Ds1820 dla xilinxowego ise ??
  • Poziom 21  
    Witam ponawiam pytanie czy ktoś już okiełzał tego Dallasa pod FPGA ??
  • Poziom 21  
    Jak rozumiem to kolegę interesowałby obiekt one-wire który by testował napisną przez Ciebie konfigurację. Obawiam się że ciężko będzie z czymś takim. Ale łatwo to zasymulować mając do dyspozycji charakterystykę tranismisji. Pozdrawiam
  • Poziom 21  
    Chodzi mi o to czy ktoś poprawnie zaimplementował strukturę obsługi komunikacji szyny 1-wire z termometrem DS w układzie programowalnym FPGA i czy poprawnie mu to działa , odczytuje temperaturę itp. :)