Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Hydepark działu mikrokontrolerów

dondu 06 Lut 2017 20:58 17364 452
  • #181 06 Lut 2017 20:58
    Artur k.
    Admin grupy audio

    Freddie Chopin napisał:
    VirtualBox + darmowe obrazy Windowsa wprost od Microsoftu

    Znam to rozwiązanie, tyle że w przypadku gdy 90% czasu będzie wykorzystywany Windows poprzez VirtualBox, to po co w ogóle Linuxa instalować? Prościej od razu zainstalować Windowsa i Linuxem sobie głowy nie zawracać. Koszt Windowsa w momencie gdy komputer służy do celów zarobkowych jest naprawdę pomijalny.

    Freddie Chopin napisał:
    No właśnie, akurat w dziale Mikrokontrolerów używanie Linuxa nie jest w ogóle problematyczne

    No właśnie, jednak nie wszędzie to tak wygląda jak w dziale Mikrokontrolerów. :)

  • #182 07 Lut 2017 22:03
    strikexp
    Poziom 27  

    Artur k. napisał:

    strikexp napisał:
    Artur k. napisał:
    Tak naprawdę wiele aplikacji sieciowych wymaga zainstalowania odpowiedniego środowiska na komputerze lokalnym - Java, Flash, Silverlight itd, itp.


    Bzdura, wystarczy w miarę aktualna przegladarka z tych najbardziej rozbudowanych typu Chrome czy Firefox.

    Co jest nieprawdą. Przykładowy flash w całości wykonywany jest po stronie komputera klienta, a nie po stronie serwera. I nie ma znaczenia czy jest to plugin Adobe, czy jego wolny odpowiednik w Linux czy wbudowany w przeglądarkę. Bez wątpienia jest to aplikacja desktopowa.


    Trudno żeby żadnego softu nie było na komputerze docelowym.
    I jak pisałem, bzdura. Odkąd przeglądarki obsługują HTML 5 to i flash jest niepotrzebny.
    To że jest używany wynika raczej z tego że jest tani. Ta technologia umiera, a konkurencyjny Javascript to duże pieniądze. Stąd flash jeszcze oddycha i oddychać będzie przynajmniej kilka lat.

  • #183 08 Lut 2017 06:47
    Artur k.
    Admin grupy audio

    strikexp napisał:
    Odkąd przeglądarki obsługują HTML 5 to i flash jest niepotrzebny.

    Flash niepotrzebny, ale za to potrzebny jest kodek video i to kompatybilny z tym w którym zakodowano film. To samo dotyczy audio. O ile wiem, standard jako taki nie istnieje.
    Zatem jak by do tego nie podejść - czy będzie to Flash, czy HTML5, jakieś dodatkowe oprogramowanie jest potrzebne. Samo się odtwarzało nie będzie.
    Gdzie tu bzdura? Uczepisz się, że napisałem o Flashu? A co to za różnica czy potrzebuję Flash-a, czy kodek np. h.264? Istotne jest to, że bez dodatkowego oprogramowania działać to nie będzie.

  • #184 08 Lut 2017 10:22
    Piotrus_999
    Poziom 39  

    strikexp napisał:
    To że jest używany wynika raczej z tego że jest tani. Ta technologia umiera, a konkurencyjny Javascript to duże pieniądze. Stąd flash jeszcze oddycha i oddychać będzie przynajmniej kilka lat.
    Możesz bliżej wyjaśnić dlaczego flash jest tani a JavaScript do duże pieniądze? Bo z tego co mi wiadomo to JavaScript jest bezpłatny a flash platny (narzędzia do tworzenia). Chyba że w ciągu ostatnich 24h coś się zmienilo

  • #185 15 Lut 2017 00:59
    strikexp
    Poziom 27  

    Chodzi mi o Canvas bo to jedyne co ma współnego Javascript z Flash. We flashu da się dość łatwo wyklikać i oprogramować gry/animacje. W Javascript to sporo roboty, szczególnie jak to coś większego i trzeba użyć programowania czysto obiektowego.

  • #186 19 Lut 2017 20:19
    BlueDraco
    Specjalista - Mikrokontrolery

    tmf napisał:
    Nadawanie \r też nie jest potrzebne, skoro wiemy, że zawsze cztery najbardziej znaczące bity mają wartość zero, więc można łątwo synchronizować odbiór.


    No pewnie. Podaj algorytm synchronizacji dla ciągu próbek o wartościach z zakresu np. 0x0a01..0x0a0f. ;)

    A poza tym, jak powszechnie wiadomo, transmisji asynchronicznej na ogół nie daje się w ogóle odebrać, jeśli dane są transmitowane bez przerwy.

  • #187 19 Lut 2017 20:46
    tmf
    Moderator Mikrokontrolery Projektowanie

    @BlueDraco Podałeś skrajny przypadek. Normalnie nie będzie takiego problemu, tym bardziej, że RS232 nie gubi losowo bajtów. Jeśli mogą być przesyłane długie ciągi tak "spreparowanych" danych, to zawsze można nadać ciąg synchronizujący raz np. na 100 bajtów, lub więcej. Dzięki temu będziemy mieli nie 30% overhead, lecz 1% lub mniejszy. Można to skompensować nawet z nawiązką kompresując dane - przetwornik zapewne jest 12- lub 10-bitowy, więc sklejając kolejne dane zyskamy co najmniej 25%, można też je przesyłać różnicowo, jako różnicę bieżącej wartości w stosunku do poprzedniej. Jeśli sygnał nie zmienia się zbyt często o więcej niż x-bitów, to można dzięki temu zyskać (16-x)/16.

  • #188 20 Lut 2017 09:18
    94075
    Usunięty  
  • #189 20 Lut 2017 09:40
    Piotrus_999
    Poziom 39  

    albertb napisał:
    Szczerze, to nie wiem po co timer.
    Po taby odległości pomiędzy próbkami były identyczne. W przeciwnym wypadku, dla wielu aplikacji dane są bezwartosciowe

  • #190 20 Lut 2017 09:47
    BlueDraco
    Specjalista - Mikrokontrolery

    Jak napisał Piotruś - stały okres próbkowania plus zapewnienie niezbędnej przerwy w transmisji. Przecież to są naprawdę podstawy podstaw - o czym w ogóle ta dyskusja?

  • #191 20 Lut 2017 11:50
    ufock
    Poziom 8  

    A jakby pobierać adc do dma, a dma na uart?

  • #192 20 Lut 2017 12:02
    Piotrus_999
    Poziom 39  

    ufock napisał:
    A jakby pobierać adc do dma, a dma na uart?
    Miało by to sens jak byś pobierał paczke danych z adc a następnie ją transmitował. Wtedy oczywiście możesz czytac z ADC tak szybko jak ADC pozwala, ale i tak będziesz miał przerwę na czas transmisji. Jest to przydatne jak np analizujesz fragment sygnału. Tak działa to np. w moim oscyloskopie ze stopki.

  • #193 20 Lut 2017 12:14
    94075
    Usunięty  
  • #194 20 Lut 2017 12:27
    Piotrus_999
    Poziom 39  

    albertb napisał:
    Czasy wysyłania określonej porcji informacji też są identyczne.


    Bardzo odważna teoria. Błąd i retransmisja i już masz.

    Poza tym przy użyciu timera masz bardzo precyzyjne odległości miedzy odczytami - takie jakie chcesz aby były a nie takie jak akurat wyjdzie.

    @albertb Próbujesz polemizować ze sprawami tak oczywistymi, że trudno to nawet skomentować.

    Jak sobie chcesz coś co jakiś czas wysłać - to oczywiście takie przeplatane wyzwalanie w przerwaniach możesz zastosować.

  • #195 20 Lut 2017 12:37
    94075
    Usunięty  
  • #196 20 Lut 2017 18:02
    trol.six
    Poziom 30  

    albertb napisał:
    Biorę DS, i sprawdzam, czy szybciej mogę otrzymywać próbki z ADC, czy szybciej wysyłać dane.
    Jeśli to pierwsze to każdy start wysyłania danej uruchamia konwersję ADC. przy wysyłaniu następnej dane mam gotowe.
    W przeciwnym wypadku odwrotnie.

    W zasadzie wystarczy sprawdzić dwie flagi, od USART i od ADC.
    Jeśli obie są wolne, startujemy pomiar, oraz wysyłamy poprzedni.
    Możliwe że będzie te intstrukcje wolniej. Ale przynajmniej mamy jakąś namiastke informacji z peryferri.

    tmf napisał:
    Normalnie nie będzie takiego problemu, tym bardziej, że RS232 nie gubi losowo bajtów. Jeśli mogą być przesyłane długie ciągi tak "spreparowanych" danych, to zawsze można nadać ciąg synchronizujący raz np. na 100 bajtów, lub więcej.

    Losowo nie gubi, ale z tego co wiem gwarancja systemów to 128 (czasem 256) bajtów. Potem może gubić. A dokładnie, można nie nadążyć z odbiorem z bufora, jeśli nagle system ma inne zajęcie. Więc kwestia obsługi transmisji może okazać się istotna.

  • #198 20 Lut 2017 18:21
    trol.six
    Poziom 30  

    Piotrus_999 napisał:
    trol.six napisał:
    ale z tego co wiem gwarancja systemów to 128 (czasem 256) bajtów
    A kto ją dał tę gwarancję, jakiś mądrala z jakiegoś forum?

    Wyczytałem kiedyś z jakieś dokumentacji do jakieś funkcji obsługującej czytanie i zapisywanie.
    W tej chwili musiałbym sobie to odświerzać. Więc może sprawy mają sie tak że nic nie wiadomo, i trzeba "dziergać" po bajcie z potwierdzeniem.

  • #199 20 Lut 2017 18:44
    mariomario
    Poziom 18  

    Dziękuję, widzę wiele cennych wpisów, ale jak pewnie już na początku widać mój kod programu nie jest jakiś bardzo zaawansowany (korzystam z gotowych bibliotek w MikroC PRO for PIC), oraz potrzebuję przesyłać wynik na komputer w formie dziesiętnej z przedziału 0-1023 (czyli od 10bit ADC). A sam jeszcze nie dam rady tego inaczej ogarnąć jak dać szybciej taktowanego uC (np. PIC18F26K22 @ 64MHz) oraz zwiększyć baud rate (np. 115k).

    W związku z powyższym - czy mógłby ktoś podlinkować/podesłać jakieś przykłady, które pomogą mi w zrozumieniu jak można inaczej rozwiązać ten problem z tego tematu. Lub być może ktoś dysponuje już sprawdzonym kawałkiem kodu o podobnym zagadnieniu (szybkim wysyłaniu wyników ADC po UART)?

    Generalnie ten kod ma służyć do bardzo prostego oscyloskopu - raczej edukacyjnego niż przydatnego do czegokolwiek ze względu na małą ilość sampli/s

  • #200 20 Lut 2017 20:06
    BlueDraco
    Specjalista - Mikrokontrolery

    Zieeew. Mówimy o podstawach działania UART, a nie o jakichś wydumanych parametrach ilościowych. MUSIMY co jakiś czas (np. co kilkadziesiąt bajtów) robić przerwy w transmisji danych nie krótsze niż czas transmisji bajtu, bo inaczej być może NIGDY nie odbierzemy żadnej danej. Parę razy temat ten był już poruszany.

    Co do projektu. Przyjmijmy np. że:
    - szybkość transmisji wynosi 115200 b/s
    - przy transmisji danych w postaci binarnej (nie zalecałbym, bo do odbioru musimy mieć wtedy uC z timerem lub UART z funkcją przerwania przy IDLE) możemy łapać i transmitować próbki co czas transmisji 30 bitów, czyli z częstotliwością 3840 próbek 16-bitowych na sekundę
    - ustawiamy timer na częstotliwość 3840 Hz, w przerwaniu timera odczytujemy ADC, startujemy następną konwersję i transmitujemy dane (od biedy nawet z aktywnym oczekiwaniem na UART w przerwaniu - nikt się o to nie obrazi).

    To jest b. prymitywne rozwiązanie, ale działa. Przy buforowaniu próbek i przesyłaniu w większych porcjach możemy dojść do 5.7 kHz przy tej szybkości transmisji.

  • #201 20 Lut 2017 20:39
    Piotrus_999
    Poziom 39  

    BlueDraco napisał:
    Zieeew. Mówimy o podstawach działania UART, a nie o jakichś wydumanych parametrach ilościowych. MUSIMY co jakiś czas (np. co kilkadziesiąt bajtów) robić przerwy w transmisji danych nie krótsze niż czas transmisji bajtu, bo inaczej być może NIGDY nie odbierzemy żadnej danej. Parę razy temat ten był już poruszany.

    Ale nie jak wysyłamy na VCOM (a tu pewnie o to chodzi). Tu żadnych problemów przy pakietach w granicach 64K i prędkościach rzędu 1M nie zaobserwowałem (przynajmniej na STM-ach)

  • #202 20 Lut 2017 20:45
    BlueDraco
    Specjalista - Mikrokontrolery

    Nie ważne, dokąd wysyłamy; ważne, że wysyłamy przez UART. Ciągła transmisja zadziała pod warunkiem, że bity startu będą miały kolor inny od bitów danych. Znasz jakiś UART z kolorowaniem bitów?

  • #203 20 Lut 2017 20:59
    Piotrus_999
    Poziom 39  

    BlueDraco napisał:
    Nie ważne, dokąd wysyłamy; ważne, że wysyłamy przez UART. Ciągła transmisja zadziała pod warunkiem, że bity startu będą miały kolor inny od bitów danych. Znasz jakiś UART z kolorowaniem bitów?
    Chodzi aby się nie rozjechały. Przy dobrze ustawionej baud rate - testowałem przy transmisji przez DMA wiele dni chodziło bez większych zacięć (pakiety były zCRCowane). Ale nie będę wchodził w polemikę - dałem tylko przykład z mojego doświadczenia. Przy procesorach ze słabo ustawialnym baudrate (np AVR) zgadzam się a długość pakietu jaki da się przesłać bedzie zależna od błedu tego ustawienia i jego stabilności.

  • #204 20 Lut 2017 21:10
    BlueDraco
    Specjalista - Mikrokontrolery

    Litości, po czym masz poznać bit startu?! Skąd biedny UART ma wiedzieć, gdzie jest pierwszy bit danych?

  • #205 20 Lut 2017 21:14
    Piotrus_999
    Poziom 39  

    BlueDraco napisał:
    Litości, po czym masz poznać bit startu?! Skąd biedny UART ma wiedzieć, gdzie jest pierwszy bit danych?
    O czym Ty piszesz? Jaki pierwszy? Przerywanie co jakiś czas jest po to aby się zegary po obu stronach nie rozjechały - a raczej aby przy wznowieniu transmisji znowu się zsynchronizowały.

  • #206 20 Lut 2017 23:49
    BlueDraco
    Specjalista - Mikrokontrolery

    Jasne, a bit startu jest czerwony... ;)

  • Pomocny post
    #207 21 Lut 2017 00:34
    trol.six
    Poziom 30  

    mariomario napisał:
    Dziękuję, widzę wiele cennych wpisów, ale jak pewnie już na początku widać mój kod programu nie jest jakiś bardzo zaawansowany (korzystam z gotowych bibliotek w MikroC PRO for PIC), oraz potrzebuję przesyłać wynik na komputer w formie dziesiętnej z przedziału 0-1023 (czyli od 10bit ADC). A sam jeszcze nie dam rady tego inaczej ogarnąć jak dać szybciej taktowanego uC (np. PIC18F26K22 @ 64MHz) oraz zwiększyć baud rate (np. 115k).

    Pisz jak umiesz, bez praktyki raczej się nie nauczysz. Jak nie potrafisz ogarnąć transmisji danych bezpośrednio z ADC, bądź masz tylko standardowy port COM, możesz ten program przyspieszyć, buforując dane z ADC, zapisując je najpierw do pamięci w mikrokontrolerze, i wysyłać następnie taką paczke danych. Nie będziesz miał ciągłego pomiaru, ale uzyskasz próbki z ADC z możliwie wyższą częstotliwością próbkowania.

    Można też zrezygnować z dokładności, i zapisywać tylko najbardziej znaczące 8 bitów. Wtedy możesz zbuforować więcej danych.

    Generalnie to jest problem złożony, i można go przerobić na wiele sposobów.
    Zważywszy na pytanie domniemuje, że masz za mało wiedzy z programowania.

    Nie znam projektów z netu które mogłyby ci pomóc, szczególnie że nie wiem co umiesz. Szukaj za pomocą google. I przeglądaj różne najlepiej proste projekty.

  • #208 21 Lut 2017 02:58
    grko
    Poziom 31  

    BlueDraco napisał:
    Zieeew. Mówimy o podstawach działania UART, a nie o jakichś wydumanych parametrach ilościowych. MUSIMY co jakiś czas (np. co kilkadziesiąt bajtów) robić przerwy w transmisji danych nie krótsze niż czas transmisji bajtu, bo inaczej być może NIGDY nie odbierzemy żadnej danej. Parę razy temat ten był już poruszany.


    No właśnie temat był już kilkanaście razy poruszany i sam przyznałeś, że ta przerwa nie jest konieczna. Jednak nadal popierasz swoją bezsensowną teorię mimo tego, że zostało tam wyjaśnione, że żadna przerwa co kilkadziesiat bajtów nie jest konieczna. Bez problemu można transferować ramki > 16KB po UART (stm32f4+dma) i wszystko działa bez najmniejszego problemu. Testowałem tego typu transmisję w różnych konfiguracjach:
    Router z OpenWRT <-> PC
    Router z OpenWRT <-> STM32
    STM32 <-> PC

    Testy przeprowadzałem na PC z linuxem oraz windowsem dla prędkości UARTa 921600. Błędy transmisji były sporadyczne (nie wiem czy było to więcej niż kilka ramek na godzinę). Przerwa pomiędzy ramkami może i jest potrzebna. Ale na pewno nie jest to kilkadziesiąt bajtów. A ile to jest to się nigdy nie dowiemy bo nigdy nie raczyłeś dokładnie odpowiedzieć na to pytanie. Bardzo prosiłbym o wzór na wyliczenie co ile bajtów powinna być przerwa dla danego baudrate, różnicy w próbkowaniu transmittera/receivera oraz oversampling rate (pytanie co jeszcze wziąć pod uwagę). W końcu jesteśmy inżynierami a nie wróżbitami.

  • #209 21 Lut 2017 11:06
    BlueDraco
    Specjalista - Mikrokontrolery

    Nie czepiam się liczb. To nie jest istotne, co ile ma być przerwa, ale być musi. Nie ma żadnej teorii określającej częstotliwość przerw. Im częstsze przerwy, tym mniejsze straty czasu w przypadku retransmisji ramek, o ile będziemy je retransmitować. Możesz mieć i megabajtową ramkę, a potem wysyłać ją drugi raz, co zajmie jakieś 10 sekund przy 1 Mb/s - dlatego ja wolę ramki znacznie krótsze - do pojedynczych KiB.
    Skoro jednak byłeś łaskaw zgodnie ze swym zwyczajem określić moją "teorię" o konieczności przerw jako bezsensowną, to proszę o podanie sensownej teorii umożliwiającej odbiornikowi danych odebranie poprawnego podciągu danych od nadajnika, który wysyła je bez jakiejkolwiek przerwy i został uruchomiony przed włączeniem odbiornika, zakładając, że transmitowane bajty mogą mieć dowolne wartości. Chętnie się czegoś nauczę od wszystkowiedzącego.

  • #210 21 Lut 2017 11:23
    Piotrus_999
    Poziom 39  

    @BlueDraco Z kolęgą @grko często się spieram, ale ja też na STM-ach nie zauważyłem problemów. Na AVR zegar jest ustawiany tak jak jest i błedy są spore. Na stronie FTDI był kiedyś (nie wiem czy jest teraz) artykuł o synchronizacji fazy wewn zegara dostosowujący się do zaobserwowanych zmian. Pewnie w STM-ach taki mechanizm przy odbiorze też jest zaimplementowany.
    Nie zaobserwowałem problemów przy dużych ramkach danych STM <-> PC-et. Ale na pewno STM <-> atmega będzie trzeba policzyć kiedy sumaryczny bład przekroczy szerokość jednego bitu i transferować ramki odpowiednio krótsze i robić przerwy.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME