Jaki jest sens używania nienatywnych języków jak Java czy Python do systemów embedded?
Java 
Python - Rejestracja:ponad 6 lat
- Ostatnio:około rok
- Postów:3561
1
Np Lua ma mocną pozycję na niektórych kontrolerach. Język do głębi przemyślany pod embedowanie, między innymi lekki, ale też z innych powodów (jakbyś chciał integrować, to pytaj).
Python się zrobił BARDZO tłusty, nie da się oderwać od kory... od systemu plików (a taki był koło wersji 2.6 - był jeszcze podatny na embedowanie np w większe aplikacje pecetowskie ówczesnych czasów, potem od 2.7 się skończyło)
edytowany 3x, ostatnio: AnyKtokolwiek
- Rejestracja:ponad 6 lat
- Ostatnio:13 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
0
AnyKtokolwiek napisał(a):
Np Lua ma mocną pozycję na niektórych kontrolerach.
A to jest specjalna wersja Lua jak eLua czy ta normalna?
- Rejestracja:ponad 6 lat
- Ostatnio:około rok
- Postów:3561
0
KamilAdam napisał(a):
AnyKtokolwiek napisał(a):
Np Lua ma mocną pozycję na niektórych kontrolerach.
A to jest specjalna wersja Lua jak eLua czy ta normalna?
Zerknąłem, co to jest eLua i m.,in.
*
eLua is not a stripped down set of Lua to fit in the embedded environment. Much on the contrary, it strives to offer the same features as the desktop version of Lua, complementing them with specific features for embedded use and discarting the need of an operating system running on the microcontrollers. Besides offering different flavors of the full Lua implementation (like the possibility of choosing between an integer-only and a floating point numbers implementation), a lot of work was and will be done in the direction of making Lua more "embedded-friendly" by augmenting the core language with features that allow lower memory requirements and faster embedded performance.*
Generalnie jest rozdzielenie kernela języka od biblioteki standardowej, np zupełnie poprawnie można nie zlinkowac IO, dać swój alokator.
Można dodać swoje typy, i nie będzie to kalekie itd...
Sądzę, że nie ma potrzeby innego kernela, choć jest taki, z kompilatorem JIT, nic o nim ni wiem.
Na marginesie, jest zupełnie aktualny kernel w Javie (5.3 - ma integery oprócz floatów), widziałem chyba automatyczny port do Kotlina (da się to zrobić automatycznie? Znalazłem takie ślady)
Wersja javowska nie jest kompatybilna binarnie z postacią pośrednią "natywną", ale nikt tego nie oczekuje, przenośne są źródła.
Chyba nie ma aktualnego/wspieranego portu na .NET w jakiejś aktualnej wersji
edytowany 1x, ostatnio: AnyKtokolwiek
- Rejestracja:prawie 10 lat
- Ostatnio:2 dni
- Lokalizacja:Tam gdzie jest (centy)metro...
0
Jest wersja języka Python, dedykowana dla MCU. https://micropython.org/
Na repozytorium można zerknąć jakie platformy obsługuje:
https://github.com/micropython/micropython/tree/master/ports
https://github.com/micropython/micropython/
Aby łatwiej portować aplikację, jest implementacja na PC.
No a jak ktoś chce nietypowo programować.. to może Forth :-) ?
- Rejestracja:prawie 5 lat
- Ostatnio:4 miesiące
- Postów:2420
1
Czasami wynika to ze standardu np. JavaCard - taki standard (aka SmartCard np. karta SIM albo twoja debetówka), Java musi być choć mocno okrojona.
Niektóre architektury np. ARM mają nawet wsparcie to wykonania bytecode'u Javy wprost (https://en.wikipedia.org/wiki/Jazelle)
W tym wypadku Java została wybrana ze względu na bezpieczeństwo (brak wskaźników) oraz łatwość użycia. Jeżeli pracujesz np. z pakietami kryptograficznymi to ostatnia rzecz o jakiej chcesz myśleć to jeszcze jawne zwalnianie pamięci itp. Narzędzia do Javy też są znacznie przyjemniejsze w użyciu niż C++ (np. testy jednostkowe).
2
0xmarcin napisał(a):
W tym wypadku Java została wybrana ze względu na bezpieczeństwo (brak wskaźników) oraz łatwość użycia. Jeżeli pracujesz np. z pakietami kryptograficznymi to ostatnia rzecz o jakiej chcesz myśleć to jeszcze jawne zwalnianie pamięci itp. Narzędzia do Javy też są znacznie przyjemniejsze w użyciu niż C++ (np. testy jednostkowe).
To było prawdziwe z 15 lat temu.
Po pierwsze, w międzyczasie C++ stało się dużo przyjemniejsze w użyciu i bezpieczniejsze - w swoim projekcie embedded miałem różne błędy ale ani jednego związanego z pamięcią. Po drugie w embedded oraz w krypto rzadko w ogóle jest sens używania pamięci dynamicznej. Po trzecie na rynku mocno rozpycha się Rust, który nie ma wad C++ i nie ma wad Javy - jest równocześnie szybszy, lżejszy i bezpieczniejszy niż Java.
Podsumowując, używanie Javy w embedded nie ma żadnego sensu. Jedyny powód to gdy mamy platformę legacy typu JavaCard, która jako jedyną opcję oferuje API w Javie.
Co do innych języków - można, ale po co?
Jedyny powód jaki dostrzegam, to że ktoś np. zna Pythona i nie chce mu się uczyć C++. Niemniej docelowo nie pisze się w Pythonie szybciej ani lepiej niż w C++, więc to jest dość słaby powód (w stylu - zrobię ten wykop łopatą, bo nie chce mi się uczyć obsługi koparki).
edytowany 3x, ostatnio: Krolik
Zobacz pozostałe 2 komentarze
Kilka rzeczy imho: 1. MISRA, „proven in use” etc. 2. Przeświadczenie, że C++ jest wolniejsze (częściowo jest to prawdziwe patrząc przez pryzmat pktu pierwszego, kompilatory bywajà antyczne, optymalizacja totalnie wyłączona itd.). 3. W C nie ma wielu subtelności (język jest prostszy) ale przez to trudniej coś popsuć.
Amazon, Microsoft, Google, Discord używają Rust. Trwaja też prace nad komercyjnym wsparciem Rusta na platformie ESP8266/ESP32. Linki można łatwo znaleźć w Google.
Chodziło mi o stricte embedded rust, widziałem tylko jakieś example na Cortex-M STM32. Platforma ESP8266/ESP32 i komercja jak dla mnie to nie do końca się łączy jedno z drugim, ale okej.. :)
No ESP8266 faktycznie nie jest jakieś mega popularne - jest za dobre i za drogie widocznie do masowej produkcji. Jak widzę jaki crap pakują do komercyjnych urządzeń IoT to włosy stają na głowie. Przykładowo mam aparat foto pentax oraz rejestrator dźwięku tascam, oba mają problemy z połączeniem wifi i bardzo mizerny zasięg. Dla porównania ESP8266 działa dobrze.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
3
Jakbym miał coś obecnie robić w embedded to wybierałbym tak:
- asm do wstawek dedykowanych i superwydajnościowych typu AVX, najlepiej wciśnięte w C, ew. od biedy jako osobny moduł ASM do programu w C
- C (ostatecznie ASM) do maszynek typu Pic - https://botland.com.pl/431-pic
- Python do tłustych maszynek typu Raspberry Pi / Odroid / Tinker Board, do rozwinięcia bardziej rozbudowanych projektów - https://projects.raspberrypi.org/en/projects?software[]=python
W innych językach (Java, C#, JavaScript) też są projekty, ale raczej mniej popularne, przez co jeśli na czymś utkniesz to będzie problem z kontynuacją.
edytowany 3x, ostatnio: vpiotr
- Rejestracja:około 21 lat
- Ostatnio:około 4 godziny
1
pioflor napisał(a):
Jaki jest sens używania nienatywnych języków jak Java czy Python do systemów embedded?
Jeśli masz wystarczająco RAMu i procka to sens jest taki sam jak wszędzie.
Jeśli to jest jakieś ATtiny na którym masz 2 kB na program i 256 B RAM no to problem się sam rozwiązuje.
nil, ale żeniljest też wartością zwracaną przez wiele bibliotecznych funkcji…