LC 531 i SN74141 problem

[mpestkow]

Witam wszystkich,

To mój pierwszy post, ale mam nadzieję, że uda mi się uzyskac odpowiedź na moje pytanie. Jestem początkujący jeśli chodzi o elektronikę i lampy, ale zacząłem własną edukację w tym kierunku. Jako jeden z pierwszych większych projektów postanowiłem zbudowac zegar Nixie. Posiadam 4 lampy LC-531 wymontowane z multimetru Unitry. Działają ok jeśli podłączam je do źródła HV (stosuję przetwornicę 9V -> 150-220V schemat). Do zasilanai używam 180-190V oraz rezystor 10k od strony anody (mam nadzieję, że taki jest ok (działało równiez z 47k).

Kilka dni temu w końcu udało mi się zdobyć SN74141 i próbowałem go przetestować. Więc podłączyłączyłem wszystko używając ATtiny2313 w ten sposób:

i zaprogramowałem mikroklocka tym kodem:

Kod: Zaznacz cały

#include <avr/io.h>
#include <util/delay.h>

int main()
{
	DDRB = 0x0F;

	while(1)
	{
		PORTB = 0x00;

		for(int i=0;i<10;i++)
		{
			_delay_ms(2000);
			PORTB+=1;
		}
	}

	return 0;
}

Jak widać chciałem aby na lampie wyświetliły się cyfry od 0-9 zmieniając się co 2 sekundy.

Dwa razy sprawdziłem wszystkie połaczenia i w rezultacie zamiast działac jak się spodziewałem, zaświeciły się wszystkie cyfry na jednej lampie.

Wydaje mi się, że 74141 jest w porządku, bo spróbowałem do wyjść podłączyć diody LED (+ do 5V i - do wyjść układu) i działało prawidłowo (zapalały się jedna po drugiej we właściwej kolejności.

Jakiekolwiek sugestie co robię nie tak? Brakuje mi czegoś w schemacie, podłaczyłem coś źle, a może to wina kodu?

Pozdrawiam,
MP

[_idu]

Sprawdź sam 74141 z lampą Nixie podając różne dane na wejścia BCD scalaka. Jeśli będzie OK to winnym jest wystawianie danych na porcie kontrolera. Krótkotrwałe złączenie innych segmentów w wyświetlaczu LED może nie dać widocznego efektu ale spowoduje zapłon w Nixie który potrzebuje czasu by zgasnąć.
Czyli wg mnie może być konieczny zatrzask danych aby przekazać już gotowe dane do 74141 a nie wszystkie stany przejściowe zanim mikrokontroler a raczej jego program wystawi kombinację danych BCD.

[Einherjer]

STUDI Z tymi stanami przejściowymi to trochę przesadziłeś. Mogą się pojawić duchy przy multipleksowaniu, ale nixie nie są tak szybkie, żeby przy statycznym wyświetlaniu reagowały na jakieś stany przejściowe portów uC, zwłaszcza że tu nie ma jakiegoś zmieniania kierunkowości portów itd. Żadne zatrzaski nie są potrzebne. Ja zwykle w takich sytuacjach wystawiałem na wyjście uC na stałe jakąś wartość na zasadzie:

Kod: Zaznacz cały

while (1){
   PORTB=0x05;
}

Można wtedy zobaczyć czy faktycznie wyświetli się 5, a jeśli nie to na spokojnie nawet multimetrem posprawdzać stany na wyjściach uC i 74141. W Twoim przypadku stawiałbym na uszkodzony 74141.

[Tomasz Gumny]

Jeśli zapaliły się wszystkie cyfry, to albo 74141 wystawił na wszystkich wyjściach Q0..9 stan niski, albo cyfry zapalają się kolejno, tylko zbyt szybko, aby to zauważyć. Pierwszy przypadek może wystąpić przy uszkodzonym lub niezasilanym dekoderze 74141. Drugi wskazuje na błędną lub brak deklaracji zegara systemowego.
Wyciągnij procesor i podaj masę na kilka wejść DCBA tak, żeby stan był <10 i zobacz czy wyświetli jakieś cyfry.

[mpestkow]

Dzięki za propozycje. Jak pisałem diody LED podłaczone pomiędzy 5V i nóżki 74141 zachowywały się prawidłowo (każda zapalała się na 2 sekundy). Rozwiązaniem problemu okazało się: zmiana opornika na 47k oraz zmniejszenie napięcia do 170V (przy wyższym efekt znów się pojawiał). Problem rozwiązany

[_idu]

STUDI Z tymi stanami przejściowymi to trochę przesadziłeś.

Nie znam szczegółów kompilacji / interpretacji kodu przez narzędzie. Bardzo łatwo jest napisać program tak że zanim wystawi pożądane stany na portach przez np. kilka cykli stany na portach szaleją (niekiedy kompilator/interpeter sam o takie zachowanie "zadba"). Miałem tak ze prostym sterownikiem PLC klasy smart relay i programem w FBD. W symulacji było OK, ale w rzeczywistości zachowanie było nieprzewidywalne. Trzeba było zastosować bardziej rozbudowana logikę i problem zniknął. Niestety w rzeczywistości procesor zachowywał się zupełnie inaczej niż symulowany. A niestety z racji braku zasobów układ niestety wymagał nieco "hazardowych rozwiązań" aby się zmieścić z kodem w możliwości PLC.

Dodam jeszcze że producenci procesorów nie zawsze wszystko ujawniają. Tak sie sparzyłem na dwukrotnie większym zegarze dla Amigi. Nie było wyjaśnienia czemu 5% przełączeń powoduje zatrzymanie procesora(przy próbie zachowania taktu zegara E). Żaden datasheet nie zawierał (i nadal nie zawiera) pewnej drobnej informacji pomagającej to wyjaśnić / usunąć. Dopiero pewna książka o tej rodzinie procesorów z adnotacją, że niewolno jej posiadać i używać poza terytorium USA i Kanady dała wyjąśnienie oraz najważniejsza informację jak naprawdę pracuje interfejs układów rodziny 6800. Mała poprawka (dodatkowe dwa scalaczki) i było już 100% pewne. W żaden sposób nie oczywista opierając się na oficjalnych informacjach Motoroli.
.