Ten sam program, ten sam procesor, a różne działanie.

Cześć.

Zaciekawiła mnie jedna rzecz.
Dzisiaj programowałem kilkadziesiąt uC Attiny13.
Na kilku z nich ten sam program działa nieco inaczej.
Myślałam, że to przez rozbieżność w taktowaniu wewnętrznego oscylatora, ale...

Różnica choć minimalna, to powtarza się idealnie.
Tzn. Jeśli trafiają się uC na których działa inaczej, to na tych wszystkich jest idealnie tak samo źle.

Wygląda to tak, jakby program od czasu do czasu wgrywal się z jakimś błędem.

Nic poważnego i może tak działać, ale zżera mnie ciekawość.

A fusebity tak samo skonfigurowane?

Wszystko identycznie.
Podpinam wtyczkę pod kolejne urządzenia, wgrywam ustawienia Fuse, Lock i program.
Po wgraniu każde sprawdzam no i właśnie wychwyciłam w niektórych delikatną, ale powtarzalną różnicę.
To prosty kontroler serwa modelarskiego.
Realizuje powolny ruch między dwiema pozycjami i o ile jedna z nich jest zawsze tam gdzie ma być, to druga pozycja czasem nieco się różni, ale zawsze różnica jest taka sama.

Jeśli wyniki są zależne od f oscylatora wewnętrznego, to wiedz, że kalibracja fabryczna ma dokładność +/- 10% i f jest zależna od temperatury otoczenia i napięcia zasilania. W skrajnych przypadkach (zabawy z kalibracją) zapis do Flasha i EEPROM mogą przestać działać.

Nie zdążyłam przed Tobą, przeczytaj post wyżej.
Gdyby chodziło o f.osc, to obie by się rozjeżdżały i różnice nie były by powtarzalne (tak myślę)

Środek serwa mam ~3600, jedna skrajna która mnie interesuje to 1200, druga 6000.
O ile 6000 zawsze się zgadza, to dolna w niektórych przypadkach wymaga korekty na 1100.

Tak w skrócie.

Zdaje się, że serwa modelarskie sterowane są szerokością impulsu, więc przy problemie z f.osc w pozycji serwa, w której szerokość impulsu jest największa problem byłby bardziej zauważalny, ale też pozycja środkowa będzie z błędem (ok. połowa błędu pozycji skrajnej). Zauważyłaś coś takiego?

Sygnał dla serwa to wypełnienie impulsu. Okres coś chyba 2ms a środek serwa to 1,5ms przy czym najmniejsze wychylenie przy 1ms. Tak więc przy prawie pełnej skali może różnicy nie widac a widać tylko tę bliżej nizszych wartości.

W rozwiazaniu zagadki zacząłbym od prostego pomiaru czestotliwości


Bierzesz te dwa rózniace się przypadki i patrzych czy nie ma różnicy w częstotliwości czyli jak daleko różni się od 9,6MHz/2 (albo 1,2MHz/2 z CKDIV8).
Powinno się coś wyjasnic a na pewno bedzie mozna coś juz wykluczyć zamiast zakładać.

Można potem sobie skalibrować jakąś wartością OSCCAL = 128 itp.

Te wewnętrzne oscylatory są niedokładne do tego stopnia, że ostatnio na wewnętrznym 8MHz w Atmega16 nie mogłem się dogadać po serialu 38400 bo predkość faktyczna była 40000 i w terminalu tylko krzaki.

bart-projects napisał:

Te wewnętrzne oscylatory są niedokładne do tego stopnia, że ostatnio na wewnętrznym 8MHz w Atmega16 nie mogłem się dogadać po serialu 38400 bo predkość faktyczna była 40000 i w terminalu tylko krzaki.

Czyli zachowuje się dokładnie tak, jak to opisane jest w nocie.Dopiero nowsze AVRy - XMEGA i nowe ATMega oraz AVR Dx mają wewnętrzny zegar na tyle stabilny, że w wielu przypadkach można go użyć dla transmisji asynchronicznych.
@Justyniunia Wrzuć kod, może masz jakiś nieoczywisty błąd. Chociaż teoria o różnej kalibracji zegarów jest bardzo prawdopodobna. Może być tak, że masz dwie serie procków, które są fabrycznie tak kalibrowane, w efekcie w ramach serii mają taką samą odchyłkę. Dlatego właśnie warto uważnie czytać noty, tam masz dokładnie opisane jakie są tolerancje zegara i jak się zmienia f w funkcji temperatury i napięcia. Warto to uwzględnić, bo potem są różne kwiatki.

Wychodzi na to, że to jednak temperatura i częstotliwość.
Teraz podłączyłam sterowniki, które leżały przez noc przy oknie na parapecie (zimne) i te których pozycje się rozjeżdżały - rozjeżdżają się jeszcze bardziej.
W skrajnych przypadkach serwo zahacza o wewnętrzną blokadę
Po delikatnym podgrzaniu wracają do normy.

Muszę po prostu zawęzić trochę te wartości w programie.

Zmierzę z ciekawości f, ale strzelam, że będzie znacznie różna.

Ciekawostka (nie związana z tematem).
Uwaliłam jeden stabilizator (VIN ~ Vout), Zasilacz byl ustawiony na jakieś 9V.
Serwo szlag trafił, Attiny żyje i ma się dobrze
Dość długo poddany był takiemu napięciu zanim doszłam dlaczego serwo stoi i tyka, a przycisk i kontrolki normalnie działają.

AVR ciężko ubić. Ostatnio podłączyłem AVR128DB32 (w TQFP) odwrotnie +/- i tak sobie siedział podłączony do USB które na szczęście miało tylko 500mA i zabezpieczenie.
Procesor był tak gorący że się sam wylutował z plytki i jak go dotknąłem paluchem to się przesunął a ja się oparzyłem.
Po wlutowaniu i poprawnym połączeniu działa do dzisiaj. Do tej devboard wlutowałem sobie na wszelki wypadek zaporowo diodę która zewrze zasilanie gdy jeszcze raz się pomylę, chociaż nie podejrzewam bo palec bolał długo

Test "hota i lodówki" jednoznacznie potwierdził duży wpływ temperatury na działanie.

Miałeś rację, górna granica ucieka (zmniejszałam wartość) dolna jest zawsze ok.

Taki OT jak już tu jesteśmy.
Czy dobrze rozumuję, że reset można wykorzystać jako port, ale musimy być pewni co do działania programu, bo później nie ma już odwrotu (tylko fusebit doctor)?

Czy polega to na czymś innym.

Raczej tylko Doctor
Bawiłem się tym przy projekcie HID klawiatury multimedialnej (sterowanie głośnością PC z Tiny85) i właśnie potrzebowałem jeszcze jednego pinu.


Przywracałem funkcjonalność Resetu wielokrotnie zanim wszystko "zagrało" właśnie programatorem HVSP.

Tiny85 jest ciekawy bo można go też taktować z zegara peryferii który ma 64MHz więc teoretycznie USB powinno ruszyć i bez kwarca 12MHz, ale to działało chimerycznie.
Tak samo DigiSpark nie działa z każdym portem USB.

bart-projects napisał:

Po wlutowaniu i poprawnym połączeniu działa do dzisiaj. Do tej devboard wlutowałem sobie na wszelki wypadek zaporowo diodę która zewrze zasilanie gdy jeszcze raz się pomylę,

Lepiej użyc P-MOSFET - praktycznie zerowy spadek napięcia i straty. Te 0,3-0,6V spadku na diodzie może robić różnicę, jeśli MCU łączysz z układami zasilanymi spoza tej diody. Wtedy masz na dzień dobry przesunięcie napięć, poziomów logicznych itd. Jak to zewnętrzne napięcie wzrośnie jeszcze bardziej, to nagle się okaże, że diody zabezpieczające wejścia MCU zaczną przewodzić, rosną straty i robią się cuda.

U mnie tak jest.
Wszystko zasilone z 1117-5.0, ale serwo bezpośrednio, a napięcie do uC idzie przez 4148 no i 10uF do gleby żeby wyeliminować wpływ obciążenia na działanie uC.
Nawet chwilowe przytrzymanie serwa mechanicznie nie wpływa na działanie programu.

Może źle się wyraziłem. Diodę wlutowałem pomiedzy plus i masę Zwarcie zrobi dioda a nie uC Rozwiązanie z mosfetem znam, ale nie wiem czy tu by się sprawdziło jak podłączam się z 5V równolegle bezpośrednio do uC

Wiem że koleżance zależy często na rozmiarach układów bo to najczęściej pracuje przy makiecie kolei (semafory itp). Tak więc z takich maluchów ośmiopinowych to Attiny212 i Attiny214 oferują możliwość wykorzystania pinu RST jako I/O a nawet wejście ADC i to z poziomu programu. Programatora kupować nie trzeba bo programuje się je zwykłym konwerterem USB<>USART
Jak z Microchip - im nowszy układ tym tańszy i one są po 3zł więc tańsze od starszych.

Tak tak, rozumiem.
Twoja dioda zabezpiecza przed odwrotna polaryzacja robiąc zwarcie na zasilaniu w razie W.
To było do wpisu Kolegi @tmf

bart-projects napisał:

i właśnie potrzebowałem jeszcze jednego pinu.

Miałeś jeszcze 2 dodatkowe. Kwarc do USB tam nie jest potrzebny. Wystarczy wbudowany RC + prosta kalibracja automatyczna.

Justyniunia napisał:

Taki OT jak już tu jesteśmy.
Czy dobrze rozumuję, że reset można wykorzystać jako port, ale musimy być pewni co do działania programu, bo później nie ma już odwrotu (tylko fusebit doctor)?

Tylko po co? skoro można brakujący pin 'odzyskać' używając generatora zamiast kwarcu i ustawiając w fusach zewnętrzne taktowanie. Tym bardziej że teraz generatory sa taki same lub mniejsze od kwarców obudową.
A co do wątku głównego, mam ciekawszy przypadek, na attiny861 zrobiony generator 3F PWM na sinus na timerze 1 pracujący w przerwaniu przepełnienia timera, a w pętli głównej w poolingu startowanie i odczyt ADC z 2 kanałów naprzemiennie przełączanych. Inie ma odczytu z 0 czyta tylko 1, jak dodam delay-a 100uS to działają oba, jak go skrócę to zaczyna się krzaczyć główny przebieg, na razie temat odłożyłem ale wrócę i opiszę to w osobnym wątku bo to naprawdę ciekawostka.

Rany Boskie... Po co, po co...
Pytanie teoretyczne.
Nie znasz układu, procesora, nic, a piszesz o wywaleniu kwarcu.
Tam JUŻ nie ma kwarcu!
W innym projekcie potrzebuję 3 IN i 3 OUT z Attiny13 i po to pytam.
Mogę zrobić trzeci przycisk (K3) programowo, rozdzielić diodami i podać na raz na K1+K2, ale mogę też użyć PB.5, tylko nie wiem, co będzie prostsze.

Justyniunia napisał:

Rany Boskie... Po co, po co...
Pytanie teoretyczne.
Nie znasz układu, procesora, nic, a piszesz o wywaleniu kwarcu.
Tam JUŻ nie ma kwarcu!

Spokojnie, wyluzuj, odniosłem sie do schematu

bart-projects napisał:

Przywracałem funkcjonalność Resetu wielokrotnie zanim wszystko "zagrało" właśnie programatorem HVSP.

Justyniunia napisał:

Nie znasz układu, procesora, nic, a piszesz o wywaleniu kwarcu.
Tam JUŻ nie ma kwarcu!

Ale ci bruździ jego brak.

Gdyby było to takie ważne, to byłby inny uC i kwarc/generator.
Na szczęście nie jest i wystarczyło ograniczyć ruch, żeby mieć zapas w razie duzych różnić/rozbieżności.

Nie mam niestety w mojej wersji Tiny212 i podobnych nowszych kontrolerów, a informatyk że mnie słaby.
Zaraz zacznę coś pobierać, to pewnie wszystko przestanie działać

Justyniunia napisał:

Nie mam niestety w mojej wersji Tiny212 i podobnych nowszych kontrolerów, a informatyk że mnie słaby.

Jego byś i tak nie zaprogramował bez nowego programatora obsługującego UPDI, a sam procek ciekawy, ma np 4 różne timery

Justyniunia napisał:

Mogę zrobić trzeci przycisk (K3) programowo, rozdzielić diodami i podać na raz na K1+K2, ale mogę też użyć PB.5, tylko nie wiem, co będzie prostsze.

Oczywiście że diody.

Dodano po 3 [minuty]:

Przy większych brakach nóg ja bym przeszedł na attiny24, bardzo podobny programowo a daje większe możliwości, ma 14 nóg, -2 na zasilaniu, reset i 2 na kwarc zostaje ci 9 nóg.

Janusz_kk napisał:

Jego byś i tak nie zaprogramował bez nowego programatora obsługującego UPDI

Jesteś w błędzie. Programuję je bardzo często zwykłym konwerterem USB<>SERIAL łącząc w nim TX poprzez rezystor 2K2 z RX i to wystarczy. Śmiga do 1.6Mb/s Można tym też ustawiać FuseBity na przykład wyłączając RESET a uC wygodnie resetować sobie też tym interfejsem z PC`eta podczas testów.

bart-projects napisał:

Jesteś w błędzie.

No nie.

bart-projects napisał:

Programuję je bardzo często zwykłym konwerterem USB<>SERIAL łącząc w nim TX poprzez rezystor 2K2 z RX i to wystarczy.

Ale to coś innego niż isp, opisałeś bieda UPDI. Więc się nie myliłem.

Dobra, bo nic nie rozumiem co piszecie . Takie pytanko.
Co bym potrzebowała żeby się przesiąść na te nowe uC?
Działam w Bascom i to MUSI zostać, do tego mam MKAVR (tam ustawiam Fusy) i USB ASP

(proszę nie komentować, ani języka, ani sprzętu, na tym działam i już).

Rozumiem, że nie ma już MISO, MOSI, CLK itd? Będzie to działać na tym co mam?

Na stronie MCS nie mogę się za cholerę zalogować, żeby pobrać aktualizację (o ile jest jakaś dla tych uC)
Widzę, że mam 2 konta, więc już raz logowałam się awaryjnie.
Chyba pozostaje mi kupić kolejny program...

@Janusz_kk
Tiny24, 84, mam, stosuję, ale cenowo > Tiny13, a w 13 na razie się wszystko mieści (flash), dwie diody do trzeciego guzika raczej bardziej niż Tiny24, bo to i większa płytka i cena.

Z aktualizacją Bascom to chyba wystarczy jak napiszesz do <support@mcselec.com> podając numer licencji która się Tobie wyświetla w oknie "About". Przypomną Tobie albo ustawią nowe hasło. Od pewnej wersji działa update prosto z programu.

Niemniej do programowania Xtiny/AVRX/MEGAX to potrzebny jest osobny addon.
Kiedy wyszły Xmegi do dodane zostały za free a to było dużo pracy. Z nowymi jest podobnie i coś jednak za update chcą.
Addony też można uaktualniać z programu i właśnie sprawdziłem swoje...



Kalkulator do FuseBitów tu się nie przyda bo w tych nowych się zegary konfiguruje programowo. Grzębię w fusach tylko jak chcę ustawić poziom dla BOD czyli żeby uC mi spał gdy nie ma wystarczajacego napięcia.

Programator to zwykła przejściówka USB<>USART. Z opcji które oferują droższe narzędzia nie ma tylko debuggera, ale wiele rzeczy można przetestować w symulatorze i tam podglądać rejestry.
Można za złotówkę dołozyć sobie układ 74HC4053 i Bascom sygnałem DTR będzie automatycznie przełączał UPDI<>SERIAL i mieć od razu dostęp do uC poprzez terminal bez przepinania jakichkolwiek kabelków. Nie jest to "bieda UPDI" bo ograniczenie prędkości do 1.6Mbps wynika z ograniczeń mikroprocesora a dokładniej jego taktowania, o czym w nocie piszą:



Nie wiem jaką masz wersje, ale w mojej wystarczy wcisnąć F1 i wpisac "updi". Tam jest schemat z tym jednym rezystorem a nawet ten z 74HC4053.



W nowych uC jest dużo bajerów. Można jeden port podłączyć pod 5V a drugi pod 3V3 i niepotrzebne są translatory napięć. W resztę udogodnień się tu zagłębiać nie będę. Większość ma już wewnętrzny oscylator 24MHz.

A może jednak skusisz się na przesiadkę na inny kompilator? Mam na myśli Great Cow BASIC: Link.
Programy dla Bascom prawie bez zmian kompilują się bez problemu, w bonusie obsługa MCU PIC i innych języków programowania .

bart-projects napisał:

Po wlutowaniu i poprawnym połączeniu działa do dzisiaj.

To, że działa znaczy tylko i wyłącznie, że... działa, nic więcej. Z doświadczenia wiem, że po takich "przygodach" często nie trzyma parametrów niskiego poboru mocy w trybach power-down i podobnych. Ale działa... R

@adam_es
Ciekawie, nie mam teraz czasu na naukę, ale na pewno się tym zainteresuje.
Czy w razie czego mogę liczyć na pomoc?