eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaPICowanie
Ilość wypowiedzi w tym wątku: 95

  • 41. Data: 2013-10-10 22:49:40
    Temat: Re: PICowanie
    Od: Marek Borowski <m...@x...com>

    On 10/10/2013 9:49 PM, Sebastian Biały wrote:
    > On 2013-10-10 21:43, Marek Borowski wrote:
    >>>> Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?
    >>> Mniej więcej w wersji lite.
    >> A w wersji full ?
    >
    > Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
    To akutrat wymienilem.

    > szybkości na uC) bądź obliczenia na szablonach.
    >
    Czyli metaprograming. Jeszcze cos ?

    Pozdrawiam

    Marek





  • 42. Data: 2013-10-11 00:11:51
    Temat: Re: PICowanie
    Od: Sylwester Łazar <i...@a...pl>

    > pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
    > nie różni od pisania w asm i świadczy o ubogim warsztacie.
    Tu bym się nie zgodził.
    Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.
    Zresztą niektórzy twierdzą, że już tak jest.
    Warsztat to chyba nie jest dobre słowo na metody pracy.
    Wydaje mi się, że mieszasz. Uznajesz, że wybór języka programowania
    wpływa na warsztat.
    Na to jest już szereg innych określeń: inteligencja, umiejętność myślenia
    przestrzennego,
    dobra realizacja zadań. I moim zdaniem nie ma to kompletnie nic wspólnego
    z rodzajem języka, którego używasz.
    Choć, przyznaję, nauka kolejnego może rozwijać "warsztat".
    Zupełnie tak samo, jak nauka budowy kolejnego ukontrolera.
    A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
    Mój warsztat jest bardzo "ubogi":
    1) kod jest napisany zwięźle i czytelnie.
    2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
    tablice LUT.
    3) każda linijka ma swój komentarz.
    4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
    celu.
    5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
    algorytmu
    lub innych form zapisu, takich jak tabela stanów, opis struktur danych itp.
    6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
    konkretnego mikrokontrolera 8,16,32 bitowego
    7) kodowanie jest czynnością przyjemną choć dość prymitywną.
    8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
    postawienia Breakpointa i odczytanie stanu procesora.
    9) cała analiza opiera się na oglądaniu kolorowych algorytmów.
    10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
    Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
    W szczególności nie interesuje mnie nawet język programowania.
    Mógłby to być C++ czy C bez różnicy.
    Tylko tak się składa, że asm sprawdza się najlepiej.

    I teraz. Twój przykład mnie po prostu zastrzelił.
    Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
    (twoje cli())
    Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
    Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
    sprzętu.
    Ważna jest komunikacja POP (ISR) i programu głównego.
    Czasem ważne są priorytety przerwań.

    W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
    że:
    1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
    (C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
    dość śmieszne.
    Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
    że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.
    A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?
    Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)
    2) Twoja argumentacja:
    "W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
    znacznie czytelniejszy"
    Czy ja wiem?
    Toż przecież - spójrz w swój kod po kompilacji.
    Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
    rejestr,
    bez pośrednictwa nawet rejestru?
    3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
    potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.
    Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
    Czas leci do przodu, a kompilatory operują już na wysokiej klasie
    abstrakcji.
    Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
    mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.
    No bo jak poprawiać kod asm wygenerowany przez kompilator,
    który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
    procesora,
    wykonuje jedno podstawienie i przywraca te rejestry.
    Niestety zwiększając częstotliwość przerwań, okazuje się, że szybki procesor
    spędza swój żywot na zapisywaniu stosu w tą i z powrotem, tracąc głupio
    swoją moc obliczeniową
    oraz potencjalną gotowość do błyskawicznej reakcji na inne zmienne
    środowiskowe.

    --
    -- .
    pozdrawiam
    Sylwester Łazar
    http://www.alpro.pl Systemy elektroniczne.
    http://www.rimu.pl -oprogramowanie do edycji schematów
    i projektowania PCB.



  • 43. Data: 2013-10-11 00:19:44
    Temat: Re: PICowanie
    Od: Sebastian Biały <h...@p...onet.pl>

    On 2013-10-10 22:49, Marek Borowski wrote:
    >>>> Mniej więcej w wersji lite.
    >>> A w wersji full ?
    >> Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
    > To akutrat wymienilem.
    >> szybkości na uC) bądź obliczenia na szablonach.
    > Czyli metaprograming. Jeszcze cos ?

    Rzadziej:

    Programowanie obiektowe (ze względu na heap raczej arm7 i więcej). Sporo
    SFINAE w różnych postaciach. Obciętą wersję template expressions w
    jednym z projektów. Silnie typowane flagi bitowe. Namespaces
    powszechnie, często anonimowe. Type traits. Inicjalizacja przed main
    (szczególnie peryferiów).

    Natomiast latwiej będzie czego nie używam:

    Smart pointerów, bo fragrmentują pamięć, boosta (tylko dlatego że nie ma
    zazwyczaj na mniejsze uC), stla ze względu na fragmentacje. Boosta
    żałuję najbardziej.


  • 44. Data: 2013-10-11 00:53:30
    Temat: Re: PICowanie
    Od: Sebastian Biały <h...@p...onet.pl>

    On 2013-10-11 00:11, Sylwester Łazar wrote:
    >> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
    >> nie różni od pisania w asm i świadczy o ubogim warsztacie.
    > Tu bym się nie zgodził.
    > Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.

    Zauważ ciekawostkę. Każdy programista C powie, że u niego też się da "bo
    tu panie, można takie makro zrobić i już". Trudno się z tym nie zgodzić,
    skoro oba języki są identyczne w sensie Turinga. Tylko co z tego wynika?
    Wymyslanie kwadratowych kół. Takich jak "przecież gcc ma destruktory w
    C". Absurd. C++ ma destruktory i jest wspierany *wszędzie* poza niszami.
    I cały problem sprawadza się do wymiany gcc na g++ w makefile. Jeśli
    "wszystko też się da zrobić w C" to masz ubogi warsztat. Bo masz tylko
    młotek i wkręcasz nim śrubki.

    > A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
    > Mój warsztat jest bardzo "ubogi":
    > 1) kod jest napisany zwięźle i czytelnie.

    Asm jest językiem write-only i 100% nie przenośnym. I turing complete,
    bez wątpienia. Meta assemblery które robią abstrakcję na cpu muszą i tak
    robić jakieś założenia ktore sa nieprzenośne.

    > 2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
    > tablice LUT.

    Mój kod ma taki rozmia jaki jest w nim algorytm. Twierdzenie że asm
    magicznie zmniejsza rozmiar jest nadużyciem. LUT (w jakiejkolwiek
    formie) w C++ jest jakims problemem?

    > 3) każda linijka ma swój komentarz.

    No właśnie, kod jest tak nieczytelny że bez komentarzy nie da rady. Tak,
    wiem że to co teraz napisałem powoduje skok ciśnienia. Dobrze się
    zastanów czy obecnośc komentarzy świadczy o czytelności *kodu*, czyli
    punkt 1. Niektórzy twierdzą że *kod* prawidłowo napisany nie zawiera
    komentarzy. Sa zbędne i nie zawsze synchroniczne względem kodu czesto
    wproawadzają w bład.

    > 4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
    > celu.

    Trudno mi się zgodzić z hipotezą że każdy komentarz jest aktualny do
    każdego kawałka kodu. Zazwyczaj nie jest. Jesli trzymasz to w ryzach to
    gratuluje. Nikt nie dałby rady. Widziałem wiele prób.

    > 5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
    > algorytmu
    > lub innych form zapisu, takich jak tabela stanów, opis struktur
    danych itp.

    Strukturę logiczną masz porozmywaną na detalach obsługi stosu, rolowania
    bitów i tym podobnych elementarnych operacji ktore ukrywają sens
    algorytmu skupiając sie na emulacji mnożenia. Jesli istnieje
    wysokopoziomowy opis to naduzyciem jest twierdzenie że to jest assembler.

    > 6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
    > konkretnego mikrokontrolera 8,16,32 bitowego

    Oczywiście o ile ilośc rejestrów się zgadza. Albo Neumann zamienil się w
    Harvard. Wiem że można sporo zrobić w ten sposób ale po co skoro po to
    powstal C i masa innych jezyków?

    > 7) kodowanie jest czynnością przyjemną choć dość prymitywną.

    Bo kazdy język write-only przyjemnie się koduje. Zapytaj programistów
    perla. Oni kochają pisać. Czytać nienawidzą.

    > 8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
    > postawienia Breakpointa i odczytanie stanu procesora.

    To dośc interesujące bo wiekszość moich projektów nie ma ani kawałka
    IDE. Makefile, konsola, edytor. Ponadto polemizowalbym że odczytywanie
    stanu procesora jest wygodniejsze niż chodzący po ekranie IDE kursor i
    podgląd zmiennych pod myszką.

    > 9) cała analiza opiera się na oglądaniu kolorowych algorytmów.

    Z chęcią zobacze jak wygląda taki zapis w *assemblerze*.

    > 10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
    > Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
    > W szczególności nie interesuje mnie nawet język programowania.
    > Mógłby to być C++ czy C bez różnicy.
    > Tylko tak się składa, że asm sprawdza się najlepiej.

    Piszesz najprawdopodobniej dość określone algorytmy, gdzie metoda się
    sprawdza.

    Ja też nie jestem zainteresowany na co piszę. Co gorsza kod zazwyczaj
    jest przetestowany w sporym stopniu przed pierwsza wrzutą w uC. I nie
    chodzi tutaj o emulatory, tylko o unit testy.

    > I teraz. Twój przykład mnie po prostu zastrzelił.
    > Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
    > (twoje cli())

    Ja pamiętam. Wtedy gdy to konieczne. Na przykład wczoraj musiałem w
    ciągu 5 cykli zegara coś wystawić na piny. Nie mam czasu na obslugę timera.

    > Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
    > Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
    > sprzętu.

    Co czasem wymaga wylaczenia przerwań. O takich drobnostkach jak atomowe
    operacje na typach > niż slowo maszynowe ciezko mi wspominać.

    > W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
    > że:
    > 1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
    > (C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
    > dość śmieszne.

    Nie znasz kontekstu więc śmieszne jest twierdzenie że jest o
    nieprzydatny. A kontekst co gorsza jest niepotrzebny bo to po prostu
    czesto spotykany idiom.

    Pamietaj że to nie jest *jedyny* przykład. To tylko najprostsza rzecz
    jaką programista embedded może uzyć po zamianie gcc na g++. Jest tego od
    groma.

    > Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
    > że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.

    Zazwyczaj robi to w parach i upiera się że robienie pary ręcznie jest
    lepsze niż automatycznie. Nie wiem dlaczego.

    > A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?

    Jest wiele celów. Zazwyczaj sprawdzają się do RT albo atomowych
    operacji. Przykladow jest tak wiele że aż cieżko coś wybrać. jęsli nie
    napotykasz na takie zastosowania gdzie jest to konieczne to być może nie
    miałeś do dzisiaj okazji.

    > Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)

    Kod nie jest ani troche obiektowy. ANI TROCHĘ. Dlaczego każdy kto widzi
    C++ od razu wrzeszczy obiektowość!? Przeciez to ficzer zazwyczaj bez
    znaczenia dla uC.

    > 2) Twoja argumentacja:
    > "W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
    > znacznie czytelniejszy"
    > Czy ja wiem?
    > Toż przecież - spójrz w swój kod po kompilacji.

    Jest identyczny z C. Tak sama ilośc instrukcji kodu maszynowego.

    > Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
    > rejestr,
    > bez pośrednictwa nawet rejestru?

    Przecież czytelnośc nie dotyczy asm. Czytelnośc dotyczy kodu źrodłowego.
    kod maszynowy wygeneruje się w obu wypadkach taki sam.

    > 3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
    > potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.

    Jaki kompilator takie efekty.

    > Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
    > Czas leci do przodu, a kompilatory operują już na wysokiej klasie
    > abstrakcji.
    > Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
    > mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.

    Stajesz okrakiem w stosunku do faktów. Kompilatory stosują wysokie
    poziomy abstrakcji aby poprawnie korzystając z C++ móc generować kod
    lepszy niż ręcznie wydziobany w C. Niestety to wymaga dużego
    doświadczenia w znajomosci architektury, języka i idiotyzmów c++.
    Ogólnie twierdzenie ze kompilatory C++ generują marny kod jest
    absurdalne. To jest prostu nieprawda. Natomiast niektóre z nich tak
    robią z róznych przyczyn wlaczając w to debilizm programisty czy bledy
    projektowe samego kompilatora a sytuacji nie poprawia fakt że z tego
    powodu nikt ich nie chce używać, szczególnie w embedded.

    > No bo jak poprawiać kod asm wygenerowany przez kompilator,
    > który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
    > procesora,

    A używa 20 rejestów? Mój odkłada tyle ile użyje. Ponadto temat RT jest
    delikatny: tam nalezy uzyć czasem asm, czasem C, czasem C++. Zależy.
    Jesli wydaje Ci się że C+ jest w/g mnie dobry na wszystko to się mylisz.
    Mam setki wstawek assemblerowych bo muszę rozkladać cykle *perfekcyjnie*
    i żaden język wysokiego poziomu do tego sie nie nada.

    > wykonuje jedno podstawienie i przywraca te rejestry.

    Masz popsuty kompilator. Weź lepszy.


  • 45. Data: 2013-10-11 07:53:04
    Temat: Re: PICowanie
    Od: Marek <f...@f...com>

    On Fri, 11 Oct 2013 00:11:51 +0200, Sylwester Łazar<i...@a...pl>
    wrote:
    > 1) kod jest napisany zwięźle i czytelnie.
    > 2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to
    szybkie
    > 3) każda linijka ma swój komentarz.

    Tak się zastanawiam ile czasu Ci zajmuje realizacja jakiegoś
    zadania/projektu, czy sa to projekty rozwojowe czy jednorazowe
    zadania, które po realizacji nie są dalej rozwijane.

    --
    Marek


  • 46. Data: 2013-10-11 08:43:39
    Temat: Re: PICowanie
    Od: Zbych <a...@o...pl>

    W dniu 10.10.2013 18:18, Sebastian Biały pisze:
    > On 2013-10-10 18:13, Zbych wrote:
    >> Słaby przykład, w gcc można zrobić destruktor w C.
    >
    > I wtedy mamy jaki język?

    Jeśli pijesz do tego, że nie jest to czyste C, to argument jest
    chybiony. Przerwań też nie masz w C (ani w C++).




  • 47. Data: 2013-10-11 08:56:17
    Temat: Re: PICowanie
    Od: Marek <f...@f...com>

    On Fri, 11 Oct 2013 00:53:30 +0200, Sebastian
    Biały<h...@p...onet.pl> wrote:
    > Asm jest językiem write-only i 100% nie przenośnym. I turing
    complete,
    > bez wątpienia. Meta assemblery które robią abstrakcję na cpu muszą
    i tak
    > robić jakieś założenia ktore sa nieprzenośne.

    Trudno się nie zgodzić z Twoimi argumentami.
    Sam osobiście nie jestem entuzjastą programowania obiektowego, ale
    pewnie to wynika z przyzwyczajenia i uprzedzeń.

    Natomiast jako pracodawca zatrudniający kilkunastu programistów
    obecnie (nie embeded), a w skali kilkunastu lat kilkudziesięciu się
    przewinęło, zauważyłem ciekawą statystykę:
    1. Najwięcej poroblemów jest z kodem progranistów, którzy deklarują
    się jako programiści jedynie w c++ lub (najczęściej) java. Głównie
    problemy jakie mam na myśli to brak nawyków testowania tego co piszą.

    2.Najczęściej programiści (z tymi ci miałem do czynienia) "obiektowi"
    nie maja wyobrażenia jak działa procesor czy jakie są różnice w arch.
    Neumann/Harvard. Kompletnie nie zastanawiają się nad kwestia jak
    będzie wyglądał kod wynikowy tego ci piszą.
    Chodzi mi o sytuacje, w których można czasami trochę "pomóc"
    kompilatorowi aby nie wygenerował jakiegoś potworka. Ale ok,
    powiedzmy, że to raczej cecha języka, że nie muszą się o to martwić.

    3. Mimo deklaracji, że jest się programistą obiektowym programują
    strukturalnie (sic!), nie wykorzystując zalet/cech deklarowanego
    języka.

    4. Ogromne problemy z bezpieczeństwem. Pierdyliąt zewnętrznych
    "gotowców" (biblioteki, frameworki, konektory i inne dziwactwa)
    powoduje nawyk korzystania z nich i mamy oprócz błędów w "własnym"
    kodzie błędy innych.

    Natomiast najmniej problemów jest tymi, którzy deklarują się jako
    "multi-kulti" z naciskiem na C, lizneli kiedyś embeded i uwaga, nie
    stosują żadnych IDE tylko sam vim lub emacs + makefile (!).

    --
    Marek


  • 48. Data: 2013-10-11 09:51:52
    Temat: Re: PICowanie
    Od: RoMan Mandziejewicz <r...@p...pl.invalid>

    Hello Marek,

    Friday, October 11, 2013, 8:56:17 AM, you wrote:

    [...]

    > Natomiast najmniej problemów jest tymi, którzy deklarują się jako
    > "multi-kulti" z naciskiem na C, lizneli kiedyś embeded i uwaga, nie
    > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).

    Ale stać Cię na takich?


    --
    Best regards,
    RoMan
    Nowa strona: http://www.elektronika.squadack.com (w budowie!)


  • 49. Data: 2013-10-11 10:18:12
    Temat: Re: PICowanie
    Od: Marek <f...@f...com>

    On Fri, 11 Oct 2013 09:51:52 +0200, RoMan Mandziejewicz
    <r...@p...pl.invalid> wrote:
    > > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).
    > Ale stać Cię na takich?

    Dobre pytanie, tylko na kilku takich, niestety. Ale muszą być, aby
    pilnować resztę (głowinie jako team leaderzy). Trzeba uważać bo, jak
    mawiał Jobs, kiepski programista przyciąga do siebie innych
    kiepskich. W końcu możesz się ocknąć, że firmie masz samych
    kiepskich. Inwestując w tych kilku najlepszych udaje się na razie
    uniknąć takiej sytuacji. Ale bywało że nie było stać i faktycznie to
    powiedzenie się sprawdzało.

    --
    Marek


  • 50. Data: 2013-10-11 11:00:11
    Temat: Re: PICowanie
    Od: RoMan Mandziejewicz <r...@p...pl.invalid>

    Hello Marek,

    Friday, October 11, 2013, 10:18:12 AM, you wrote:

    >> > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).
    >> Ale stać Cię na takich?
    > Dobre pytanie, tylko na kilku takich, niestety.

    Albo jesteś bardzo bogaty albo jednak ci programiści nie są tak
    dobrzy...

    > Ale muszą być, aby pilnować resztę (głowinie jako team leaderzy).
    > Trzeba uważać bo, jak mawiał Jobs, kiepski programista przyciąga do
    > siebie innych kiepskich. W końcu możesz się ocknąć, że firmie masz
    > samych kiepskich. Inwestując w tych kilku najlepszych udaje się na
    > razie uniknąć takiej sytuacji. Ale bywało że nie było stać i
    > faktycznie to powiedzenie się sprawdzało.

    :(

    --
    Best regards,
    RoMan
    Nowa strona: http://www.elektronika.squadack.com (w budowie!)

strony : 1 ... 4 . [ 5 ] . 6 ... 10


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: