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

DS18B20 na delay_ms, wyświetlacz na timerze nie działa

nsmarcin 07 Wrz 2011 18:37 4854 54
  • #1 07 Wrz 2011 18:37
    nsmarcin
    Poziom 12  

    Witam,
    Uporałem się już z obsługą multipleksowania wyświetlaczy 7-segmentowych za pomocą timerów, ale teraz powstał kolejny problem. Mam taki kod:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    I niestety nie wyświetla się temperatura. Obsługę DSa wziąłem z gotowca z jakiegoś kursu i jest ona zrobiona na delay_us i nie wiem czy przypadkiem nie w tym problem. Gdy rozdzielę funkcję na dwie tzn jedna odpowiedzialna za konwersję i dam ja w obsłudze przerwania, a druga za wyświetlanie (fragment ze switchem) to pokazuje mi się cały czas temperatura 00.0.

    0 29
  • Arrow Multisolution Day
  • #3 07 Wrz 2011 19:03
    nsmarcin
    Poziom 12  

    Na początku funkcji temperatura() wstawiłem cli(); a na jej końcu sei(); ale niestety dalej to samo

    0
  • #4 07 Wrz 2011 19:23
    snnaap
    Poziom 25  

    Tak nie powinno się robić ale to wstaw w przerwanie od Timera

    Kod: cpp
    Zaloguj się, aby zobaczyć kod




    W temperatura() od komentuj //_delay_ms(750);

    A poza tym pokaż co masz w "ds18b20.c" bo nie wiadomo co jest w ds18b20_ConvertT() i ds18b20_Read().

    0
  • #5 07 Wrz 2011 22:08
    nsmarcin
    Poziom 12  

    To jest kod z kursu i nie wiem czy mogę go tak umieszczać na forum ale najwyżej jeśli to niezgodne z regulaminem to proszę usunąć

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #6 07 Wrz 2011 22:27
    tmf
    Moderator Mikrokontrolery Projektowanie

    Generalnie cały ten twój układ trzebaby przeprojektować. Jeśli blokujesz przerwania na 750ms przy wyświetlaniu multipleksowym to nie spodziewaj się dobrych efektów. Postaraj się najpierw zrozumieć jak coś działa. W tym przypadku obsługę OW musisz zrobić sprzętowo, wykorzystując np. UART, co rozwiąże problemy z zależnościami czasowymi.
    Przykłady multipleksowania i takiej obsługi OW są do ściągnięcia z linku ze stopki poniżej. Przeanalizuj je i pomyśl jak to działa. Bez sensownej refleksji nigdy się programować nie nauczysz, bo co krok będą nowe problemy.

    0
  • Arrow Multisolution Day
  • #7 08 Wrz 2011 08:44
    snnaap
    Poziom 25  

    tmf napisał:
    Generalnie cały ten twój układ trzebaby przeprojektować. Jeśli blokujesz przerwania na 750ms przy wyświetlaniu multipleksowym to nie spodziewaj się dobrych efektów. Postaraj się najpierw zrozumieć jak coś działa. W tym przypadku obsługę OW musisz zrobić sprzętowo, wykorzystując np. UART, co rozwiąże problemy z zależnościami czasowymi.
    Przykłady multipleksowania i takiej obsługi OW masz w linku poniżej - są do ściągnięcia na ftp. Przeanalizuj je i pomyśl jak to działa. Bez sensownej refleksji nigdy się programować nie nauczysz, bo co krok będą nowe problemy.



    Nikt Tu nie mówił o wyłączaniu przerwania na 750ms
    Tak jak to napisał piotrva przerwania należy wyłączać na czas zapisu i odczytu 1wire, a nie na czas oczekiwania na koniec konwersji temperatury.

    piotrva napisał:
    W tym problem pewnie, że przerwania od odświeżania LEDów zakłócają zależności czasowe dla magistrali 1w - musisz na czas wysyłania komend wyłączyć przerwania (cli(), a potem, po obsłudze 1w, sei())


    Błędem podstawowym było umieszczenie tego fragmentu obsługi wyświetlacza

    Kod: cpp
    Zaloguj się, aby zobaczyć kod


    w funkcji temperatura o czym piałam wcześniej.


    Po drugie nie wiem czy w przypadku użytkownika nsmarcin jest dobrym pomysłem obsługę 1wire zrobić sprzętowo posługując się UART'em z uwagi na to, że jak początkującym w temacie uK.

    Moim zdaniem lepszym pomysłem byłoby uporanie się z obsługą 1wire w sposób jaki to robi czyli przy wykorzystaniu bibliotek z kursu które są zapewne w nim opisane w sposób pozwalający je zrozumieć.
    Następnym krokiem po zrozumieniu idei 1wire użytkownik może spróbować sił i napisać własną jej obsługę, np. wykorzystując UART.

    A po zatem link nie działa.


    Co do programu, to po wyrzuceniu obsługi wyświetlacza i wyłączeniu obsługi przerwania na czas wysyłania do i odbierania z 1wire funkcja temperatura powinna wyglądać tak:

    Kod: cpp
    Zaloguj się, aby zobaczyć kod


    przy czym zmienne
    int temp;
    int minus;
    int temp_ulamek;

    to zmienne globalne które należy zadeklarować na zewnątrz funkcji.

    0
  • #8 08 Wrz 2011 09:28
    gaskoin
    Poziom 38  

    Zrobienie OW na USARCIE moim zdaniem jest prostsze i bardziej efektywnie niż pajacowanie z delayami i ustawieniami portów, tym bardziej, że schemat takiego połączenia jest bardzo prosty i wszystko sprowadza do wysłania/odbierania pojedynczych bajtów z USARTu, co jest dobrze opisane na stronie MAXIMa

    0
  • #9 08 Wrz 2011 12:06
    mirekk36
    Poziom 42  

    gaskoin napisał:
    Zrobienie OW na USARCIE moim zdaniem jest prostsze i bardziej efektywnie niż pajacowanie z delayami i ustawieniami portów, tym bardziej, że schemat takiego połączenia jest bardzo prosty i wszystko sprowadza do wysłania/odbierania pojedynczych bajtów z USARTu, co jest dobrze opisane na stronie MAXIMa


    A mi się wydaje, że pajacowaniem jest twierdzenie, że obsługa 1wire DOBRZE to może wyjść tylko na UART. Ponieważ:

    1. jeśli mam procek tylko z jednym UART'em to marnowanie go na 1wire jest jak dla mnie totalną porażką. Zwykle UART jest dla mnie ważniejszy jak nie do debugowania to do jakiejkolwiek komunikacji z otoczeniem, z innym prockiem, z terminalem - przez Bluetooth czy przez kabel - obojętnie

    2. obsługa za pomocą UART'a i tak wymaga DELAY'ów więc ktoś tu sam sobie zaprzecza

    3. bo można wykorzystać dowolny pin dowolnego procesora, nawet tego, który nie ma UART'a !!!

    3. WCALE ANI W ZĄB TYPOWA obsługa 1wire nie koliduje z OBSŁUGĄ WYŚWIETLACZY 7-SEGMENTOWYCH, które są multipleksowane ani z żadnymi innymi przerwaniami w zdecydowanej większości przypadków.

    Tylko trzeba sobie porządnie tą obsługę 1wire napisać i korzystać umiejętnie z cli oraz sei a w zasadzie to nie sei tylko przywracania ustawień rejestru SREG. Przede wszystkim CLI można wykonywać tylko na czas najbardziej krytycznych opóźnień, które są w obsłudze 1wire na tyle krótkie że wręcz pomijalne. Proszę bardzo poniżej film z działania na jednym procku AVR

    1. obsługi 1wire - akurat tylko 1 czujnik DS18B20 miałem pod ręką
    2. wyświetlacza 4 pozycyjnego 7segm (odświeżanie 200Hz)
    3. obsługa LCD
    4. Nie widać na filmie ale działa w tle także BEZ PROBLEMÓW, komunikacja przez UART z terminalem na PC

    czy coś migocze na wyświetlaczu LED ???
    czy są jakieś błędne odczyty temperatury?
    czy zakłóca się praca LCD?
    czy zakłóca się działanie UART ??? tego nie widzicie ale podpowiadam że NIE

    dodam, że jednocześnie jeszcze obsługuję odbiornik podczerwieni TFMS i też nadal NIC A NIC się nie kłóci.

    więc o czym w tych tematach na elektrodzie ostatnio wszystkim chodzi? bo wciąż widzę, że obsługa 1wire bez udziału UART'a jest już prawie odżegnana od wiary.

    Uważam, wprawdzie, że obsługa 1wire przez UART może się przydać ale jeśli mam akurat dwa UARTY w procku i drugi leży odłogiem - to z nudów bym może tak zrobił albo wtedy gdyby mi rzeczywiście zaczęło przeszkadzać coś w projekcie. Tylko nie wiem jak on by musiał być rozbudowany.

    Więc panowie - nie opowiadajcie, że tradycyjna obsługa 1wire jest BEE ;)

    DS18B20 na delay_ms, wyświetlacz na timerze nie działa

    a poniżej filmik żebyście panowie mogli ocenić własnymi oczkami czy coś jest "nieteges":

    DS18B20 na delay_ms, wyświetlacz na timerze nie działa

    a poniżej jeszcze mały przykład kodu, bo wielu np już przy samej funkcji RESET wrzuca blokowanie przerwań na cały długi czas opóźnienia 480us a po co ??? ważniejsze czasowo jest to co potem czyli odpowiedź, zatem robimy to tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    I podobnie trzeba w TYLKO odpowiednich miejscach funkcji przesyłających/odbierających poszczególne bity robić - a nie! wyłączać TAK NA WSZELKI wypadek przerwania na cały czas / na całą pętlę przesyłającą cały bajt informacji. Wtedy rzeczywiście będą problemy

    0
  • #10 08 Wrz 2011 12:30
    gaskoin
    Poziom 38  

    mirekk36 napisał:
    gaskoin napisał:
    Zrobienie OW na USARCIE moim zdaniem jest prostsze i bardziej efektywnie niż pajacowanie z delayami i ustawieniami portów, tym bardziej, że schemat takiego połączenia jest bardzo prosty i wszystko sprowadza do wysłania/odbierania pojedynczych bajtów z USARTu, co jest dobrze opisane na stronie MAXIMa


    A mi się wydaje, że pajacowaniem jest twierdzenie, że obsługa 1wire DOBRZE do może wyjść tylko na UART. Ponieważ:


    Masz dziennikarski styl pisania, gdzie ja napisałem, że TYLKO dobrze na uart wyjdzie ?

    Cytat:

    1. jeśli mam procek tylko z jednym UART'em to marnowanie go na 1wire jest jak dla mnie totalną porażką. Zwykle UART jest dla mnie ważniejszy jak nie do debugowania to do jakiejkolwiek komunikacji z otoczeniem, z innym prockiem, z terminalem - przez Bluetooth czy przez kabel - obojętnie


    Debugowania? Gotowe projekty też zostawiasz z debugiem ? Jak mam jeden UART to biorę procka który ma ich więcej skoro ich więcej potrzebuję, a nie płaczę, co tu podłączyć i jak bo jest tylko jeden. Wyjątkiem jest sytuacja, kiedy dostaję procesor - "Panie Mieciu masz pan taki procesor, napisz pan na to program" a tu się okazuje, że tylko 1 UART.

    Cytat:

    2. obsługa za pomocą UART'a i tak wymaga DELAY'ów więc ktoś tu sam sobie zaprzecza


    Nie powiedziałbym, obsługa chociażby resetu po uarcie to poprostu wysłanie bajtu 0xF0 z baudem 9600 bez żadnego oczekiwania na cokolwiek. W przerwaniu można sobie odebrać bajt od 0x10 do 0x90 jeżeli urządzenie jest dostępne (inny jeżeli nie). Gdzie Ty tu widzisz jakieś delaye ?
    Jedyny jaki będzie potrzebny to te 750ms czasu konwersji, ale to sobie można w tym czasie i tak robić coś innego i poczekać na flagę z timera.

    Cytat:

    3. bo można wykorzystać dowolny pin dowolnego procesora, nawet tego, który nie ma UART'a !!!


    I zarżnąć ten procesor (jeżeli już mowa o dowolnych) delayami trwającymi wieki.

    Cytat:

    Więc panowie - nie opowiadajcie, że tradycyjna obsługa 1wire jest BEE ;)


    Próbowałeś nietradycyjnej, bo coś mnie się zdaje, że nie.

    0
  • #11 08 Wrz 2011 12:46
    mirekk36
    Poziom 42  

    gaskoin napisał:

    Próbowałeś nietradycyjnej, bo coś mnie się zdaje, że nie.


    Pewnie, że próbowałem i to już dawno. Jak na razie nie miałem potrzeby skorzystania z niej co nie oznacza, że tak jak ty uważam, że tylko jedna jest dobra albo najlepsza. Ja jak zwykle uważam, że trzeba umieć rozsądnie wybrać w zależności od warunków.

    A bajanie o delayach trwających wieki można włożyć raczej między bajki, bo delaye są po to żeby ich używać, tyle że sztuką jest wiedzieć jak. Podobnie jak z organizacją całego programu/projektu. Nie chcę broń boże wmawiać ci, że ty masz z tym problemy - nawet jestem pewien, że nie .... Ale posiadanie klapek na oczach i nie uznawanie innych argumentów w dyskusji tylko swoje własne to już inna sprawa.

    Gdzie w swojej nader długiej również dziennikarskiej wypowiedzi odniosłeś się do zalet korzystania z tradycyjnej metody ? co powiesz na procki nie posiadające UART'a ???? rozumiem że w nich już byś nawet nie tknął 1wire bo będą wiecznie trwające Delaye ???? Rozumiem też, że jeśli już MUSISZ wykorzystać UART np do komunikacji z PC a procek to np ATmega88 - to od razu wymienisz go na taki co ma dwa UART'Y żeby zrealizować 1wire ??? Spójrz na to i pomyśl czy troszkę nie przesadzasz....


    bo to ty napisałeś wyżej - że takie tradycyjne korzystanie z obsługi 1wire to pajacowanie a nie ja. I do tego tylko się odniosłem.

    A gdybym był uszczypliwy tak jak ty - to również mógłbym zapytać czy próbowałeś tradycyjnej obsługi 1wire żeby wszystko działało tak jak pokazałem to na filmie ??? czy jeszcze nie ?

    0
  • #12 08 Wrz 2011 13:21
    gaskoin
    Poziom 38  

    mirekk36 napisał:
    (...) co nie oznacza, że tak jak ty uważam, że tylko jedna jest dobra albo najlepsza. Ja jak zwykle uważam, że trzeba umieć rozsądnie wybrać w zależności od warunków.


    Ja tak nie uważam, twierdzę, że jeżeli jest możliwość to warto skorzystać z UARTA niż dziabrać się z delayami.

    Cytat:

    A bajanie o delayach trwających wieki można włożyć raczej między bajki, bo delaye są po to żeby ich używać


    Nie na szybszych procesorach. Nie zawsze możesz tak skonstruować projekt żeby móc sobie czekać i nic nie robić przez 750ms. Albo czekać aż się bajt pośle, zrobi reset etc.

    Próbowałem tradycyjnej metody, sto lat temu na Atmedze8 z delayami, ale program tylko posyłał coś po Uarcie, sterował przekaźnikiem i posyłał gdzieś tam sobie kod RC5 więc mogłem sobie pozwolić na 750 milisekund nic nie robienia.

    Nie mam klapek na oczach, piszę to, wiedząc, że dla szybkich procesorów delaye to jest mnóstwo zmarnowanego czasu. Z drugiej strony w ARMach, bo głównie o nie mi chodzi, standardem są 3 czy więcej uartów. Jak robisz coś więcej to niestety, ale rzeczy, które pożerają najwięcej czasu się optymalizuje. Na pierwszy odstrzał idą właśnie takie pożeracze czasu jak delaye.

    Trzeba mieć tylko świadomość zeżartego czasu, o to mi jedynie chodzi. Z multipleksowaniem to nie będzie kolidowało, ale z czymś innym już może.

    Koniec offtopicu :)

    0
  • #13 08 Wrz 2011 14:07
    mirekk36
    Poziom 42  

    Po pierwsze to ty jak zwykle w temacie, gdzie chodzi o AVR 8bit zaczynasz opowiadać jak to ty robisz na ARM'ach - a to nie ma nic wspólnego z tematem.

    Po drugie - panie kolego - może już przestań opowiadać o Delayu 750ms, bo myślałem że co do tego to chyba się rozumiemy - że to jakaś bzdura i tak się nie robi. Ja piszę o pozostałych delayach ale tych w mikrosekundach i nawet nie o tym najdłuższym dla 1wire-reset.

    A widzę, że teraz jakby uczepiłeś się tego 750-milesekundowego delaya ;) (Więc ja już nawet pomijam dalszą dyskusję o tym delayu)

    Wcale to nie taki oftopic, bo z takiej dyskusji czasem początkujący coś wyniesie.

    0
  • #14 08 Wrz 2011 15:55
    tmf
    Moderator Mikrokontrolery Projektowanie

    Te 750 ms to była moja pomyłka, ale przy reset pulse musisz robić delaye po 480us, potem czekać na presence, w wielu przypadkach poprawna obsługa wymaga czekania aż magistrala wróci do 1 - efektem jest blokowanie procesora na czas nawet do 750us - reset_pulse+precence_pulse z czekaniem aż wróci do 1. Typowo na czas rzędu 100us. Ponieważ robisz to z zablokowanymi przerwaniami o tyle zwiększa się latency przerwań - a tu sorki, ale w 99% moich projektów nie mogę sobie na to pozwolić. Oczywiście, ktoś kto robi wyświetlanie temp. na multipleksowanym LED, kombinując jakoś to połączy. Ale jak już będzie chciał przez PWM na tym LED zrobić regulację jasności to pojawi się problem.
    Nie zgodzę się też z twoją tezą o jednym UART lub jego braku. Obecnie są do dyspozycji procesory ze wszelkimi udogodnieniami, jeśli ktoś do projektu wybiera procesor z jednym UART, a nagle okazuje się 2 byłyby potrzebne, to znaczy, że od początku totalnie projekt zwalił - i tu nie ma co szukać usprawiedliwień, tylko trzeba nazywać rzeczy po imieniu. Wtedy oczywiście można robić protezy o jakich piszesz, ale nie mylmy przyczyny ze skutkiem.
    Oczywiście nie znaczy to, że w każdym przypadku trzeba z UART korzystać - znaczy to tylko, że o ile się da, to tak jest po prostu wygodniej.
    BTW, osobiście uważam, że używanie delay to akt desperacji i w 90% świadczy o złej koncepcji na program.

    0
  • #15 08 Wrz 2011 16:09
    mirekk36
    Poziom 42  

    tmf napisał:
    Oczywiście, ktoś kto robi wyświetlanie temp. na multipleksowanym LED, kombinując jakoś to połączy. Ale jak już będzie chciał przez PWM na tym LED zrobić regulację jasności to pojawi się problem.


    No ale ja się całkowicie zgadzam. Po prostu zawsze się dziwię, gdy ktoś nagle zachwala jedno rozwiązanie nad innym nie biorąc pod uwagę w ogóle czynników, które mogą być różne dla różnych programistów, potrzeb, projektów czy wreszcie budżetów.


    tmf napisał:
    Nie zgodzę się też z twoją tezą o jednym UART lub jego braku. Obecnie są do dyspozycji procesory ze wszelkimi udogodnieniami, jeśli ktoś do projektu wybiera procesor z jednym UART, a nagle okazuje się 2 byłyby potrzebne, to znaczy, że od początku totalnie projekt zwalił - i tu nie ma co szukać usprawiedliwień, tylko trzeba nazywać rzeczy po imieniu. Wtedy oczywiście można robić protezy o jakich piszesz, ale nie mylmy przyczyny ze skutkiem.


    No ale na szczęście możemy mieć przecież różne zdanie. Nikt przecież na tym nie ucierpi.

    tmf napisał:
    Oczywiście nie znaczy to, że w każdym przypadku trzeba z UART korzystać - znaczy to tylko, że o ile się da, to tak jest po prostu wygodniej.


    No i z takim zdaniem w ogóle bym nawet nie zaczynał tej polemiki całej - bo to generalnie racja, pomimo to, że kwestia wygody to pojęcie bardzo względne ;) ale nie będę się spierał.


    tmf napisał:
    BTW, osobiście uważam, że używanie delay to akt desperacji i w 90% świadczy o złej koncepcji na program.


    Powiedziałbym nawet, że w 95% albo nawet w 99,99% w przypadku początkujących, dla których często zorganizowanie tak podstawowego narzędzia jak timer programowy graniczy wręcz z cudem.

    0
  • #16 08 Wrz 2011 16:39
    nsmarcin
    Poziom 12  

    Kod poprawiony teraz wygląda tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Przy czym przy deklaracji zmiennych temp, minus, temp_ulamek ustawiłem im jakąś wartość, żeby sprawdzić czy w ogóle funkcja temperatura ma jakiś na nie wpływ i okazało się, że nic się z tymi zmennymi nie dzieje, tzn są takie jak na początku i wyświetlają się na wyświetlaczu ale tak jakby albo funkcja była jakoś źle napisana, chociaż kiedyś to działało przy multipleksowaniu przez delaye (teraz nawet to nie działa) myślałem, że czujnik uwalony, ale zmieniłem na nowy i jest tak samo

    0
  • #17 08 Wrz 2011 18:05
    _Robak_
    Poziom 33  

    Proszę wszystkich o MERYTORYCZNE wypowiedzi!

    0
  • #19 08 Wrz 2011 21:59
    nsmarcin
    Poziom 12  

    Wiem, wiem volatile dodałem ale na razie chodzi mi o sam odczyt temperatury, może być co 750ms ważne, żeby tylko się wyświetlała bo póki co to nie działa

    0
  • #20 08 Wrz 2011 22:03
    snnaap
    Poziom 25  

    Przy programie który zamieściłeś to nic Ci się nie będzie wyświetlało.

    Kod: cpp
    Zaloguj się, aby zobaczyć kod




    Przy takim programie jak powyżej powinno się wyświetlacz 22,2.
    Sprawdź.
    Jeżeli jest ok od komentuj // temperatura();.

    0
  • #21 08 Wrz 2011 22:29
    nsmarcin
    Poziom 12  

    Kurcze miałem taki program ale przeoczyłem w mainie sei(); Eh... Ale teraz z kolei miga troszkę ekran, zapewne przez wyłączanie i włączanie przerwań, ale czy da się coś z tym zrobić?

    0
  • Pomocny post
    #22 08 Wrz 2011 22:52
    snnaap
    Poziom 25  

    Wiem że zaraz mi się oberwie od innych ale na szybko to pokombinuj z wartością OCR0 - zwiększ ją np do 150 , po drugie możesz przełączyć na inny preskaler mniejszy niż 256.
    Lecz nie spodziewał bym się wielkiego efektu.

    Aby otrzymać pożądany efekt musisz zmienić plik ds18b20.c i zamiast wyłączać i włączać przerwania w funkcji temperatura musisz je włączać i wyłączać przed i po _delay_us(500); znajdujących się w ds18b20.c.

    Poza tym przed
    PORTA=LedLookup[(temp/10)];
    PORTA=LedLookup[(temp%10)]|~LED_DP;
    PORTA=LedLookup[temp_ulamek];

    powinno być PORTB=0xff;
    które wyłączy wszystkie cyfry przed zmianą wartości portu A

    0
  • #23 08 Wrz 2011 22:57
    nsmarcin
    Poziom 12  

    No i pięknie, wystarczyło rzeczywiście tylko w konkretnych miejscach wstawić cli() oraz sei() i już jest tak jak powinno, a wartości OCR0 nie ruszałem, tak samo próbowałem PORTB=0xff bądź 0x0f (bo mam pierwsze cztery piny zajęte) ale nic nie zmienia w działaniu programu więc wywaliłem to. A swoją drogą czy PORTB=1 to nie to samo co 0xff bo kiedyś to używałem i przy PORTB=0xff były wygaszone wszystkie a przy PORTB=1 nie, nie pamiętam już dokładnie co się działo ale na pewno nie działało tak jak powinno. Czy to działa tak, że 1 to było tak naprawdę 0x01? Zauważyłem też, że co jakiś czas wyświetlają się jakieś losowe znaki na wyświetlaczu, co kilkanaście sekund (przy PORTB=0x0f częściej niż bez tego)

    0
  • #24 08 Wrz 2011 23:07
    snnaap
    Poziom 25  

    nsmarcin napisał:
    ...próbowałem PORTB=0xff bądź 0x0f (bo mam pierwsze cztery piny zajęte) ale nic nie zmienia w działaniu programu więc wywaliłem to



    To akurat powinno być.
    Bo przed zmianą cyfry na inną zmieniasz poprzednią.

    Zasada jest taka, że wygaszasz wszystkie a następnie ustawiasz wartość dla nowej cyfry i zapalasz konkretną cyfrę.


    PS. Mam nadzieje, że zrozumiałeś co miałem na myśli.

    Dodano po 5 [minuty]:

    Przed tym fragmentem

    koniecznie wyłącz przerwanie
    Kod: cpp
    Zaloguj się, aby zobaczyć kod


    a po nim włącz.

    0
  • #25 08 Wrz 2011 23:10
    nsmarcin
    Poziom 12  

    Tak myślałem właśnie :D ale to nic nie daje :/

    0
  • #27 08 Wrz 2011 23:21
    nsmarcin
    Poziom 12  

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Znaki są to po prostu jakieś losowo zapalane segmenty na wszystkich wyświetlaczach (oczywiście na pierwszym tylko minus się wyświetla ale to wynika z programu), trwa to bardzo krótko ale jest wyraźnie zauważalne. Na pewno nie są to liczby więc wyglądało by to tak, że po operacjach w switchu na zmiennych temp, temp_ulamek, minus, wartości wychodzą poza zakres tablicy LED_Lookup, ale z kolei jest niby tam blokowanie przerwania przed zapisem do tych zmiennych więc wartości powinny być ok

    0
  • #28 09 Wrz 2011 00:20
    michalko12
    Specjalista - Mikrokontrolery

    Do którym porcie masz 1W?
    Pokaz makra do sterowania migistralą.

    0
  • #29 09 Wrz 2011 08:12
    snnaap
    Poziom 25  

    nsmarcin napisał:
    ... tak samo próbowałem PORTB=0xff bądź 0x0f (bo mam pierwsze cztery piny zajęte) ... . Zauważyłem też, że co jakiś czas wyświetlają się jakieś losowe znaki na wyświetlaczu, co kilkanaście sekund (przy PORTB=0x0f częściej niż bez tego)


    Jeżeli oprócz wyświetlacza masz zajęte inne piny portu B to nie możesz używać PORTB=0x0f lecz musisz dać PORTB|=0x0f. Nie możesz również używać

    PORTB=~0x08; PORTB=~0x04; PORTB=~0x02; PORTB=~0x01;

    tylko

    PORTB&=~0x08; PORTB&=~0x04; PORTB&=~0x02; PORTB&=~0x01;


    Co masz podpięte pod PB4, Pb5, Pb6, Pb7 bo w programie tego nie widać?
    Czy nie jest to przypadkiem 1wire jak kolega powyżej pisze?

    0
  • #30 09 Wrz 2011 09:00
    nsmarcin
    Poziom 12  

    1W mam na PORTD pin 6, na porcie B mam tylko wyświetlacz

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0