Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2613
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    195

Posty napisane przez Elvis


  1. Ja tylko podpowiem, że nawet jeśli sam kurs jest dla początkujących to micro:bit jako platforma może być używana przez o wiele bardziej zaawansowanych użytkowników. Na micro:bit można uruchomić pythona, pisać programy za pomocą bibliotek Arduino, albo wyrzucić to wszystko i pisać programy w samym C/C++ (a nawet asemblerze) odwołując się bezpośrednio do rejestrów. Mamy wtedy całkiem ciekawy mikrokontroler nRF51822 z obsługą BT w wersji low-energy, akcelerometr LSM303, matrycę 5x5 led, drugi mikrokontroler do obsługi USB oraz możliwość podłączania modułów tak samo jak opisano w kursie.

    • Lubię! 2

  2. Moim zdaniem wysyłanie niewielkiej liczby zapytań, czy to będzie co minutę, czy co 30s nie podpada nawet w najmniejszym stopniu w "użycie systemu teleinformatycznego w sposób niezgodny z przeznaczeniem" - w końcu serwer www jest właśnie po to, żeby takie zapytania realizować. A że nie są wykonywane przez przeglądarkę, tylko przez skrypt to już szczegół techniczny. Oczywiście administrator może w takiej sytuacji zablokować IP, może nawet dodać regułę, która będzie takie zapytania odrzucała z automatu.

    • Lubię! 1

  3. @ethanak możesz podać o jakie nadużycie ostarżyć można kogoś kto co np. 1 minutę wysyła zwykłe zapytanie do ogólnodostępnego serwera? Pytam ze zwykłej ciekawości, bo to nie atak, nawet próba DoS, po prostu zwykłe zapytania, w dodatku niezbyt częste. Więc ciekaw jestem jaka ustawa coś takiego reguluje.


  4. @jackg Rozwiązanie, które podałeś wygląda poprawnie, chociaż zawsze warto byłoby sprawdzić na prawdziwej płytce (to praca domowa 6.1B).

    Jedyne co można się przyczepić to zaokrąglenia:

    Dla pierwszej wersji kursu mamy jak napisałeś Fcpu = 64MHz, dzielnik 6 i poprawnie policzone Tconv = 84. Obliczając fconv mamy więc:

    fconv = Fcpu / div / Tconv = 64MHz / 6 / 84 = 126.98 kHz

    Różnica nie jest duża, ale warto zwrócić uwagę, że wynik to nie "okrągłe" 128kHz, ale trochę poniżej 127 kHz. Czasem potrzebujemy faktycznie okrągłych wartości i wtedy trzeba dopasować Fcpu do możliwości przetwornika. W przykładach z kursu ta wartość akurat nie miała znaczenia.

    W nowej wersji mamy Fcpu = 8MHz, dzielnik 2 i Tconv = 26, czyli:

    fconv = Fcpu / div / Tconv = 153.85 kHz

    • Lubię! 1
    • Pomogłeś! 1

  5. @malkos chyba najprościej będzie zainstalować wireshark na raspberry i sprawdzić jak wygląda komunikacja. Możesz oczywiście "podsłuchać" co jest przesyłane między stm32, a rpi używając PC, ale to już jest nieco trudniejsze. Switch "uczy się" adresów MAC podłączonych urządzeń i wysyła pakiety tylko do odpowiednich kart - dlatego na PC nie widzisz komunikacji między pozostałymi.


  6. @Emerid możesz do typu zmiennej będącej licznikiem pętli dodać volatile, wtedy optymalizator nie będzie mógł całkiem wyrzucić tej pętli.

    Natomiast co do drugiego pytania, to chyba chodzi Ci po prostu o zmienną globalną, wtedy zarówno callback, jak i funkcja main będą miały do niej dostęp. Tutaj podobnie jak w przypadku pętli użycie volatile może być potrzebne.

    • Lubię! 2

  7. @Nikto0 spróbuj może wykonać następujący eksperyment myślowy: weź baterię, np. 9V i zmierz napięcie gdy nic nie jest do niej podłączone (to możesz zrobić nawet nie tylko myślowo). Otrzymasz jakiś wynik, pewnie nie 9V, ale pewną konkretną wartość. Masz więc napięcie U = <wartość zmierzona>, a prąd w obwodzie nie płynie, więc I = 0 A. Teraz druga część, już raczej tylko teoretyczna. Wyobraź sobie, że robisz zwarcie idealnym przewodnikiem, czyli takim, który ma rezystancję zerową. I teraz pytanie - jaki popłynie prąd?

    Gdyby R=0 podstawić do wzoru na rezystancję, czyli R = U/I to po przekształceniu mielibyśmy I = U/R, ale R=0, czyli I = 9 / 0 - a tego nie lubią matematycy. Nawet jeśli R nie będzie idealnie zerem, ale wartością bliską zeru, to i tak teoretycznie prąd będzie prawie nieskończony...

    Jak pewnie się domyślasz w takim eksperymencie nie uzyskasz nieskończonego prądu, tylko znowu jakąś konkretną wartość. W przypadku baterii 9V będzie to w dodatku zaskakująco mała wartość. Tym co ogranicza płynący prąd i sprawia że nie następuje koniec świata jest właśnie opór wewnętrzny - możesz go nawet zmierzyć, ale robienie zwarcia raczej nie jest dobrym pomysłem, więc można zrobić takie "prawie" zwarcie i zamiast R=0 użyć rezystora o większej wartości. I wtedy dostaniesz układ o którym pisał kolega @Gieneq 

    Ale najprościej wyobrazić sobie opór wewnętrzny jako taki niechciany rezystor, który mieszka w każdej baterii. Z drugiej strony to dzięki niemu nie uzyskamy nieskończonych prądów gdy niechcący zrobimy zwarcie.

    • Lubię! 1
    • Pomogłeś! 1

  8. To jakiś konkurs na największą ilość kodu która nic nie robi? Może chociaż spróbuj wyjaśnić co starasz się osiągnąć - bo jeszcze niechcący ktoś początkujący kiedyś znajdzie ten wątek i zacznie się z tego uczyć...


  9. W tym co napisałem nie ma nic sprzecznego z notą katalogową. PINx zwaca faktyczny stan pinów wybranego portu - zapis od PORTx jedynie próbuje zapisać określoną wartość. Jeśli zapis się uda, to po pewnym czasie np. 0.5-1.5 cyklu masz taki wynik jak chciałeś. Więc szybciej (optymalniej) będzie działało użycie zmiennej - a inna sprawa, że w zależności od konfiguracji pinu i tego co do niego jest podłączone ten kod może po prostu nie działać tak jak oczekujesz.

    • Pomogłeś! 1

  10. Zacznijmy od nieporozumienia - PORTB i PINB to nie są zmienne. To rejestry i chociaż czasem zachowują się podobnie do zmiennych to zupełnie co innego.

    Z rejestru PORTB możesz odczytać to co niego zapisałeś - więc zamiast sprawdzać PINB lepiej sprawdzać bit PORTB. Ale w niektórych mikrokontrolerach, np. stm32 jest tak, że dostęp do rejestru zajmuje o wiele więcej czasu niż odczyt ze zmiennej, czy rejestru procesora.

    Natomiast to co odczytujesz z PINB to faktyczny stan piny PB5. Okazuje się, że może być on inny niż wynikałoby z zapisu do PORTB - dlatego to może zupełnie nie działać. Jeśli wyjście jest typu push-pull to na 99% będzie działało, ale już mając wyjście open-drain, zapis do PORTB może nie mieć wpływu na wartość w PINB. Wystarczy, że zewnętrzny układ zewrze do masy i PINB zwróci 0 nawet jeśli PORTB zapisywał 1. Czegoś takiego mniej więcej się spodziewałem, stąd było moje pytanie.


  11. Ok, teraz rozumiem o co chodziło 🙂 W każdym razie używanie PINB jako zmiennej jest mocno mylące, może być mało wydajne, albo i zupełnie nie działać.

    Nie wiem jak jest na AVR, ale na ARM dostęp do rejestrów może być o wiele wolniejszy niż do pamięci. Poza tym PINB może zwrócić inną wartość niż wpisałeś do PORTB... Proponuję po prostu dodać zmienną, która będzie przechowywała stan diody i odpowiednio do jej stanu sterować programem. Będzie prościej, szybciej i czytelniej.


  12. Tak dla wyjaśnienia i zamknięcia offtopu - w przypadku większości mikrokontrolerów i mikroprocesorów z rdzeniem ARM, dostępny jest tzn. barrel-shifter. Dzięki niemu wczytując wartość instrukcją LDR można jednocześnie i niejako "za darmo" wykonać przesunięcie bitowe. Oczywiście nie mamy gwarancji że kompilator wygeneruje akurat taki kod i nie powinno się takich optymalizacji wprowadzać bez potrzeby. Ale tak jako ciekawostkę warto wiedzieć, że ARM to niby RISC, a potrafi mieć zaskakująco skomplikowane instrukcje asemblera 🙂

    • Lubię! 1

  13. W każdym razie:

    10 minut temu, ethanak napisał:

    Zauważ: zakładając, że PB5 to stała a PINB to odwołanie się do zawartości rejestru - 1 << PB5 obliczany jest w czasie kompilacji. PINB >> PB5 w czasie wykonania.

    Ergo: jeśli moje założenia są słuszne, nie jest optymalny niezależnie od mikrokontrolera 😉

    to nieprawda. Są takie architektury gdzie oba kody mogą być tak samo wydajne.


  14. Przy okazji warto jeszcze wyjaśnić jak ten pin jest skonfigurowany i jak niby miało działać - bo najpierw używany jest rejestr PORTB, czyli wygląda jakby to miał być pin w trybie wyjścia, ale chwilę później następuje odczyt z rejestru PINB, więc jednak wejście. Jestem bardzo ciekaw jak autor rozumie działanie takiego programu.

    @ethanak zostawmy te optymalizacje w spokoju, może warto zacząć od poprawności programu. Może nie być różnicy, czy przesunięcie jest wykonywane podczas kompilacji, czy wykonywania.


  15. Niestety nie znam metody na użycie GPS w małym robocie, dlatego zapytałem. Dokładność 2m to bardzo optymistyczne założenie. Filtr Kalmana to dobry pomysł, sprawdza się w nawigacji samochodowej - ale znowu, przy rozmiarze i szybkości reakcji robota raczej nie zadziała poprawnie.

    Można uzyskać wysoką dokładność w przypadku GPS, taki sprzęt używany jest np. w geodezji - ale ceny są zupełnie inne niż w przypadku opisywanych modułów, czas pomiaru jest dość długi no i konieczny jest abonament na dane dla DGPS.

×
×
  • Utwórz nowe...