dambo

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.

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!

Ł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ć.

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++". @Bemol Zapoznaj się np z tym: https://www.learncpp.com/cpp-tutorial/4-2a-why-global-variables-are-evil/

"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.

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

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ł?

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

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.

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ś.

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.

@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.cpp avr-gcc -flto -fdata-sections -ffunction-sections -c -o sd1.o sd1.cpp avr-gcc -flto -fdata-sections -ffunction-sections -c -o dw.o dw.cpp avr-gcc -flto -Wl,-gc-sections -o s1.elf sc1.o sd1.o dw.o avr-size s1.elf Natomiast fajnie, że constexpr załatwia sprawę - warte zapamiętania. [UPDATE] A nawet trochę za daleko pojechałem - już wsadzenie tego w sekcję, bez - flto powoduje ten sam efekt. Czyli chodziło mniej więcej o to co pisał Elvis wcześniej: "Zapomniałeś o opcji dla linkera - bez niej nieużywane śmieci zostają w pamięci."

i jak tam?

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.

nie zostanie to zapisane w postaci jednej zmiennej - uzupełni się w ten sposób tablica.