Skocz do zawartości

Matthew11

Użytkownicy
  • Zawartość

    60
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    1

Matthew11 wygrał w ostatnim dniu 14 października

Matthew11 ma najbardziej lubianą zawartość!

Reputacja

55 Bardzo dobra

O Matthew11

  • Ranga
    4/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Kraków
  • Języki programowania
    C, C++, QML

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. Wzięte z półki, raczej na pewno nie zadziałają, przynajmniej nie od razu. Arduino to od dawna już nie tylko płytki i biblioteki ale ogromny framework jak inne, gdzie masz setki różnych interfejsów i określonych API. Jeśli twój procesor ma wsparcie Arduino (ktoś napisał drivery), to po dołączeniu wszystkich zależności i bibliotek do peryferiów, które ta konkretna biblioteka potrzebuje raczej powinno ostatecznie zadziałać. Tylko właśnie problem w tym, że tych zależności może być sporo, które mogą wymagać kolejnych. Inna sprawa to fakt, że większość z tych bibliotek jest napisana w C++.
  2. Jak ma być zaawansowanie, ładnie i nowocześnie to ja polecam C++ i framework Qt, a konkretnie technologie QtQuick i QML do budowy interfejsów, a C++ zostaje na cześć bacekend'ową. Polecam Ci wpisać w wyszukiwarkę "built with qt" gdzie znajdziesz studium przypadków użycia Qt w komercyjnych projektach np. https://www.qt.io/ulstein-built-with-qt. Sam na co dzień korzystam z tych technologii i szczerze mówiąc nigdy nie pomyślałem o próbie poszukania czegoś innego. Nie mam dużego doświadczenia ze wspomnianym GTK, ale uważam że wykorzystanie Qt jest znacznie wygodniejsze. Aktualnie pracujemy z @Treker nad kontynuacją kursu Qt i właśnie wszystko nowe (dotyczące interfejsu) będzie oparte w 95% na QtQuick i QML. Więc sama będziesz mogła ocenić czy to jest to czego oczekujesz. Inną, dopiero rosnącą alternatywą jest język Dart i framework Flutter. Flutter to takie cross platformowe Qt stworzone z myślą o urządzeniach mobilnych ale nie tylko, które prawdopodobnie zagarnie część rynku.
  3. Musisz po prostu dodać kontrolkę do wprowadzania tekstu np. https://doc.qt.io/qt-5/qlineedit.html i w niej wpisywać imię badanego, której zawartość możesz na jakiś przycisk dodać do okna logów i/lub wysłać za pomocą metody, która została przedstawiona w artykule. Podałem Ci w poprzedniej wiadomości: "QTextEdit daje Ci dwie metody: toPlainText() i toHtml() obie zwracają QString'a", czyli biorąc kod z artykułu ui->textEditLogs->toPlainText(); i z tym robisz już to co w przykładzie z zapisem do pliku. I tak jak napisał @atMegaTona niestety, ale bez odpowiedniej wiedzy C++ i podstaw OOP nie zrobisz dużych postępów i nie będziesz w stanie dobrze wykorzystać Qt. Nie wiem jaką Ty preferujesz metodę uczenia, ale tutaj masz darmowy kurs od Johna Purcella do podstaw C++ (składnia, podstawy programowania obiektowego, dziedziczenie, zarządzanie pamięcią itp). Pomijając projekt na końcu kursu (5h) i podstawy (1h) zostaje około 12 godzin, który robiąc na przyspieszeniu zajmie Ci około tygodnia poświęcając ~1h dziennie.
  4. Cześć @Wrona Metoda MainWindow::sendMessageToDevice(QString message) właśnie zapewnia, Ci taką funkcjonalność, mamy na sztywno w kodzie: this->sendMessageToDevice("1"); a możesz zrobić w slocie pod dowolnym przyciskiem (generalnie możesz tam wysłać to co chcesz): this->sendMessageToDevice("Mateusz"); wtedy powinieneś po drugiej stronie odebrać cały string. Okej, to można zrobić na wiele sposobów w zależności od celu jaki chcesz osiągnąć, chyba najprostszy moim zdaniem to zapisanie zawartości okna z logami do pliku. QTextEdit daje Ci dwie metody: toPlainText() i toHtml() obie zwracają QString'a. W twoim przypadku chyba odpowiedniejsza będzie toPlainText(), wtedy używając klasy QFile, możesz takiego QStringa, wcześniej konwertując do QByteArray zapisać do pliku, przykład poniżej: #include <QCoreApplication> #include <QFile> #include <QString> #include <QDebug> int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); QFile file("logs.txt"); // Uwaga! Plik będzie stworzony w katalogu, gdzie znajdują się pliki wynikowe programu (build dir) if(!file.open(QIODevice::WriteOnly)) { qDebug() << "Could not open!"; } else { const QString dataToWrite("Mateusz"); file.write(dataToWrite.toUtf8()); file.close(); } return a.exec(); } W twoim programie, musisz wydostać zawartość okna z logami i wykorzystać powyższe. Więcej info znajdziesz w dokumentacji.
  5. @Lukasz1996 Miałeś okazje sprawdzić na nowej wersji czy problem nadal występuje? @dernis Nadal to jest bardzo podejrzane. Wykorzystanie funkcji blokujących jak w tym przypadku waitForBytesWritten() nie jest najszczęśliwszym rozwiązaniem (nieco więcej info tutaj) jeśli obsługujemy jeszcze GUI w tym samym wątku. Generalnie jedna z możliwych metod write(x) powinna działać bez problemu - wysyłając zawartość, którą chcieliśmy wysłać: Identycznie wygląda sprawa w przykładowym projekcie: https://doc.qt.io/qt-5/qtserialport-terminal-example.html, gdzie wywołane jest zwyczajnie write() w MainWindow::writeData(). Mogę się mylić, ale nadal wygląda to jak bug w Qt... Albo bardzo specyficzny przypadek.
  6. @Matthew11 Hmmm, wydaje mi się że cały proces podłączenia telefonu do komputera w celu debugowania został opisany w artykule ze szczegółami (przynajmniej mam taką nadzieję) i jeśli są dodatkowe kroki to o nich po prostu nie wiem. Jak podłączam mój telefon to widzę belkę "Podłączono moduł debugowania USB" więc to pierwszy krok żeby się upewnić że debugowanie jest aktywne. Jak podłączyłem telefon pierwszy raz to przy otwartym oknie deploy (to które pokazałeś) miałem identyczną sytuacje - nie wykrywa telefonu - włączyłem opcje debugowania pojawiła się belka i wtedy zrobiłem "Odśwież ..." albo stało się to automatycznie i Qt (prawdopodobnie) wysłało informację do telefonu i na telefonie musiałem zezwolić na debugowanie USB (pojawia się wtedy okienko z RSA itp). Po akceptacji, Qt wykryło telefon. Miałeś taki komunikat? To jest bardzo kluczowy etap. Potencjalne problemy: 1. wybierasz złą architekturę (tam przy przycisku run/uruchom) 2. masz starszego Androida niż 4.1 (w co wątpię) 3. inny nieznany problem Bieda-rozwiązanie - budujesz normalnie aplikację, potem przenosisz ręcznie wynikowy .APK na telefon i instalujesz (słabe, bo nie masz debugowania... ale powinno działać). Inne rozwiązanie - tworzysz wirtualne urządzenie Android i testujesz lokalnie. Potem dystrybuujesz pliki apk na konkretny telefon
  7. @dkrakowski Wygląda jak brak włączonego debugowania USB w opcjach programistycznych w opcjach telefonu.
  8. @dernis W takim razie musisz dokładnie prześledzić co wysyłasz z Qt, a co faktycznie odbierasz na STM - czyli sprawdzić zawartość Received i atoi(&Received). Sprawdź też najpierw opcję z dwoma możliwościami w switch'u : 1) case 1: zapal(); 2) default: zgas(); skoro udaje się diodę zapalić to Qt przynajmniej raz wysłało "1".
  9. Cześć @dernis czy fragment "Terminal działa za to bez problemowo" mam rozumieć tak, że łącząc się przez Putty lub coś podobnego z STMem wysyłając 1 lub 0 możesz sterować diodą? Co sugeruje że problem znajduje się po stronie programu w Qt. Fragmenty aplikacji, które załączyłeś wyglądają w porządku, w on_pushButtonLedOff_clicked() masz dodatkowo return; na końcu, którego nie ma w on_pushButtonLedOn_clicked() ale nie sądzę żeby to było problemem. Możesz też nieco przepisać kod i odsyłać to samo co wysyła PC na zasadzie echa żeby zobaczyć co dokładnie wysyła aplikacja w Qt a co terminal, żeby sprawdzić zawartość Received. Możesz też dodać default case w switchu switch (atoi(&Received)) i za komentować case 0 - na zasadzie jak 1 to zapal, a wszystko inne zgaś. Musisz dokładniej opisać zachowanie, żeby można było powiedzieć coś więcej.
  10. Aktualizacja: Moje obecne ustawienia na świeżym Ubuntu 18.04.3 LTS: Qt 5.12.5 openJDK (instalacja przez: $ sudo apt-get install openjdk-8-jdk ) NDK r20b (20.1.5948944) SDK 26.1.1 Mogą być wymagane następujące pakiety: sudo apt install build-essential sudo apt install libgl1-mesa-dev W ustawieniach QtCreatora ścieżki do narzędzi (za $USER wstaw swoja nazwę użytkownika) JDK location: /usr/lib/jvm/java-8-openjdk-amd64 Android SDK location: /home/$USER/Android/Sdk Android NDK location: /home/$USER/Qt/Android/android-ndk-r20b JDK i SDK standardowo znalazło się w podanych folderach, lokalizacja NDK to mój wybór. Jedyny problem jaki miałem, to w trakcie budowania: Checking the license for package Android SDK Build-Tools 28.0.3 in /home/mateusz/Android/Sdk/licenses Warning: License for package Android SDK Build-Tools 28.0.3 not accepted. FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring root project 'android-build'. > Failed to install the following Android SDK packages as some licences have not been accepted. build-tools;28.0.3 Android SDK Build-Tools 28.0.3 To build this project, accept the SDK license agreements and install the missing components using the Android Studio SDK Manager. Alternatively, to transfer the license agreements from one workstation to another, see http://d.android.com/r/studio-ui/export-licenses.html Using Android SDK: /home/mateusz/Android/Sdk * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 7s Building the android package failed! -- For more information, run this command with --verbose. 11:35:03: The process "/home/mateusz/Qt/5.12.5/android_arm64_v8a/bin/androiddeployqt" exited with code 14. Rozwiązujemy przez wywołanie poniższego i zaakceptowanie wszystkich licencji, sdkmanager znajdziemy w katalogu /home/$USER/Android/Sdk/tools/bin, ./sdkmanager --licenses więcej info tutaj: https://stackoverflow.com/a/43003932
  11. Ja tylko nieskromnie dorzucę, że Arduino to nie tylko AVR, są też ARMy, gdzie najczęściej twórcy core stosują SysTick. Czy takie rozwiązanie jest też złe (może jest złe tylko dlatego że nie jest to STM). Jako przykład, fragment z Teensy Core: https://github.com/PaulStoffregen/cores/blob/f606ad9efb149e5559f37899c94784ca0bba9463/teensy3/core_pins.h#L2003
  12. Jeśli chodzi o wspomniane przeze mnie Visual Studio Code - tak. Skok do definicji lub deklaracji i zmiana nazwy symbolu (lokalnie): Wyszukiwanie w w całym projekcie po wykonaniu kombinacji ctrl + shift + h. Do tego są takie czary jak edycja multi-linijkowa (multiline editing): https://kencenerelli.files.wordpress.com/2018/03/multilineediting_thumb.gif?w=630&h=586 i wiele innych czekających na własnoręczne odkrycie.
  13. Nawiązując do edytorów, ja dawno porzuciłem używanie Arduino IDE na rzecz najpierw Atmel Studio 7 + Visual Micro, a potem Visual Studio Code i rozszerzenia PlatformIO, te dwa ostatnie są moimi absolutnymi faworytami, w których piszę (już o wbudowanej w VSC obsłudze Gita czy dodatkach do analizy statycznej kodu nawet nie wspominam). PlatformIO korzysta z tych samych repozytoriów co Arduino IDE - w sensie jak programujemy np. ESP8266 za pomocą SDK od Espressif, to PlatformIO dość szybko ściągnie nam najnowszą wersję z gałęzi master. Sam proces konfiguracji to wyklikanie odpowiedniego zestawu, frameworka i poczekanie aż PlatformIO ściągnie wszystkie potrzebne narzędzia. Na tą chwilę Platformio zapewnia wsparcie dla ponad 700 zestawów. Jeśli kogoś męczy Arduino IDE i brak podświetlania składni czy brak podpowiadania kodu to zachęcam do przetestowania VSC i PlatformIO.
  14. Coś mi się tutaj nie podoba, masz w slocie on_pushButtonLedOn_clicked() lokalny obiekt QElapsedTimer i chyba także taki sam obiekt z taką samą nazwą jako członka MainWindow. Z tego pierwszego nie korzystasz bo zaraz bo wyjściu z tego slotu zostaje on niszczony. A ten który jest w drugim slocie (jako członek MW) jest tylko restartowany. Czy to tłumaczy zachowanie które opisujesz?
×
×
  • Utwórz nowe...