Jaki jest sens używania nienatywnych języków jak Java czy Python do systemów embedded?
0
2
Tak jak i w systemach głównego nurtu. Jeśli są zasoby i wymagania pozwalają na takie zastosowania, to można wybrać rozwiązanie z językiem Java lub Python.
Na tak ogólne pytanie może paść taka ogólna odpowiedź :)
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)
0
AnyKtokolwiek napisał(a):
Np Lua ma mocną pozycję na niektórych kontrolerach.
A to jest specjalna wersja Lua jak eLua czy ta normalna?
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
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 :-) ?
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).
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ą.
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.