Programowanie Embedded wysokopoziomowe.

Embedded dzieli się na parę gałęzi. Mi chodzi o tą gałąź dalej sprzętu. Czyli linux raspbery pi itd.
Zastanawia mnie to czemu nazywają to programowaniem embedded ? Przecież raspberry to zwykły komputer. Na nim mogą hulać takie programy w zależności od tego jaki system jest zainstalowany. Po co taką gałąź wymyślili? Przecież jak zainstaluję android i uruchomię apkę android to będę programistą embedded ? W takim razie każdy programista jest embedded.

kamil kowalski napisał(a):

Zastanawia mnie to czemu nazywają to programowaniem embedded ? (...) W takim razie każdy programista jest embedded.

Nie każdy programista jest programistą embedded bo o ile języki programowanie są takie same (C++, C, Python, Java, Pascal) to podstawy do embeded są jednak inne.
Tutaj musisz znać przynajmniej:

• kilka protokołów komunikacji oraz umieć je stosować w praktyce np. I2C, 232,422,485 itd...,
• znać zjawiska jakie zachodzą na liniach sygnałowych, którymi potencjalnie będziesz z tego RPI sterował,
• umieć obsłużyć jakieś watchdogi,
• wiedzieć coś o zakłóceniach i zasilaniu urządzeń.
• podstawy elektroniki mile widziane żeby wiedzieć jak sterować przekaźnikiem, jak odczytać stan przycisku, jak zrobić proste filtry RC itp...
• w bardziej zaawansowanym obszarze trzeba wiedzieć jak korzystać z różnego rodzaju peryferii, których w takim zwykłym PC nie masz a chodzi np. o: komparatory, DAC, ADC...
• dobrze umieć obsłużyć jakieś wyświetlacze, klawiatury, manipulatory,
• wiedzieć jak napisać soft i jak skonfigurować system żeby działał jak najdłużej na jednym ładowaniu akumulatora.
• i na koniec... systemy embedded powinny być mocno wyspecjalizowane - to nie jest jedna z aplikacji działająca w systemie operacyjnym a raczej aplikacja, działająca jako system do wyspecjalizowanego zadania lub działająca w mocno okrojonym środowisku/systemie.

Żeby zacząć przygodę z embedded takiej niezbędnej wiedzy nie jest bardzo dużo ale też nie jest to tak, że jak umiesz JavaScript i zrobisz stronkę postawioną na RPI to to będzie programowanie embeded.

Nie no jak embedded to ma na myśli, że poradzisz sobie z elektronikom, badanie wagi, temperatury, odległości czyli umiejętność łączenia fizyki z programowaniem.
RPI ma dostęp do pinów cyfrowych to można smart dom zrobić sterując relayami i rest api wystawić, żeby telefon mógł sterować.
Zbyt bardzo wnikasz w język naturalny, język jest tylko po to, żeby umieć przed samym sobą wytłumaczyć jakieś zagadnienia w celu lepszego zrozumienia.

Zastanawia mnie to czemu nazywają to programowaniem embedded ?

Na mój gust embedded to taki soft, który da się zmieścić w pamięci ROM. Soft, który odpala się (albo ma się możliwość z korzystania z niego) przy włączeniu urządzenia/procka.
Ogólnie bardzo fajna sprawa, ale trzeba mieć mega wiedzę. W sumie to co @katakrowa wymienił

EDIT: embedded nie potrzebuje też systemu operacyjnego, który zarządza pamięcią i zasobami

@trojanus: Embedded to nie fajna sprawa. Szczególnie kiedy trzeba czytać instrukcje obsługi dla programistów po 1700 stron. Przynajmniej jeśli chodzi o niskopoziomowe jakieś stm32. Bo niestety arduino nie jest używane komercyjnie i jeszcze ciężej kiedy robi się coś mając świadomość że w arduino zrobiło by się to 10 razy szybciej. Chodzi mi o całą koncepcje arduino. Bo w nim można nie tylko płytki arduino programować ale też esp itd. Popełniając po drodze 100 razy mniej błędów. A to dopiero początek. Bo mikrokontroler ma coś robić czyli komunikować się z czymś. Np z modułem jakimś. Którego instrukcja obsługi liczy 400 stron. i się człowiek zastanawia czy czytać całe od deski do deski. Czy tylko część. A po drodze zapomni o filtrowaniu zasilania przez kondensator i później się zastanawia dlaczego urządzenie nie działa mając w głowie masę różnych scenariuszy.

kamil kowalski napisał(a):

Szczególnie kiedy trzeba czytać instrukcje obsługi dla programistów po 1700 stron.

To żaden wielki wyczyn, zwykle i tak treba się wczytywać jedynie w wybrane części dokumentu. Cała elektronika wymaga sprawnej umiejętności czytania dokumentacji, datasheet'ów itp.. Na tym polega cały bajer, że chcąc oprogramować zwykły cyfrowy potencjometr(o ile nie ma gotowej biblioteki) to już musisz znać podstawy.

Tylko że jak zapomni się o jednym parametrze to już nic nie działa. W najlepszym przypadku. A w najgorszym ten błąd wyjdzie jak już będzie na wszystko za późno. Jak się nie czyta od deski do deski. To się może okazać że przeoczy się coś ważnego w stylu. "Żeby zacząć pracę z modułem musisz uruchomić tą sekwencję komend dopiero wtedy moduł wchodzi w tryb aktywny". Zajmujesz się tym zawodowo ? katakrowa ? Potrafiłbyś z tego dokumentu powiedzieć mi jak ustawić rejestry pinów cyfrowych aby były wyjściami ze stanem wysokim względem masy? https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf

kamil kowalski napisał(a):

Tylko że jak zapomni się o jednym parametrze to już nic nie działa. W najlepszym przypadku. A w najgorszym ten błąd wyjdzie jak już będzie na wszystko za późno.

W jeszcze gorszym to błąd będzie ukryty

kamil kowalski napisał(a):

się może okazać że przeoczy się coś ważnego w stylu. "Żeby zacząć pracę z modułem musisz uruchomić tą sekwencję komend dopiero wtedy moduł wchodzi w tryb aktywny".

Mam wrażenie, ze nie da się zostać dobrym programistą embedded w dzień / miesiąc / nawet rok.

Trzeba mieć intuicyjnie wbudowane, zinternalizowane, chwytać to o 3ciej w nocy, kanony - doczytać o konkretnej generacji chipu.
Np (w miarę) sprofesjonalzowany programista embedded NIE ZAPOMNI o inicjacji moduł i będzie to PIERWSZE MEIJSCE gdzie będzie szukał przyczyn błędu. To jest dla niego jak picie, siusianie i oddychanie (zgodzę się, mamy w rękach nowy chip, nowe czytanie, i to niejednokrotne)

Programistę "dużego komputera" można wyprodukować na skróty, w bootcamapch, szkołach dla studentów którzy sie nie chcą uczyć itd... np
Regularnie widzę, ze programiści "dużych" systemów maja problem z wyczuciem świata rzeczywistego, miktosekund, nanosekund, zboczy sygnału, po stosunek sygnał-szum, pomiaru i jego błędu, zagadnienia linii długiej itd... nie jest to wielki grzech dopóki pozostają w swoim ekosystemie (choć często podstawowe braki, elementarne z metod numerycznych grzechem dla mnie są)

kamil kowalski napisał(a):

Potrafiłbyś z tego dokumentu powiedzieć mi jak ustawić rejestry pinów cyfrowych aby były wyjściami ze stanem wysokim względem masy? https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf

Po pierwsze jeszcze napisz, które konkretnie piny - bo to może mieć znaczenie.
Ale ogólnie od strony 45....

Nie zajmuję się tym zawodowo. Nie znam ESP32 bo mnie ten uC nie bawi ale znam podstawy uC i wiem, że:

1. należy szukać w dokumencie słów GPIO pull-up setup itp...
2. dla bardziej złożonych uC producenci albo hobbyści dostarczają konfiguratory.: np: https://hubberthus.github.io/#/layout
   Przykładowo firma STM daje na te cele całe środowisko o nazwie CubeMX: https://www.st.com/en/development-tools/stm32cubemx.html
   Oczywiście można konfigurować na piechotę jak w jakimś AVR ale to już są dość złożone układy i raczej szkoda czasu.

Polecam poczytać bloga:
https://ucgosu.pl/
Oraz odwiedzić kanał:

Ja i tak wolę arduino. Za 10 lat będzie takie samo. Dzięki niemu wystarczy że przeczytam 30 stron dokumentacji mikrokontrolera a nie Więcej. Jest łatwy w przenoszeniu. Cała ta wiedza o zaawansowanym embedded za 4 lata będzie nic nie warta. Bo gdyby tak nie było to by nie powstawały nowe kursy i poradniki.

@kamil kowalski: Arduino nie zainstalujesz w respiratorze, rakiecie czy samolocie

Wyciągam mikrokontroler i wpakuję na pcb rezonator kondensatory itd. Płytki całej nie zamierzam używać i tak 98% błędów popełniają programiści. Ci co tworzą biblioteki do arduino popełnią ich mniej niż ci co chcieli by używać modułów do arduino samemu je pisząc. Bo ci twórcy tych bibliotek pracują nad nimi latami. A nie od miesiąca. Sprawnie to działa na githubie widać że reagują na różne zgłoszenia użytkowników tych bibliotek.
Dzięki temu Żeby zrobić komunikację bluetooth nie muszę pisać 90 linijek konfiguracyjnych tylko 3.
Oprócz tego można skupić się na tym co naprawdę jest ważne . A nie zastanawiać się czy wszystkie rejestry skonfigurowałem

@kamil kowalski: Gdy masz do zbudowania coś bardziej złożonego niż copy - paste z tutoriala zaczynają się schody i przydaje algorytmika, RTOS i teoria sterowania

@Marcin Marcin: Coś bardziej zaawansowanego ? Komputer który umożliwił lądowanie na księżycu był o wiele gorszy od atmegi. A w arduino ide można programować o wiele bardziej skomplikowane użądzenia. ESP itd.

@kamil kowalski: Akurat jestem z branży:
https://www.microchip.com/en-us/solutions/aerospace-and-defense/products/microcontrollers-and-microprocessors/cots-to-radiation-tolerant-and-radiation-hardened-devices
https://www.microsemi.com/product-directory/fpga-soc/1640-rad-tolerant-fpgas
https://www.ti.com/applications/industrial/aerospace-defense/space/overview.html

Dodam że nawet w FPGA implementuje się soft core który programuje się w C

Obecnie bawię się tym:
https://www.microchip.com/en-us/product/SAMV71Q21RT

Space grade jest bardzo trudnym zagadnieniem i wysłanie ESP w kosmos po prostu nie zadziała ze względu na wibracje przy starcie rakiety, temperatury rzędu 70 K oraz promieniowanie i cząstki wysokoenergetyczne

W kosmos dużo poleciało 386 oraz starych procesorów POWER PC
Mi:
https://en.wikipedia.org/wiki/RAD750
https://en.wikipedia.org/wiki/IBM_RAD6000
https://en.wikipedia.org/wiki/RAD5500
Pisanie oprogramowanie na satelity lub statki kosmiczne jest dosyć problematyczne

kamil kowalski napisał(a):

@Marcin Marcin: Coś bardziej zaawansowanego ? Komputer który umożliwił lądowanie na księżycu był o wiele gorszy od atmegi. A w arduino ide można programować o wiele bardziej skomplikowane użądzenia. ESP itd.

Np. cokolwiek co przetwarza/analizuje sygnały analogowe audio z częstotliwością 192kHz / 32bit. i już możesz sobie to Arduino głęboko w szufladę włożyć.

katakrowa napisał(a):

kamil kowalski napisał(a):

@Marcin Marcin: Coś bardziej zaawansowanego ? Komputer który umożliwił lądowanie na księżycu był o wiele gorszy od atmegi. A w arduino ide można programować o wiele bardziej skomplikowane użądzenia. ESP itd.

Np. cokolwiek co przetwarza/analizuje sygnały analogowe audio z częstotliwością 192kHz / 32bit. i już możesz sobie to Arduino głęboko w szufladę włożyć.

Polałbym koledze ale tylko jakby dodał jeszcze informacje że na Arduino nie da się zrobić dobrze np. elementów które muszą wyrabiać się w czasie. Bez RTOS się nie obejdzie

Przykład z dźwiękiem jest dobry, bez procesorów DSP się nie obejdzie.

Dodam że po prostu niemożliwe jest zrealizowanie niektórych funkcji na Arduino. To fajna platforma z myślą o szybkim prototypowaniu i nauce elektroniki dla początkujących

kamil kowalski napisał(a):

@trojanus: Embedded to nie fajna sprawa. Szczególnie kiedy trzeba czytać instrukcje obsługi dla programistów po 1700 stron. Przynajmniej jeśli chodzi o niskopoziomowe jakieś stm32.

Na pecetach ze standardowym systemem operacyjnym programiści sterowników urządzeń również muszą przeczytać setki stron, żeby wiedzieć do jakich rejestrów I/O pisać. Bliżej im do embeddedowców gdzie znajomość sprzętu jest ważna i każda pomyłka może skutkować paniką kernela. Zwykły programista aplikacji korzystający z gotowych driverów raczej "kernel panick" się nie obawia i w przypadku błędów wysypie się tylko aplikacja, OS się o to zatroszczy.

Na MCU przeważnie nie ma OS-a, więc obsługę sprzętu trzeba sobie samemu implementować na podstawie dostarczonej dokumentacji. W Arduino twórcy "shieldów" dostarczają również pliki nagłówkowe i źródłowe, które są odpowiednikiem driverów w PC-tach, czyli pewną abstrakcją sprzętu łatwą w użytkowaniu i ukrywającą skomplikowane sekwencje inicjalizujące. Jak nie ma takiej biblioteki to czeka nas kilkaset stron dokumentacji to przeczytania.

Bo niestety arduino nie jest używane komercyjnie i jeszcze ciężej kiedy robi się coś mając świadomość że w arduino zrobiło by się to 10 razy szybciej. Chodzi mi o całą koncepcje arduino. Bo w nim można nie tylko płytki arduino programować ale też esp itd. Popełniając po drodze 100 razy mniej błędów. A to dopiero początek. Bo mikrokontroler ma coś robić czyli komunikować się z czymś. Np z modułem jakimś. Którego instrukcja obsługi liczy 400 stron. i się człowiek zastanawia czy czytać całe od deski do deski. Czy tylko część. A po drodze zapomni o filtrowaniu zasilania przez kondensator i później się zastanawia dlaczego urządzenie nie działa mając w głowie masę różnych scenariuszy.

Jak ci się nie podoba wizja czytania kilkaset stron to trzeba polegać na innych, który stworzą abstrakcję sprzętu i napiszą te sterowniki. Problem może być taki, że mogą one przestać działać kiedy mamy jednocześnie kilka różnych modułów i bibliotek do nich.

Filtracja zasilania, "debouncing" przycisków, diody zabezpieczające przed przepięciami na cewce przekaźnika, brak terminatorów na szynie CAN, RS485, etc. to wiedza podstawowa pozwalająca uniknąć uszkodzeniu sprzętu a przynajmniej jego niepoprawnym działaniu. Na początku to może zaskakiwać, ale z czasem ta wiedza wchodzi w krew i masa scenariuszy się redukuje.

Przecież Arduino nie ma nic wspólnego z wysokopoziomowym pisaniem na mikrokontrolery (*1). To po prostu zestaw gotowych klocków z których można, przeważnie bez znajomości elektroniki czy nawet architektury uC, złożyć program realizujący jakieś funkcje. Takie klocki Lego dla osób wolących elektronikę od mechaniki.

Zresztą Arduino nie jest tu same - Microchip (Atmel) ma IDE z zestawem gotowych bibliotek. STM oferuje Cube, gdzie są inicjalizatory kodu ale i gotowe rozwiązania graficzne, AI, wireless, itp. To wszystko jest fajne jak robimy coś na szybko, na kablach z płyty uruchomieniowej żeby sprawdzić ideę. Nie wyobrażam sobie przemysłowego urządzenia opartego na tym badziewiu, gdzie nikt nawet nie wie z jakimi zegarami pracują peryferia...

Ale wracając do tematu - embedded kiedyś dotyczyło jedynie mikrokontrolerów, a to dało się znacząco odróżnić od sprzętu klasy PC (czyli takich z procesorem). Ale te grupy zaczęły się powoli zlewać; popatrzmy np na ARMa9 - formalnie to mikrokontroler, ale można na nim postawić Linuxa/WinCE i traktować jak PC. Jak dla mnie dalej granica przebiega właśnie na tym czy nasz program ma do dyspozycji 100% sprzętu, grzebie w rejestrach, obsługuje przerwania i stanowi po prostu integralną część urządzenia, czy też jest to kod uruchamiany w jakimś gotowym środowisku w ramach jakiegoś systemu operacyjnego jako jedno z jego wielu zadań.

(*1)
Nie znam się, ale jak dla mnie wysokopoziomowe to będzie np to:

• Java (https://github.com/DanijelAskov/microjava-compiler),
• Python (https://micropython.org/),
• JavaScript (https://www.espruino.com/).
  Po co? Nie wiem. Ale można.

Mam wrażenie, że tytuł wątku i tytułowy post traktuje o dwóch róznych rzeczach.

Jeśli chodzi o wysokopoziomowe programowanie bare metal/embedded z perspektywy C++ to polecam sprawdzić co ma do powiedzenia Odin Holmes/Odin the nerd.

A jeśli chodzi o to, że rabsperry pie to zwykły komputer i każdy z nas jest programista embedded to nie, bardzo nie. A odpowiedź dlaczego jest w samej nazwie Embedded i wystarczy sprawdzić etymologie.

Ja bym problem postawiony przez OP rozwiązał tak:

Jeżeli Twoje kawałek oprogramowania dotyka sprzętu to ta cześć jest embedded
Przykład:

• zakładamy ze system używa Raspberrypi
• wyświetlacz LCD podłączony do portów IO
• używasz biblioteki https://lvgl.io/ do rysowania na LCD
• w urządzeniu jest jakaś dodatkowa elektronika która mierzy "coś"

I wszystko zamknięte jest w obudowę z napisem SYTEM XYZ

System jako całość jest Embedded

Aby uruchomić wyświetlacz potrzebny jest programista który rozumie sprzęt, meandry komunikacji IO i jest w stanie napisać warstwę HARDWARE <-> LVGL
ta osoba z mojego puntu widzenia jest programista embedded
Komunikacja z dodatkową elektroniką wymaga stworzenia warstwy która stworzy tez programista embedded

Resztę aplikacji może już napisać "zwykły programista"

Teraz jest taka wolność jaka sie filozofom nie śniła: każdy może nazywać oprogramowaniem embedded to chce

Widywałem ogłoszenia w których embeded oznaczało, coś w stylu że klepiesz gui do odtwarzacza video w QT, który będzie działał na hardware multimedialnym samochodu. Nie wiem w sumie czy wymagali nawet przy projektach babrania się z ograniczeniami prędkości przesyłu szyny danych jakie są typowo w samochodach.