eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaAVR po latach
Ilość wypowiedzi w tym wątku: 106

  • 11. Data: 2021-11-15 16:26:43
    Temat: Re: AVR po latach
    Od: "Grzegorz Niemirowski" <g...@g...net>

    Janusz <j...@o...pl> napisał(a):
    > Tak, ale styl avr studio został i o to mi chodziło.

    Przyczym ten styl jest od AVR Studio 5, pierwszej wersji bazującej na Visual
    Studio Shell. Przedtem było AVR Studio 4, które było tak naprawdę innym
    oprogramowaniem, wymagającym doinstalowania kompilatora.

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/


  • 12. Data: 2021-11-15 17:44:09
    Temat: Re: AVR po latach
    Od: heby <h...@p...onet.pl>

    On 14/11/2021 22:53, Grzegorz Niemirowski wrote:
    >> To jakiś pogląd religijny?
    > Są wystarcząjące obiektywne argumenty przeciw.

    A które?


  • 13. Data: 2021-11-15 17:46:04
    Temat: Re: AVR po latach
    Od: heby <h...@p...onet.pl>

    On 15/11/2021 08:36, Bool wrote:
    >> To jakiś pogląd religijny?
    > Jestem kompletnie areligijny.
    > Narzędzia dla hobbystów zostawiam hobbystom.

    Pod spodem jest ten sam kompilator gcc, używany w projektach komercyjnych.

    Jeśli, z powodów religijnych, uważasz to za narzedzie dla hobbystów,
    zerknij na platformio. Jest "profesjonalny", cokolwiek to znaczyć by miało.


  • 14. Data: 2021-11-15 18:30:08
    Temat: Re: AVR po latach
    Od: "Grzegorz Niemirowski" <g...@g...net>

    heby <h...@p...onet.pl> napisał(a):
    > A które?

    1. Prymitywne IDE, niewiele bardziej zaawansowane od Notatnika, bez
    możliwości debugowania
    2. Biblioteki pisane na kolanie
    3. Dziwna konstrukcja z setup/loop
    4. Ukrycie użycia timera i wielu innych rzeczy, bo ma być przede wszystkim
    prosto
    Arduino nie powstało i nie jest rozwijane z myślą o profesjonalistach.
    Wywodzi się z projektu Wiring, który miał artystom pozwolić tworzyć
    automatyczne lub interaktywne instalacje. Nieprzypadkowo w Arduino nie ma
    projektów tylko szkice. Dlatego jest spoko do szybkiego prototypowania a nie
    poważniejszych zastosowań.

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/


  • 15. Data: 2021-11-15 18:40:00
    Temat: Re: AVR po latach
    Od: heby <h...@p...onet.pl>

    On 15/11/2021 18:30, Grzegorz Niemirowski wrote:
    >> A które?
    > 1. Prymitywne IDE, niewiele bardziej zaawansowane od Notatnika, bez
    > możliwości debugowania

    1) Możesz zostawić środowiko arduino i używać
    Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.

    2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu. Często
    ta emulacja sprzetu jest milion razy trudniejsza. Dlatego wymysliliśmy
    techniki pisania kodu, które praktycznie redukują potrzebę debugowania
    na *prawdziwym* targecie, asymptotycznie do zera. Zaryzykuje że
    poprawnie napisany program w języku C/C++ będzie wymagał debugowania w
    emulatorze CPU w mniej niż promilu przypadków. Za to będzie znakomicie
    debugował się na hoście.

    > 2. Biblioteki pisane na kolanie

    Nikt nie każe z nich korzystać. Przypomnę tylko, że firma Atmel dla SAM7
    miała na kolanie napisane *wszystko* do stanu który powodował wymioty na
    sam widok tej niewiarygodnej fuszerki. Jak bym nie wiązał tego
    dziadostwa z Arduino, tylko z embedded. Tam wszystko jest dziadowskie do
    granic absurdu i nikomu to nie przeszkadza.

    > 3. Dziwna konstrukcja z setup/loop

    W 99% programów pojawi się taki setup/loop.

    > 4. Ukrycie użycia timera i wielu innych rzeczy, bo ma być przede
    > wszystkim prosto

    Albo abstrakcyjnie. Sugeruje nie mylić pojęć.

    > Arduino nie powstało i nie jest rozwijane z myślą o profesjonalistach.
    > Wywodzi się z projektu Wiring, który miał artystom pozwolić tworzyć
    > automatyczne lub interaktywne instalacje. Nieprzypadkowo w Arduino nie
    > ma projektów tylko szkice. Dlatego jest spoko do szybkiego
    > prototypowania a nie poważniejszych zastosowań.

    Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
    padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych IDE"
    skoro kod nie jest większy niż max kilka stron na ekranie i może być
    pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć tak
    nisko bym nie upadał.


  • 16. Data: 2021-11-15 18:57:43
    Temat: Re: AVR po latach
    Od: "Grzegorz Niemirowski" <g...@g...net>

    heby <h...@p...onet.pl> napisał(a):
    > 1) Możesz zostawić środowiko arduino i używać
    > Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.

    Idąc za ciosem można zrezygnować z Arduino zupełnie.

    > 2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu. Często ta
    > emulacja sprzetu jest milion razy trudniejsza. Dlatego wymysliliśmy
    > techniki pisania kodu, które praktycznie redukują potrzebę debugowania na
    > *prawdziwym* targecie, asymptotycznie do zera. Zaryzykuje że poprawnie
    > napisany program w języku C/C++ będzie wymagał debugowania w emulatorze
    > CPU w mniej niż promilu przypadków. Za to będzie znakomicie debugował się
    > na hoście.

    Moje doświadczenia są zgoła odmienne. Nie wiem do czego miałby mi być
    potrzebny emulator CPU. Kod pracuje w jakimś urządzeniu i komunikuje się z
    innymi układami. Potrzebna jest możliwość sprawdzania co się dzieje w
    rzeczywistym układzie. Tu przydaje się oscyloskop, analizator stanów
    logicznych oraz debuger.

    >> 2. Biblioteki pisane na kolanie
    > Nikt nie każe z nich korzystać.

    Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro nie
    oferuje żadnej dużej wartości.

    > W 99% programów pojawi się taki setup/loop.

    Pojawia się, ale jest to sztuczne zaciemnianie.

    > Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
    > padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych IDE"
    > skoro kod nie jest większy niż max kilka stron na ekranie i może być
    > pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć tak nisko
    > bym nie upadał.

    Nawet krótki kod wolę pisać w wygodnym IDE.

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/


  • 17. Data: 2021-11-15 19:07:59
    Temat: Re: AVR po latach
    Od: heby <h...@p...onet.pl>

    On 15/11/2021 18:57, Grzegorz Niemirowski wrote:
    >> 1) Możesz zostawić środowiko arduino i używać
    >> Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.
    > Idąc za ciosem można zrezygnować z Arduino zupełnie.

    Dokładnie tak. Przecież to był tylko pretekst do ewaluacji
    "hobbystyczne" vs "profesjonalnie" gdzie oba, to tylko inna odmiana
    dziadostwa, typowego dla embedded.

    >> 2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu.
    >> Często ta emulacja sprzetu jest milion razy trudniejsza. Dlatego
    >> wymysliliśmy techniki pisania kodu, które praktycznie redukują
    >> potrzebę debugowania na *prawdziwym* targecie, asymptotycznie do zera.
    >> Zaryzykuje że poprawnie napisany program w języku C/C++ będzie wymagał
    >> debugowania w emulatorze CPU w mniej niż promilu przypadków. Za to
    >> będzie znakomicie debugował się na hoście.
    > Moje doświadczenia są zgoła odmienne. Nie wiem do czego miałby mi być
    > potrzebny emulator CPU. Kod pracuje w jakimś urządzeniu i komunikuje się
    > z innymi układami. Potrzebna jest możliwość sprawdzania co się dzieje w
    > rzeczywistym układzie. Tu przydaje się oscyloskop, analizator stanów
    > logicznych oraz debuger.

    Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
    poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać
    kod obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na
    poziomie 95% coverage, gdzie po stronie AVR znajduja się juz tylko gołe
    read/write do rejestrów uartu. Nie wiem gdzie tu miejsce dla
    oscyloskopu, to ostateczność.

    To kwestia bardziej jakości kodu i umiejętności pisania abstrakcyjnego,
    ale blisko sprzetu.

    Zaznaczam, że wbrew opini niedzielnych programistów C++, ta abstrakcja
    przychodzi z zerowym obciązeniem dla kodu wynikowego, nie pojawi się
    nawet instrukcja więcej.

    >>> 2. Biblioteki pisane na kolanie
    >> Nikt nie każe z nich korzystać.
    > Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro
    > nie oferuje żadnej dużej wartości.

    Dokładnie do tego dążę.

    >> W 99% programów pojawi się taki setup/loop.
    > Pojawia się, ale jest to sztuczne zaciemnianie.

    Akurat to jest prawdziwe rozjaśnianie intencji ;)

    >> Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
    >> padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych
    >> IDE" skoro kod nie jest większy niż max kilka stron na ekranie i może
    >> być pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć
    >> tak nisko bym nie upadał.
    > Nawet krótki kod wolę pisać w wygodnym IDE.

    I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
    tylko tyle potrzeba w 99% wypadków pisania kodu embedded.

    Co innego gdy to jest hobbystyczne pisanie na ATTINY. Tam można sobie
    pomigać diodą w symulatorze, wiadomo. Ale czy to nie jest aby własnie
    "hobbystyczne"?


  • 18. Data: 2021-11-15 19:19:42
    Temat: Re: AVR po latach
    Od: "Grzegorz Niemirowski" <g...@g...net>

    heby <h...@p...onet.pl> napisał(a):
    > Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
    > poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać kod
    > obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na poziomie
    > 95% coverage, gdzie po stronie AVR znajduja się juz tylko gołe read/write
    > do rejestrów uartu.

    Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji i bez
    uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że praktycznie
    zawsze coś potem nie działa i wcale niekoniecznie z Twojej winy.

    > Nie wiem gdzie tu miejsce dla oscyloskopu, to ostateczność.

    Nie tylko Modbus jest na świecie. Poza tym mówimy o styku programowania z
    elektroniką. Jeśli oscyloskop nie jest potrzebny, to jest to albo prosty
    projekt albo embedded wysokopoziomowe (odległe od sprzętu).

    > To kwestia bardziej jakości kodu i umiejętności pisania abstrakcyjnego,
    > ale blisko sprzetu.
    > Zaznaczam, że wbrew opini niedzielnych programistów C++, ta abstrakcja
    > przychodzi z zerowym obciązeniem dla kodu wynikowego, nie pojawi się nawet
    > instrukcja więcej.

    Wiadomo :)

    W każdym razie ta część wątku zaczęła się od emulatora CPU. Arduino i tak go
    nie ma, więc nie ma co tu drążyć :)

    > I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
    > tylko tyle potrzeba w 99% wypadków pisania kodu embedded.

    Wracamy więc do początku wątku. Jeśli ktoś wybiera znakomite środowisko
    zamiast Arduino IDE, to nie ze względów religijnych ale dlatego, że jest
    ono... znakomite :)

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/


  • 19. Data: 2021-11-15 19:34:19
    Temat: Re: AVR po latach
    Od: heby <h...@p...onet.pl>

    On 15/11/2021 19:19, Grzegorz Niemirowski wrote:
    >> Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
    >> poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać
    >> kod obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na
    >> poziomie 95% coverage, gdzie po stronie AVR znajduja się juz tylko
    >> gołe read/write do rejestrów uartu.
    > Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji

    Nie, dalej nie rozumiesz. Ja nie mówie o pisaniu zgodnie z dokumentacją
    i wymagania nieomylności.

    Ja mówie o pisaniu kodu w sposób, który redukuje potrzebę debugowania w
    sprzęcie do zera lub blisko zera. To wymaga innych technik
    programowania, niż stosowane w embedded, w szczególności przeproszenia
    sie z C++ (przez co czeka nas przeczekanie obecnego pokolenia
    programistów embedded, jako że to problem białkowy).

    > uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że
    > praktycznie zawsze coś potem nie działa i wcale niekoniecznie z Twojej
    > winy.

    Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR.
    Miliony programistów Arduino raczej by go znalazły.

    >> Nie wiem gdzie tu miejsce dla oscyloskopu, to ostateczność.
    > Nie tylko Modbus jest na świecie. Poza tym mówimy o styku programowania
    > z elektroniką. Jeśli oscyloskop nie jest potrzebny, to jest to albo
    > prosty projekt albo embedded wysokopoziomowe (odległe od sprzętu).

    Ani jedno ani drugie. Możesz napisać skomplikowany projekt blisko
    sprzetu, w 95% pokryty testami po stronie komputera dev. To nie jest
    rocket science. To normalna praktyka pisania kodu na dowolną platoformę,
    od superkomputerów do attiny.

    Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu musisz
    ich używać, to masz kiepsko napisany kod.

    Zgodzę się, że czasami mogą być przydatne przy uruchamianiu kodu, ale
    zazwyczaj to oznacza, że coś jest spieprzone i nieprzetestowane
    wcześniej, lub błąd masz w konkretyzacji abstrakcji (gdzie zwyczajowo
    kodu wiele nie ma).

    > W każdym razie ta część wątku zaczęła się od emulatora CPU. Arduino i
    > tak go nie ma, więc nie ma co tu drążyć :)

    Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest
    mało potrzebny.

    >> I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
    >> tylko tyle potrzeba w 99% wypadków pisania kodu embedded.
    > Wracamy więc do początku wątku. Jeśli ktoś wybiera znakomite środowisko
    > zamiast Arduino IDE, to nie ze względów religijnych ale dlatego, że jest
    > ono... znakomite :)

    Ale nie jestem przekonany, czy środowiska do embedded są znakomite. Jak
    na razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na same
    słowa "embedded IDE".


  • 20. Data: 2021-11-15 19:57:55
    Temat: Re: AVR po latach
    Od: "Grzegorz Niemirowski" <g...@g...net>

    heby <h...@p...onet.pl> napisał(a):
    > Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR. Miliony
    > programistów Arduino raczej by go znalazły.

    Oczywiście nie mówię o bugach w AVR. Chodzi o to, że urządzenie nie składa
    się z samego MCU. Masz też różne inne układy, które mogą się zachowywać
    inaczej niż myślałeś lub mieć błędy. Przykładowo UART w Raspberry Pi wysyłał
    na początku transmisji dodatkową szpilkę, która mogła być traktowana jako
    bit startu. Nie było to nigdzie opisane. Pracując w embedded takie i inne
    kwiatki spotyka się cały czas.

    > Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu musisz
    > ich używać, to masz kiepsko napisany kod.

    To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas :)
    Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale źle
    świadczyć o programiście. Jego brak jest ograniczeniem środowiska.

    > Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest mało
    > potrzebny.

    Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy i
    słabą dokumentację.

    > Ale nie jestem przekonany, czy środowiska do embedded są znakomite. Jak na
    > razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na same słowa
    > "embedded IDE".

    No właśnie :) Tym bardziej Arduino IDE :)

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/

strony : 1 . [ 2 ] . 3 ... 10 ... 11


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: