Skocz do zawartości

Matthew11

Użytkownicy
  • Zawartość

    39
  • Rejestracja

  • Ostatnio

Wszystko napisane przez Matthew11

  1. getBytes zwraca size_t jeśli mamy być poprawni, ale przyjmuje void * buf, więc rzutujesz na void* -> getBytes(key, (void *)tablica, 10);
  2. Okej, zatem void * oznacza wskaźnik na nieokreślony typ, Ty jako programista musisz zadbać na na jaki typ ten wskaźnik będzie wskazywał wykorzystując rzutowanie - więcej info: https://pl.wikipedia.org/wiki/Pusty_typ_danych#Definiowanie_wskaźników_do_danych_nieokreślonego_typu A przykładowe pisanie do abstrakcyjnego EEPROMu może wyglądać tak (uruchom w kompilatorze C++): // Example program #include <iostream> #include <string> #include <cstring> static uint8_t eepromMemory[256]; void write(const void* source, uint8_t size, uint8_t startIndex) { memcpy((eepromMemory + startIndex), source, size); } void read(void* destination, uint8_t size, uint8_t startIndex) { memcpy(destination, eepromMemory + startIndex, size); } int main() { int8_t dataToSave[4] = {-1, 0, 1, 2}; int8_t dataFromEeprom[4]; for(uint8_t i = 0; i < 4; i++) { printf("Item to save: %d \tValue: %d\n", i, dataToSave[i]); } printf("\n"); // rzutuje dataToSave na const void* write(reinterpret_cast<const void*>(dataToSave), 4*sizeof(int8_t), 5); for(uint8_t i = 0; i < 20; i++) { printf("Item in EEPROM: %d \tValue: %d\n", i, eepromMemory[i]); } printf("\n"); // rzutuje dataFromEeprom na void* read(reinterpret_cast<void*>(dataFromEeprom), 4*sizeof(int8_t), 5); for(uint8_t i = 0; i < 4; i++) { printf("Item retrieved from EEPROM: %d \tValue: %d\n", i, dataFromEeprom[i]); } return 0; } Efekt: Item to save: 0 Value: -1 Item to save: 1 Value: 0 Item to save: 2 Value: 1 Item to save: 3 Value: 2 Item in EEPROM: 0 Value: 0 Item in EEPROM: 1 Value: 0 Item in EEPROM: 2 Value: 0 Item in EEPROM: 3 Value: 0 Item in EEPROM: 4 Value: 0 Item in EEPROM: 5 Value: 255 Item in EEPROM: 6 Value: 0 Item in EEPROM: 7 Value: 1 Item in EEPROM: 8 Value: 2 Item in EEPROM: 9 Value: 0 Item in EEPROM: 10 Value: 0 Item in EEPROM: 11 Value: 0 Item in EEPROM: 12 Value: 0 Item in EEPROM: 13 Value: 0 Item in EEPROM: 14 Value: 0 Item in EEPROM: 15 Value: 0 Item in EEPROM: 16 Value: 0 Item in EEPROM: 17 Value: 0 Item in EEPROM: 18 Value: 0 Item in EEPROM: 19 Value: 0 Item retrieved from EEPROM: 0 Value: -1 Item retrieved from EEPROM: 1 Value: 0 Item retrieved from EEPROM: 2 Value: 1 Item retrieved from EEPROM: 3 Value: 2
  3. Nie do końca rozumiem co chcesz osiągnąć. Po co chcesz zamieniać tablicę typów int8_t na ciąg bajtów - skoro twoja tablica typów int8_t jest ciągiem bajtów sama w sobie - więc masz to tak jakby w gratisie. Chyba że przez 'bajt' rozumiemy liczbę bez znaku (0 - 255), co nadal nie zmienia faktu, że tablica jest ciągiem bajtów.
  4. Okej, to może pytanie bardziej z gatunku wiedzy o składni: Zakładając, że mamy tablicę: int arr[5] = {1,2,3,4,5}; Oraz interesuje nas element o indeksie: const int idx = 2; // zwróć liczbę 3 Wypisz wszystkie możliwe sposoby na uzyskanie dostępu do wartości elementu o indeksie 2, czyli wartości = 3, korzystając z C lub C++ (bez użycia wstawek assemblerowych).
  5. Co więcej jest darmowy nawet do użytku komercyjnego (bardzo dobra opcja dla startupu): https://www.autodesk.com/campaigns/fusion-360-for-hobbyists: "Fusion 360 is free for startups generating less than $100K per year in total revenue or wholly non-commercial hobbyist users"
  6. Ślędzę wątek od samego początku i coś w tych "wątkach" mi nie gra tak jak nie gra @ethanak . @wojtekizk napisałeś kilka postów wcześniej, że nie ma żadnego problemu z blokującymi funkcjami - podałeś przykład DS18B20 - że wystarczy je wrzucić do pętli razem z pracującym tam obiektem Timers i wszytsko się ładnie wykona w zadanych interwałach niezależenie od tego czy odczyt z czujnika będzie trwał np. 750ms a my np. chcemy z f = 1kHz sterować silnikiem. No i właśnie o to zapewne chodzi @ethanak że w obecnej formie klasa Timers nie zapewni nam pożądanego efektu. Bo niema tutaj - w takiej formie jak to przedstawiasz - mowy o tych prawdziwych wątkach, tylko nieblokującym sprawdzaniu timeout'ów.
  7. @Dominik111 Cześć, nieco ponad rok temu przez kilka miesięcy rozwijałem swój projekt drona. Celowałem w średniego drona (650mm rama i do 1-2 kg uciągu). Moim głównym założeniem było wykonanie wszystkiego od zera - kontrolera lotu od zera, zdalnego sterowania, firmware dla sterowników (jedynymi gotowymi komponentami były ESC do silników). Zrobiłem do tego aplikację na Androida (kontrola w bliskim zasięgu) i kontrola w dalekim zasięgu (zrobiłem do tego też swoją własną aparaturę RC). Udało mi się doprowadzić do wzbicia drona w górę i chwilowego utrzymania stabilnej pozycji w powietrzu, ale bez większych fajerwerków. Napisałem do tego ogrom oprogramowania i to co się nauczyłem to moje, ale nie nazwałbym całokształtu sukcesem. Moje doświadczenia: zrobienie własnego drona to bardzo dobry sposób na poszerzenie własnej wiedzy - pisałem aplikacje na PC, Androida i firmware do sterowników, używałem też MATLABA, testowałem też różne filtry do fuzji odczytów z IMU. Generalnie przeszedłem przez dużo ciekawych zagadnień Złe strony: próba wykonania większości od zera niekoniecznie popłaca - lepiej niektóre komponenty wybrać spośród tych dostępnych komercyjnie. Doprowadzenie własnego kontrolera lotu do stabilnej wersji to dość ciężki orzech do zgryzienia. Miałem duże problemy z utrzymaniem stabilności. Prawdopodobnie przez kiepski moduł IMU (komercyjne kontrolery mają nawet po 3 niezależne IMU). Dlatego uważam że lepszym pomysłem było by kupienie gotowego kontrolera lotu co zaoszczędziło by mi sporo czasu i nerwów. Jeśli jesteś zainteresowany tematem to ma moim githubie znajdziesz moje wszystkie programy (do sterownika, aparatury i aplikacji czy poszczególnych modułów) jak również pełną specyfikację. Większość softu jest na bardzo liberalnych licencjach więc możesz śmiało korzystać. Chętnie pomogę jeśli będziesz miał jakieś pytania związane z tematem.
  8. @Treker @matimoto87 Panowie, może posiadacie taką wiedzę - jak wygląda sprawa z licencją tego oprogramowania w przypadku zastosowania komercyjnego?
  9. @klarec W takim razie problemem może być CH340. Więc pozostaje Ci faktycznie opcja z natywnym Serialem - SerialUSB.
  10. @klarec Sprawdziłem właśnie u siebie korzystając z Due - wgrałem identyczny soft jak w kursie - korzystam z Serial (Serial0) i nie mam żadnych problemów z komunikacją w obie strony. Czy Qt otworzyło Ci port bez problemu? Możesz wykorzystać sygnał QSerialPort::errorOccurred żeby zobaczyć błąd jeśli jakiś się pojawi: //mainwindow.h: private slots: //... void onErrorOccurred(QSerialPort::SerialPortError error); // mianwindow.cpp: MainWindow::MainWindow(QWidget *parent) : //... { //... connect(device, SIGNAL(errorOccurred(QSerialPort::SerialPortError)), this, SLOT(onErrorOccurred(QSerialPort::SerialPortError))); } void MainWindow::onErrorOccurred(QSerialPort::SerialPortError error) { qDebug() << error << device->error(); } Może sprawa dotyczy dostępu do portu? Może np. IDE otworzyło port i go nie zamknęło, wtedy ponowne otwarcie i zamknięcie portu go odblokowało? Może problem wynika z tego, że korzystasz z SerialUSB - na Serial jest to samo?
  11. Ja tylko dodam, że jest też rodzina płytek Teensy. Od wersji płytek 3.x wszystkie pracują na rdzeniach ARM. Można programować z poziomu Arduino IDE - biblioteki niskopoziomowe są napisane w C, a API zgodne z Arduino napisane w postaci wrapperów w C++ dla większości klas które występują w Arduino. Więc nadal masz zapewnioną wygodę w postaci zalet C++ ale równie dobrze możesz się odwoływać do funkcji napisanych w C jeśli zależy Ci na większej wydajności. Teensy ma do tego bardzo prężnie działającą społeczność i sam twórca jest dostępny mailowo lub udziela się na forum. Jak ktoś jest zainteresowany to zdecydowanie polecam pisać w Visual Studio Code z dodatkiem PlatformIO (nie tylko w przypadku Teensy, ale ogólnie wszystkiego co jest zgodne z Arduino).
  12. @rziomber Kurs na samym początku zakładał tylko cztery części - wprowadzenie do Qt, port szeregowy, Android i Bluetooth - podstawowe rzeczy, które mogą być przydatne w projektach. Zobaczymy może powstanie więcej części np. o QtQuick i QML oraz sieciach (TCP, UDP). Jeśli chodzi o sygnały i sloty to polecam Pana o którym wspominałem w pierwszej części: - https://www.youtube.com/watch?v=JtyCM4BTbYo, - https://www.youtube.com/watch?v=qEGRYYx0RBw Jest też taka książka (jest ich więcej w sieci) - http://www-cs.ccny.cuny.edu/~wolberg/cs221/qt/books/C++-GUI-Programming-with-Qt-4-1st-ed.pdf - rozdział 2 Signals and Slots in Depth I tak, w twojej aplikacji rozsyłającej SMS masz bardzo dobry przykład użycia tego mechanizmu.
  13. Aktualizacja: Moje obecne ustawienia na świeżym Ubuntu 18.04.2 LTS: Qt 5.12.4 openJDK NDK 19c (19.2.5345600) SDK 26 (26.1.1) Przy NDK 20 nie byłem w stanie zbudować nic na Androida. Brakowało mi też kilku narzędzi i pakietów - problem mogły załatwić poniższe komendy (nie wiem, która dokładnie): sudo apt install build-essential sudo apt install clang sudo apt install libgl1-mesa-dev Gdyby kogoś irytował fakt, że powtarzają mu się narzędzia w opcjach i przy ich wyborze to należy wyczyścić ustawienia które gromadzi QtCreator: rm -rf ~/.config/QtProject ~/.local/share/data/QtProject/qtcreator
  14. @rziomber Problemy, które pojawiły się u Ciebie czyli np. wspomniana chęć użycia socketu czy agenta w obrębie kilku klas pojawiają się nieco automatycznie z racji że poruszamy się między klasami, które często są pochodnymi QWidget - chcielibyśmy np, wykonać kilka operacji na tych obiektach z różnych okien (QWidget). Sama technologia widgetów w Qt już jest nieco stara, ale nadal użyteczna i pomaga szybko coś zbudować - stworzenie GUI zajmuje krótką chwilę i możemy zająć się programowaniem logiki. Natomiast już gorzej nadaje się do tworzenia interfejsów aplikacji mobilnych. Możemy pozbyć się części problemów (ale też wpakować w inne) korzystając z nowej technologii dostarczonej przez Qt - QtQuick. Która skierowana jest na tworzenie aplikacji mobilnych właśnie. Tam mamy jasne rozdzielenie spraw frontendowych i backendowych. Mamy kilka możliwości, ale interesująca może być ta gdzie obsługę wspomnianego BT napisalibyśmy wyłącznie w C++ np. jedna konkretna klasa lub moduł, który nie ma nic wspólnego z wyglądem aplikacji a dostarcza jedynie informacji dla obsługi interfejsu lub przekazuje input użytkownika. Natomiast interfejs napisalibyśmy w QML (język stworzony przez Qt, wykorzystuje JavaScript) i jedynie wywoływalibyśmy bezpośrednio metody, które zdefiniowaliśmy w naszej klasie napisanej w C++. Co więcej obsługa sygnałów i slotów między QML i C++ również jest w pełni wspierana. Przejście na QtQuick na początku jest nieco problematyczne i ciężkie w przestawieniu na nowe mechanizmy , ale jak już zrozumie się mechanizmy integracji C++ z QML to dostajemy bardzo potężne narzędzie.
  15. Cześć @rziomber. Metoda, którą użyłeś readLine() według dokumentacji nie ma możliwości zwracania błędów więc nie dowiesz się czy dzieje się coś złego. Spróbuj printować wszystko co przychodzi w konsoli qDebug() << socket.readAll() - jak zobaczysz że nadal brakuje danych to problem leży raczej po stronie BT. Może zdarza się tak, że część danych (pierwsze znaki) "przychodzą" wraz z jednym sygnałem readyRead() a reszta z kolejnym. Zamiast czytania pojedynczych linii, spróbuj wykorzystać readAll() i gromdzić dane w jakimś buforze np. QByteArray jako member MainWindow i dopiero w tym buforze szukaj linii. Jeśli tracisz zawsze początek danych to strzelam, że wina leży w metodzie odczytu z socketu. Odnośnie wskaźników to nie sądze, żeby dobrym pomysłem było eksponowanie ich poza klasę. Raczej stworzyłbym kilka metod w tej klasie, w ktorej korzystam z socketu i agenta i tylko te udostępnił poza klasą i to za ich pomocą korzystał z QBluetoothDeviceDiscoveryAgent i QBluetoothSocket jeśli byłaby taka potrzeba. Więc przechowywałbym je jedynie w klasie, która obsługuje socket i agenta i z tej klasy korzystał. Przy okazji, podczas tworzenia nowych obiektów klas Qt -> new QBluetoothDeviceDiscoveryAgent używaj new QBluetoothDeviceDiscoveryAgent(this) albo sam zadbaj o zwolnienie pamięci po tych obiektach. Więcej info tutaj: https://doc.qt.io/qt-5/objecttrees.html#overview
  16. @akuch2 Moja konfiguracja na Ubuntu 18.04: Narzędzia Qt: openJDK: Instalacja: https://openjdk.java.net/install/index.html Standardowo ścieżka którą należy dodać w Qt powinna wygląda tak: /usr/lib/jvm/java-8-openjdk-amd64 możesz to też sprawdzić urchamiając w terminalu: "update-alternatives --list java". NDK i SDK tak samo jak na Windows u mnie konkretne wersje to SDK Version: 26.1.1, NDK Version: 19.2.5345600
  17. Z pinów potrzebujesz RX i TX (które masz pewnie wolne)
  18. A gdyby tak faktycznie wstawić moduł Bluetooth (pisałeś o tym w jednym z pierwszych postów) i... napisać aplikację (bardzo prostą!) w Qt i ustawiać czas na uC na aktualny z Twojego telefonu jednym kliknięciem przycisku? Mógłbyś się wtedy całkowicie pozbyć klawiatury. Masz prawie wszystko dostępne w kursie a część dotycząca BT pojawi się niebawem. Do nauki będziesz miał więcej ale chyba warto. W razie problemów z Qt pomogę
  19. @sebaskow Jeśli możesz, to podczas testów zapisuj co się dzieje na jakich wersjach narzędzi, może to pomoże rozwiązać problem u innych. Przy okazji, czy pamietasz fakt instalowania Gradle przez Qt?
  20. W takim razie dla osób, którym ostatecznie nie uda się skonfigurować Qt dla Androida pod Windowsem pozostaje zainstalowanie Qt na Linuxie i tam konfiguracja dla Androida, która powinna być zdecydowanie mniej problematyczna. W moim przypadku korzystałem z Ubuntu 18.04 @sp3uqw korzystał z Debiana 9.9. W linku https://doc.qt.io/qt-5/android-getting-started.html#installing-the-prerequisites znajduje się lista potrzebnych narzędzi. Są to te same co w przypadku Windowsa, z tą różnicą, że zamiast Javy od Oracle można skorzytać z OpenJDK.
  21. Okej, wersja Qt 5.12.4 oraz JDK(1.8.0_211) i NDK(r20) takie samo jak u @sp3uqw. Otrzymałem te same błędy, generalnie związane z androiddeployqt np: ...androiddeployqt.exe" exited with code 14. Następnie sprawdziłem wersje NDK r19c, r18b, r17c - efekt taki sam - błąd budowania. Za każdym razem zmiany wersji narzędzi resetowałem QtCreatora. Następnie wróciłem do wersji NDK 18c. I sprawdziłem na wersji JDK 1.8.0_191 - efekt taki sam - błąd budowania. Następnie przypadkowo sprawdziłem na jaką architekturę faktycznie buduję, był to ARM64v8a (Clang 5.12.4 ...), mój telefon to architektura x86 (aplikacja zbudowana pod ARM64v8a zadziała, ale widać gołym okiem, że nieco topornie), więc zmieniłem build na właściwą architekturę czyli x86. I wtedy... Qt ściągnęło mi Gradle, który buduje nam pliki aplikacji w formacie .apk, które potem wędrują na telefon. Fakt, że Qt ściąga nam Gradle zobaczymy w komunikatach kompilatora (pisałem o tym w jednej z części). Po tym jak Qt ściągnęło i zainstalowało Gradle, proces budowania zakończył się sukcesem. @sp3uqw @Mateuh czy podczas waszych procesów budowania zauważyliście, żeby Qt ściągało Gradle? Myśle, że problemem jest właśnie brak Gradle. Jak już udało mi się zbudować raz, to później wróciłem do NDKr20 i JDK1.8.0_211 czyli de facto najnowszych wersji i również nie miałem żadnych problemów z budowaniem na żadną z trzech architektur. Strzelam, że problem wynikał z braku Gradle, którego Qt automatycznie nie ściągało. Ciężko stwierdzić czy akurat zmiana docelowej architektury build'a spowodowała wywołanie procesu instalacji Gradle, ale może to jest sposób? Tak samo ciężko powiedzieć czy moja kombinacja zmian wersji narzędzi miała wpływ na ostateczny sukces - może ale niekoniecznie. W sytuacji gdy, nie uda się zainicjować instalacji Gradle przez Qt, może pomoże ręczna instalacja. Niestety to jest cena, którą trzeba zapłacić za Qt w wersji Open Source. Jak już raz się uda to więcej problemów konfiguracyjnych później nie ma. Z własnego doświadczenia radzę osobom, które tworzą jakiś projekt w Qt i wiążą się z tym jakieś umowy lub deklaracje to polecam nie zmieniać wersji Qt ani narzędzi w trakcie projektu jeśli nie musimy tego robić. A jak musimy to zachowajmy starą konfigurację.
  22. Komunikat wskazuje, że nadal budujesz na wersji 5.13. Sprawdź dla pewności ustawienia w QtCreatorze.
  23. Przy okazji zmiany wersji, Qt ma do tego specjalne narzędzie Qt Maintenance Tool. Instaluje się razem z Qt.
  24. @sp3uqw Problem może też wynikać z błędów (jeśli takie są) w wersji Qt 5.13 (wyszła gdzieś tydzień temu?) z informacji, które wrzuciłeś widać że korzystasz z tej wersji. W trakcie pisania kursu korzystałem z wersji 5.12.0, jak prosiłem @Treker o sprawdzenie to też korzystał z wersji 5.12.0 przy czym wystąpiły problemy z JDK (które musiało być w wersji 1.8 już niższej). @sp3uqw @Mateuh Niestety nie jest to najszybsze rozwiązanie ale, może instalacja Qt w wersji 5.12.0 lub niższej rozwiąże problem na Windows.
  25. @sp3uqw wysłał mi pełną informacje z konsoli, która zaprowadziła mnie tutaj: https://stackoverflow.com/questions/56621970/clang-error-linker-command-failed-with-exit-code-1-qt-android i tutaj: https://forum.qt.io/topic/103713/error-cannot-find-lc-qt-5-12-android/5 Opcje są dwie: 1. Użyć NDK w wersji NDK r19c https://developer.android.com/ndk/downloads/older_releases 2. Dodać zmiany w qmake (post użytkownika Albertino z drugiego linku u samej góry) Może to też być problem z wersją JDK (zdarzały mi się takie). @Mateuh @sp3uqw dajcie znać czy te informacje pomogły. Dla użytkowników Linuxa: miałem przyjemność konfigurować Qt dla Androida na Ubuntu 18.04 - nie miałem żadnych problemów, wszystko udało się za pierwszym razem w przeciwieństwie do moich poprzednich konfiguracji na Windows gdzie problemy miałem zawsze. Dla zainteresowanych wymagane narzędzia: https://doc.qt.io/qt-5/android-getting-started.html#installing-the-prerequisites. Nie rozwiązuje to problemów użytkowników Windowsa, ale jest to jakaś alternatywa.
×
×
  • Utwórz nowe...