Skocz do zawartości

Elvis

Użytkownicy
  • Zawartość

    2516
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    183

Wszystko napisane przez Elvis

  1. 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.
  2. A sprawdziłeś czy nie masz przepełnienia stosu?
  3. 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.
  4. 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.
  5. @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?
  6. 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.
  7. 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.
  8. 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...
  9. 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".
  10. 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.
  11. 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.
  12. @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
  13. 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
  14. 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?
  15. 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
  16. 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ć
  17. 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
  18. 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.
  19. 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.
  20. 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
  21. @DevTomek Linux dla komputerów stacjonarnych, laptopów i systemów wbudowanych jest absolutnie taki sam. Więc w większości przypadków nawet na stacjonarnym PC można mieć dostęp do GPIO, tylko nic dobrego z tego nie wyjdzie bo piny i tak są podłączone do odpowiednich peryferiów. Ale w większości przypadków nie ma różnicy czy mówimy o komputerze przemysłowym / wbudowanym, stacjonarnym, czy opartym o układ ARM.
  22. Skoro zostałem przywołany do dyskusji to chyba nie mam wyjścia i muszę się wypowiedzieć. Więc po pierwsze - nie twierdziłem, że na pewno da się i że wiem jak w tym konkretnym systemie zintegrować wszystko na jednym mikroprocesorze. Jeśli się nie da, albo jest za trudno itd. to oczywiście dodanie mikrokontrolera może mieć sens. Gdy to pisałem bardzo raziło mnie używanie płytek Atnela, bo uważałem że są zbyt drogie, a i nie przepadałem za ich twórcą, bo uważałem że robi kasę na początkujących, chociaż wcale nie ma wiedzy i umiejętności, żeby uczyć innych. Jednak teraz, będąc starszym i mądrzejszym o dyskusje na naszym forum chciałbym się z tego wycofać i bardzo przeprosić M.Kardasia. Nadal mam pewne zastrzeżenia, ale w porównaniu z innymi samoukami w dziedzinie elektroniki i informatyki jest on prawdziwym geniuszem. A co najważniejsze jest normalny i po prostu zarabia tam gdzie ma to sens. Więc przepraszam, zachęcam do używania płytek ATB, brania udziału w zbiórkach na polakpotrafi itd. Natomiast co do set-top-box'ów, to akurat tego modelu nie znam, ale przy kilku pracowałem i obsługa gpio była dostępna zarówno na platformach intela, jak i ARM-ach. Chociaż bez dostępu do dokumentacji faktycznie może to być trudniejsze, żeby nie powiedzieć niemożliwe do implementacji. Jednak internet, a google w szczególności to dobre źródło informacji - może na ten mikroprocesor są dostępne źródła linuksa oraz niezbędne sterowniki. Warto to sprawdzić zanim użyje się dodatkowych układów.
  23. I tak chyba trzeba wydzielić ostatnie wpisy, bo zaśmieciły skutecznie workloga Mogę parę słów napisać, chociaż ja nie zajmuję się bezpieczeństwem w tym projekcie, wiele rzeczy znam bardziej ze słyszenia czy dyskusji. Ale jakby ktoś był zainteresowany tworzeniem oprogramowania dla branży medycznej, to o tym mogę od razu pisać całą książkę
  24. @atMegaTona tak, też byłem zaskoczony. Chodzi o ochronę przesyłanych danych, nie może być możliwości podłączenia sondy, a dodatkowe warstwy działają jak zabezpieczenia w sklepie - przerwanie kasuje wszystkie wrażliwe dane. Nawet procesor ma dodatkowe warstwy na krzemie - ich przecięcie również powoduje usuwanie danych.
  25. Straszny się offtopic robi, ale odpowiem na pytanie @RFM Wstawiłem link i napisałem przy czym pracowałem - nie robiłem nic związanego ze zliczaniem monet, jak napisałem pracuję przy NFC. Natomiast komentarz odnośnie wysyłania kodów klawiszy pokazuje że nic nie wiesz o urządzeniach płatniczych. Ta niepozorna klawiaturka w bankomacie to tzw. pinpad - szyfrowanie i poziom zabezpieczeń w nim używane jest o wiele wyższy niż w całej reszcie systemu. Dane takie jak numer karty (PAN) są na niższym poziomie zabezpieczeń niż PIN, więc kody naciskanych klawiszy nigdy, przenigdy nie mają prawa być wysyłane poza pinpad - no chyba że porządnie zaszfrowane. Ale nie po to robi się 12-warstwową płytkę, używa specjalnych mikrokontrolerów z dodatkowymi warstwami ochronnymi, żeby później wszystkie dane wysyłać otwartym tekstem. Z drugiej strony ja też kiedyś myślałem że ta klawiaturka w bankomacie to taka zwykła klawiatura matrycowa jak każdy ma do arduino
×
×
  • Utwórz nowe...