Dopiero co tu rozmawialiśmy o podciąganiu przycisków itp. ale zakładam
osobny temat, bo poniższe lepiej przeczytać i wiedzieć - jako przestroga.

Sprawa dotyczy tego samego urządzenia, no ale to mniej ważne.
Ważne jest, że 2 dni straciłem na poszukiwanie perfidnego problemu.

Otóż, w poprzedniej wersji miałem takie rozwiązanie ;

klawiatura (9 przycisków) podłączonych przewodem taśmowym ok. 13cm do
PCB z procesorem (atmega128). 10 żył (9+masa).

Czyli są 2 PCB; klawiatury i procesora.
Na PCB klawiatury, równolegle z każdym przyciskiem był kondensator
100nF. Rezystory podciągające włączone w Atmedze.

I zasadniczo wszystko działało. No, poza tym jednym przypadkiem, kiedy
mi się te rezystory podciągające w MCU odłączyły, co już opisywałem parę
razy.

No i teraz - postanowiłem sobie poprawić, i zrobiłem 2 zmiany;
- dałem zewnętrzne rezystory podciągające 10K
- kondensatory 100nF przeniosłem z PCB klawiatury na PCB procesora - tuż
przy złączu taśmy, niedaleko procesora.

I co ? Niby wydawałoby się, że to nic nie powinno zmienić.
NIEPRAWDA !

Nagle okazuje się, sterownik głupieje ; podczas naciskania klawiszy
dzieją się cuda - nie zawsze, ale często program się wywala, albo sobie
przeskakuje w dowolne miejsce, albo kaszani się LCD.

No masakra. 2 dni straciłem na walkę z programem, bo myślałem, że coś
tam jest nie halo - chociaż poprzednio ten sam program był, i było ok.

Rozwiązanie ? Kondensatory !
Po wylutowaniu tych kondensatorów wszystko wróciło do normy !

Co ciekawe, zanim w desperacji wywaliłem te kondensatory, podglądałem
oscyloskopem napięcie na liniach wejściowych klawiatury - i nic
podejrzanego !

Co jeszcze ciekawsze, kondensatory blokujące, które były poprzednio na
PCB były tej samej wartości - też 100nF. Co oznacza, że kiedy ten
kondensator był "za" 13 centymetrowym kawałkiem przewodu - nie stwarzał
problemu. A podłączony blisko MCU - robi problem.

Dlaczego ? Zapewne te 100nF to za dużo, i podczas zwierania go do masy
przez "odległy" przycisk dzieją się jakieś cuda - może z prądem
wpływającym lub wypływającym do pinu procesora - dlatego podgląd
napięcia nic nie ujawnia.

W tej chwili nie mam czasu na dokładne rozgryzanie - bo mam parędziesiąt
urządzeń do poprawki :) - czyli do wywalenia tych kondensatorów...

Ale potem wrócę do tego - bo gdybym sam tego nie przeżył, to bym nie
uwierzył, że taki cyrk jest możliwy. Co opisuję ku przestrodze !

Dodam dla jasności, że MCU zasilany z 5V, zasilania do MCU doprowadzone
przez dławiki (odpowiednie) + zablokowane kondensatorami itp.
Czyli od strony zasilania jest ok - opisuję, bo oczywiście najpierw
myślałem, że coś się dzieje od tej strony.

No i teraz pytanie się rodzi - zapewne zmniejszenie tych kondensatorów
problem wyeliminuje - ale ile powinno być, i dlaczego tyle ??

do góry

W dniu 03-05-2014 19:25, sundayman pisze:

> No i teraz pytanie się rodzi - zapewne zmniejszenie tych kondensatorów
> problem wyeliminuje - ale ile powinno być, i dlaczego tyle ??

Te kondensatory nie są konieczne. W teorii mają likwidować drgania
styków. U Ciebie do tych kondensorów doszła indukcyjność taśmy i może tu
jest problem. Poprawnie napisany program nie wymaga tych kondensatorów.
Można dać jakieś symboliczne wartości np. 1n. Zbyt duże wartości mogą
sprawiać kłopoty zwiększając czas narastania / opadania w połączeniu z
rezystorami podciągającymi w uC oraz dodatkowymi indukcyjnościami w
układzie.

do góry

> Te kondensatory nie są konieczne. W teorii mają likwidować drgania
> styków. U Ciebie do tych kondensorów doszła indukcyjność taśmy i może tu
> jest problem. Poprawnie napisany program nie wymaga tych kondensatorów.
> Można dać jakieś symboliczne wartości np. 1n. Zbyt duże wartości mogą
> sprawiać kłopoty zwiększając czas narastania / opadania w połączeniu z
> rezystorami podciągającymi w uC oraz dodatkowymi indukcyjnościami w
> układzie.

Zastanawiam się, czy właśnie biorąc pod uwagę indukcyjność przewodu tam
nie powstaje jakieś ujemne napięcie, czy coś - bo sam czas narastania
chyba nie powodowałby kaszanienia się programu.

A tutaj działy się cuda na kiju - łącznie z przeskoczeniem programu
zupełnie w inne miejsca :)

Później to spróbuję przeanalizować, bo dobrze byłoby wiedzieć dokładnie
co się tam wyrabia.

do góry

On 2014-05-03 20:01, sundayman wrote:
> A tutaj działy się cuda na kiju - łącznie z przeskoczeniem programu
> zupełnie w inne miejsca :)

Do dzisiaj nie wiem dlaczego AtMega128 pomimo zastosowania absurdalnych
zabezpieczeń, włacznie z izolacja optyczna czego się dało,
kilkudziesięciu kondensatorów na zasilaniu, podciągania wyjśc
nieuzywanych, zwieszala się lub resetowała z powodu *małego* silnika
indukcyjnego metr dalej. Albo to jest naprawdę jakiś problem z
niektórymi AtMega albo dupa ze mnie a nie elektronik.

do góry

W dniu 2014-05-03 19:25, sundayman pisze:

> No i teraz pytanie się rodzi - zapewne zmniejszenie tych kondensatorów
> problem wyeliminuje - ale ile powinno być, i dlaczego tyle ??

http://mikrokontrolery.blogspot.com/2011/04/przycisk
-drgania-stykow-debouncing.html

Brak jednego rezystora. Po naciśnięciu przycisku kondensator oddaje cały
swój ładunek przez kawałek kabla, którego indukcyjność w tym przypadku
już ma znaczenie. Efekt - szpilka ujemnego napięcia.

do góry

On Sat, 03 May 2014 20:01:52 +0200, sundayman
<s...@p...onet.pl> wrote:
> A tutaj działy się cuda na kiju - łącznie z przeskoczeniem programu
> zupełnie w inne miejsca :)
> Później to spróbuję przeanalizować, bo dobrze byłoby wiedzieć
dokładnie

A klikajac lutownica transformatorową blisko układu coś się dzieje?

--
Marek

do góry

On Sun, 04 May 2014 09:03:01 +0200, Atlantis <m...@w...pl>
wrote:
> swój ładunek przez kawałek kabla, którego indukcyjność w tym
przypadku
> już ma znaczenie. Efekt - szpilka ujemnego napięcia.

zawieranie kondensatorów nie jest dobrym pomysłem, rezystancja pętli
zwarcia w takim przypadku przy 5V@100nF w czasie kilkudziesięciu ns
może wywoływać przepływy prądu rzędu 10-20A. To nie jest zdrowe dla
zestyków czy samego kondensatora, nie wspominając już o szalejącym
mcu.Zaciekawiły mnie te spontaniczne skoki w "różne miejsca
programu". Jesteś pewien, że to co nazywasz "skokami" to nie efekt
resetu i start programu z innymi warunkami początkowymi, stąd
złudzenie przeskoku do innej części kodu?

--
Marek

do góry

> Do dzisiaj nie wiem dlaczego AtMega128 pomimo zastosowania absurdalnych
> zabezpieczeń, włacznie z izolacja optyczna czego się dało, kilkudziesięciu
> kondensatorów na zasilaniu, podciągania wyjśc nieuzywanych, zwieszala się
> lub resetowała z powodu *małego* silnika indukcyjnego metr dalej. Albo to
> jest naprawdę jakiś problem z niektórymi AtMega albo dupa ze mnie a nie
> elektronik.

Jeśli chodzi o ATmega32, to takie układy pracują przy transformatorach
zgrzeawlniczych 100kVA i nic się z nimi nie dzieje. Jeśli chodzi o
ATmega128, to jedynie używałem go do prostownika 600A, gdzie włączanie
obwodu siłowego potrafiło wykrzaczyć wyświetlacz, natomiast z ATmega128 nic
się nie działo. Układy też testuję za pomocą jonizatora oraz starego sporego
stycznika - okręcam przewody wokół stycznika, dotykam jonizatorem do
obudowy. Nic złego się nie działo z ATmegami. Generalnie wszelki problemy z
ATmegami, które miałem, to były moje błędy, głównie programowe.

Jeśli chodzi o zabezpieczenie układu, to stosuję także kondensatory między
masą a PE (pisałem już o tym kilka razy). To jest naprawdę dobre i pozwoliło
mi się pozbyć problemów ze znikającym obrazem z wyświetlaczy. Wystarczy
jeden taki kondensator. W jednym z falowników, który rozbierałem producent
dał dwa takie kondensatory. Ja, na wszelki wypadek, w moim nowym układzie
dam cztery w różnych miejscach. Mam to szczęście, że mam do dyspozycji PE,
ale nie każdy ma taką dogodność (na przykład twórcy układów zasilanych z
baterii).

Robbo.

do góry

On 2014-05-04 13:30, Robbo wrote:
> Jeśli chodzi o ATmega32, to takie układy pracują przy transformatorach
> zgrzeawlniczych 100kVA i nic się z nimi nie dzieje. Jeśli chodzi o
> ATmega128, to jedynie używałem go do prostownika 600A, gdzie włączanie
> obwodu siłowego potrafiło wykrzaczyć wyświetlacz, natomiast z ATmega128
> nic się nie działo.

U mnie było tak:

Miałem kilka wariantów płytek pod Atmega8l. Niezawodnie działało przez
lata klepiąc stycznikami, sterują silnikami w środowisku "przemysłowym"
w odległościach centymetrowych od źródła szumu. Miałem licznik w
watchdogu ile razy się zresetował. Nie resetował się przez miesiące.

Pewnego dnia skończył się flash i trzeba było przeprojektować pod
atmega128 (bo jak zrobić to raz a dobrze, w dodatku 128 jest jakoś
śmiesznie tani). W zasadzie żaden problem, wszystko zostało to samo,
tyle że więcej kondensatorów i wiecej lini do podciągnięcia. I zaczely
się jaja (a program praktycznie ten sam poza adresami rejestrów).
Zmniejszyłem w końcu clock do 1MHz i analizowałem co się dzieje. Program
wskakiwał w przypadkowe miejsca w momencie klepnięcia przekaźnika tak
jak gdyby przestawiały się pojedyncze bity rejestru wskaźnika
instrukcji. Sprawdzilem kilkadziesiąt razy połaczenia i żadne nie
wisiało, wszystkie zasilania perfekcyjne. Myśle - pewno szpilki w
zasilaniu. A gdzie tam, albo mam za wolny oscyloskop albo nie było
żadnych szpilek. Potem poszly meotdy drastyczne: zasilanie z akku,
izolacja optyczna co się dało itd, najdłuższy przewód miał ze 2cm. Dalej
zalaczenie przekaźnika w silniku obok powodowalo pewne
prawdopodobieństwo wskoczenia w krzaki. Tak po prostu. Pomyślałem:
jestem dupa nie elektronik. Wziąłem cudzą płytkę prototypową z mega128,
zasilaniem z baterii i po kilku załaczeniach silnika - bum.

Obok pracujący Mega8 ani się nie zająknąl mimo znacznie gorszych
warunkow pracy.

IMHO problem jest w krzemie. Tym bardziej że internety też gadały o
badziewności krzemu 128.

PS. Lutownica transformatorowa też powoduje przeskoki, ale bardzo
rzadko. W zasadzie przyłapałem 2x na skoku w krzaki przy machaniu przez
kilka minut wlaczona lutownicą. Soft byl tak przygotowany aby cała
pamięć wypełnić poleceniem ustawienia gdzieś na porcie 1 a główna pętla
nie miała prawa wyjść. I wychodziła ...

Nie stosuje już 128. Byc może to moja wina, ale kilka PCB *akurat* nie
działają 128 a działają wszelkie inne. Dziwne. Ba, pająk z SAM7 zrobiony
byle jak nie zresetował się ani razu pomimo że to jednak rząd wyżej
komplikacji i więcej krzemu.

do góry

a gdybyś wywalił kwarc i dał generator?

do góry