Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2471
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    173

Wszystko napisane przez Elvis

  1. Cześć @FlyingDutch, Aliexpress ma podobno taką politykę, że sprzedawca nie dostaje pieniędzy za towar do momentu, gdy klient potwierdzi odebranie przesyłki. Dzięki temu sprzedawcy są raczej uczciwi - ja nie miałem nigdy problemów jak chodzi o tę część transakcji. Gorzej wygląda sama przesyłka - trwa długo, nie zawsze poczta, szczególnie nasza, obchodzi się z przesyłką jak byśmy tego oczekiwali. Ale znowu - na ogół nie jest źle. To co może być źle to po pierwsze cło. Jeśli do ceny urządzenia doliczysz koszty celne może już być drożej - no i papierologii trochę. Nie zawsze cło jest naliczane, ale czasem się zdarza. A wtedy poczta polska też sobie sporo dolicza za usługę. Najgorzej jest natomiast jak już taka zabawka przyjdzie i leży na biurku. Nie wiem jak będzie z tą płytką, ale mam całą szufladę pięknych płytek, do których nie było dokumentacji, oprogramowania, właściwie nic - i leżą sobie czekając kiedy będę miał mnóstwo czasu żeby z takimi zagadkami walczyć (do emerytury coraz bliżej). Moim zdaniem czasem lepiej więcej wydać i dostać coś ze wsparciem, przykładami, dokumentacją itd. Inaczej można wydać mniej, ale absolutnie z tego nie skorzystać. A co do "dużych" FPGA to ja nie mam doświadczenia, ale wystarczy popatrzeć na ofertę Xilinxa: https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdf Artix-7 to "Transceiver Optimization at the Lowest Cost and Highest DSP Bandwidt", dużych chyba trzeba szukać wśród Virtex-7, tam zamiast 100k LE są modele do prawie 2 milionów komórek. Ale jakie są ceny tych płytek to już chyba lepiej nie wiedzieć Natomiast autentycznie duże systemy FPGA z tego co wiem używają wielu układów, więc mając całą macierz Virtex-7 można o dużych FPGA mówić. Artix-7 to taki maluszek, nawet w wersji z 200k LE.
  2. @Pieterlpl Poczytaj trochę o pomiarze ciśnienia, a przy okazji wysokości. (np. https://stacje-pogody.pl/artykul_cisnienie_atmosferyczne_bezwzgledne_i_wzgledne_zredukowane_do_poziomu_morza_o_co_chodzi_z_tymi_cisnieniami,83.html ). Szybko odkryjesz, że to co wskazuje BME280 to niezupełnie to co chyba myślisz... W każdym razie prognoza pogody podaje tzw. ciśnienie względne (zredukowane do poziomu morza), a czujnik mierzy bezwzględne. Jeśli wiesz na jakiej wysokości jesteś możesz sobie to przeliczyć. Z drugiej strony wtedy zwracana wysokość (meters) nie ma sensu, bo w końcu przeliczając wiedziałeś już na jakiej wysokości jesteś.
  3. Teraz dużo lepiej. Popatrz na to: czas_o=millis(); if(czas_o - czas >= 30000UL) { ... } else { stan_maszyny=Alarm1; }
  4. Wolałem zapytać, bo tylko to mi przychodziło do głowy widząc ten fragment kodu. Wydaje mi się, że coś źle jest w pozostałym kodzie. Na pewno jest coś nie tak tutaj: case Rozbrajanie: i2c_lcd.setCursor(0,0); i2c_lcd.print("Rozbrajanie"); if(czas_o - czas >= 30000UL) { // PIN } break; Nie aktualizujesz zmiennej czas_o jak w poprzednim przypadku, w sumie czas też ma jakąś starą wartość. Ale ciężko jest powiedzieć o co chodzi widząc tylko fragmenty kodu. Zgaduję że czas_o powinien być aktualizowany za pomocą millis(), a do zmiennej czas należałoby wstawić wartość z millis() albo czas_o podczas przechodzenia do stanu Rozbrajanie.
  5. Nie gniewaj się za moje uwagi, wcześniejszy program wygladał jakbyś nie za bardzo zrozumiał instrukcję przypisania, były już takie nieporozumienia na forum więc to nie jest niemożliwe Teraz masz w programie źle nawiasy, w pętli while zwiększasz pulseval1, ale używasz jej dopiero jak osiagnie 1000.
  6. @aldenham Wydaje mi się, że powinieneś zacząć od nadrobienia pewnych zaległości z samego języka C. Operator = przypisuje zmiennej po lewej stronie wartość, która jest wynikiem wyrażenia po prawej, czyli: oc.Pulse = pulseval1; Taka instrukcja oznacza odczytanie wartości zmiennej pulseval1 i wstawienie tej wartości do oc.Pulse. Jednak od tego momentu pulseval1 jest zupełnie niezależna od oc.Pulse. Można do niej przypisywać dowolne wartości, odczytywać, nawet sama zmienna może przestać istnieć - a wartość oc.Pulse pozostanie bez zmian. Inna sprawa, że nawet zmiana wartości oc.Pulse nic by nie zmieniła - to jest tylko kolejna zmienna, dopiero jej przekazanie do funkcji HAL powoduje zmianę wypełnienia PWM. Ale jak napisałem, proponowałbym zacząć od powtórki samego języka C, opanowanie działania zmiennych, przypisań itd. A później wrócić do kursu STM32.
  7. Testowałem używając OpenSTM32 i win10, ale u mnie wszystko działa poprawnie. Czy na pewno używasz tego samego mikrokontrolera co w kursie?
  8. Tak jak napisał @Gieneq stykówki mają plusy i minusy. Ja chciałbym tylko dodać że stykówki, jak pewnie wszystko z czasem się "zużywają". Przyznam że nigdy nie miałem problemów z nową stykówką oraz nowymi kabelkami - ale im więcej przeżyła płytka i im bardziej zużyte są kabelki połączeniowe, tym gorzej. Więc nie popadałbym w skrajności - stykówka nie jest ani absolutnie zła, ani idealna. Do nauki, szybkiego przetestowania prostego układu - bardzo fajna.
  9. Z tego co na szybko można o module hc05 wyczytać, napięcie zasilania powinno być w zakresie 3.6-5V. Natomiast linie sterujące max. 3.3V. Nie wiem do czego był ten dzielnik używany, na pewno nie powinno być go przy zasilaniu modułu, nie powinno się również bezpośrednio łączyć 5V do linii sterujących. Edit: chyba dałem się podejść opisowi na stronie Botlandu. W sumie już sam nie wiem czy ten moduł toleruje 5V czy nie.
  10. Poczytaj https://pl.wikipedia.org/wiki/Kod_uzupełnień_do_dwóch W dokumentacji układu masz wyraźnie powiedziane, że w tym formacie są wyniki - więc np. 65339 to po prostu -197.
  11. Więc zostawiając własne opinie, a wracając do tematu wątku. @jare72 nie wiem jak dokładnie masz wszystko podłączone, ale zgaduję. Więc wiersze (ROWS) używasz do sterowania, natomiast stan klawiatury odczytujesz w kolumnach (COLS) - co jest dokładnie odwrotne od tego jak jestem przyzwyczajony, ale to bez znaczenia Na wejściach, czyli kolumnach masz włączone rezystory podciągające (PULL_UP), więc jeśli nic nie jest przyciśnięte, będzie tam stan wysoki. Wciśnięcie przycisku może zwierać do masy, co spowoduje pojawienie się stanu niskiego. Jak wcześniej @Gieneq zauważył, odczyt działał więc niepoprawnie: if(ekspander.digitalRead(COLS[y]) == HIGH) return KEYS[x][y]; Pierwsz zmiana to testowanie LOW, zamiast HIGH. Teraz trzeba zająć się wierszami. Ponieważ na wejściu masz pull-upy więc przyciskając klawisze użytkownik powinien zwierać odpowiednią linię do masy. Aktualna kolumna powinna być więc wybierana stanem niskim, a nie wysokim. Więc kod powinien być mniej więcej taki: char readKey() { for(int x = 0; x < NUM_ROWS; x++) { ekspander.digitalWrite(ROWS[x], LOW); for(int y = 0; y < NUM_COLS; y++) { if(ekspander.digitalRead(COLS[y]) == LOW) return KEYS[x][y]; } ekspander.digitalWrite(ROWS[x], HIGH); Na początku programu powinieneś też wystawić stany wysokie na wszystkich wyjściach. Nie wiem jak wygląda schemat elektryczny, ale powinieneś uważać na możliwe zwarcia na pinach. Podczas skanowania, na jednej kolumnie jest wymuszany stan niski, a na pozostałych wysoki. Więc naciśnięcie dwóch przycisków jednocześnie może spowodować zwracie... Możesz to obejść sprzęowo dodając diody lub rezystory, albo programowo. W skrócie - zamiast zapisywać stanu wysokiego do kolumn lepiej przełączać piny w stan wysokiej impedancji (czyli wejście, najlepiej z pullup-em). Wtedy ewentualne przyciśnięcie dwóch klawiszy nic złego nie zrobi. Ale to moim zdaniem zadanie na kolejny etap - zacznij od uruchomienia tego co masz, tylko nie wciskaj dwóch klawiszy jednocześnie Edit: pomyliłem kolumny z wierszami na końcu komentarza. przyzwyczajenie to jednak druga natura
  12. Przepraszam, że się wtrącam - ale moim zdaniem używanie ekspandera to nic złego. Oczywiście ma swoje wady: po pierwsze jest drogie, po drugie powolne. Wydaje mi się jednak, że w przypadku konstrukcji amatorskiej, to nie przekreśla stosowania ekspandera. Pierwszy argument, czyli cena nie ma znaczenia jeśli budujemy jeden egzemplarz. Nawet jeśli jeden układ kosztuje 1zł, a drugi 5, to i tak koszty przesyłki będą wyższe. A gdyby nadal była różnica, to czas spędzony przy zabawie tymi układami ma i tak większą wartość niż wszystkie elementy razem wzięte (doliczając złocenie wyprowadzeń). Natomiast jak chodzi o czasy działania, to wszystko zależy jak często potrzebujemy wykonywać skanowanie klawiatury. Tak teoretycznie licząc: zapis do ekspandera to 3-4 bajty (adres urządzenia, numer rejestru, 1-2 danych). Niektóre wymagają mniej, ale liczmy dla 4 bajtów. Dla każdej kolumny musimy wykonać zapis - załóżmy że klawiatura ma 4 kolmny - mnożąc przez 4 mamy 16 bajtów. Po każdym zapisie dajemy odczyt wartości - i i wychodzi wszystkiego razem 32 bajty, czyli 256bitów. Dojdą jeszcze bity startów, stopów, potwierdzeń - żeby w pamięci łatwiej liczyć, niech będzie 500 bitów. I2C powinno poradzić sobie co najmniej z 100kHz, więc skanowajmie zajmie jakieś 5ms. To z jednej strony wieki - ale jeśli takie skanowanie wykonamy co 100ms to będziemy mieli działającą klawiaturę oraz zużycie CPU na poziomie 5%. Tak jak napisałem wcześniej - w pełni się zgodzę, że inne rozwiązania są szybsze, tańsze, lepiej dopasowane do produkcji seryjnej. Ale moim zdaniem w tym konkretnym przypadku można spokojnie dodać ekspander, albo dwa i mieć prosty projekt, który pozwoli jego autorowi uczyć się dalej programowania. Edit: w pierwszej wersji pomyliłem się o rząd wielkości, wyszło mi 0.5%, poprawiłem na 5%.
  13. Moim zdaniem warto przetestować jak zachowa się program i czujnik przy maksymalnych wartościach - ale nie musisz się nimi szczególnie przejmować. Jak będziesz znał zakres, który Cię interesuje wystarczy wpisać go do funkcji map(), ale przed jej użyciem wywołać funkcję constrain() https://www.arduino.cc/reference/en/language/functions/math/constrain/ Wtedy wszystko powinno działać jak należy
  14. Nie musisz testować wszystkich możliwych kolorów - potrzebujesz tak naprawdę 6 liczb, czyli minimalnej i maksymalnej wartości, która jest zwracana przez pulseIn() dla trzech kolorów w używanym przez Ciebie otoczeniu. Później możesz te wartości wstawić do map(). Musisz tylko doczytać jak działa ta funkcja: https://www.arduino.cc/reference/en/language/functions/math/map/ Wykonuje ona proste skalowanie, czyli: long map(long x, long in_min, long in_max, long out_min, long out_max) { return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min; } Więc jeśli wartość x, czyli wejście jest poza zakresem in_min - in_max, to i wynik jest poza zakresem out_min i out_max. Będziesz musiał więc odczytany wynik ograniczyć jeśli wyszedł poza zakres, albo jeszcze lepiej - ograniczyć wartość danej wejściowej, czyli x.
  15. @startrek1p2p Ja też nie wiem jakie wartości będziesz odczytywał - dlatego napisałem żebyś na razie zrezygnował z funkcji map() i przetestował jaki jest zakres wartości. Bo map() przelicza zakresy, czyli jak miałeś: frequency = map(frequency, 25,72,255,0); to zakres 25-72 był przeliczany na 255-0. Jeśli dostałeś wartość spoza zakresu 25-72, to i wyniki wyszły poza 0-255. Stąd takie dziwne wartości. Moim zdaniem powinieneś zacząć od ustalenia jakie wartości dostajesz dla R, G i B - zaczynając od całkiem zasłoniętego czujnika, a kończąc na oświetlonym białym światłem. Co więcej warto sprawdzić, czy czujnik odpowiednio reaguje na kolory - tak żeby się upewnić że wszystko działa. Nie musisz mieć do tego oscyloskopu, wystarczy trochę się pobawić i poobserwować wyniki. Jeśli umieścisz czerwony obiekt - wartości dla czerwonego powinny maleć itd. Dopiero wiedząc jakie otrzymujesz "gołe" wyniki możesz dodać funkcję map() i przeskalować odczytane wartości na oczekiwany zakres. Musisz jednak pamiętać, że map może zwracać też wartości spoza oczekiwanego przedziału. I jeszcze jedno - zmień typ zmiennych R,G,B z powrotem na int. Teraz jest dużo gorzej niż było.
  16. @startrek1p2p wyłącz na chwilę wywołania funkcji map(), będzie można wtedy zobaczyć jak wyglądają same odczyty z czujnika. Wygląda na to że, twój czujnik zwraca wartości z innego przedziału niż zakładasz - zacznij więc od sprawdzenia, jakie są to wartości i czy zmieniają się zgodnie z oczekiwaniami.
  17. Dla mikrokontrolerów są biblioteki np. od ST: https://www.st.com/en/embedded-software/x-cube-ai.html Cały trening sieci wykonuje się "jak zwykle" za pomocą narzędzi opartych o Pythona, ale nauczoną sieć można skonwertować na zminimalizowaną postać dopasowaną do mikorokontrolera, którą obsługują biblioteki napisane w C.
  18. Powiedziałbym bardziej że widziałem przykłady użycia sieci neuronowych na STM32 podczas szkolenia. Były to faktycznie małe sieci, ale stm całkiem sprawnie sobie radził. Moim zdaniem w przypadku mikrokontrolerów mogłoby być ciekawe użycie sieci neuronowych do wstępnego przetwarzania mniejszych zbiorów danych niż w przypadku obrazu - np. analizować dane z akcelerometru, czy żyroskopu. Z ciekawostek - w sieci są przykłady używania ML do nauki "chodzenia" przez roboty. Planowałem więcej się tym pobawić, ale jak zwykle - brakuje czasu
  19. Można mieć komercyjne produkty w pełni amatorskie - jako przykład weźmy chociażby zestawy AVT. Nie wszystko za co ktoś płaci jest profesjonalne - i odwrotnie, wiele produktów typu open-source, open-hardware itd jest darmowych, a często w wiele lepszej jakości niż niejeden płatny projekt. Na AVR można opracować w pełni profesjonalny projekt, a na ARM mieć zupełnie skopaną amatorszczyznę - więc nie ma sensu porównywać architektur i rozwiązań, podbudowywać własne ego dopiero co poznanym mikrokontrolerem. To co zaproponował p. Kardaś o ile wiem jest rozwiązaniem skierownym do amatorów, osób które chcą się nauczyć programowania, poznać podstawy elektroniki. I chyba jest to dobry wyrób skoro wiele osób go kupuje i sobie to chwali - jak to się mówi, zagłosowali portfelami
  20. Panie Skrzyński, to bardzo nieładnie czepiać się tego co robi ktoś inny, szczególnie jeśli wymienia się go z nazwiska. Rozumiem że ma pan ogromny żal i przemawia przez pana ogromna zawiść, że prace p. Kardasia, które nie tylko są przez wiele osób lubiane, ale jeszcze wspierane znacznymi kwotami. Jednak to forum nie jest miejscem na terapię i leczenie kompleksów - prosiłbym o unikanie takiej krytyki. Oczywiście można napisać że nie powinno się używać układów poza zakresami wskazanymi przez producenta, ale pamiętajmy, że zarówno konstrukcje pojawiające się na tym forum, kursy p. Kardasia, jak i artykuły w EP, czy EdW to wszystko amatorskie i hobbistyczne zastosowania.
  21. wszystko zależy do czego i gdzie te tranzystory były dodawane. Używanie wyjścia w trybie open-collector (albo raczej open-drain) nie zawsze jest idalnym rozwiązaniem. Dodatkowe tranzystory czasem bardzo się przydają, np. kiedy potrzebne są nieco większe prądy, albo odporność na zakłócenia. Co więcej czasy przełączania dla OC są znacznie niższe niż w trybie push-pull, a zewnętrzny tranzystor dużo lepiej zadziała z małym rezystorem podciągającym - więc moim zdaniem trzeba dobierać rozwiązanie do problemu, a nie teoretyzować. Tym bardziej że w większości przypadków sterowanie napięciem 3.3V w zupełności wystarczy nawet dla wejść w logice 5V.
  22. Jak najbardziej może być tam 5V. Bazując na standardowej technice wytwarzania układów półprzewodnikowych można umieścić więcej niż jedno złącze pn i wtedy 5V nie stanowi problemu. Co więcej można odpowiednio domieszkując można uzyskać złącze zenera, co chyba nawet lepiej pasuje w takim przypadku - w każdym razie schemat z diodą to tylko model i ogromne uproszczenie.
  23. @atMegaTona stm32 i wiele innych mikrokontrolerów jest wyposażone w wyprowadzenia "tolerujące" napięcie wyższe niż zasilania samego układu - czyli powiedzmy tolerujące 5V, gdy układ jest zasilany z 3.3V. Rysunki z diodami zabezpieczającymi są oczywiście uproszczeniem, a jak faktycznie dane zabezpieczenie jest rozwiązanie to już zupełnie inna sprawa. W każdym razie w przypadku wielu wyprowadzeń stm32 podawanie 5V nie stanowi problemu - a ustawienie pinu w tryb wejścia, albo wyjścia open-colector z rezystorem podciągającym to żadna tajemnica ani czarna magia.
×
×
  • Utwórz nowe...