Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2426
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    168

Wszystko napisane przez Elvis

  1. Proponuję przeprowadzić następujący test: Po pierwsze należy porównywać programy wynikowe, a nie efekty pośrednie działania kompilatora. Wobec tego przykłady należy trochę zmienić - żeby się kompilowały i nie były puste: test1.c void digitalWrite(int a, int b) { volatile int xa = a; volatile int xb = b; } #define PIN 2 int main(void) { digitalWrite(PIN,1); } test2.c void digitalWrite(int a, int b) { volatile int xa = a; volatile int xb = b; } const int PIN = 2; int main(void) { digitalWrite(PIN,1); } Kompilacja: avr-gcc -Os -c test1.c avr-gcc -Os -c test2.c avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o test1.elf test1.o avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o test2.elf test2.o Teraz można porównać co wyszło: elvis@raider:~/blink_test/test$ avr-size test1.elf text data bss dec hex filename 178 0 0 178 b2 test1.elf elvis@raider:~/blink_test/test$ avr-size test2.elf text data bss dec hex filename 200 0 0 200 c8 test2.elf Jak widać po danych nie ma nawet śladu, ani w segmencie data, ani bss. Co ciekawe wersja z const daje większy plik wynikowy - ale to już taki urok kompilatora Można zawsze wygnerować faktycznie użyte pliki i popatrzeć czym się różnią: elvis@raider:~/blink_test/test$ avr-objdump -d test1.elf > test1.s elvis@raider:~/blink_test/test$ avr-objdump -d test2.elf > test2.s Po stałej PIN w obu przypadkach nie ma śladu, natomiast faktycznie kompilator trochę gorzej się zachował po zobaczeniu const. W każdym razie używanie const nie powoduje zużycia pamięci RAM, ta zmienna, która była widoczna w plikach .o jest usuwana przez linker, bo nie jest do niczego potrzebna.
  2. Sprawdziłeś zawartość plików wynikowych jak napisałem wcześniej, czy ciągle porównujesz tylko pliki .o ?
  3. @Matthew11 możesz porównać wyniowy kod progamu, a nie to co wychodzi po kompilacji samych plików? Bo u mnie linker wyrzuca nieużywaną sekcję, więc pliki .o mają dodatkowy bagaż, ale docelowy elf już nie. Dodatkowy test dla ciekawskich - dodanie static do const. Wtedy każdy kompilator powinien już dać poprawny wynik, nawet w plikach pośrednich. Edit: Coś co mnie dla odmiany zaciekawiło - użycie avr-g++ zamiast avr-gcc daje inny kod i wtedy oba pliki są identyczne nawet na etapie plików obiektowych... Może dlatego tylko entuzjaści C++ lubią wersję z const
  4. Przetestowałem z Arduino 1.8.9 i kod jest identyczny. Więc pewnie sporo zależy od wersji kompilatora użytych ustawień itd. No i wypadałoby chyba porównywać kod programu, a nie coś pośredniego. W każdym razie kod z const jest bardzo łatwo popsuć, dlatego dawno temu polecano używanie #define. Obecnie moda się zmieniła i fanatycy C++ preferują const. Od czasów C++11 dostępny jest operator constexpr, który działa z moją wersją Arduino - może to pogodzi obie strony?
  5. Co więcej kod wynikowy obu wersji będzie taki sam. Żadnej alokacji pamięci nie będzie, no chyba że ktoś zacznie robić jakieś nieeleganckie sztuczki z tak zadeklarowanymi stalymi, np. odczytując ich adres. W poprawnie napisanym programie nic złego się nie wydarzy, nie będzie też marnowania zasobów.
  6. Dawno temu dioda, bo tak się kiedyś nazywał Forbot był mega fajnym miejscem, ale widzę że czasy się zmieniają. W każdym razie, wracając do krytyki konstruktywnej - mamy taki kod: long long delta_time = actual_time - _elements[i].begin_time; if (delta_time < 0) { delta_time += 0xffffffff; delta_time += 1; } if (_elements[i].interval > 0 && delta_time >= _elements[i].interval) { onTime(i); _elements[i].func(); _elements[i].begin_time = actual_time; } mam więc kilka konstruktywnych pytań: 1) ile operacji musi wykonać 8 bitowy mikrokontroler, żeby poradzić sobie z typem danych long long 2) czy jego użycie jest konieczne 3) czy uzasadnione 4) i wreszcie konstruktywnie - jak to samo napisać prościej, szybciej i poprawniej
  7. Ponieważ wątek jest ostatnio nadspodziewanie popularny, chciałem tylko zwrócić uwagę na niską jakość wspomnianej biblioteki. Wiele bibliotek dla Arduino cierpi na podobną przypadłość, ale nie można poprawiać całego świata na raz - w każdym razem zanim ktoś użyje gotowca z internetu proponowałbym poświęcić chwilę na analizę kodu i zastanowienie czy to na pewno jest program, z którego warto skorzystać, albo chociaż czy jest on wystarczająco dobry do danego zastosowania. Swoją drogą analiza błędów oraz poprawianie tego co autor biblioteki miał na myśli mogłoby być dość pouczające.
  8. Pomijając samą dyskusję pozwólcie że nieco skrytykuję samą "bibliotekę". Skoro tyle o niej napisano, to może warto byłoby ją nieco udoskonalić. Po pierwsze absolutnie bez sensu jest używanie 64-bitowej arytmetyki - dla 8 bitowego mikrokontrolera to mnóstwo pracy, a wystarczyłoby 32, albo i mniej bitów. Osoba mająca tak duże doświadczenie w ograniczonych sprzętowo platformach chyba powinna o tym widzieć. Kolejna i poważniejsza sprawa to samo obliczanie czasów - nazwa interval sugeruje że co tyle mają się wywoływać odpowiednie funkcje. Niestety nieco naiwna implementacja sprawia. że każde "przetrzymanie" procesora przez pozostałe wątki zwiększa opóźnienie. Polecam poczytać czym różnią się funkcje vTaskDelay i vTaskDelayUntil używane przez FreeRTOS-a, może wtedy coś się rozjaśni.
  9. Ja bym proponował zacząć od poczytania co znaczy IT Security - bo jak widać po wpisach to nie do końca zrozumiane pojęcie. A ma dużo mniej wspólnego z filmami, gangsterami i hackerami niż z tym co robi dobry administrator.
  10. Po prostu mnie to zaskoczyło - ta płytka kosztuje 383zł z tego co widzę na stronie producenta. Za to można mieć kilka oryginalnych arduino, albo worek chińskich. Poza tym Arduino są ładniejsze i zgrabniejsze, więc nie będą straszyły koło telewizora. Pytałem bez żadnej złośliwości po prostu wybór platformy zaskoczył - ale jako testowa i zalegająca w domu faktycznie może mieć sens
  11. Tylko po co w tym projekcie ATB? To chyba najbardziej przepłacona płytka na świecie... Po pierwsze można całość zrobić pod linuksem i bez dodatkowego mikrokontrolera - ale nawet jeśli ten mikrokontroler ma być, to czemu taki potwornie przepłacony staroć? Przy tej płytce to nawet oryginalne Arduino jest tanie, o klonach nawet nie wspominając.
  12. Do niedawna cyberbezpieczeństwo było chyba głównie jako studia podyplomowe (nie polecam). Natomiast teraz cyberbezpieczeństwo pojawia się też jako kierunek studiów np. http://www.elka.pw.edu.pl/Studia/Informacje-dla-kandydatow/Opis-kierunkow-studiow/Cyberbezpieczenstwo
  13. Ze słownika PWN: Jak widzisz nie ma tam nic o działaniu. Można mieć działający program, który nie jest poprawnie napisany, albo niedziałający napisany poprawnie.
  14. To nie jest poprawna odpowiedź - i nie pisz o rozszerzeniach gnu c bo to nie ma sensu. Fajnie że je znasz, ale mieszasz tylko początkującym w głowach i pokazujesz że nie rozumiesz co znaczy język C. Więc tak dla wyjaśnienia: Język C nie obsługuje zagnieżdżonych funkcji. Są dostępne kompilatory, które "rozszerzają" standard C, czyli dodają coś od siebie, np. obiektowość, konstrukcje zależne od sprzętu, czy też zagnieżdżone funkcje. Ale trzeba pamiętać, że to nie jest język C, tylko pewne implementacje w konkretnym kompilatorze - zawsze można napisać własny i dodać do niego instrukcje których nigdzie indziej nie będzie.
  15. Takie głupie pytanie - gdzie w standardzie ANSI C opisane są zagnieżdżone funkcje? Bo rozumiem że mówimy o standardowym C, a nie o rozszerzeniach jakiegoś konkretnego kompilatora.
  16. Największym problemem HAL nie jest uint8_t jako taki, ale brak const przy wysyłaniu. Natomiast w C lepszym rozwiązaniem byłoby użycie void* nawet jeśli to nieco archaiczne - ale oszczędziłoby używania konwersji tam gdzie nie jest to konieczne. Tym bardziej że wysyłane dane nie zawsze są w 8-bitowych bajtach. Natomiast czy trzeba zmieniać język programowania to bym polemizował. Wystarczy nauczyć się używać tego co się ma.
  17. Trzy dni to krótko, wręcz standardowy czas na znalezienie błędu Oczywiście nie zawsze można pomijać czy zmienna jest ze znakiem, czy bez - chodziło mi o ten konkretny przypadek i napisy w 7-bitowym ASCII. A wyjaśniając - właśnie dlatego wprowadzono typy w rodzaju int8_t, uint8_t i podobne, żeby uniknąć różnic wynikających z wersji, czy parametrów kompilatora. Stare typy w C mają niestety taką cechę, że mogą mieć różną reprezentację w zależności od środowiska - przykładowo int może mieć 16, albo 32 bity, char może być ze znakiem lub bez itd.
  18. uint8_t to najzwyklejszy, w dodatku 8-bitowy bajt. W języku C odpowiada dokładnie unsigned char. Zarówno signed char i unsigned char zajmują 8-bitów, różnica polega na interpretacji najwyższego bitu, czyli liczby ze znakiem lub bez. Sam typ char niestety nie wiadomo czy jest signed, czy unsigned - ale ew. pomyłka nie jest krytyczna. Kompilator ostrzega że typ jest inny, ale nic złego się nie dzieje. Biblioteka HAL jest delikatnie mówiąc przeciętna, używanie uint8_t jako typu bufora jest marnym pomysłem, ale ST potrafi produkować dobre mikorokontrolery, z programowaniem u nich gorzej. Nie pozostaje więc nic innego jak rzutować typ wskaźnika (rzutowany jest typ wskaźnika, nie same dane). Odbieranie po jednym bajcie jest oczywiście mało wydajne, ale nie jest błędem. Tym co było najgorsze w programie to brak miejsca na znak końca napisu, czyli '\0' - trzeba o tym pamiętać, że w języku C napisy są przechowywane z zerem na końcu. Czyli żeby zapisać łańcuch o długości 4 znaków potrzebna jest tablica o długości 5.
  19. Naucz się chłopie czym się różni CubeMX od Cube - bo z cubemx raczej ciężko coś wycinać. To tylko aplikacja napisana w javie, jak Arduino IDE.
  20. Chyba pomyliło ci się Cube z CubeMX. Można używać Cube HAL nie dotykając CubeMX. Inna sprawa że TCP bazuje na lwIP, więc nie ma potrzeby nawet HAL dotykać. A co do USB to w przypadku device czemu nie zrobić samemu, to wcale nie takie trudne.
  21. Potwierdzam pierwszą część, ale nie zgadzam się że jest nieodzowny Nawet z zegarami lepiej sobie poradzić bez niego, chociaż może być pomocny jako kalkulator - o ile akurat działa. A przy okazji polecam przeczytać komentarz na początku wygenerowanego przez CubeMX kodu... Prawa autorskie do pliku z funkcją main ma ST.
  22. Czyli jednak piszesz głupoty, bo nie masz nic innego do roboty. W sumie to przykre.
  23. Skoro piszesz tylko banalne programiki sterujące diodami to nic dziwnego, że asember nie jest ci potrzebny. Ale skąd masz dane że 98% osób na tym forum nie używa debuggera to chyba napiszesz, bo przecież nie wymyśliłeś tych danych i głupot nie piszesz, prawda?
  24. Ja tylko wspomnę, że ARM to nie tylko Cortex-M więc to co zostało wcześniej napisane nie jest prawdą - w przypadku Cortex-M ogólnie się zgadza, ale już na Cortex-A nie. Natomiast znajomość asemblera bardzo się przydaje, chociażby podczas debugowania. Poza tym w Cortex-A jest potrzebna przy obsłudze przerwań, ale nawet na Cortex-M kod wykonywany przed wejściem do main jest napisany w asemblerze. Natomiast poleganie na tym co ST dostarcza nie zawsze wystarcza.
  25. To zmień księgowość i przestań wypisywać bzdury na forach internetowych.
×
×
  • Utwórz nowe...