Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2506
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    177

Elvis wygrał w ostatnim dniu 26 grudnia 2019

Elvis ma najbardziej lubianą zawartość!

Reputacja

1022 Mistrz

2 obserwujących

O Elvis

  • Ranga
    8/10

Informacje

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. Nikt w geodezji nie mierzy palcami. Przy okazji prośba do admina - o wywalenie tego offtopicu do kosza. To chyba nie ma nic wspólnego z tematem, ani PPF. A żeby była jasność - GPS jest używany w geodezji i błąd pomiarowy rzędu milimetrów można uzyskać z tymi trzema palcami w ...
  2. Oczywiście że nie wyeliminowano. Każdy pomiar jest obarczony błędem, nawet najdokładniejszy geodezyny. Błąd można więc tylko zredukować, nigdy wyeliminować.
  3. Błąd był celowy, gdy wprowadzano GPS do użycia, ale później wprowadzany błąd bardzo zredukowano. Na bazie różnic między pomiarem dokładnym, a uzyskanym z GPS działa DGPS (https://pl.wikipedia.org/wiki/Różnicowy_GPS). Niestety w przypadku tanich odbiorników nie liczyłbym na jakąkolwiek użyteczność rozwiązania opisywanego w artykule. Profesjonalne odbiorniki GPS to zupełnie inna półka - proponuję sprawdzić ich ceny, gdyby można było w takich zastosowaniach użyć popularnych odbiorników używanych np. w telefonach, czy nawigacjach samochodowych, już dawno firmy sprzedające urządzenia za dziesiątki tysięcy złotych musiałyby zmienić asortyment... Tanie czytniki zwracają potworną wręcz ilość błędnych odczytów - nie jest to jedna i ta sama wartość, ale seria mocno losowych odczytów. To że wyniki wyświetlane w telefonie wyglądają sensownie, zawdzięczamy tylko odpowiednim algorytmom filtrującym oraz wykorzystaniem danych z wielu źródeł. Ale jako ciekawostkę zachęcam do podłączenia taniego odbiornika GPS i pobrania danych NMEA - z tego co wiem, takie surowe dane nie przydadzą się właściwie do niczego.
  4. Bez problemu można i 16 grafik dotyczących gita przygotować
  5. Proponuję wyłączyć antywirusa i spróbować ponownie (https://forum.arduino.cc/index.php?topic=513525.0)
  6. W obsłudze przerwania masz wywołanie TIM_OC1Init, po pierwsze nie jestem pewien, czy zmienna channel jest poprawnie ustawiona, ale co ważniejsze Init służy do inicjalizacji - a z tego co rozumiem chciałeś tylko zmienić wypełnienie PWM. Do tego lepiej użyć TIM_SetCompare4.
  7. @aldenham Bardzo dobrze, że pytałeś i bardzo się cieszę że sprawa się wyjaśniła Po prostu skoro już wiemy, że problem nie dotyczył DMA można pytania wydzielić z tego tematu - to nic złego i mam nadzieję że admin bez problemu to załatwi. Jeśli będziesz miał kolejne pytania odnośnie tablic, wskaźników i printf-ów, to też pytaj - na pewno pomożemy, w końcu po to jest Forbot. Wracając do printf-ów, nie wiem jakie ostrzeżenia generował kompilator, mogło chodzić o użycie typów bez znaku i wtedy zamiast %d można zastosować %u. Ale możliwe, że ostrzeżenia dotyczyły użycia wskaźników w miejscu gdzie powinny być liczby - więc jeśli ten problem pojawi się przy poprawnym użyciu tablic, napisz co wyświetla kompilator i jaki dokładnie masz kod.
  8. Widzę, że kolega @miszczu18 wyprzedził mnie w tłumaczeniu o co chodziło w programie Proponuję więc zostawienie DMA na chwilę w spokoju i powtórkę z działania tablic oraz wskaźników w języku C - bez tego raczej ciężko będzie napisać właściwie jakikolwiek program. Natomiast od administratora mam prośbę o wydzielenie tej dyskusji do oddzielnego tematu, dotyczy ona podstaw C i nie ma nic wspólnego z DMA, ani kursem STM32.
  9. Przyznam, że nic nie zrozumiałem - bufory mają i powinny mieć inne adresy, to co wstawiasz wygląda właśnie na adres bufora źródłowego, bo 536873560 czyli 0x20000a58 to adres w pamięci SRAM. Co więcej 536873592 - 536873560 = 32, a tyle wynosi wielkość bufora źródłowego, więc możemy się domyślać że wyświetliłeś tutaj adresy buforów, a nie ich zawartość. Funkcje copy_cpu/dma nie zmieniają adresów buforów, a jedynie kopiują dane. Więc adresy powinny być różne, ale ich zawartość identyczna.
  10. @aldenham piszesz, że wyniki są jednakowe, a chwilę później że różne. Mogłbyś nieco dokładniej opisać co masz na myśli?
  11. Taka uwaga z innego forum, ale chyba warta poprawienia - zmienna pinAlarmuPozycja nie jest resetowana do początkowej wartości, więc po wpisaniu poprawnego hasła, przy kolejnych próbach wystarczy wpisać tylko koniec pinu. Wypadałoby to poprawić i dodać pinAlarmuPozycja=1 w odpowiednich miejscach, żeby nikt nie pisał o błędach w kursach Forbot-a
  12. Wygląda na to, że po prostu nie zainstalowałeś sterownika. Plik .7z to archiwum, podobnie jak .zip, albo .rar. Drugi błąd to informacja, że nie masz programu do rozpakowania tego archiwum - możesz pobrać i zainstalować darmowy: https://www.7-zip.org/7z.html Jak rozpakujesz .7z i zainstalujesz sterownik to powinno działać.
  13. @hantercv spróbuj podłączyć sam konwerter usb-uart do komputera i sprawdź, czy Windows poprawnie go wykrywa. Jeśli nie to nie ma sensu podłączać malinki, najpierw musisz mieć wirtualny port COM, a na zdjęciu wygląda na problem ze sterownikami. Jeśli windows nie wykrywa konwertera, to najlepiej spróbować z innym komputerem - możliwe że jest to uszkodzony układ, ale w 99% przypadków problem jest po stronie oprogramowania.
  14. Komunikaty o błędach wskazują na zbyt małą ilość pamięci RAM dla sterty (heap) maszyny wirtualnej javy. To dość dziwne, ale na wszelki wypadek proponuję sprawdzić ustawienia JVM. Google powinien podpowiedzieć jak to zrobić, przykładowe linki: http://www.messiahpsychoanalyst.org/wikihow/index.php/How_to_Increase_Java_Memory_in_Windows https://stackoverflow.com/questions/17369522/set-default-heap-size-in-windows
  15. W pierwszych eksperymentach z WS2812B używałem Arduino UNO. Tak jak napisałem wcześniej, było to proste, łatwe i przyjemne. Właściwie wystarczyło podłączyć układ, dodać bibliotekę i wszystko działało - chociaż oczywiście z ograniczeniami. Opisując sterowanie za pomocą UART chciałem wykorzystać inny mikrokontroler. Możliwe że nie było to konieczne i pewnie znacznie więcej można "wycisnąć" z atmegi 328p, ale jak napisałem wcześniej zmiana układu ma swoje plusy, a nawet jeśli nie ma, to była okazją do przetestowania innych rozwiązań Dawniej standardem zasilania mikrokontrolerów było napięcie 5V. Atmega328p z racji wieku, ma tę niewątpliwą zaletę, że zarówno do zasilania rdzenia, jak i peryferiów jest używane właśnie takie napięcie. Można więc podłączyć pasek WS2812B zasilany z 5V i wszystko powinno działać. Natomiast, gdy używamy mikrokontrolerów pracujących z logiką 3.3V, mogą pojawić się problemy. W dokumentacji WS2812B znajdziemy następującą informację: Jak widzimy napięcie do 0,3 Vin będzie traktowane jako stan niski, natomiast powyżej 0,7 Vin jako wysoki. Z pierwszym parametrem raczej nie będziemy mieli problemów, ale z drugim może być już trudniej. Jeśli zasilamy pasek LED z napięcia 5V, to 0,7 * 5V = 3,5V, czyli więcej niż mikrokontroler może zaoferować. Przy okazji warto zwrócić uwagę, że problem z którym się musimy zmierzyć nie dotyczy tylko WS2812B. To ogólny problem sterowania układu pracującego w 5V-logice przy użyciu 3.3V mikrokontrolera. Na szczęście znajdziemy wiele możliwych rozwiązań naszego problemu, będziemy mogli więc wybrać taki, który najbardziej nam pasuje. Rozwiązanie 1: czyli zignorowanie problemu Właściwie nie powinienem o tym pisać, bo to jest złe, niedobre i niepoprawne, ale zawsze można spróbować po prostu podłączyć mikrokontroler zasilany z 3.3V do paska pracującego z 5V. Okazuje się, że to na ogół działa. Pin sterujący jest wejściem WS2812B, więc nie pojawia się na nim 5V. Dzięki temu nie ma ryzyka uszkodzenia mikrokontrolera. Natomiast układ może nie działać (a nawet nie powinien o ile wierzymy dokumentacji), ale jak napisałem wszystkie diody które testowałem działały bez problemu. Jest to więc niepoprawne, ale często działające rozwiązanie. Rozwiązanie 2: obniżenie napięcia zasilania WS2812B Okazuje się, że napięcie 5V chociaż typowe wcale nie jest minimalnym do pracy ws2812B. Jeśli mamy zasilacz z regulowanym napięciem wyjściowym możemy zamiast 5V użyć nieco niższego napięcia. Dzięki temu zmniejszymy straty mocy, a sam pasek będzie świecił równie jasno (opinie są podzielone, ale z moich testów wynika że zejście nawet do 4V nie ma wpływu na jasność świecenia). W każdym razie już przy 4,7V będziemy "na styk" z dokumentacją, ale już przy 4,5V wszystko powinno działać poprawnie i z niezbędnym zapasem. Kolega @ethanak zaproponował bardzo ciekawe rozwiązanie "hybrydowe". Można wykorzystać jeden moduł WS2812B, który zasilimy z niższego napięcia do wysterowania kolejnych. Do obniżenia używając nawet jednej lub kilku diod prostowniczych. W przypadku paska led takie rozwiązanie wydaje się nieco kłopotliwe, ale większość pasków można rozcinać - więc wystarczy odciąć jedną diodę i wykorzystać jako sterownik. Bardzo sprytne rozwiązanie Rozwiązanie 3: dedykowany układ scalony To chyba moje ulubione rozwiązanie. Może niezbyt tanie i proste, ale za to skuteczne i teoretycznie bezawaryjne. Po prostu musimy wybrać odpowiedni układ scalony, który wykona za nas całą pracę. Dostępnych jest mnóstwo opcji, są dedykowane układy tzw. https://en.wikipedia.org/wiki/Level_shifter. Przykład takiego układu znajdziemy np. analizując schemat płytki Maximator (http://maximator-fpga.org/), która wyposażona jest w układ FPGA pracujący w logice 3.3V. Dostępne są gotowe moduły z podobnymi układami, np. https://botland.com.pl/pl/rozszerzenia-gpio-nakladki-hat-do-raspberry-pi/4290-konwerter-poziomow-logicznych-txb0104-dwukierunkowy-4-kanalowy-sparkfun.html Jeśli ktoś uważa, że cena jest nieakceptowalna, może poszukać tańszych odpowiedników np. na aliexpress. Ceny podobnych modułów zaczynają się od 4zł z przesyłką. Prawdopodobnie tańszym rozwiązaniem będzie wybranie odpowiedniego układu z rodziny 74. Przykładowo SN74LV1T34 (http://www.ti.com/product/SN74LV1T34) - jeśli znacie inne, np. tańsze, łatwiej dostępne układy, piszcie w komentarzach - ten model znalazłem na szybko za pomocą google, wcale nie twierdzę że to najlepszy układ na świecie. Rozwiązanie 4: wyjście open-drain lub open-collector To rozwiązanie jest pozornie proste. Jeśli nasz mikrokontroler toleruje napięcia 5V oraz ma możliwość przełączenia wyjścia w tryb open-drain, wystarczy podłączyć rezystor podciągający do 5V i teoretycznie wszystko działa. Pierwszy problem to tolerancja 5V. Nie wszystkie układy mają taką możliwość, więc np. jeśli chcemy z ESP32 wysterować diody WS2812B nie możemy bezpośrednio podłączyć rezystora pull-up. Możemy to łatwo obejść dodając tranzystor, ale to już nie jest tak proste jak wcześniejsza opcja. Drugi, dużo poważniejszy problem to ograniczenia takiego sterowania. Jak pewnie wszyscy wiedzą, sygnały nie zmieniają się natychmiast, nawet "idealny" prostokąt ma swoje czasy narastania. Jeśli użyjemy układu open-drain, to zmiana ze stanu niskiego na wysoki będzie trwała dość długo - jest to wręcz książkowy układ R-C (https://pl.wikipedia.org/wiki/Układ_RC), więc stała czasowa t=R * C. W nocie katalogowej WS2812B znajdziemy informację o pojemności wejściowej wynoszącej 15pF. Do tego musimy doliczyć pojemności wprowadzane przez PCB lub/i przewody. Podstawmy kilka wartości R do wzoru: Jak widzimy przy typowej wartości rezystora podciągającego, czyli 47k stała czasowa wynosi 705ns - to oznacza że po tym czasie na wyjściu będziemy mieli napięcie ok. 63% docelowego (czyli mniej niż wymagane 0,7Vin). W przypadku 10k jest nieco lepiej, ale 95% docelowej wartości otrzymamy po czasie 3 * t, czyli większym niż szerokość impulsu, który staramy się uzyskać. Dopiero bardzo małe rezystory podciągające, jak 4k7, czy 1k dają w miarę rozsądne czasy. Jednak ich użycie oznacza dość spore prądy wpływające do mikrokontrolera. Wykonałem kilka pomiarów, żeby przetestować takie sterowanie w praktyce. Testy Pierwsze dwa rozwiązania działały na wszystkich posiadanych przeze mnie diodach. Ponieważ do zasilania używam zasilacza laboratoryjnego, więc zmniejszenie napięcia z 5V do 4,5V było bardzo łatwe. Jak napisałem wcześniej, nie powoduje to widocznej zmiany jasności świecenia. Trzecie rozwiązanie testowałem używając płytki Maximator. Jak można się spodziewać wszystko działa wówczas bardzo dobrze, a FPGA pozwala na sterowanie WS2812B bez "sztuczek" z UART, SPI, czy innymi modułami. Ostatnie rozwiązanie postanowiłem sprawdzić podłączając oscyloskop. Na początek dla porównania pierwsza opcja, czyli sterowanie WS2812B bezpośrednio z 3.3V: Tutaj przydałby się lepszy oscyloskop, ale jak się nie ma co się lubi... W każdym razie widać silne dzwonienie sygnału. Warto przetestować polecane często w internecie wpięcie rezystora szeregowego w linię sterującą. Po podłączeniu 82 Ohm oscylogram wygląda następująco: Użycie 220 Ohm sprawia daje jeszcze ładniejszy rezultat: Nie jestem niestety ekspertem od elektroniki analogowej, ale mam nadzieję, że ktoś - może @marek1707 ładniej opisze dlaczego warto (albo nie) dodawać rezystor szeregowo. W każdym razie wyraźnie widać różnicę. Jednak celem testu miało być co innego - zmieniam więc wyjście mikrokontrolera na open-drain, podłączam zasilanie 5V do paska WS2812B oraz rezystor podciągający 33k (z 47k było jeszcze gorzej, a później gdzieś sobie poszedł): Diody oczywiście nie działają z takim rezystorem. Zmieniam więc na 10k: Układ nadal nie działa, ale jest postęp. Czas podpiąć 4k7: Wykres nadal fatalny, prąd 1mA wpływa do biednego mikrokontrolera, natomiast co ciekawe układ działa. Na koniec jeszcze pull-up 1k: Tutaj jak widzimy jest już prawie dobrze. Czasy narastania nadal są kiepskie, prąd wynosi aż 5mA - ale chociaż działa. Podsumowanie Sposobów na rozwiązanie problemu podłączenia WS2812B jest na pewno więcej. Opisałem kilka, które znam oraz które pojawiały się ostatnio na forum. Jeśli macie jakieś uwagi, pomysły na lepsze rozwiązania, piszcie proszę w komentarzach. Tylko bardzo proszę o merytoryczną dyskusję, a nie przekonywanie się nawzajem że moja racja jest najmojsza... Każdy problem można rozwiązać na wiele sposobów, a dzieląc się wiedzą wszyscy tylko zyskujemy.
×
×
  • Utwórz nowe...