Jaki język do programowania arduino , mikroktorolerow ?

0

Cześć
Jakie język polecacie do nauki aby programować urządzenia IoT(arduino , mikrokotrolery). Wiem że kiedy był to język C ale czy nadal tak jest i jak tak to dla czego ma przewagę nad innymi językami?

0

Jak się mieści w pamięci to c++ bo szybko i wygodnie oraz przenośnie a jak trzeba żeby szybko działało i wchodziło w attiny to asm.

1

C nadal jest bardzo popularny w embedded i raczej prędko to się nie zmieni. Więc C jest bardzo dobrym wyborem. Co do przewagi, na to składa się wiele czynników. Na przykład to, że język ten od kilku dekad jest używany do pisania niskopoziomowego oprogramowania i spisuje się tam wyśmienicie.

0

Do embedded (szczególniez małą pamięcią i słabymi prockami) polecam: C i asm. Jeśli jesteś sado-masochistą to bierz C++.

0

To ciekawe że nawet spore firmy zaczynają skazywać się na ten "sado-masochizm" o którym piszesz. Ba... nawet standardy temat adresują....

Widocznie mają "mądrych" doradców i lubią i sobie i innym "ułatwiać" życie? A może kierują się zasadą, którą słyszałem osobiście w jednej z firm: "napiszmy ten program w pythonie, bo w końcu Google używa pythona - a skoro tak wielka firma go używa to on musi być dobry." To prawie taka sama argumentacja :) C++ jest nowszy, więc lepiej jego używajmy no bo C jest takie stare, passe i w ogóle be. A poza tym C za krótko się kompiluje i za szybko działa :)

A teraz na poważnie bo chyba nie jestem na czasie - w kwestii standardów, o których piszesz - chodzi Ci o standard MISRA?

0

C/C++ z punktu widzenia komercyjnego. Dla zabawy, to właściwie cokolwiek. Python, NodeJS śmigają pod Raspberry, jest też Rust, który daje rade na ARMach i Go, które radzi tam sobie słabiej ale jednak radzi.
Warto się jednak zastanowić jakie parametry ma mieć ten mikrokontroler - pisanie w C++ bez korzystania z dobrodziejstwa STL'a to masochizm, a niestety przy słabszych płytkach trzeba uważać z czego się korzysta.

Odnośnie samego Arduino - jeśli patrzysz pod kątem zawodowym, to odpuść sobie tę platformę.

5

Nie nie chodzi mi o MISRA... Z argumentacją na tym poziomie trudno dyskutować i także tracić czas. Wybij tylko okno w swojej piwnicy by podano Ci posiłek. Python i owszem. Infrastruktura testowa i CI. Jesteś już przekonany stąd poprzestanę na stwierdzeniu że ktoś powinien zgasić światło...

Ech, takie wycieczki osobiste są zupełnie zbyteczne (wybij okno w piwnicy, etc).

Starałem się zwrócić uwagę na fanatyzm i głupotę niektórych osób, które najchętniej w każde urządzenie embedded pchałyby na siłę C++ a szczególnie do systemów o bardzo ograniczonych zasobach i w zastosowaniach niskopoziomowych.

Realny przykład z pewnej firmy - porównanie:

jest sobie system działający na Linuxie, 32MiB flash, 64 MiB RAM, brak grafiki - działają tylko programy typu daemon:

pewna prosta aplikacja - daemon bez GUI forwarduje dane między serialem a ethernetem - czyli w miarę niskopoziomowo

  1. najpierw napisana w C, objętość kodu wynikowego kilkadziesiąt kiB, zajętość procka <20%
  2. przepisana przez fanatyka w C++ z Boostami i innymi *@#%-ami, kod wynikowy: 11MiB, zajętość procka >60%

Zwróćmy uwagę że to system Linux, gdzie ma działać nie jedna a wiele aplikacji - a tu jedna app-ka w C++ zajmuje tyle RAM-u, flasha i procka. A gdzie miejsce dla innych aplikacji?

Nie zawsze jest tak, że jak brakuje pamięci "to sobie dokup". To są rozwiązania embedded - one muszą spełniać określone
warunki poboru prądu, wymiarów, wagi, kosztów, etc.

Jedna z decyzyjnych osób z tego zespołu, który portował tę aplikację na C++ stwierdziła kiedyś:
"C++ ma niewielki narzut w stosunku do C" - czy to nie jest zaślepienie i fanatyzm?

A z tym pythonem chodziło mi o to jak umotywowaną argumentację zastosowano a nie o sam fakt używania pythona.

Morał miał być taki - trochę rozwagi przy wyborze rozwiązań dla embedded.

1

"C++ ma niewielki narzut w stosunku do C"

To akurat prawda jeśli mówimy o wydajności. Natomiast problemy polegające na tym, że ta sama aplikacja napisana w C++ działa wolniej niż ta w C (bądź odwrotnie) najczęściej wynikają nie z cech tych języków tylko umiejętności programistów. Oczywiście mam na myśli aplikacje działające na systemach operacyjnych (np. linux) a nie firmware do mikrokontrolerów bo tam nie miałem doświadczenia z C++ więc się nie wypowiadam.

1

C++ jest dobry, bo tworzy miejsca pracy, których taki C nie byłby w stanie. Z samych błędów programistycznych łatwych do popełnienia w C++ a praktycznie niewykonalnych w innych językach można by pisać doktorat. Jak śledzę ekhm ekhm "rozwój" standardu C++ na przestrzeni dekady, to się zastanawiam, czy komitet standaryzacyjny bierze w łapę od korporacji stojących na produkowaniu koszmarnego kodu w C++, by miały jeszcze więcej potencjalnych sposobów na kiwanie klientów w łatanie/refaktoryzację/rozszerzanie/utrzymanie kodu. Czy po prostu jest to nieudolny i niewykonalny zabieg mający na celu "naprawę" tego języka.

0

"C++ ma niewielki narzut w stosunku do C"

Zdecydowanie tak jest jeśli weźmiemy pod uwagę, że kod w C nie trzeba mocno przerabiać by skompilował się pod kompilatorem C++. Jednak taki kod nie będzie typowym kodem w C++. Jeśli ktoś wybiera C++ to raczej nie po to, by pisać w nim jak w C, tylko po to by sobie z "dobrodziejstw" C++ skorzystać. Mikrobenchmarki porównujące C i C++ niewiele mówią, bo z racji małego rozmiaru łatwo je starannie zaprojektować tak, by miały niski narzut w obu wersjach.

A może kierują się zasadą, którą słyszałem osobiście w jednej z firm: "napiszmy ten program w pythonie, bo w końcu Google używa pythona - a skoro tak wielka firma go używa to on musi być dobry."

Python jest teraz używany w ogromnej ilości firm. Znalazł zastosowanie np:

Popularność Pythona i jego zwięzłość skłania niektórych do pisania dużych systemów w Pythonie, ale nie sądzę by to był dobry pomysł. Anegdota (niby jeden przykład, ale w grę wchodzi wieeele milionów GBP):
https://www.quora.com/Why-are-banks-like-JP-Morgan-and-Bank-of-America-Merrill-Lynch-using-Python-to-replace-historic-legacy-systems-built-in-Java-C++

I will preface this by saying that, for confidentiality purposes and other reasons, I will not name any specific banks, projects, or persons, whether or not they were mentioned in the question. Any similarity to banks, projects, or persons, living or dead, is purely coincidental.

Several years ago, there was a major bank that undertook a project to replace a Java risk system (built in house in less than one year) with a Python risk system (which is still being built in house). Over a number of years, the cost of the Java system totaled less than 20 million British pounds, including hardware costs, software license + maintenance + support costs, developer costs, and operational costs (charge-back). The Java system is able to deliver on-demand results for ad hoc queries (e.g. n-way pivots on any of hundreds of variables) in 5 seconds or less against the real-time risk profile of the entire bank. Furthermore, due to the risk engine architecture, it can handle increased load and/or lower the response time of queries by scaling the hardware (either scaling up or out).

In this particular bank, the system that was in place before the current Java system was apparently an overnight process that utilized hundreds or thousands of CPUs from a compute grid. As an overnight process, it provided results only from the previous day's positions, with no ad hoc support, (i.e. no custom pivots, etc.) It may have had some ability to perform intra-day updates, but the results were generally at least a few hours old, if not a day old. (My knowledge of the previous system is minimal, but from what I've seen at other banks, I assume that ad hoc queries were possible on-demand at the cost of a dedicated server and an hour or so of processing. Edit: I have been corrected, that the system did not support any ad hoc queries.)

So far, the Python system -- which is not yet usable in production -- has an (estimated) cost much higher (at least an order of magnitude, from what I've heard Edit: supposedly, the entire project now totals over a billion pounds cumulatively) than the cumulative cost of the Java system, and the last time I heard about it, its result times were in the 90 second range. Also, to get it to perform that fast, the bank was forced to code a number of calculation routines in a lower level language (C, I believe), thus losing the potential algorithmic flexibility and dynamic behavior that could be achieved with Python (which was a major reason for selecting Python in the first place; see GS Slang, for example).

As an aside, the person who was the driving force behind the Python system described above was coincidentally the same person who was responsible for (among other things) risk technology at an infamously no-longer-existing bank. (Edit: This person departed some time back when "the writing was on the wall.")

Lastly, as Abdul mentioned, many of these projects are attempts to emulate the GS Sec/Slang environment. The irony is that as other banks attempt to move toward the GS model, GS is working to reduce their IT exposure that results from a completely proprietary (and rapidly aging) technology stack. (Edit: I was told that this shift began in 2007.)

For the sake of full disclosure, I work at Oracle. The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.

2
  1. ktoś, kto w ten wątek włączył **Pythona **chyba nie bardzo wiedział, co to jest mikrokontroler. Ostatnimi wersjami Pythona które dawały szansę na udane embedding były 1.7.x, (udawając że mamy RAMu dostatecznie dużo). Robiłem embedding pythona do aplikacji pecetowskiej, więc coś tam wiem, znam API itd...
    Python od 2.x już nie da się eksploatować w środowisku nie mającym systemu operacyjnego i filesystemu, w całym runtime są wywołania. Wykonanie pythona potrzebuje dużo RAM, wielokrotnie więcej niż uK ma.

  2. warta zwrócenia uwagi jest Lua, język dedykowany do wbudowywania zarówno w jako interpreter w większe systemy "pecetowskie", czy ma udane realizacje w górnym segmencie mikrokontrolerów (ESP8266 i ESP32). Czyli jest interpreter na bare metal.

  3. Święte oburzenie wyznawców C nie ma sensu. Po przekonwertowaniu projektu w C Atmega 8 na C++ (inteligentne C z klasami - bez STL), skorzystaniu z funkcjonalności (np kontruktory inteligentnie coś inicjują), precyzyjne deklaracje danych ułatwiają widocznie optymalizację, skoro wyszło MNIEJSZE zużycie statycznego ram i kod o kilka bajtów MNIEJSZY od wersji C, przy zwiększonej funkcjonalności.
    Np funkcje inline bardzo szanują przestrzeń na stosie, wiele rzeczy działa na etapie kompilacji porządkując ją (pierwsze z brzegu namespace)

  4. Nie ma co pytać o język na arduino i hejtować C++,, to co na nim natywnie jest, jest dialektem C++ (co nie znaczy że poważam tę platformę - np za brak promocji namespace)

1 użytkowników online, w tym zalogowanych: 0, gości: 1