Do dokończenia najnowszego projektu jest mi potrzebna biblioteka do obsługi modułu RFM69 (w moim przypadku RFM69HCW).
Niestety najwyraźniej jak dotąd nie powstała wersja pod AVR-y (albo chociażby pod "czyste" C, z niskopoziomowymi funkcjami do samodzielnego uzupełnienia). Na GitHubie znalazłem jedynie bibliotekę dla Arduino, napisaną w C++. Trzeba będzie ją przerobić. Kod można znaleźć TUTAJ
W C++ nigdy nie pisałem niczego bardziej złożonego, ale jestem w stanie zrozumieć sens kodu, poza tym miałem też do czynienia z Arduino, więc myślę, że odróżnię większość poleceń typowych dla środowiska wiring.

Mam jednak kilka pytań, co do kilku kwestii chciałem się też upewnić, zanim stracę czas na wprowadzanie zmian, które potem okażą się zupełnie niepotrzebne.

1) Jak rozumiem, na samym początku powinienem pozbyć się klasy RFM69 i wszystkie zawarte w niej funkcje i uczynić najzwyklejszymi funkcjami języka C, nazywając je np. wedle schematu RFM69_nazwa(). Tylko jak przy okazji tego procesu potraktować funkcje i zmienne o statusie "public" i "protected"? Jakie są ich odpowiedniki w C?

2) Widzę, że niektóre z funkcji mają argumenty już na starcie zainicjowane jakąś wartością, np.



W przypadku C nigdy nie spotkałem się z taką konstrukcją. Czyżby była to właściwość języka C++? Jeśli tak, to w jaki sposób potraktować ją podczas konwersji do C?

3) Defnicja klasy RFM69 w pliku nagłówkowym RFM69.h zawiera następujący fragment (sekcja public):



Wygląda jak funkcja, ale jest umieszczona w dość nietypowym miejscu jak na funkcję. Czemu to służy i czym to zastąpić w C?

4) Do czego służy wskaźnik static RFM69* selfPointer?

5) Czy w przypadku C również dopuszczalne jest umieszczenie wśród argumentów funkcji wskaźnika na void, do którego potem podstawia się bufor dowolnego typu? Czy może raczej powinienem się twardo trzymać jednego typu danych, np. uint8_t albo char?

6) W obsługujących transmisję widzę instrukcje odpowiadające za zapisywanie i odtwarzanie konfiguracji SPI (zmienne _SPCR i SPSR). Rozumiem, że nie mając na magistrali żadnego innego urządzenia mogę sobie darować tę część?

7) Dlaczego właściwie w czystym C pod AVR-ami praktycznie nie stosuje się zmiennych bool? Jest to związane z jakąś ważną przyczyną? Powinienem pozamieniać je na uint8_t, czy mogę spokojnie dołączyć odpowiedni plik nagłówkowy i zostawić kod w obecnej postaci.

1. Niekoniecznie pozbyć, zawsze można pisać w dalszym ciągu w C++, ale już na innej platformie. Nie będzie wtedy potrzeby zmiany czegokolwiek . Zarówno Atmel Studio, jak i Eclipse wspiera ten język, więc jeśli Ci to odpowiada to jak najbardziej można używać tego języka.
Funkcje w klasie nazywają się metodami i oczywiście można je nazywać dowolnie. Kwalifikator "public" może być traktowany jako nazwy eksportowane na zewnątrz biblioteki tzn. deklaracje zawarte w pliku *.h. Natomiast "protected" to takie, które nie wymagają, a co więcej nie mogą być udostępniane na zewnątrz tzn. z modyfikatorem "static" w pliku *.c.

2. "Czysty" język C nie daje możliwości używania argumentów domyślnych funkcji, jednak w "avr-gcc" taką funkcjonalność wspiera. Można też odrzucić parametry domyślne, skazując się w ten sposób na konieczność ich podawania.
Ciężko ją w jakiś sposób "emulować"... Należałoby przeciążyć funkcję (dla większej ilości argumentów domyślnych dość żmudne), a następnie na początku ciała jednej z nich domniemać (przypisać) wartość domyślną (w tym wypadku "true").

3. Podobnie jak w pkt. 2. z tym że ten konstruktor służy inicjalizacji niezbędnych pól obiektu. Można zastąpić funkcją typu "RFM69_Init" pomijając przypisania argumentów domyślnych.

4. Ciężko jednoznacznie powiedzieć, bo zależy od jego umiejscowienia w kodzie... Jeśli znajduje się w klasie to jest to pojedyncze pole (zmienna), która przechowuje wskaźnik do pewnego obiektu klasy "RFM69".

5. Jak najbardziej jest to możliwe.

6. Raczej tak.

7. Nie ma ich w standardzie, a dlaczego to dokładnie sam nie wiem , jednak wydaje mi się że przechowywanie jednego bitu informacji i tak wymagało użycia komórek 8-mio bitowych stąd też taki typ pominięto, ale zaznaczam jest to tylko moje przypuszczenie dlaczego takiego typu nie ma.
Można dołączyć bibliotekę <stdbool.h>, pozamieniać wszystkie wystąpienia typu bool na uint8_t, zdefiniować nowy typ (typedef uint8_t bool) lub użyć preprocesora (#define bool uint8_t, #define true 1, #define false 0).

Chwileczkę, nie wiem czy dobrze zrozumiałem. Mogę "mieszać" obydwa języki? To znaczy "wziąć" już gotowy projekt pisany od początku w C i dodać do niego bibliotekę C++, podmieniając jedynie elementy charakterystyczne dla Arduino na ich odpowiedniki AVR (np. Wiring na niskopoziomową obsługę pinów I/O)?
Czy też miałeś na myśli to, że mogę utworzyć projekt na nowo, dodać bibliotekę napisaną w C++ i przepisać resztę tak, żeby do niej pasowała?
Bo w tym drugim przypadku to na dobrą sprawę mógłbym wgrać do urządzenia bootloader Arduino i napisać wszystko od nowa w tym środowisku. Niby jest to jakieś rozwiązanie, ale nie wiem, czy przeportowanie biblioteki nie będzie mniej uciążliwe.




Czyli te elementy mogę zostawić tak, jak są? Będą działały również w przypadku programu napisanego w C?
Jak właściwie wygląda wywołanie takiej funkcji, żeby uwzględniona została wartość domyślna?




Tak, znajduje się w klasie. Czy w związku z tym mogę ten element po prostu usunąć, jako specyficzny dla C++, czy też będę musiał go w jakiś sposób "zaemulować"?

Odnośnie Twoich pytań Atlantis to oczywiście chodziło mi o nowy projekt w całości napisany w C++ (niekoniecznie pod platformę Arduino).
Tak jak napisał wyżej Kol. mokrowski w C++ jest ta "potęga", że można w nim pisać tak jak w zwykłym C, a na dodatek daje o wiele większe możliwości. Jednak rozwiązanie konstrukcji C++ w C jest nie do końca możliwe o czym świadczy założony przez Ciebie temat.

Ze swojej strony zdecydowanie bardziej polecam C++ nawet dla początkujących, bo przecież to taki "C na sterydach".
Jak to ktoś kiedyś powiedział (albo i nie ): "Najpiękniejsze w obiektowości C++ jest to, że nie trzeba wcale z niej korzystać".

Wywołania funckji z parametramy domyślnymi mogą wyglądać następująco:


Usunąć tej zmiennej (static RFM69* selfPointer) raczej nie możesz. Piszę raczej, bo to wszystko zależy od kodu i zastosowania tej zmiennej w nim. Jednak bez powodu taka zmienna została tam utworzona...
Ogólnie to nie jest to jakaś specyficzna konstrukcja C++, ot po prostu jakaś zmienna statyczna (w tym wypadku istniejąca jedna jej instancja dla całej klasy, a nie dla poszczególnych obiektów).


Oczywiście że tak jednak nie zmartwiłeś mnie tym faktem . Doskonale zdaję sobie sprawę ze znaczenia "protected", jednak było to moje uproszczenie dla potrzeb prostej i jasnej odpowiedzi. Skoro brak dziedziczenia w C to ciężko w ogóle mówić o rozróżnianiu "protected" od "private", czyż nie tak?


Dobrze wiedzieć, jednak w takim razie nie jest on typem wbudowanym dla wszystkich kompilatorów.

Ogólnie makra i #define to nie są najlepsze konstrukcje i przez wielu określane jako "zło". Dlatego możliwość ich użycia podałem jako czwarty, ostatni możliwy wariant. Zdecydowanie lepiej użyć wbudowanej biblioteki <stdbool.h>.

Dziękuję za wszystkie porady. Teraz muszę przemyśleć która droga będzie najbardziej odpowiednia. Mam dwa, a właściwie trzy wyjścia (przy czym trzeciego nie biorę pod uwagę).

1) Przeportowanie biblioteki z C++ do C. Może być dosyć trudne, poza tym istnieje spora szansa, że po drodze coś popsuję w kodzie ze względu na niewystarczające zrozumienie specyfiki C++. Jeśli się uda, będę miał gotową bibliotekę do zastosowania w przyszłych projektach (a na tym też mi zależy).
2) Przeniesienie projektu z C do C++, wykorzystanie biblioteki z Arduino, zmodyfikowanej pod kątem funkcji niskopoziomowych. Chyba łatwiejsze rozwiązanie, jeśli faktycznie mogę w projekcie C++ wykorzystywać istniejące biblioteki C.
3) Wgranie do urządzenia bootloadera Arduino i przepisanie wszystkiego od nowa, z wykorzystaniem tego środowiska. Rozwiązanie najbardziej żmudne (istniejący kod nie jest do końca kompatybilny z Arduino i trzeba by go pisać od nowa) ale najmniej skomplikowane (nie wymagające żadnych nowych informacji).

Tak swoją drogą może istnieje szansa, że ktoś już równolegle pracuje nad taką biblioteką do RFM69?

Ja już ją mam na ukończeniu .... Pisząc ją od totalnego ZERA, bo oczywiście przeglądając te wszystkie kody z netu jak zwykle nie pasowało mi w nich praktycznie wszystko ... Podejście typowe dla hoperf'aów - czysta masakra ... Takie same problemy miałem pisząc kiedyś swoje LIBS'y do RFM12 czy RFM70 ... no ale jak już wyszły - to teraz korzystanie z tych modułów to poezja. A powiem, że ten RFM69 też jest wart grzechu .... nie dość że można nim jeśli chodzi o HARDWARE zastąpić (bo pinologicznie się zgadza) starego RFM12 to jeszcze można zrobić nawet tak że RFM69 będzie sobie swobodnie mógł "gadać" z tymi RFM12 ... nie wspomnę już o szaleńczym zasięgu modułów RFM69 i to wcale nie tych WH, ja testuję wersję CW ... i rzeczywiście w porównaniu do i tak dobrego pod tym względem RFM12 - nowszy brat RFM69CW - śmiga jak ta lala

ale niestety ukażą się te moje wypociny dopiero w nowym poprawionym wydaniu GreenBooka - być może jeszcze przed końcem tego roku. Z tym że czytelnicy posiadający już starsze wydanie książki będą mogli skorzystać z takiego samego przywileju jak poprzednio przy Bluebooku, że będą mogli nabyć samą płytę DVD od nowego Greenbooka . Więc tą drogą też będzie można mieć tego LIB'sa.

Ale sądzę, że do tego czasu to pewnie sam już temat roztrzaskasz.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

W takim razie będę czekał z niecierpliwością, chociaż w międzyczasie oczywiście spróbuję coś zrobić z tą biblioteką.
Swoją drogą jakich nowości można jeszcze spodziewać się na tej płycie, jeśli można zapytać?

Poprawione biblioteki tzn przeportowane z RFM70 do RFM73

i być może jeszcze kilka innych drobiazgów

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]