Skocz do zawartości

atMegaTona

Użytkownicy
  • Zawartość

    465
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    3

atMegaTona wygrał w ostatnim dniu 1 grudnia

atMegaTona ma najbardziej lubianą zawartość!

Reputacja

87 Bardzo dobra

2 obserwujących

O atMegaTona

  • Ranga
    6/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    to tu, to tam
  • Języki programowania
    C, ASM
  • Zainteresowania
    życie i świat
  • Zawód
    pilot oblatywacz
  • www

Ostatnio na profilu byli

424 wyświetleń profilu
  1. Przekonująco o tym opowiadasz ale nawet Ty wiesz, że oprogramowanie napisane w j. C jest dużo szybsze i wydajniejsze od spełniającego te same funkcje oprogramowania w C++ a widać to szczególnie dobrze na małych platformach gdzie zasoby są ograniczone. Różnica jest natomiast tego typu, że w C++ pisze się dużo wygodniej więc więcej czasu zajmuje napisanie tego samego kodu w C który jest mniej elasyczny. Niektórzy twierdzili nawet, że C++ nie nadaje się do programowania mikrokontrolerów ale to zależy też czego się wymaga. Dostępny na rynku sprzęt również jest coraz lepszy więc takie twierdzenia zaczynają być przestarzałe tak jak AVR z 30 letnim stażem. Jednak, kiedy się używa starego sprzętu chcąc wykorzystać wszystkie jego możliwości należy stosować metody do tego odpowiednie czyli w tym wypadku j. C będzie znacznie lepszym rozwiązaniem.
  2. I dlatego właśnie działanie programu napisanego z pominięciem arduino jest na ogół wiele szybsze i wydajniejsze ale coś za coś, arduino jest muliste ale wygodne i dlatego jest takie popularne. Nic nie stoi jednak na przeszkodzie aby miksować sobie kod dowolnie, w krytycznych czasowo miejscach wstawiać wstawki asm lub przerabiać napisane w C++ biblioteki na C, albo jeszcze oszczędzać pamięć rezygnując z zasobożernych operacji typu dzielenie, liczby zmiennoprzecinkowe lub nadużywanie zmiennych volatile lub static, gdzie się tylko da ale to wymaga czasu. Więc coś za coś, pod arduino masz wszystko na już co jest okupione często nawet 5-krotnie większym zużyciem pamięci.
  3. Coś o programowaniu na poziomie wysokiej abstrakcji. Jeśli się okaże, że nie pasuje do tego działu można przesunąć do "na luzie". Miłego seansu
  4. Małe sprostowanie. Programowanie/debugowanie w trueSTUDIO jest jednak możliwe bez podłączania zewnętrznego resetu. Niestety nadal nie wiem jak ustawić w atolicu nr. klona przez co nie jest w nim rozpoznawany. Jeśli ktoś wie jak ten nr. w trueSTUDIO przypisać to dajcie znać.
  5. Proponuję na początek porzucić marzycielstwo i zapoznać się choćby z podstawami języka do którego frameworka chcesz używać bo inaczej będziesz próbowała pisać chińską poezję po japońsku, którego, jak twierdzisz nie znasz. Do obsługi plików w Qt służy klasa QFile. Wszystko jest pięknie opisane we wbudowanym manualu łącznie z przykładami użycia.
  6. Mikroporadnik dla początkujących. Przeglądając internet często trafiałem na posty dotyczące problemu z debugowaniem popularnych tanich płytek Blue Pill a szczególnie tych zawierających chińskie klony mikrokontrolerów z kuźni STM oznaczonych CKS32. Sposoby tu przedstawione działają w środowisku Ac6 SW4STM32 i zapewne w podstawowym eclipse z dołączonymi pluginami dla STM32 za pomocą taniego klona programatora st-link v2. ------------- STM32F103C8T6 --- Problem z błędem dot. resetu podczas debugowania w SW4 przez SWD można obejść edytując plik konfiguracyjny, który jest tworzony w katalogu projektu po dodaniu nowej konfiguracji: RUN -> Debug Configurations... Trzeba kliknąć 2 razy na "Ac6 STM32 Debugging", pojawi się nowa konfiguracja. Trzeba teraz dodać plik .elf w polu "C/C++ Application" Następnie w zakładce "Debugger" po drodze można dodać opcję w polu "OpenOCD Command" na końcu za ścieżką do ocd -d3 lub -d2 dzięki czemu w konsoli debugera wyświetli się więcej informacji. Poniżej w Configuration Script należy zaznaczyć opcję "User Defined", kliknąć przycisk Browse... i otworzyć do edycji plik .cfg w pliku tym na samym dole trzeba pozbyć się wpisu "srst_only" Od tej pory procek będzie resetowany prawidłowo i możliwe będzie debugowanie po kliknięciu w robala w pasku narzędzi a połączenie z st-linkiem nie wymaga linii reset. W moim przypadku to jedyny sposób na uruchomienie debugera bo nie pomagało nawet fizyczne podłączenie resetu. W trueSTUDIO natomiast konieczne jest podłączenie linii resetu do płytki. W zakładce "Startup" na dole można też odznaczyć opcję "set breakpoint at: main " która w niektórych wersjach gdb powodowała błędy. Najlepiej dodać własne breakpinty. Tyle wystarczy aby debugować oryginalne procesory STM32 ostatnio jednak bardzo często spotykane są płytki z klonami STM. ------------- CKS32F103C8T6 (odpowiednik STM32F103CBT6 128kB Flash) --- Chiński klon ma wbity inny nr. urządzenia niż STM przez co debuger wywala błąd stlinka o niewłaściwym nr. urządzenia. Pierwsze co trzeba zrobić na początku, to w folderze instalacyjnym SW4STM32 włączyć wyszukiwarkę plików i wyszukać pliki " stm32f1x.cfg " (powinny być 2) i w każdym z nich zmienić instrukcję set _CPUTAPID 0x1ba01477 na set _CPUTAPID 0x2ba01477 Dzięki temu uC będzie poprawnie identyfikowany i debuger się uruchomi. Nie znalazłem niestety sposobu aby przekonać trueSTUDIO do debugowania tego klona tak więc w CubeIDE pewnie też będzie problem. Trzeba pamiętać aby przywrócić oryginalne pliki stm32f1x.cfg po zmianie płytki na oryginalny STM32. Czasami zdarza się, że debuger się zatnie, tj. nie zamknie sesji prawidłowo przez co jej wątek wisi w systemie i nie da się uruchomić debugowania ponownie. Pomaga wyłączenie wątku eabi-... przez w systemie operacyjnym alt+ctrl+del lub konsolę czy monitor systemu w linuxie. Oprócz ilości pamięci jest jeszcze jedna ważna różnica pomiędzy oryginalnym STM32F103C8T6 a CKS, tym razem na korzyść STM a mianowicie możliwość przetaktowania. STM32 będzie działał poprawnie przy taktowaniu ponad 120MHz chiński klon natomiast przetaktować się już nie da powyżej 72MHz. Na koniec jeszcze przykładowy plik main.c, blink za pomocą freeRTOS. Aby móc go sobie uruchomić do debugowania trzeba utworzyć nowy projekt C/C++ typu Ac6 wybrać odpowiedni procesor na blue pillu C8T6 lub CBT6, w kolejnym oknie dodać freeRTOS i podmienić plik main.c w projekcie na przykładowy. Miłego debugowania. #include "stm32f1xx.h" #include "FreeRTOS.h" #include "task.h" // Przedrostki funkcji np. v lub i pochodz¹ od zwracanych typów np. void lub int // Przedrostkiem prv zaczynaj¹ siê funkcje prywatne czyli statyczne static void prvSetupHardware(void); void vLEDTask(void *); //! Przydalaby sie wlasna struktura inicjalizujaca HAL int main(void){ prvSetupHardware(); /// Creating tasks Start: // dynamiczna alokacja pamiêci xTaskCreate( vLEDTask, "LEDTask", 100, NULL, 1, NULL );// (adres funkcji,dowolna nazwa, wielkosc stosu dla zadania w bajtach, opcjonalny parametr, priorytet wywolywania funkcji 1 - 9, wskaznik do konkretnego adresu pamiêci lub null) // statyczna alokacja pamiêci //xTaskCreateStatic(); /// End tasks creating // Glówna funkcja RTOS vTaskStartScheduler(); for(;;); // stack overflow // Kod programu jest podzielony na zadania, funkcja main sluzy tylko do // tworzenia zadañ poczatkowych. } //------------------------------------------------------------ void vLEDTask(void *pvParameters) { // Powinna byc w systemie funkcja umozliwiajaca zmiane // wartosci pvParameters z zewnatrz tutaj argument nie jest uzywany TickType_t xMonotonicClockState; // Pobiera aktualny czas systemwy // dziala podobnie do millis w arduino xMonotonicClockState = xTaskGetTickCount(); for(;;){ HAL_GPIO_TogglePin (GPIOC, GPIO_PIN_13); // Po przelaczeniu kreci sie w tym tasku vTaskDelayUntil(&xMonotonicClockState, pdMS_TO_TICKS(100)); } vTaskDelete(NULL); } /* void vApplicationTickHook(void){ //! Ta funkcja jest wykonywana w przerwaniu od ticka systemowego //! aby dodac tê funkcjonalnosc nale¿y w pliku FreeRTOSConfig.h //! #define configUSE_TICK_HOOK 1 //! Dzia³anie podobne do IDLE_HOOK z ta róznica, ze IDLE jest //! wykonywana podczas stanu bezczynnosci po oczyszczeniu pamiêci //! z zakoñczonych tasków. } void vApplicationIdleHook(void){ //! Ta funkcja jest wykonywana podczas idle state. } */ static void prvSetupHardware(void){ //inicjalizacja na podstawie kursu forbota SystemCoreClock = 8000000; // taktowanie 8Mhz HAL_Init(); __HAL_RCC_GPIOC_CLK_ENABLE(); GPIO_InitTypeDef LedC13 = { // obiekt gpio bêd¹cy konfiguracj¹ portów GPIO GPIO_PIN_13, // konfigurujemy pin 5 GPIO_MODE_OUTPUT_PP, // jako wyjscie GPIO_NOPULL, // rezystory podciagajace sa wylaczone GPIO_SPEED_FREQ_LOW // nieskie czêstotliwosci przelaczania }; HAL_GPIO_Init(GPIOC, &LedC13); // inicjalizacja portu GPIOC }
  7. Może być 5V. Zobacz tu: https://maker.pro/arduino/projects/arduino-soil-moisture-sensor
  8. A masz ten podciąg do Vcc w ogóle? Ten od DO, być może dht11 ma wewnętrzny a 22 nie. Tak też może być jak@ethanak pisze, trzeba zawsze najpierw przejrzeć chociaż pobieżnie pliki wykorzystywanych bibliotek.
  9. może spróbuj nim poruszać, raz w jedną raz w drugą stronę.. może w czujniku coś nie łączy. Chińskie guano świat zalewa i tylko czasu szkoda się z tym zmagać godzinami, dniami, latami.. i życie zleci jak z.. strzelił. Powinien działać bez żadnego problemu.
  10. Trudno zgadywać co może być przyczyną takiego zachowania czujnika. Oba czujniki mają taki sam pin-out więc nie powinno być problemu przy zamianie o ile nie podłączasz ich odwrotnie. Jedyna różnica poza zakresem pomiarowym to częstotliwość dokonywania pomiarów która dla dht22 wynosi 0.5H czyli pomiaru można dokonywać co 2 sekundy, w przypadku dht11 jest to 1H. Jeśli więc nie ma nigdzie przerwy w połączeniach to wniosek nasuwa się tylko jeden - czujnik jest uszkodzony. Możesz spróbować jeszcze przed podłączeniem zewrzeć ze sobą wszystkie nóżki czujnika np. wtykając go w jedną linię na stykówce - czasami taki zabieg pomaga bo rozładowuje wewnętrzne pojemności. Jeśli to nie pomoże to chyba już nic innego nie pomoże. Dla testów spróbuj pobierać dane wolniej, np. raz na 3s. -------- zrobiłem mały research i znalazłem taki poradnik: http://akademia.nettigo.pl/dht22/ Zwróć uwagę na rezystor podciągający pomiędzy pinem 1 a 2 i sposób pobierania danych. Powodzenia
  11. Wygląda na to, że masz coś źle podłączone a ten wynik to nie temperatura tylko kod błędu. Zapoznaj się z plikiem DallasTemperature.h // Error Codes #define DEVICE_DISCONNECTED_C -127 #define DEVICE_DISCONNECTED_F -196.6 #define DEVICE_DISCONNECTED_RAW -7040 Zobacz też przykłady dołączone do biblioteki. To podstawowe czynności jakie powinno się wykonać jeszcze przed skorzystaniem z nowej biblioteki. Myślę, że sobie z tym poradzisz, zachęcam jednocześnie do opublikowania rozwiązania na forum aby ktoś zmagający się z podobnym problemem w przyszłości mógł go rozwiązać dzięki Tobie. Pozdrawiam i życzę powodzenia z hardware debuging. -- Wygląda na to, że pin nie jest skonfigurowany.
  12. Cóż, winny się tłumaczy, po obfitości tłumaczenia można wnioskować o wadze winy. Oj @Elvis , @Elvis jak pijesz to nie śpiewaj bo fałszujesz. I żebyś nie zapomniał, łap mordę, hah
  13. Jest to określone w dokumentacji modułu łącznie z maksymalną odchyłką w ciągu doby/roku. Są też przedstawione metody kalibracji kwarcu.
  14. Myślę, że to nie zależy od czyjegoś zdania a wynika ze stanu faktycznego i zachęcam do takich eksperymentów. Moim pierwszym projektem na mikrokontrolerze był właśnie zegar napisany w bascom 8051 na procku at89c2051 kiedy jeszcze nie było arduino a z internetu mogłem skorzystać od przypadku do przypadku. Byłem nieco zdziwiony kiedy się okazało, że nie chodził dokładnie.
  15. Wystarczy wiedza, że został przestawiony aby odpowiednio skompensować wyniki, tak samo wystarczy inkrementowana na podstawie modułu RTC zmienna żeby sobie zrobić monotoniczność samemu, zapewniam, że będzie dokładniejsza niż millis(). Niektóre moduły mają nawet funkcję interrupt na taką okoliczność, nie służy ona jedynie do mrugania kropkami pomiędzy godzinami i minutami.
×
×
  • Utwórz nowe...