Ustawienie pinu jak wyjście HS przy starcie programu

[ethanak]

14 godzin temu, atMegaTona napisał:

lepsza niż fast digidigi

Z ciekawości: czym się różni

PORTB |= _BV(2);

od

digitalWriteFast(2,1);

 

[Anonim]

Nie używałem tego nigdy, wolę asm bo mam pewność, że tak jest jak chce na już a nie w rezultacie. Można to podejrzeć w pliku *lss którego arduino nie generuje domyślnie i nie wiem jak to zmienić żeby zaczęło. Ale można włączyć samemu program avr-objdump z opcją -S na pliku *elf

../arduino-1.8.10/hardware/tools/avr/bin/avr-objdump -S "../TMP/arduino_build_xxx<-nr_kompilacji/nazwa_skeczu.ino.elf"

 

Poza tym jakiego byś nie użył sposobu to i tak nie będzie szybciej niż inicjalizacja w podsekcji .init

[daniel89]

Mi to się wydaje że to co ja piszę nie bardzo przez Marka jest rozumiane i zaczyna tutaj wypisywać jakieś książkowe wypowiedzi. Gdzie napisałem że na wyjściu z trafo jest 5V ? Na wyjściu ze stabilizatora jest ponad delikatnie 5V i to jest normalna praca , wszystko działa przecież pisałem. Trafo jest 230/6V-8V prądu zmiennego. Jedynym problemem jest ta szpilka napięcia i to właśnie zmierzę - Stan na wyjściach mikroprocesora. Rozwiązanie hardwarowe nie leży po stronie zasilania układu bo układ działą poprawnie . tutaj chodzi tylko i wyłącznie o to co podaje mikroprocesor na wyjściu . Mogę jeszcze zmierzyć jakie zasilanie dochodzi do mikroprocesora w momencie startu układu jeśli to co kolwiek pomoże ... Zobaczę też czy kondesnator pomoże i czy zamieniając na sterowanie stanem wysokim ten problem zniknie ... Oczywiście najpierw sprawdzę czy softowo się nie uda tego poprawić .

Edytowano Grudzień 3, 2019 przez daniel89

[Anonim]

Ze strony software'owej szybciej się już nie da, ale tak jak już było wspomniane niewiele to pomoże jeśli nie wywalisz bootloadera z tego arduino. Jeśli masz programator choćby najtańszy do AVR to problemu nie będzie.

Rozumiem, że chodzi o to, że podczas włączenia zasilania tranzystor się włącza na chwilkę? Można też pomyśleć, żeby dobudować układ soft start do zasilania ale do tego jest konieczna ingerencja w schemat. 

Edytowano Grudzień 3, 2019 przez Anonim

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

"Mostek oddaje delikatnie ponad 5V DC"

Jak miałem to zrozumieć?

[ethanak]

Tak się zastanawuam (nie wiem czy dobrze, bo schemat jest  chyba nieco niekompletny, prxynajmniej na komórce nie widzę X2).

Startuje atmega. Na pinie jest trzeci stan, czyli dioda w optotriaku nie jest zasilana. Jest OK.

Pin jest na dzień dobry w trybie INPUT. Teraz robię digitalWrite(pin, 1) - w efekcie podłączany jest wewnętrzny rezystor podciągający. Na pinie mam słabą jedynkę, ale dioda (zasilana przecież prądowo) dalej się nie pali.

Teraz ustawiam pin na OUTPUT. W efekcie powinienem na pinie uzyskać twardą jedynkę. Dioda (zasilana prawdopodobnie z Vcc i pinu) dalej się nie pali...

Ciekawe, czy taka proteza (bo to oczywista proteza) zadziała...

[marek1707]

Tak, to rozwiązanie które powinno być stosowane, ale już o tym pisaliśmy. Kolega rzeczywiście robi odwrotnie, ale powstająca w ten sposób szpilka ma kilka us. A potem napisał, że odwrócenie kolejności zapisów (czyli postulowane przez Ciebie najpierw PORTx a potem jego DDRx) nie pomaga..

Edytowano Grudzień 3, 2019 przez marek1707

[ethanak]

A to nie zauważyłem że się powtarzam - przepraszam.

Czyli mamy typowy błąd w projekcie, którego żadnym protetycznym softem nie da się poprawić. Cóż - zdarza się, nie raz wywalałem do kosza bardzo wspaniałe (tak mi się wydawało) kody, różne niemniej wspaniałe płytki leżą mi w pudełeczku i przypominają o tym, że najpierw się trzy razy sprawdza, potem dla pewności czwarty i piąty, a potem można liczyć na to, że dane ustrojstwo będzie działać...

No, ale ja to taki nietypowy jestem 😞

[marek1707]

No właśnie chyba nie. A przynajmniej ja tu oczywistego błędu nie widzę. Wyjścia z procka są zrobione poprawnie a program - jeśli tylko nie zrobi czegoś głupiego - nie powinien generować szpilek na wyjściach. Tym dziwniejszy jest objaw i tym łatwiej przyczepiłem się do problemów z zasilaniem bo to właśnie wygląda jak tego typu sprawa. No nic, czekamy aż Kolega @daniel89 coś pomierzy i pokaże wyniki z zimnego startu. Być może gdzieś dalej w kodzie dzieje się coś dziwnego, ale zawsze można zrobić próbę z wykasowanym procesorem. Taki "program" ba pewno nie rusza portów. Wtedy włączyć urządzenie kilkadziesiąt razy i próbować zaobserwować szpilkę oczywiście wciąż mając podpięty i uzbrojony oscyloskop. Jeśli w takim zestawie nic się nie wydarzy, to można zacząć dodawać kawałki kodu, począwszy od inicjalizacji właśnie linii I/O. Dobrze przeprowadzona także nie powinna wygenerować żadnej szpilki. Być może problem leży zupełnie gdzie indziej, np. długie przewody i bliskość transformatora 230V/50Hz powodują, że w chwili wkładania wtyczki do gniazdka na kabelku do transoptora robi się ten 1V i zapala IREDa, albo program nie jest taki jak nam się wydaje... W sumie zagadkowa sprawa, nie wiemy wszystkiego i trzeba trochę improwizować.

[Anonim]

Zgadzam się, w obu kwestiach. Najpierw trzeba ustawić stan, później kierunek. Cóż, być może przypisywanie do .init łamie konwencję arduino ale ona w zasadzie jest tak ustalona chyba po to właśnie żeby ją łamać 😉

[Anonim]

Najlepiej będzie zrobić test na pustym procku. Będzie przynajmniej wiadomo czy to wina inicjalizacji. Jeśli tak to najpier PORT a później DDR i będzie maksymalnie najszybciej, można też zmienić sekcję na .init0 o czym wspomniał @RFM ale nie było jeszcze wtedy widać jego postów. Jeśli jednak nie to jedyne co zostaje to jakieś pojemności spowalniają narastanie napięcia na bramce albo transformator ma defekt.

[daniel89]

Kod kolegi atmegatona dalej nie działa.  Wyniki z oscyloskopu tylko mnie upewniły że sterując stanem wysokim uniknął bym tego typu problemu.  Z zasilaniem faktycznie idzie delikatna szpilka przy starcie mimo kondensatora 100nF blisko zasilania

Pierwsze zdjęcie od góry to właśnie na wyjściu przelaczanie na stan wysoki z low zajmuje jakieś 20ms i pełza to napięcie.  Przy normalnej pracy zawiera do masy na 20ms i jest to okej. Potem kolejne próby pomiaru tego stanu na tym piwie i pomiaru zasilania ta ciągła linia widać tam szpilkę.

[Anonim]

Dnia 2.12.2019 o 15:22, marek1707 napisał:

• Po narośnięciu zasilania reszta układów wokół procesora już działa - czas start. Procesor stoi w stanie RESET wymuszonym przez wewn BOR i/lub specjalny licznik- ten czas ustawiasz fusami, plus czas startu generatora. RC jest najszybszy a oscylator ceramiczny używany w Arduino - duużo wolniejszy.
• Po wyjściu z zerowania rusza bootloader Arduino i sprawdza czy na uarcie jest jakaś komunikacja z PC - to mogą być setki milisekund.
• Jeśli kontakt nie został nawiązany, bootloader startuje aplikację
• Ta zaczyna od inicjalizacji swoich podstawowych rejestrów i zmiennych oraz zmiennych w obszarze data programu w C - to w małym procesorku trwa dziesiątki mikrosekund, nie ma o czym mówić.
• Potem następuje wywołanie funkcji main() a ta na dzień dobry odpala setup() gdzie możesz ustawiać do woli swoje piny.

Tak dla przypomnienia. 

1 godzinę temu, daniel89 napisał:

Kod kolegi atmegatona dalej nie działa.

Kod działa na pewno, to układ nie działa zgodnie z założeniami a dlaczego nie działa tak jak powinien to Marek wypunktował po kolei. Procesor ma za wolny start. Mimo, że piny są z domniemania ustawiane jako wejścia to jakąś rezystancję ten pull-down w pinie jednak ma i na out robi się dzielnik napięcia stąd to "pełzanie" na pojemności tranzystora jak mniemam. Co prawda można jeszcze przyspieszyć start procka przez odpowiednie ustawienia fuse-bitów to raz, wywalenie bootloadera to dwa, wtedy procek od razu włączy Twój program i pierwsze co w nim zrobi to wykona "mój kod" ale zanim procek wystartuje to i tak minie jakiś czas i tego nie przeskoczysz choć w tym przypadku mogłoby to rozwiązać problem a co najmniej go zredukować.

Zostaje jeszcze rozwiązanie sprzętowe, czyli można uruchomić procesor wcześniej niż resztę układu ale to wymaga przebudowania jego części a tego nie chcesz więc możesz spróbować przyśpieszyć włączenie procka biorąc pod uwagę wszystkie powyższe uwagi zawarte w tym wątku i.. przyzwyczaić się do faktu, że ten układ nie jest idealnie doskonały.

[marek1707]

Ja się poddaję. Kolega @daniel89 używa oscyloskopu jak cepa i jakoś nie widzę płaszczyzny porozumienia. Nie zrobiłeś żadnej z rzeczy o które prosiłem. Ani nie widzę dwóch przebiegów na raz więc nadall nic nie wiemy o koincydencji sygnałów które mierzysz (czyli najwazniejszego: kiedy stan niski się pojawia), ani nie korzystasz z całości ekranu w pionie tylko bawisz się w jednej kratce, ani nie ustawiłeś wyzwalania jak prosiłem, ani nie usunąłeś tej idiotycznej tabelki z liczbami i nawet sondę masz podpiętą jakoś od czapy, bo sądząc ze skali pionowej widzimy sygnały o wielkości <1V. Dostałeś drobiazgową instrukcję co poustawiać i nie wysiliłeś się żeby ją wykonać. Ja tam nie widzę żadnej szpilki, bo chyba nie mówisz o zakłóceniu od wkładania wtyczki, jeszcze przed pojawieniem się jakiegokolwiek napięcia. Widzę zamiast tego stan niski wymuszony na 100% przez program, bo trwający prawie 40ms. Nie, nie jest to nic związanego z upływnościami (procesory aż takich nie mają by pokonać opornik kilka kilo) ani pojemnościami czegośtam. To twarde zero - o ile oczywiście mierzyłeś na pinie procesora bo nawet nie chciało Ci się napisać skąd każdy sygnał był zdjęty. Acha, i przypominam, że do łapania szpilek (o ile w ogóle tam są) służy tryb akwizycji Peak Detect (pod przyciskiem Acquire) a nie standardowy Sampling. I warto w takich zabawach ograniczyć pasmo fukcją BW Limit. Może w wolnej chwili poczytaj coś o oscyloskopach w ogóle, a przynajmniej instrukcję do tego Rigola? Wiesz podstawy obowiązujące od czasów sprzętów lampowych: czym się różni NORMAL od AUTO i od SINGLE, tryby wyzwalania (najważniejsze oręże osyloskopu) i akwizycji, itd.. Bez tego nic ciekawego nie zobaczysz a losowe zdjęcia nie posuną Cię ani o krok w kierunku znalezienia przyczyny problemów. To jakbyś próbował wykopać rów nie wiedząc z której strony i jak trzymać łopatę. Przykro mi. Jeśłi pokażesz przebiegi o jakie prosiłem możemy wrócić do dyskusji.

[Chumanista]

A jak włożysz pendrive w to USB z przodu to będziesz mógł robić zrzuty ekranu tym przyciskiem z drukarką a nie wrzucać zdjęcia z pomarańczy zamontowanej na wentylatorze.