ethanak

OK - mój błąd.

Wcale nie oszukiwałem! Po prostu zawsze staram się trzymać w jednym pliku konkretny fragment kodu. LTO zadziała tylko jeśli wszystkie pliki kompilowane są jednocześnie - builder Arduino IDE kompiluje je oddzielnie, czyli nic nie zmieni.

Strzelam: bo autor w programie posługuje się zamiast nazwami pinów NodeMCU (np. D6, co oznacza GPIO12, czyli pin do dyspozycji programisty grzecznie podłączony do nogi oznaczonej D6 na NodeMCU) cyferkami (np. 6, co oznacza GPIO6, który to pin podłączony wyłącznie wewnętrznie odpowiedzialny jest za komunikację z pamięcią flash i próba jakichś operacji na tym pinie powoduje natychmiastowy crash)?

Nie zauważyłeś, że tu nie ma nieużywanych śmieci. Przy dokładnie takich samych opcjach jak Twoje mam: $ avr-size sg1.elf text data bss dec hex filename 214 2 0 216 d8 sg1.elf $ avr-size sg2.elf text data bss dec hex filename 188 0 0 188 bc sg2.elf

No to troszkę inaczej, czyli bliżej rzeczywistości. Plik dw.cpp identyczny w obu przypadkach: void digitalWrite(int pin, int value) { volatile int a = pin; volatile int b = value; } Zestaw pierwszy: plik sc1.cpp: #include "testy1.h" const int PIN = 7; int main(void) { pinOn(); } plik sd1.cpp: #include "testy1.h" void pinOn(void) { digitalWrite(PIN,1); } plik testy1.h: extern void pinOn(void); extern const int PIN; extern void digitalWrite(int, int); Zestaw drugi: plik sc2.cpp: #include "testy2.h" int main(void) { pinOn(); } plik sd2.cpp: #include "testy2.h" void pinOn(void) { digitalWrite(PIN,1); } plik testy2.h: extern void pinOn(void); #define PIN 7 extern void digitalWrite(int, int); I teraz kompilacja: $ avr-gcc -Os -o s1.elf sc1.cpp sd1.cpp dw.cpp $ avr-gcc -Os -o s2.elf sc2.cpp sd2.cpp dw.cpp $ avr-size s1.elf text data bss dec hex filename 80 2 0 82 52 s1.elf $ avr-size s2.elf text data bss dec hex filename 52 0 0 52 34 s2.elf Jak widać, w przypadku const kod jest dłuższy, a w sekcji data mamy naszego pina Przypadek ze static pominąłem.

No ale to już jest naciąganie - sztuczne tworzenie zmiennych statycznych. Jeśli program składa się z więcej niż jednego pliku (co jest raczej normalne przy czymś poważniejszym niż "Hello world") tworzenie identycznych statycznych zmiennych nie jest raczej dobrą praktyką. Owszem - można w jakimś pliku "cośtam.h" zdefiniować "static const int cośtam = ileśtam" i inkludować go gdzie się da - ale czy nie jest to po prostu próba ominięcia #define (które w pojęciu zatwardziałych cdwuplosowców jest be i fujaste i powinno wylecieć z języka)?

Zaraz zaraz... Kod pierwszy: extern void digitalWrite(int, int); #define PIN 2 int main(void) { digitalWrite(PIN,1); } Kod drugi: extern void digitalWrite(int, int); const int PIN = 2; int main(void) { digitalWrite(PIN,1); } I teraz: $ avr-gcc -Os -S -o k1.s k1.c $ avr-gcc -Os -S -o k2.s k2.c $ diff k1.s k2.s 1c1 < .file "k1.c" --- > .file "k2.c" 23a24,29 > .global PIN > .section .rodata > .type PIN, @object > .size PIN, 2 > PIN: > .word 2 24a31 > .global __do_copy_data Gdzie to takie same? Co robię źle?

W poprawnie napisanym tak...

Możesz jeszcze spróbować zmniejszyć w programie prędkość I2C.

Poniższa dyskusja została wydzielona z innego tematu od poniższego miejsca: ----- No - różnica jest, i to wielka. const tworzy zmienną, która nie pozwala do siebie nic wstawić. Możliwy jest odnośnik lub wskaźnik do takiej zmiennej, a zmienna zajmuje ileśtam bajtów w RAM-ie. #define nic nie tworzy, po prostu preprocesor w miejsce symbolu wstawia jego rozwinięcie. Nie ma żadnej zajętości pamięci, ale jeśli rozwinięciem jest literał - nie możemy użyć referencji czy wskaźnika. Czyli: void fun(const int *); const int a = 7; #define b 7 fun(&a); // dobrze fun(&b); // błąd - preprocesor przetworzy to na fun(&7) Osobiście wolę #define czy enum, bo istnieją tylko w czasie kompilacji, a w maciupciej pamięci AVR-a (gdzie każdy bajt się liczy) nie widzę potrzeby zajmowania ani jednego bajtu na jakieś consty. Przy okazji - nieprawidłowe użycie const może doprowadzić do bardzo trudnych do znalezienia błędów. Oto przykład kodu w C/C++ - odpowiedzcie na pytania bez angażowania kompilatora : #include <stdio.h> const int a = 7; void fun(int *x) { *x=11; } int main(void) { fun((int *)&a); printf("%d\n",a); } Czy ten program się skompiluje? Jeśli tak, jaki będzie wynik jego wykonania np. pod Linuksem? Podobny szkic dla Arduino: const int a = 7; void setup(void) { Serial.begin(9600); *(int *)&a = 11; Serial.println(a); } void loop(void) { } Czy program się skompiluje? Jeśli tak, co wypisze

To by się zgadzało - ja wyczytałem że maksymalna długość kabla do SPI to 20 stóp, czyli mniej więcej tyle samo. Czemu Arduino a nie RPi? Jak dobrze policzysz to cenowo wyjdzie podobnie... poza tym w porównaniu do cen silników i sterowników RPi to taki mały dodatek Mam kamerkę (taką za niecałe 50 PLN) do RPi Zero, całkiem nieźle się sprawdza.

Pad działa na SPI - 20 metrów raczej czarno widzę. Coś mi się wydaje że zaczynasz oszczędzać, tylko nie na tym co trzeba. Masz w praktyce możliwość albo ethernet, albo RS232. I to i to wymaga czegoś takiego jak nadajnik i odbiornik, bez nich możesz się łączyć na 20 centymetrów a nie 20 metrów. Przemyśl to. I weź pod uwagę, że klon Arduino Pro Mini kosztuje na Allegro coś koło dychy, a na Ali połowę tego. Porównaj z ceną silnika.

A to ma szanse zadziałać.

Najprościej tak (a najtaniej klon Arduino Nano).

Będzie to działać tak, że dopóki trzymasz palec na czujniku przekaźnik będzie załączony, a jak puścisz to i przekaźnik puści. Jeśli takie jest założenie to owszem, tyle od biedy wystarczy.