Skocz do zawartości

dambo

Użytkownicy
  • Zawartość

    78
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    3

Wszystko napisane przez dambo

  1. Warto zaznaczyć, że te diodki są cały czas ulepszane przez producenta i aktualnie jest dostępny już model WS2812B-V5 i w nim jest "signal recognition range reduced to less than 2.8V - compatible with 3.3V ARM & 3.0V Bluetooth Chips" - link do stronki producenta: http://www.world-semi.com/solution/list-4-1.html#141 Dodatkowo już nie trzeba dawać kondensatorka przy nich - chyba aż takie parcie było ze strony klientów, że ten 0.1 centa czy mniej do zaoszczędzenia jest warty uwagi + wiadomo x części w montażu mniej itp - wyjaśnili to ładnie w pdfie ze stronki wyżej.
  2. Super pomysł - jest wiele sprzecznych informacji na necie i bezowocnych dyskusji/gdybania na ten temat i artykuł kogoś kto siedzi w temacie bardzo się przyda - jeśli chcesz się podzielić taką wiedzą - super!
  3. Ładnie umiesz dopowiadać po tym jak ktoś zwróci uwagę - i trzeba było tak od początku napisać. I uświadomić kolegę, że to co proponujesz to tylko jeden z kroków w nauce i że to nie jest idealne rozwiązanie, ma swoje wady, potem się tego nie stosuje itp - zamiast nazywać to "normalnym C++". Stąd też mój link do poczytania. Wstawki typu "pięćset plików nagłówkowych", "Wielcy mistrzowie z kimkolwiek na czele" sobie możesz darować.
  4. Czyli według Ciebie externowanie zmiennych pomiędzy wszystkimi plikami jak to pokazałeś dla tablicy "pozycje_serw" to "normalne C++" i nie jest to "ułatwienie dla leni"? Lepsze rozwiązanie - nie rozumiem do końca sedna problemu - dlaczego zamiast robić to od początku poprawnie z plikami h i c/cpp do nich interfejsy dostępowe, zapewnić jakąkolwiek enkapsulację sugerujesz z góry żeby to wszystko olać i dawaj globale na cały program, a potem kilkanaście rzeczy na raz z wielu miejsc będą modyfikować to samo. To się u podstaw gryzie z ideą OOP i jeszcze określasz to jako "normalne C++". @Bem
  5. "Przyzwyczaić do normalnego C++... bez ułatwień dla leni" i używać externów/dawać sobie dostęp do modyfikacji zmiennych z dowolnego miejsca bez jakiejkolwiek kontroli? Według mnie to nie jest poprawne rozwiązanie i złe podejście na start.
  6. Przepraszam, że tak post pod postem - ale chyba po edycji inni nie dostaliby komunikatu o tym. Chciałem ponownie zapytać się @PiotrekEl o tamtą wypowiedź. Nie lubię jak takie tematy wiszą nie zamknięte i się przez to tworzą dziwne historie potem, że "gdzieś czytałem, że cośtam...", ale w sumie to nie było źródeł do tego itp
  7. Przyznam, że nie słyszałem o tym + jak pogooglałem o wadach i zaletach to nie znalazłem o tym informacji - można prosić o jakieś źródła do tego, bo mnie temat zainteresował?
  8. Popatrz sobie na to: TRD1000D15-15A-DC jakiś zapas napięcia by się jeszcze przydał, bo to wersja 1000V ale to ktoś bardziej elektroniczny musiałby jeszcze potwierdzić, czy to dobra droga
  9. Ja jak pisałem - pobrałbym dane z inwertera bez ingerencji w to co już jest. Jak masz tam też dane wyrzucane przez WiFi na pokładzie to całość twojego urządzenia może się zamknąć w module EPS z przekaźnikiem.
  10. Strzalam totalnie - ta moc wyjściowa jest zawsze czymś mierzona/analizowana - nie ma jakiejś komunikacji do którejś mógłbyś się czymś podłączyć i odczytać to? Wtedy już droga wolna - czy to coś na arduino dorobić czy coś.
  11. Co rozumiesz przez "kompilowane są jednocześnie"? [UPDATE] Nawet teraz widzę, że LTO jest domyślnie uruchomione w arduino - może nie we wszystkich wersjach tak jest.
  12. @ethanak Wyszło, że dla jednego pliku działa tak jak reszta się spodziewała, więc "oszukałeś" i rozbiłeś to na oddzielne jednostki kompilacji przez co wymusiłeś żeby ta dana została - to inaczej nie mogło zadziałać - moduły zostały skompilowane tak, żeby tą wartość odczytać - więc tak to finalnie musiało być. Optymalizacja działa w obrębie jednostki kompilacji. Sprawę załatwi link time optimalization - przy "szerszym spojrzeniu" linker zobaczy, że to jest const i inaczej to zrobi - finalnie nie będzie nic w sekcji data. avr-gcc -flto -fdata-sections -ffunction-sections -c -o sc1.o sc1
  13. No ale to mogłeś przesłać co się wyświetla na terminalu jak uruchomisz taką apkę - karta jest poprawnie zainicjalizowana i plik się poprawnie otwiera, tak? Zobacz też, że w tym miejscu: while (dataFile.available()) { test[i]=dataFile.read(); i++; } jeśli plik jest większy niż tablica to sobie nadpisujesz pamięć i aplikacja się wywali - to trzeba zabezpieczyć. I generalnie celuję w to, że właśnie to się dzieje jeśli plik się wczytuje i generalnie nie ma błędów połączeniowych.
  14. nie zostanie to zapisane w postaci jednej zmiennej - uzupełni się w ten sposób tablica.
  15. char zmienna[1000]; myFile = SD.open("binary_file"); if (myFile) { file.read(zmienna, <rozmiar_pliku/tablicy>); } // close the file: myFile.close(); nie musisz w pętli - możesz podać w funkcji read dokąd ma wkleić dane i ile ich ma być
  16. xxd był do podglądu, że wszystko działa - też mam 64bitowy system i xxd śmiga - ja mam go z toolsów z instalacji GITa. Plik binarny tworzysz tym programem w C.
  17. no w linku wyżej do exampla "DumpFile" jest wszystko co potrzebne
  18. Popatrz za materiałami na ten temat na kanale Gynvaela Jakbyś chciał też posłuchać jak od innej strony to wygląda to na kanale Bsides na youtube zobacz prezentację "red teaming w Polsce".
  19. No to najpierw sobie przetestuj odczyt według tego exampla: https://www.arduino.cc/en/Tutorial/DumpFile na jakimś tekstowym pliku, żeby sprawdzić podłączenie itp i potem stopniowo kolejno dodaj wyświetlacz itp.
  20. To może ja trochę pomogę. Jak do pliku wstawisz text "0x00, 0x01" to w pliku są zapisane kody ASCII poszczególnych znaków z tego tekstu - czyli tak to wygląda: c:\files\forbot_binary λ echo "0x00,0x01" > a.txt c:\files\forbot_binary λ cat a.txt "0x00,0x01" c:\files\forbot_binary λ xxd a.txt 00000000: 2230 7830 302c 3078 3031 2220 0d0a "0x00,0x01" .. W pliku binarnym oczekiwałbyś, że plik będzie zawierał <01>. Jak uzyskać taki plik? Skoro masz tablicę w C to możesz prostym programem zapisać ją do pliku: #include <stdio.h> static unsigned char array[]
  21. No to jeszcze lepiej. To temat tego fragmentu w funkcjach metodach on i off do zamknięcia i poprawienia w wolnej chwili.
  22. Że można go zrefaktorować na wiele sposobów i teraz zgadywankę zrobiłeś "co mam na myśli". Jedna z opcji: uint8_t state = HIGH; if(_inverse) { state = LOW } digitalWrite(_pin, state); Od tego jest też mechanizm pull-requestów.
  23. To temat zostanie później przeniesiony w inne miejsce - nie widzę problemu z kontynuowaniem tutaj do tego czasu - admin/moderator nie wstawi się na zawołanie, trzeba poczekać. Nie próbuję udowodnić, że zrobiłem coś genialnego, tylko tłumaczę, dlaczego to zostało tak zrobione i jaki był cel tego. Napisałeś o digitalWriteFast to wyjaśniłem co zyskuję używając podstawowej wersji i dlaczego mi to odpowiada tak samo jak co tracę z tym podejściem. I od samego początku powtarzam o kompromisie czegoś kosztem czegoś - z czym się zawsze liczę.
  24. Odpowiadałem na twoje kolejne pytania, więc wina obopólna. Podsumowując z mojej strony - stwierdziłeś, że taka biblioteka nic nie wnosi - wyjaśniłem dokładnie jaki był jej cel i co wnosi, podałeś jeden kontrprzykład gdzie ona się nie sprawdzi (ten z 2 diodkami pod jednym pinem) - ok, w pełni się zgadzam w tym przypadku - dlatego można wtedy inne podejście zastosować. Po czym zmieniłeś temat na to, że w środku jest użyte digitalWrite niepotrzebnie i przekierowałeś na wersję fast, co także wyjaśniłem dlaczego tak zostało zrobione.
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.