Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Dyskusją nad wyższością języków programowania

JacekCz 02 Mar 2018 09:00 5535 71
Tespol
  • #1
    JacekCz
    Level 39  
    jp_elek wrote:
    ... "wyrosłem" na asm.
    i to raczej się nie zmieni, jak już coś robię to chcę "naj. jak się da"...


    nie jest konsekwencją
    nonszalancji w rodzaju " byle jak ,byle było"
    J.P.


    Po pierwsze "naj" może być w górę lub w dół.

    Nonszalancji może tu nie ma, ale MSZ popadłeś w drugą stronę, dziubiąc szczegóły mam wrażenie straciłeś ogół, ogólne widzenie, projektowanie. Np mam wrażenie za długa sekcja krytyczna, mało szczegółów podajesz ale wydaje się błędem projektowym.

    Rozwiązania assemblerowe (lub inspirowane asseblerowo) mają NAJ gorszą konserwatywność kodu itd...

    Piotrus_999 wrote:
    @jp_elek Nie za bardzo rozumiem po co się katować asemblerem.


    +1

    grko wrote:
    @jp_elek Jeżeli musisz optymalizowac tego typu rzeczy w swoim programie to albo coś poszło nie tak na etapie projektowania i wybierania odpowiedniego MCU. Albo coś poszło nie tak podczas implementacji.


    Moderated By tmf:

    Dyskusję niezwiązaną z problemami autora wydzieliłem.


    +1
  • Tespol
  • #2
    ghost2000
    Level 18  
    jp_elek wrote:
    W "C" bywam tylko hobbystą i to z konieczności, "wyrosłem" na asm.

    Na ARM też będziesz pisał w ASM?
    Nigdy nie pisałem w ASM na AVR i jak widzę rozwinięcie ASM to nie widzę możliwości optymalizacji (pomija sprawę przerwań, gdzie GCC nie zawsze sobie dobrze radzi).
    Jak miałbym optymalizować połowę kodu (np 20kB i pisac to w ASM) to wolę wybrać inny procek, np ARM a dla miłośników Atmela (Microchipa) XMEGA.
  • #3
    michalko12
    MCUs specialist
    ghost2000 wrote:
    Na ARM też będziesz pisał w ASM?

    A Ty w jakim języku piszesz?
  • Tespol
  • #4
    ghost2000
    Level 18  
    michalko12 wrote:
    ghost2000 wrote:
    Na ARM też będziesz pisał w ASM?

    A Ty w jakim języku piszesz?

    W C. Nawet na8051 też pisałem w C, naturalnie początki były w ASM.

    Na AVR to jeszcze mozna pisac w ASM ale w ARM jakoś nie moge sobie tego wyobrazić.
  • #5
    michalko12
    MCUs specialist
    ghost2000 wrote:
    W C. Nawet na8051 też pisałem w C, naturalnie początki były w ASM.
    No to czas na level up, bo według niektórych osób C jest już passé :cunning:
    A tak na poważnie, to niech każdy pisze w czym mu najlepiej. Nigdy nie wiesz kto jest po drugiej stronie, 15, 30, 45, a może i 60 latek. Niby na naukę nigdy nie jest za późno, ale z drugiej strony podobno starych drzew się nie przesadza.
  • #6
    User removed account
    User removed account  
  • #7
    ghost2000
    Level 18  
    michalko12 wrote:
    A tak na poważnie, to niech każdy pisze w czym mu najlepiej. Niby na naukę nigdy nie jest za późno, ale z drugiej strony podobno starych drzew się nie przesadza.

    Na to jakiego języka się używa duży wpływ ma użyty uC/procesor. Zagorzały miłośnik ASM nie będzie w nim pisał aplikacji na Windows czy Linux.

    Pewnym oporem jest to, że ma się dużo bibliotek na różne okazje i jest psychiczny problem przepisania tego. Początkowo na 8051 pisałem w ASM. Miałem biblioteki dla różnych peryferii. Spróbowałem C, pisało sie wygodnie, szybko (używałem Keila) i przepisałem biblioteki z ASM na C. Nie było z tym dużo roboty, zwłaszcza, że wszystkie biblioteki dla ASM pisałem sam więc widziałam jak to działa.
    Gdy przesiadłem sie na AVR to naturalnie C. ARM, można sie domyśleć, wróciłem do ASM :-)
  • #8
    michalko12
    MCUs specialist
    Piotrus_999 wrote:

    Dzisiejszy 60 latek to nie ten sam 30 lat temu. Uważasz że 60 letni naukowiec nie jest w stanie już ogarniać swojej nranży?

    Mój znajomy ma 62 lata i ogarnia jeszcze nowe języki, ale jak sam mówi nie idzie mu to najsprawniej i po drugie robi to bo musi, a nie dlatego, że ktoś mu wmawia, że tak dla niego będzie lepiej.

    Dodano po 7 [minuty]:

    ghost2000 wrote:
    Gdy przesiadłem sie na AVR to naturalnie C. ARM, można sie domyśleć, wróciłem do ASM :-)

    Jeśli ktoś będzie musiał się przesiąść na inny rdzeń to sam stwierdzi, co mu przeszkadza. Jeśli da radę nauczyć się nowego języka to to zrobi, a jak nie da rady to komuś to zleci.
    Chodzi o to, że nie rozumiem dlaczego co drugi wątek musi zawierać dyskusje o zmianie rdzenia czy języka, jeśli autor wątku o to nie pyta.
  • #9
    User removed account
    User removed account  
  • #10
    michalko12
    MCUs specialist
    Piotrus_999 wrote:
    @michalko12 Włąsnie pytał co zrobić aby kompilator C mu skompilował lepiej.

    A to była jedna z odpowiedzi...
    ghost2000 wrote:
    Na ARM też będziesz pisał w ASM?
    Nigdy nie pisałem w ASM na AVR i jak widzę rozwinięcie ASM to nie widzę możliwości optymalizacji (pomija sprawę przerwań, gdzie GCC nie zawsze sobie dobrze radzi).
    Jak miałbym optymalizować połowę kodu (np 20kB i pisac to w ASM) to wolę wybrać inny procek, np ARM a dla miłośników Atmela (Microchipa) XMEGA.

    ...mająca wiele wspólnego z tematem...
  • #11
    Freddie Chopin
    MCUs specialist
    michalko12 wrote:
    No to czas na level up, bo według niektórych osób C jest już passé :cunning:

    Ponieważ zostałem wywołany, to przybywam (;

    michalko12 wrote:
    Nigdy nie wiesz kto jest po drugiej stronie, 15, 30, 45, a może i 60 latek.

    Albo i 67-latek! https://en.wikipedia.org/wiki/Bjarne_Stroustrup
  • #13
    jp_elek
    Level 9  
    Panowie,
    .. po 21 postach ( a i to "obciętych" przez moderatora ) mamy:

    #2 @Grko - są funkcje wbudowane - "spróbuj tej",
    #3 @michalko12 - wprost : "spróbuj tak",
    #7 @Grko - "zwróć uwagę" (pośrednio) że są limity/koszty, języka / koncepcji,
    #9 @Piotrus_999 - konstrukcja zapisu determinuje optymalizację wyniku (niekoniecznie zawsze ale jednak) ,

    .. to tak jakieś 20-30% "cukru w cukrze".

    Jako ten który już niejedno widział i słyszał powiem wprost
    dobrze by było gdyby forum to "ciągnęło w górę" -tych którzy stawiają pytania.

    Ostatecznie Autorom postów powyżej, jeszcze raz podziękowania,
    @michalko12 - kłaniam się Panu - w pas , ponad wszystko cenię sobie "mówić do rzeczy, na temat , nie używając ogólników/haseł/"trendy zawołań" lecz "treściwie".
    Pozdrawiam J.P.
  • #14
    Freddie Chopin
    MCUs specialist
    michalko12 wrote:
    To jakiego NOWEGO języka uczy się w tej chwili?

    Tego typu argument w ogóle do mnie nie trafia. Branża technologii jest taka, że jak się stoi w miejscu to realnie się cofasz. Więc jeśli ktoś sobie chce stać w miejscu i zostać przy tym co nauczył się x lat temu (za 'x' wstawić dowolną liczbę, byle dwucyfrową) to proszę bardzo, ale nie przedstawiajmy tego jako cnoty czy zalety ostatecznej... No bo jak to - sugestie wzięcia nowszego układu zamiast starszego są ok, ale już sugestie użycia nowszego języka (metodologii) nie? Skoro w rozważaniach nad projektami mam rozpatrywać argument, że w projekcie może być również "sześćdziesięciolatek", to może zamiast używać C i ARMa/AVRa lepiej ograniczyć się do '51 i języka drabinkowego? Przecież jak ten biedny "sześćdziesięciolatek" zaczynał w branży, to nie było ani ARMów, ani AVRów - w końcu AVRy zostały wprowadzone w roku 1996, więc ten biedny i niezbyt ogarnięty w nowościach dzisiejszy "sześćdziesięciolatek" miał wtedy prawie "czterdziechę" na karku i z 15 lat w branży, więc już mogło mu się nie chcieć uczyć niczego nowego, bo i po co z takim nastawieniem?

    Do tego nie mówimy tu o jakichś ultranowościach - na dzisiejsze standardy C czy C++ to prehistoria informatyki (jeden i drugi starszy niż zapewne większość uczestników tego wątku), tak samo jak architektura mikrokontrolerów AVR czy ARM... Nie trzeba mieć doktoratu żeby to zrozumieć - tylko trochę chęci. A jak ktoś nie ma nawet chęci, to... przykro mi, nie mój problem (;
  • #15
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    A jak ktoś nie ma nawet chęci, to... przykro mi, nie mój problem (;
    Po co komuś wpychać na siłę coś o co w ogóle nie prosi? Każdy ma swój rozum i jeśli będzie potrzebował takiej porady to założy taki temat. Niektórzy tylko czekają na okazję, żeby wtrącić standardową regułkę - "przejdź na C, zmień na ARMa", naprawdę to już nudne się zrobiło. Proponuję założyć temat " Przejdź na C (C++), zmień procesor na ARMa - to dla twojego dobra" i niech tam każdy się produkuje codziennie jeśli ma taką potrzebę. Chciałbyś, żeby Ci ktoś w każdym twoim temacie mówił co masz robić i do znudzenia powtarzał to samo? Ludzie obserwują otoczenie i widzą co jest "trendy" i "na topie", ale jak w każdej innej dziedzinie życia są ludzie co mają swoje zdanie i nie podążają za tłumem. Dlaczego Ty @Freddie Chopin nie zostaniesz przy C, przecież tu 90% uważa, że to byłoby "najlepsze" dla Ciebie? Powiem coś na swoim przykładzie. C++11 mam opanowane powiedzmy w > 90%, ale co z tego jeśli nie potrafię zacząć myśleć w tym języku. Nauka samej składni to nie wszystko. Bardzo mam zakorzenione praktyki z C i teraz ciężko zacząć myśleć inaczej. Jak będę miał czas i jakiś przymus to wezmę się za to, ale teraz nie mam ani czasu, ani chęci i nie chciałbym, żeby mi ktoś w kółko mówił żebym to zrobił, bo tak będzie dla mnie najlepiej.
  • #16
    Freddie Chopin
    MCUs specialist
    michalko12 wrote:
    Po co komuś wpychać na siłę coś o co w ogóle nie prosi?

    Jak ktoś będzie chciał naprawić silnik w samochodzie przy pomocy młotka i dłutka to rozumiem że udzielisz mu informacji o tym jak to zrobić, bo przecież nie pytał się o żadne profesjonalne metody regeneracji swojego bolidu, a może akurat masz do czynienia z "sześćdziesięciolatkiem"?

    michalko12 wrote:
    Każdy ma swój rozum i jeśli będzie potrzebował takiej porady to założy taki temat.

    michalko12 wrote:
    Chciałbyś, żeby Ci ktoś w każdym twoim temacie mówił co masz robić i do znudzenia powtarzał to samo?

    To jest forum dyskusyjne, a nie helpline czy pomoc techniczna. Niemniej jednak odpowiem - jeśli rozwiązanie które by proponował było obiektywnie lepsze i miał na to argumenty, to czemu miałbym brnąć w zaparte w swoją własną, gorszą wizję? Na swoim przykładzie wiem, że czasem nie do końca wiadomo z czym jest problem, więc ciężko spytać się konkretnie o to, czy nawet mieć świadomość tego że problem może być zupełnie gdzie indziej. Bardzo często rozwiązując jakiś problem można się zafixować na jednej opcji rozwiązania go, choć ona wcale nie jest dobra czy optymalna.

    Ten wątek nawet jest doskonałym przykładem - Modbus jest generalnie bardzo BARDZO wolny, a tu ktoś chce ucinać pojedyncze rozkazy assemblera z operacji zmiany kolejności bajtów... Problemem nie jest to, że w C kod odwracający bajty w tablicy jest nieoptymalny - dla użycia w Modbusie przy śmiesznej ilości kilku/kilkudziesięciu/kilkuset rejestrów Modbusa to bez jakiegokolwiek znaczenia. Sam mam od dobrych paru lat na tapecie projekt z Modbusem (początkowo na wolnym STM32F100), w którym takich rejestrów jest już spokojnie ze 2 czy 3 tysiące, a nawet nigdy się nie zastanawiałem czy mój kod odwracający bajty jest optymalny czy nie (pewnie nie, bo to bez znaczenia). Wg Twojego podejścia powinniśmy się skupić jedynie na problemie poruszonym przez autora wątku, czyli jak uciąć kilka rozkazów assemblera z kodu wygenerowanego przez C (choć nawet nie wrzucił tu CAŁEGO kodu który jest istotny ani opcji kompilatora jakich używa). Tymczasem problem jest zupełnie gdzie indziej - w nieoptymalnej architekturze programu, która sprawiła że autor szuka cykli rdzenia w złym miejscu, bo nie wiedzieć czemu całość operacji zmiany kolejności bajtów dał w sekcji krytycznej.

    michalko12 wrote:
    Dlaczego Ty @Freddie Chopin nie zostaniesz przy C, przecież tu 90% uważa, że to byłoby "najlepsze" dla Ciebie?

    Uważać sobie owe 90% może co chce - wystarczą przekonujące argumenty i nawet nie obejrzysz się jak zostanę orędownikiem rozwiązania które uważam za lepsze (; Tyle że argument to nie jakieś gadki o tym że ktoś może być nieogarnięty, że komuś nie chce się uczyć czegoś nowego i że może akurat ma "sześćdziesiątkę" na karku, rodzinę na utrzymaniu, kredyt we frankach albo i "horom curke", więc nie ma głowy na jakieś "nowoczesne" bzdury elektroniczno-informatyczne.

    michalko12 wrote:
    Powiem coś na swoim przykładzie. C++11 mam opanowane powiedzmy w > 90%, ale co z tego jeśli nie potrafię zacząć myśleć w tym języku. Nauka samej składni to nie wszystko. Bardzo mam zakorzenione praktyki z C i teraz ciężko zacząć myśleć inaczej. Jak będę miał czas i jakiś przymus to wezmę się za to, ale teraz nie mam ani czasu, ani chęci i nie chciałbym, żeby mi ktoś w kółko mówił żebym to zrobił, bo tak będzie dla mnie najlepiej.

    I liczysz na to, że przy tym podejściu pewnej księżycowej nocy we śnie objawi Ci się wszechwiedza dotycząca programowania obiektowego? Czy naprawdę traktujesz to, że sam nie masz czasu/ochoty/chęci/zapału/... do nauki czegoś nowego jako uniwersalny argument pasujący dla każdej sytuacji i każdego pytającego?

    Przy okazji naprawdę nie zauważyłem, żeby ktoś Ci mówił, co będzie dla Ciebie najlepsze w formie ogólnikowej. Ja na pewno nie, a za innych nie odpowiadam. Bo jeśli przedstawiasz jakiś konkretny problem i istnieje pewne rozwiązanie/metodologia/język-programowania/rodzina-mikrokontrolerów które do danego rozwiązania byłyby jednak (naj)lepsze, to czemu się obruszać, że ktoś Ci takie podaje?

    Na koniec przypominam, że to jest forum dyskusyjne, a nie pomoc techniczna.

    Nie wiem też po co ten atak na mnie, skoro nie odzywałem się w tym wątku do momentu aż mnie wywołałeś [;
  • #17
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    Jak ktoś będzie chciał naprawić silnik w samochodzie przy pomocy młotka i dłutka to rozumiem że udzielisz mu informacji o tym jak to zrobić, bo przecież nie pytał się o żadne profesjonalne metody regeneracji swojego bolidu, a może akurat masz do czynienia z "sześćdziesięciolatkiem"?

    Nie mam ochoty i czasu na takie dyskusje, ale porównując to do tej analogi to odpowiedzi o zmianie języka i procesora to jak odpowiedzi o zmianie samochodu bo ten jest do dupy.
    Freddie Chopin wrote:
    Ten wątek nawet jest doskonałym przykładem - Modbus jest generalnie bardzo BARDZO wolny, a tu ktoś chce ucinać pojedyncze rozkazy assemblera z operacji zmiany kolejności bajtów... Problemem nie jest to, że w C kod odwracający bajty w tablicy jest nieoptymalny - dla użycia w Modbusie przy śmiesznej ilości kilku/kilkudziesięciu/kilkuset rejestrów Modbusa to bez jakiegokolwiek znaczenia.
    Człowiek zadał pytanie szczątkowe, więc na tej podstawie powinien dostać odpowiedź, ewentualnie powinien zostać poproszony o rozszerzenie tematu, bo na tej podstawie precyzyjnej odpowiedzi nie da się udzielić. Można zacząć dyskutować o optymalizacji kodu pod kątem MODBUSa, ale ta dyskusja nie powinna dotyczyć zmiany procesora czy języka programowania. Gdyby padło pytania o wybór optymalnego uC do obsługi MB, no to wtedy można na ten temat dyskutować.
    Freddie Chopin wrote:
    Nie wiem też po co ten atak na mnie, skoro nie odzywałem się w tym wątku do momentu aż mnie wywołałeś [;
    Źle to odebrałeś, na pewno nie atakowałem Cię, nie miałem takiego zamiaru. Tak swoją drogą gdzie Cię wywołałem? :cunning:

    Dodano po 3 [minuty]:

    Freddie Chopin wrote:
    Na koniec przypominam, że to jest forum dyskusyjne, a nie pomoc techniczna.
    Ale po to są zakładane tematy, żeby każda dyskusja była merytoryczna, a do dyskusji o wszystkim i niczym jest zdaje się hydepark.

    Jeszcze dla porównania przykład z SO i co by było gdyby na SO na takie pytanie co chwila padała odpowiedź typu "Zmień kompilator"? To a pro po tej analogi do samochodu, młotka i przecinaka...

    Freddie Chopin wrote:
    Nie wiem też po co ten atak na mnie, skoro nie odzywałem się w tym wątku do momentu aż mnie wywołałeś [;
    Tak swoją drogą, gdzie Cię wywołałem? :cunning:
  • #18
    User removed account
    User removed account  
  • #19
    Freddie Chopin
    MCUs specialist
    michalko12 wrote:
    Jeszcze dla porównania przykład z SO i co by było gdyby na SO na takie pytanie co chwila padała odpowiedź typu "Zmień kompilator"? To a pro po tej analogi do samochodu, młotka i przecinaka...

    StackOverflow to jest StackOverflow - strona o forumule Q&A, a forum dyskusyjne to forum dyskusyjne.
  • #20
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    StackOverflow to jest StackOverflow

    Tiaaa..., a elektroda to elektroda - czytaj sajgon.
  • #21
    Freddie Chopin
    MCUs specialist
    To już sam sobie powiedziałeś - nie ma sensu porównywać stron o zupełnie różnej formule. SO to nie jest forum dyskusyjne, więc co ma to do rzeczy co by się tam działo z naszymi odpowiedziami i off-topami? Tak jak napisał Piotrus_999 - na SO samo pytanie zostałoby zamknięte gdzieś w max godzinę, bo brakuje w nim połowy istotnych informacji, a tak czy siak w komentarzach pod nim najwięcej miejsca zajmowałoby info o przedwczesnej optymalizacji i o tym że problemem jest błędna architektura, a nie jakieś odwracanie bajtów... Nie wierzysz, to załóż tam taki wątek, przekonasz się sam [;

    Dodano po 5 [minuty]:

    Żeby podkreślić co jest nie w porządku z tym wątkiem, może wróćmy do pierwszego postu. Autor chce konwertować do 100 elementów. Z dalszych postów dowiadujemy się, że w assemblerze osiągnął około 8 rozkazów na jeden element, w C jest to powiedzmy 2x tyle. Nie znam AVR, wiec nie wiem czy rozkazy są jednocyklowe, no ale załóżmy że większość jest. No więc teraz ten straszny problem wynika z tego, że pętla zajmuje albo jakieś 1000 cykli, albo jakieś 2000 cykli. Załóżmy że AVR chodzi na 16 MHz. Odświeżanie rejestrów Modbusa zwykle odbywa się co abstrakcyjnie długi czas wynoszący jedną sekundę, czasem można sobie zejść do 100 ms, niżej nie ma sensu, bo timeouty odpowiedzi które się zwykle używa już są dłuższe. No więc kruszymy kopię o to, czy AVR będzie coś robił przez 0,0625% czasu czy może przez 0,125% czasu. No faktycznie - bardzo poważny temat... Każdy offtop sugerujący, że problemem jest raczej coś innego jest niedopuszczalny...
  • #22
    User removed account
    User removed account  
  • #23
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    na SO samo pytanie zostałoby zamknięte gdzieś w max godzinę, bo brakuje w nim połowy istotnych informacji, a tak czy siak w komentarzach pod nim najwięcej miejsca zajmowałoby info o przedwczesnej optymalizacji i o tym że problemem jest błędna architektura, a nie jakieś odwracanie bajtów...
    To, że cały program jest skopany i teraz autor próbuje się ratować jakimiś optymalizacjami to jest jego problem. Nie zapytał się o całą architekturę programu tylko o jakąś pierdołę, ale to nie jest powód, żeby mu wciskać inne języki i procesory. Też mam projekty z MODBUSem i tysiącami rejestrów na AVR i na CM3 i ani jeden, ani drugi nawet nie jęknie przy pełnej ramce i 115200. Do AVRów nie tykam się już, ostatnio musiałem to z przymusu zrobić i co wtedy by mi było po takich poradach odnośnie zmiany CPU? Dlaczego miałbym zmieniać na łARMa jeśli wiedziałem, że to co robię i tak nie zajedzie tego biednego łAVałeRka?
    Jest to forum dyskusyjne ale po to są działy i tematy żeby dyskusje były merytoryczne, a nie z kontekstu wyrwane pogawędki.
  • #24
    jp_elek
    Level 9  
    No cóż, czytanie ze zrozumieniem to wciąż wyzwanie :

    @piotrus_999 - jeszcze gorzej bo:
    1. AVR/[C]/ zamiana LE/GE - to z góry narzucone ramy zakresu dyskusji/pytania,
    2. (historia kowala), elementy to:
    a. zamknięcie koperty to zamiana LE/GE
    b. prasa/scyzoryk/kciuk - to narzędzia [C] / asm./asm.
    c. zegarek to platforma (obiekt działań) - AVR
    d. punkt (a) zrealizowano, każdym narzędziem (b)
    e. mistrzem jest kowal posługujący się [C]- potężne narzędzie użyte bardzo precyzyjnie, acz do prymitywnego zadania ,- potwierdzające mistrzowstwo obsługi.

    punkt 1. w języku polskim brzmi " Jakich rad udzieli mającemu mętne pojęcie o obsłudze prasy, mistrz obsługi prasy aby zamknąć kopertę zegarka jak najprościej ?

    Panowie, sofizmatów typu;- forum dyskusyjne/techniczne, silnik naprawić młotkiem itp., itd. da się spłodzić jeszcze dziesiątki...

    Po staroświecku i przyzwoicie jest odpowiedzieć:
    - gdy wiem że to niewykonalne:,; - idź pan szukaj większych fachowców ode mnie/ nie widzę możliwości / nie zabieram głosu ..
    - gdy widzę jakiś zakres możliwości - odpowiadam,jak przywołani przeze mnie Autorzy postów powyżej
  • #25
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    Odświeżanie rejestrów Modbusa zwykle odbywa się co abstrakcyjnie długi czas wynoszący jedną sekundę, czasem można sobie zejść do 100 ms, niżej nie ma sensu, bo timeouty odpowiedzi które się zwykle używa już są dłuższe.

    Wszystko zależy od projektu, mam przypadki gdzie tysiące ramek powinny przejść jak najszybciej, bo nowe dane są dostępne "od razu".
  • #26
    Freddie Chopin
    MCUs specialist
    Wysyłanie tych 100 rejestrów potrwa tak czy siak jakieś 14 ms (200 bajtów przy 115200), więc niżej niż te 14 ms i tak nie zejdziesz. No chyba że moje założenie jest błędne i autor używa Modbusa TCP albo RTU z baudratem typu 1 czy 2 Mbps... Jeśli jednak używa 115200 bps w trybie RTU, to moje wcześniejsze kalkulacje wiele się nie zmieniają - wystarczy pomnożyć przez jakieś 7 - dalej jesteśmy poniżej 1%. A nawet nie wiadomo, czy nie używa jeszcze mniejszej prędkości... Tak więc ten wątek z założenia jest mało sensowny.
    Dodano po 5 [minuty]:
    jp_elek wrote:
    No cóż, czytanie ze zrozumieniem to wciąż wyzwanie :

    Ja znam jeszcze większe wyzwania - zadawanie pytań tak żeby zawrzeć wszystkie istotne informacje i przyjmowanie informacji że obrana metoda jest błędna, a problem leży zupełnie gdzie indziej.
  • #27
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    Wysyłanie tych 100 rejestrów potrwa tak czy siak jakieś 14 ms (200 bajtów przy 115200), więc niżej niż te 14 ms i tak nie zejdziesz. No chyba że moje założenie jest błędne i autor używa Modbusa TCP albo RTU z baudratem typu 1 czy 2 Mbps... Jeśli jednak używa 115200 bps w trybie RTU, to moje wcześniejsze kalkulacje wiele się nie zmieniają - wystarczy pomnożyć przez jakieś 7 - dalej jesteśmy poniżej 1%.

    Wszystko się zgadza, jeśli dobrze podejdziesz do tematu to nawet '51@12MHz tego nie poczuje. Autor podszedł jakoś tam, tego nam nie wiadomo jak, nie chciał się tym podzielić - jego sprawa. Gdyby nie wspomniał, że chodzi o MODBUSa, tylko że potrzebuje zamienić kolejność bajtów w tablicy w krótkim czasie, to nie byłoby w ogóle mowy o tym, że to kod obsługi MODBUSa jest skopany. Trzeba jeszcze wziąć pod uwagę, że ten AVR z czegoś generuje te dane i to z kolei może mu zajmować w niektórych przypadkach 99% czasu procesora. Pewnie da to się inaczej zrobić, ale tego też nie wiemy o co chodzi, więc nie powinniśmy gdybać tylko odpowiedzieć lub nie na pytanie autora bez zbędnych dywagacji i wróżenia, lub dopytać o szczegóły.
  • #28
    Freddie Chopin
    MCUs specialist
    michalko12 wrote:
    Gdyby nie wspomniał, że chodzi o MODBUSa, tylko że potrzebuje zamienić kolejność bajtów w tablicy w krótkim czasie, to nie byłoby w ogóle mowy o tym, że to kod obsługi MODBUSa jest skopany.

    Wtedy byśmy pisali, że w innym miejscu coś skopał, skoro 1000 cykli w tą czy w tamtą jest takim problemem.

    michalko12 wrote:
    Trzeba jeszcze wziąć pod uwagę, że ten AVR z czegoś generuje te dane i to z kolei może mu zajmować w niektórych przypadkach 99% czasu procesora.

    W takiej sytuacji nawet nie trzeba pisać, że założenia projektu lub jego implementacja są kompletnie błędne, bo to jest wtedy oczywiste.

    michalko12 wrote:
    Pewnie da to się inaczej zrobić, ale tego też nie wiemy o co chodzi, więc nie powinniśmy gdybać tylko odpowiedzieć lub nie na pytanie autora bez zbędnych dywagacji i wróżenia, lub dopytać o szczegóły.

    Ty odpowiedz dokładnie na to o co pytał, a my sobie pogdybamy. Ciekawe czy większy pożytek będzie miał z porady jak urwać 1000 cykli czy może jak zmienić architekturę programu tak żeby ilości cykli mniejsze niż sześciocyfrowe go mało obchodziły?
  • #29
    michalko12
    MCUs specialist
    Freddie Chopin wrote:
    Ty odpowiedz dokładnie na to o co pytał, a my sobie pogdybamy. Ciekawe czy większy pożytek będzie miał z porady jak urwać 1000 cykli czy może jak zmienić architekturę programu tak żeby ilości cykli mniejsze niż sześciocyfrowe go mało obchodziły?
    Wspomniał w jednym z postów
    jp_elek wrote:
    W "C" bywam tylko hobbystą i to z konieczności, "wyrosłem" na asm.
    czyli jako osoba niezaawansowana nie musi mieć polotu w organizacji całego projektu. W większości przypadków może korzystać z ogólnodostępnych poradników i bibliotek, a te biblioteki (zwłaszcza dla "początkujących") wiadomo jak są pisane - bez delay nie obejdzie się. Możesz wskazywać jako osoba zaawansowana co jest źle, ale osoba niezaawansowana pewnych rzeczy nie przeskoczy i to niezależnie od języka i typu CPU. Dopóki na świecie będą tylko takie poradniki to tego typu wątków nie da się uniknąć.
  • #30
    Freddie Chopin
    MCUs specialist
    michalko12 wrote:
    Możesz wskazywać jako osoba zaawansowana co jest źle, ale osoba niezaawansowana pewnych rzeczy nie przeskoczy i to niezależnie od języka i typu CPU.

    Zgadza się, tylko że przy tym założeniu ucięcie 1000 cykli z jakiegoś tam jednego miejsca nie rozwiąże problemu. Może wyeliminuje jeden objaw, ale zaraz pojawi się kolejny. A potem jeszcze jeden. I tak dalej...

    michalko12 wrote:
    jako osoba niezaawansowana nie musi mieć polotu w organizacji całego projektu.

    No i? Co to za argument w ogóle i jak miałbym się do niego odnieść? Ja np. nie mam polotu w byciu pilotem Boeinga 777, ale czy to znaczy że koniecznie muszę nim latać? (; Jest jakiś problem, więc trzeba go rozwiązać, jeśli ktoś nie jest w stanie wcielić w życie porad jakie otrzyma na forum to co - mamy napisać za niego? Dziś nie jest biegły, ale jak się przyłoży to jutro będzie już bardziej biegły, a kolejnego dnia jeszcze bardziej - bez praktyki samo nie przyjdzie.