Skocz do zawartości

dambo

Użytkownicy
  • Zawartość

    77
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    3

dambo wygrał w ostatnim dniu 11 września

dambo ma najbardziej lubianą zawartość!

Reputacja

24 Dobra

O dambo

  • Ranga
    4/10

Informacje

  • Płeć
    Mężczyzna

Ostatnio na profilu byli

263 wyświetleń profilu
  1. 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!
  2. Ł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ć.
  3. 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/
  4. "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.
  5. 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
  6. 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ł?
  7. 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
  8. 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.
  9. 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ś.
  10. 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.
  11. @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."
  12. 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.
  13. nie zostanie to zapisane w postaci jednej zmiennej - uzupełni się w ten sposób tablica.
  14. 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ć
×
×
  • Utwórz nowe...