Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2471
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    173

Wszystko napisane przez Elvis

  1. Darmowe statystyki popularności języków są dostępne w sieci i co więcej są za darmo. Język C++ jest używany w wielu projektach opartych o uC. Zarówno kilku poprzenich projektach, jak i w mojej aktualnej pracy C++ jest wykorzystywany do pisania aplikacji działającej bez systemu operacyjnego (albo raczej używającej jedynie RTOS-a) i jakoś nikomu to nie przeszkadza. Co ciekawe akurat po linuxem pracuję więcej w czystym C, sam system też w tym języku jest napisany - więc argumenty o C++ dla linuxa, a czystym C dla uC to absolutna bzdura - chociaż nie pierwsza wygłaszana przez tego użytkownika. Jak chodzi o naukę, to zarówno C, jak i C++ są dobrymi kandydatami - chociaż ostatnio modne są zupełnie inne języki, więc można również pomyśleć o micropythonie, albo Rust. @Wloczykij555 Skoro kupiłeś zestaw z STM32, to może zacznij od kursu stm32? Jak czegoś nie będziesz wiedzał, czy rozumiał zawsze możesz zapytać na forum, na pewno pomożemy. Arduino to fajna opcja, ale skoro masz już sprzęt to bez sensu kupować kolejny - zacznij, zobacz jak Ci się będzie tym bawiło, zawsze można, a nawet należy później kupić coś kolejnego. A czy to będzie Arduino, Raspberry Pi, czy zupełnie coś innego - to się okaże
  2. C++ jest jak najbardziej używany w świecie mikrokontrolerów. Więc argument o 90% softu w C można spokojnie między bajki włożyć - no chyba że @RFM przytoczy jakieś sprawdzone statystyki, a nie tylko własne opinie. Zarówno w "świecie" Linuxa, jak i programowania mikrokontrolerów bez systemu operacyjnego jest miejsce zarówno dla języka C, jak i C++.
  3. Trochę się zastanawiałem nad tym błędem i wartością rejestru SP - bo przeglądając plik startup_stm32f103c8tx.s wszystko wygląda poprawnie (nie licząc złej wartości _estack). Wydaje mi się, że przyczyną problemów była nieco nietypowa konfiguracja. Ja najczęściej w przypadku bluepill używam bootloadera oraz programowania przez usb. Tym razem, żeby uzyskać ten sam efekt co opisywany w wątku podłączyłem st-link z interfejsem SWD (właściwie to podłączyłem stlink z płytki nucleo). W każdym razie sam bluepill nadal uruchamiał bootloader, a dopiero później przez SWD wgrywany i uruchamiany był "właściwy" program. Normalnie po włączeniu zasilania pierwsze słowo z kodu programu jest ładowane do rejestru SP. Tam znajduje się wartość _estack i wszystko powinno działać. Ale jeśli zamiast programu uruchamiany jest bootloader to oczywiście rejestr SP jest kontrolerowany przez kod bootloadera. W kolejnym kroku debugger przejmuje kontrolę i uruchamia główny program. Jednak procedura jego uruchomienia nie jest identyczna z "prawdziwym" resetem. Rejestr SP powinien być więc ustawiony przez debugger, ale ktoś tego nie przewidział w skryptach dołączonych do CubeIDE... i w efekcie program startuje z wartością SP z bootloadera. To by również tłymaczyło wpływ grzebania przy liniach BOOTx na działanie programu. Jako ciekawostkę można spróbować skompilować oryginalny program, wgrać do flasha i wystartować bez bootloadera i debuggera. Jeśli to zadziała, to będzie potwierdzenie mojej teorii...
  4. Faktycznie, kod źródłowy sporo pomaga. Problem okazał się dużo ciekawszy niż w pierwszej chwili wyglądało, więc w końcu odnalazłem zakurzone blue pill, podłączyłem programator i postanowiłem sprawdzić o co w tym chodzi. Najpierw wersja skrócona - lepiej na razie nie używać CubeIDE... to nowe środowisko, powiedziałbym że wersja beta. Więc jest w nim dużo więcej błędów niż w starych i sprawdzonych. A teraz pełna wersja: Na początek faktycznie - błąd się pojawia, występuje w dość przypadkowych momentach, nie ma najmniejszego sensu... Chociażby podczas inicjalizacji DMA, HardFault jest wynikiem dereferencji wskaźnika NULL, który pojawia się magicznie. Więc typowe debugowanie niewiele daje oraz wskazuje na problemy ze stosem. I tutaj niestety musimy zejść do poziomu samego procesora. Po uruchomieniu mamy: Jak widzimy po prawej stronie wskaźnik stosu, czyli rejestr sp ma wartość 0x200001fc, czyli od początku pamięci SRAM dzieli go 0x1fc = 508 bajtów. To za mało na skomplikowany program działający na liczbach zmiennopozycyjnych. Teoretycznie wielkość stosu ustawiamy w pliku linkera, czyli STM32F103C8TX_FLASH.ld: Tutaj znajdziemy dwie ważne wartości. _estack to adres "końca" stosu, czyli najwyższego adresu zajmowanego przez stos. Widzimy tutaj pierwszy błąd, bo adresy powinny być podzielne przez 4, a często i przez 8. W każdym razie powinniśmy zmienić deklarację na: /* Highest address of the user mode stack */ _estack = 0x20005000; /* end of "RAM" Ram type memory */ Teraz to czego szukamy, czyli wielkość stosu: _Min_Stack_Size = 0x400 ; /* required amount of stack */ Domyślna wartość 0x400 oznacza 1024 bajty. Mikrokontroler STM32F103C8 ma 20 KiB pamięci SRAM, więc nie musimy być aż tak oszczędni - można ustawić stos na nieco większy. Okazuje się jednak, że zmiana _Min_Stack_Size nie wpływa na wartość rejestru SP, czyli faktyczny wskaźnik stosu... Mamy 508 bajtów bo coś się komuś pozajączkowało. Nie jestem pewien, czy to najlepsze rozwiązanie, ale można poprawić problem zmieniając plik startup_stm32f103c8tx.s, który znajdziemy w katalogu Startup. Teoretycznie rdzeń Cortex-M3 ustawia wartość rejestru SP podczas uruchamiania programu - ale to jak widać nie działa poprawnie. Możliwe że wynika to ze sposobu działania debuggera i po wgraniu do pamięci flash byłoby poprawnie, ale możemy zastosować "obejście" i sami ten rejestr ustawić. Do wspomnianego pliku wystarczy dodać jedną instrukcję: ldr sp, =_estack Program wygląda wówczas tak: I u mnie działa...
  5. @astex a potrafisz wysyłać i odbierać komunikaty tekstowe? Bo jeśli tak, to skonwertuj wynik z czujnika na napis i wyślij. Po pierwsze łatwiej to testować, bo na początek możesz po prostu wyświetlać co dostajesz, bez przetwarzania. Możesz też testować serwer niezależnie wysyłając mu napisy z dowolnego terminala. A jak już opanujesz wysyłanie gołych tekstów to poczytaj o formacie JSON, będziesz miał wtedy piękną możliwość przesyłania nawet całkiem skomplikowanych danych, czy wyników.
  6. Nie sądzę żeby zmiana BOOT1 na 1 była choćby odrobinę dobrym rozwiązaniem. To nawet ciekawe na czym polega problem, jeśli umieścisz gdzieś kompletny projekt może będzie łatwiej poszukać przyczyny problemu. Bo zarówno DMA, jak i BOOT1 to raczej leczenie objawowe.
  7. A sprawdziłeś czy nie masz przepełnienia stosu?
  8. CPU i DMA konkurują o dostęp do pamięci - dokładniej DMA co jakiś czasu zapisuje do pamięci wyniki z przetwornika A/C. Ale skoro w programie masz: sConfig.SamplingTime = ADC_SAMPLETIME_239CYCLES_5; to ten zapis nie następuje zbyt często. Mawet nie wnikając czy ADC jest taktowane wolniej niż CPU, na jeden zapis przez DMA masz setki cykli CPU. Wiec teoretycznie program działa wolniej, ale pewnie nikt tego nie zauważy. Natomiast w programie masz pewnie inny błąd, który daje podobne efekty. Ciężko jest tak "zdalnie" zdiagnozować przyczynę problemów, ale z tego co przychodzi mi do głowy: 1) jesli wyłączysz ADC to funkcje arytmetyczne działają na stałych danych, może coś się psuje jak pojawią się określone wartości - coś gdzieś dzieli przez zero, liczy tangens z pi-pół itd. 2) może po wyłączeniu DMA optymalizator usuwa jakieś fragmenty kodu i całość działa względnie poprawnie 3) na zrzucie ekranu, który wstawiałeś wcześniej program zatrzymywał się w procedurze obsługi przerwania. Może problem nie wynika z samego DMA, ale złego sposobu obsługi przerwania od DMA? np. nie jest zerowana jakaś flaga i przerwanie wywoływane jest "w pętli", co faktycznie może uniemożliwiać działanie programu? To tylko pomysły, bo jak napisałem ciężko jest diagnozować przyczynę problemu na odległość. W każdym razie DMA nie ma prawa zatrzymać programu, może go spowolnić, ale nie zatrzymać całkiem.
  9. DMA nie zawiesza wykonywania obliczeń, ale w pewnych warunkach może mieć wpływ na czas działania procesora oraz wykonywanie programu. O ile sam mechanizm działa niezależnie od CPU, to w przypadku dostępu do tego samego modułu jak np. pamięci RAM możliwe jest spowolnienie działania procesora. Oba moduły master, czyli w tym wypadku CPU oraz DMA konkurują o dostęp do jednego układu podrzędnego (slave). Oznacza to, że gdy np. DMA zapisuje wyniki, CPU musi poczekać. Jednak to oczekiwanie to raptem jeden, a maksymalnie kilka cykli magistrali AHB. Co więcej spowalniane są tylko dostępy do pamięci, a procesor większość operacji np. arytmetycznych i tak wykonuje na rejestrach. W przypadku ADC problem jest jeszcze mniejszy - DMA zapisuje wyniki dopiero po zakończeniu konwersji A/C. Więc "zatrzymanie" CPU następuje bardzo, bardzo rzadko. Moim zdaniem problem wynika z zupełnie innej przyczyny, natomiast wpływ DMA jest raczej pomijalny. Nie ma natomiast możliwości, że DMA zupełnie zablokuje działanie CPU. Program nawet w najgorszym przypadku będzie wykonywany, chociaż z nieco mniejszą prędkością - niestety nie ma nic za darmo.
  10. @RFM czyli uważasz że nie można spalić wyjścia mikroprocesora / tranzystora MOS zwierając wyjście do masy i wystawiając stan wysoki?
  11. Zwarcie pinu wyjściowego z masą może uszkodzić port GPIO. Nie wiem, czy uszkodzi cały mikrokontroler, ale na pewno w przypadku niektórych układów można uszkodzić cały port, nie tylko tylko jeden pin. Przetestowałem na LPC-2148 dawno temu, nie przepaliło się od razu, więc testowałem błędy komunikacji z LCD przez zwieranie linii do masy... aż w końcu cały port GPIO przestałe działać. Więc nie polecam takiej zabawy, jak napisałem - może zadziałać raz, czy dwa razy, ale w każdej chwili można uszkodzić układ. Stąd moja rada szczególnie dla początkujących - nie róbcie tego jeśli nie chcecie uszkodzić mikrokontrolera. I nie wierzcie wpisom w internecie że nic złego się nie stanie.
  12. Bardzo możliwe, cały czas człowiek się uczy - możesz podać jakiś link do "lektury CE", chętnie przeczytam? Z tego co wiem CE to jedynie oznaczenie nadawane przez producenta na potwierdzenie zgodności z wymogami dyrektyw unijnych. Dla tego urządzenia moim zdaniem należałoby co najmniej spełnić wymagania dyrektywy niskonapięciowej (2014/35/UE) oraz ROHS. Ale skoro nalegasz, mogę zapytać w AVT, oczywiście jak tylko urządzenie pojawi się w sprzedaży.
  13. Chciałbym zobaczyć wyniki testów takiego urządzenia na zgodność z CE. Bo o ile widzę kit AVT5643 jest też w ofercie jako gotowe, uruchomione i zmontowane urządzenie...
  14. Ależ my nic do projektu nie mamy, ale krytykowanie pracy innych oraz wypiswyanie bzdur w internecie to chyba nie część projektu. Więc jeśli pojawi się rzeczowy artykuł o wspomnianym "akceleratorze" to nikt nie będzie miał pretensji, nawet chętnie przeczytamy. Natomisat cała nagonka na AVR, opluwanie Arduino i popisywanie się swoją niekompetencją raczej nie zrobi dobrej reklamy temu "projektowi".
  15. To co jest przedstawione na ESP32 to czujnik pojemnościowy. Nie ma on nic wspólego z czujnikiem, ani zjawiskiem Halla. Czujnik halla wymaga pola magnetycznego, więc jeśli nie trzyma się w rękach magnesów, ani nie jest medium ciężko będzie takie czujniki wykorzystać. Natomiast czujniki pojemnościowe jak najbardziej - tylko ich obsługa wcale nie będzie taka prosta jak się wydaje. Można natomiast użyć gotowca https://www.microchip.com/design-centers/capacitive-touch-sensing/gestic-technology - wyjdzie drożej, ale w cenie są biblioteki, DSP i dokumentacja.
  16. A do czego służy ten temat? Masz jakiś problem, szukasz porady? Bo krytykowanie innych chyba nie jest zgodne z PPF - jeśli nie odpowiada ci biblioteka, to jej nie używaj, proste.
  17. @t_m wydaje mi się, że powinieneś zacząć jeszcze raz od narysowania schematu. To co nam przedstawiłeś nie bardzo ma sens - już na pierwszym schemacie masz zwarte wejście z wyjściem, więc rezystancja wynosi po prostu 0. Popatrz na lewe strony rezystorów R1-R4, przecież one są połączone ze sobą oraz zarówno z wejściem i wyjściem. Chyba nie o to chodziło
  18. Wcześniej była dyskusja złączach w standardzie Arduino, więc jak dla mnie chodziło o złącza. Ale nawet jeśli chodziło o biblioteki, to proszę bardzo: https://github.com/dimag0g/nios_duino
  19. Czyli to stąd taka święta wojna przeciwko AVR... Panie Sławomir S. może lepiej zabrać się do roboty zamiast zazdrościć innym?
  20. Może dlatego że nie szukałeś. Sporo płytek Terasic-a ma gniazda zgodne z Arduino np. https://kamami.pl/zestawy-uruchomieniowe/564537-terasic-de10-nano-kit-p0496-edu.html Na tej płytce jest FPGA przy którym Maximator to maleństwo, o 2 rdzeniach Cortex-A9 @ 800 MHz nawet nie wspominając. I jakoś nikomu Arduino nie przeszkadza
  21. I tak i nie. Nie doszliśmy chyba w naszych rozważaniach do jakiegokolwiek protokołu IR. Na razie dyskusja była tylko o tym czy uda się jakimkolwiek dostępnym pinem sterować
  22. Jak chodzi o set-top-boxy i rozwiązania sprzętowe to problem polega na ilości produkowanych egzemplarzy. Załóżmy że przejściówka usb-uart kosztuje tyle co nic, czy powiedzmy 1$. W kolejnej firmie gdzie pracowałem mieli zdjęcia z imprez po sprzedaży kolejnego miliona dekoderów - i wychodziło że zabawa wypadała mniej więcej co rok. Czyli takie 1$ kosztów to ok. milion dolarów rocznie... ja chyba wolałbym to zaimplementować w programie i poprosić o przelew nadmiaru środków na moje konto
  23. Pisząc komentarz dawno temu zakładałem że da się wszystko zrobić bez zewnętrznych układów - więc i bez USB. Ale nawet wtedy napisałem to w trybie przypuszczającym - jeśli się nie da, to ok, mikrokontroler można zawsze dodać. Ale żeby nie było że piszę całkiem bez sensu - przez chwilę pracowałem w firmie Espial (https://www.espial.com/) i akurat dość sporo czasu zajmowałem sterowaniem za pomocą pilotów IR oraz RF. Nikt oczywiście nawet nie pomyślał o podłączaniu Atmel ATB, czy podróbek Arduino Nano do tych dekoderów, a jakoś można było sobie poradzić Same dekodery pracują pod kontrolą linuxa i oczywiście mają cały system kompilowany ze źródeł zamiast mint-a, czy innego desktopowego systemu.
  24. Pisząc linux mam na myśli jądro, cała reszta to GNU W każdym razie jak najbardziej uruchomisz mint-a, czy właściwie dowolną inną dystrybucję na Raspberry Pi. Jeśli masz działające jądro to ono zapewnia izolację od sprzętu. Reszta oprogramowania wcale nie interesuje się, czy działa na Raspberry Pi, Odroid, czy Khadas. Oczywiście użyty procesor jest ważny, ale kompilacja na ARM to najmniejszy chyba problem. Mnogość dystrybucji to zupełnie inny temat - w sumie każdy może sobie własną przygotować. Miałem na myśli zwykłe GPIO, takie jak na mikrokontrolerze - może Cię to zaskoczyć, ale w przypadku mikroprocesorów większość modułów działa właściwie tak samo. Są bardziej rozbudowane, ale GPIO na STM32MP1 można programować z poziomu rejestrów bardzo podobnie do STM32F1. W przypadku intela jest to nieco trudniejsze, ale jak wspominałem niektóre mikroprocesory na pewno, inne tylko jak myślę - mogą sterować pojedynczymi pinami tak samo jak mały AVR.
  25. nie wiem co dokładnie w kwestii linuxa się interesuje. To ogólnie dość rozległy temat, ja nadal wielu rzeczy się uczę.. a nie umiem nic polecić jeśli nie wiem z jakiej dziedziny
×
×
  • Utwórz nowe...