Witam,
Mam problem dotyczący rejestru przesuwnego 74HC595. Układ polega na tym, że mam STM32, który kontroluje rejestr wpisanie jedynki zapala diodę. Generalnie klasyka sterowanie dużą ilością diod za pomocą mniejszej ilości wyjść. W układzie jest tylko Rejestr podpięty pod STM-a, a pod rejestr podpięte są diody z rezystorami. Przechodząc już do samego problemu wszystko ładnie mi się zapala tak jak chcę. Jednak naszło mnie zmierzę napięcie na diodzie, aby sprawdzić czy jakiś błąd się nie wkradł. I ku mojemu zdziwieniu dioda zgasła, tak jakby się układ zresetował.

Zastanawiałem się nad powodem i jedno co mi przyszło do głowy to kwestia tego, że użyłem pod procek 3,3V rejestr HC a nie HCT z niższymi poziomami logicznymi. W związku z tym ręcznie podłączyłem reset i latch pod 5V po wprowadzeniu bajtów z procka i zacząłem skrobać sondą multimetru piny i problem nie uległ zmianie. Dioda gaśnie po dotknięciu jej samej, jej opornika innych oporników diod, jak i samego rejestru, nie zauważyłem żadnej prawidłowości są sytuacje że "znęcam" się na diodą kilkadziesiąt sekund i nie gaśnie.

Zastanawiam się czy nie są to jakieś kwestie filtrowania zasilania, ponieważ jak dotknę linii zasilania to dioda również gaśnie. Nie wiem czy jest to dobry trop.

Czym takie zachowanie rejestru może być spowodowane i co zrobić, żeby przestał się tak zachowywać.

Czy miernik którym dokonujesz pomiaru jest ustawiony na pomiar napięcia?

pierwsze i podstawowe - nie dotykać palcami - to jeden z najbardziej niedorzecznych testów jakie wykonują początkujące osoby i doszukują się tu jakiegoś problemu. Dotykasz palcami elektroniki - wszystko może się zdarzyć - taka jest podstawowa zasada. Dlatego nie dotyka się palcami....

dotykanie sondą też może wywołać zakłócenie pracy układu - co w tym dziwnego? wszystko zależy od jej rezystancji itp itd a tym bardziej jak pracujesz na układach CMOS

jeśli jeszcze do tego dodać źle zaprojektowany układ , PCB i zasilanie no to masz już gwarancję dyskoteki ... Nie oczekuj zatem że uda się coś podpowiedzieć czy wyjaśnić jak ty nawet schematu nie pokażesz albo zdjęcia tego co zrobiłeś - o ile sam PCB robiłeś - czy to na jakimś zestawie startowym czy jak ? czy na stykówce popodłączane kablami - no to wtedy masz sam mega dodatkowe anteny i dotykanie samych przewodów może powodować dyskoteki - wtedy nie ma się co nawet zastanawiać.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Kol. cebulak czyżbyś wywołał taki oto efekt?
https://youtu.be/G9Ygmu7LBu4?t=1752
Generalnie chyba trzeba porządnie odfiltrować zasilanie (zarówno procesora jak i rejestru przesuwnego) i podciągnąć linie danych.

Dokładnie tutaj nawet przykład takiego zachowania - chociaż akurat w tym układzie to pożądane ale wyjaśnione dlaczego tak się dzieje. Wystarczy podciągnąć wejścia SPI do VCC

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dzięki za zwrócenie uwagi jakich głupot się dopuściłem w moim rozumowaniu.

Mam za to dodatkowe pytanie. Mam STM32 na nucleo podpiętego pod analizator stanów logicznych. I testuje działanie SPI korzystam z następującego kodu


Sprawdzam stany logiczne na analizatorze w następujący sposób daje start nagrywania wciskam reset na Nucleo a potem patrze co się wydarzyło. Jako rezultat otrzymuje


Rozumiem to w ten sposób że szumy na linii zegara z powodu restartu STM-a, wspomniane szumy są w momencie gdy już mam linie nSS w stanie niskim czy mój docelowy odbiorca ("zestaw startowy z stled316s") zaczyna odbierać dane i te szumy traktuje jako sygnał zegarowy albo robi coś jeszcze innego. Jeśli chodzi o zachowanie układu to dopiero ten drugi bajt jest przez niego odbierany. Próbowałem zrobić to na sprzętowym nSS, niestety to rozwiązanie po każdym bajcie daje na stan wysoki. Da się jakoś tego pozbyć czy może jest to normalne zachowanie druga sprawa czy takie zachowanie występuje naturalnie przy resecie a potem już się nie pojawia.

Druga sprawa jest taka, że między nSS, a pierwszym taktem zegara musi być minimalnie 1us i tutaj chodzi o to Czy powinienem dać jakiś delay albo coś innego, żeby zagwarantować takie opóźnienie w powyższym kodzie go nie ma i na analizatorze zawsze wychodzi opóźnienie około 20us. Tutaj jeszcze kwestia, że ten czas się może zmienić jak zmienię taktowanie STM-a.

panie to nie żadne szumy - tylko stan HiZ. Daj że pan podciąganie rezystorem tej linii do VCC i twoje "szumy" znikną i nikt nie będzie ich odbierał

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dzięki nie pomyślałem o tym.

Wałkując dalej temat rejestrów mam następujący układ poniżej schemat

Wszystko ładnie mi już działa, ale wpadłem na pomysł na kontrolowanie jasności diod, wszystkich na raz. W sumie udało mi się zrobić to co chciałem z wykorzystaniem procka i przerwań jak i korzystając ze sprzętowego PWM-a. Czy ktoś wymyślił inne rozwiązanie na kontrole jasności diod. Są jeszcze SCT2110 ale tu żeby kontrolować z procka jasność potrzeba cyfrowy rezystor coś jak ad5246, może da się inaczej ale nic mi do głowy nie przychodzi.

W ramach czystej ciekawości Czy następujące podejście do kontroli jasności diod ma sens?
Kontrolowanie jasności poprzez manipulowanie napięciem zasilania rejestrów za pomocą wspomnianego już wcześniej rezystora cyfrowego przed filtrowaniem takie coś jak na załączonym poniżej naszkicowanym schemacie:

o fuj zasilaniem scalaka ? że tak żartobliwie się wyrażę ... no to już sztuczka cyrkowa lepsza niż potrójne salto mortale z okrętką przez własne plecy

A nie pomyślałeś o jakimś wejściu typu ENABLE rejestru żeby na niego zapodać PWM'a ? - prościej, szybciej, łatwiej i przyjemniej ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

ad5246 jak przedstawiłeś w takiej konfiguracji ten scalak się nie nadaje,
http://www.analog.com/media/en/technica ... AD5246.pdf -> str7 > max +-5mA także sterownie jasnością ledów jako rezystor ustalający prąd leda nie ma sensu, jest to przerost formy nad treścią. W pdfie ad5246 masz wszystko z przykładami do czego np. można wykorzystać

Przecież SCT2110 jest to led pwm driver ze stabilizacją prądu zupełnie co innego niż AD5246

No Panowie panowie - toż przecież układy SCT2110 można sterować za pomocą PWM ... Jak bym to w przeciwnym razie zrobił w wyświetlaczu w Yellowbooku ?

toż na wejście OE tego scalaka można podawać PWM i po zawodach - masz pan regulację jasności jak się należy - no toż wyżej też o tym pisałem tylko pytanie wtedy było o 74HC595 ale sposób ten sam

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Zrobiłem ze sprzętowym PWM i wejściem OE w 74HC595 działa więc pomyślałem, co nadmieniłem w wypowiedzi zawierającej moje pytanie. Tak czy siak dzięki za odwiedzenie mnie od akrobacji cyrkowych.

Mam kolejne pytanie. Czy przy sterowaniu rejestrem z STM jak lepiej wybrać konfiguracje STM32+logic level converter+74HC595 czy STM32+74HCT595. A może pominąć logic level converter, niby dla wersji HC "1" jest dla 0,57 VCC, przy VCC=5V daje to 2,9V, ale już np przy 5,5V jest to 3,13V, może też nie być podane z STM-a dokładnie 3,3V i może zrobić się problem. Z mojego krótkiego doświadczenia jeśli chodzi o rejestry nie zauważyłem problemu przy wersji HC bez konwertera poziomów logicznych. Jak byłoby to rozwiązane w profesjonalnym projekcie?