On 2016-10-25 16:10, Maciej Sobczak wrote:
>>> I właśnie dlatego (z powyższego linku):
>>> "Draw the connections between the modules on the editor, and watch your project
come to life."
>> Był kiedys taki kawałek kodu o nazwie LabView.
> Sam napisałeś, że obecni amatorzy od Arduino to przyszli inżynierowie w firmach
embedded.
> Pokazuję Ci, co ci amatorzy teraz robią.

Adruino. Takiego ruchu amatorow na rynku uC nie było nigdy.

> Zgadnij, co będą robić za parę lat. Pisać szablony w C++?

No. Mniej więcej. Moze nawet mniej bo biologia nie jest aż tak okrutna.

>>> Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++.
>> Po LabView widac
> Po ESLOV widać, że tak rośnie nowe pokolenie inżynierów.

No, to widać po obu. Moving on.

>> No ale jakos od 15 lat się nie daje rady przestawić.
> Kolega obok twierdził, że "większość" softu w samochodach się robi w Simulinku.
> Trochę przesadził z tą większością, ale i tak to są rysy na Twoich argumentach.
> To się dzieje, niezależnie od tego, czy Ci się to podoba.

Alez niech się dzieje. Tylko nic z tego nie wynika. LV nie dał rady
zdominować nawet procenta rynku. Złosliwi twierdzą że jak by sprzedawali
hardware za 1/10 ceny to może. Jestem pewny że co kilka lat ktoś musi
przeprowadzić nastepną kompletną rewolucję na rynku embedded po której
zostanie jak zwykle tylko troche rozrzuconych papierków po miętówkach na
sali konferencyjnej. Moving on.

>>>> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.
>>> Ta nisza to może być pojedynczy procent całego rynku embedded.
>> IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded.
> Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy nie mogą się
pogodzić z postępem w hardwarze.

Ale to nie jest postęp że masz coraz szybsze procesory *wszedzie* bo w
ogromnej i ignorowanej przez Ciebie części procesory nie zmieniają
prędkości na wieksze. Ba, odchudzają się z ficzerów, zmienia rdzenie na
urposzczone, dodaje hardware pozwalające zrobić coś sprzetowo itd. Takie
do migania diodą i sterowania silnikiem pralki. Przypuszczalnie ten
rynek to kilka rzedów więcej niż sterowników czarnych skrzynek w
samolotach które uważasz za istotny w tej dyskusji (a ja komiczny).

> Podsumujmy: piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest
system embedded.
> Jeśli w następnej wersji piekarnika/pralki/zmywarki tego samego
producenta będzie
> mały komputerek z Linuksem, to to już nie jest embedded. Dlaczego? Bo
specjaliści od
> embedded mają naruszone ego? No to sorry.

Pokaż gdzie jest granica. Używanie hasła embedded do wszystkiego traci
sens tej rozmowy. Smartfony to już jest wszystko, bo po drugiej stronie
siedzi AtTiny13 i nijak nie ma tutaj zadnej analogii czegokolwiek a w/g
Ciebie to jest wszystko embedded. Oczekuje że mój laptop jak tylko go
podniosę można nazwac smartfonem a mój pecet po wsadzeniu akku i
monitore na taśmie to będzie laptopem.

>> Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę
>> dlaczego miałbym to nazywać embedded.
> https://en.wikipedia.org/wiki/Embedded_system

I to lusterko ze smarfonem spełnia tą definicje? Smarfon spełnia tą
definicję?

>> Czy jak do mojego peceta dokleje
>> monitor i klawiaturę to tez bedzie embedded?
> To zależy, czy będzie częścią większego produktu.

Jak dokleje jeszcze lusterko to już będzie embedded? A jak takie duże to
już? A jak za tym lusterkime będzie monitor to już?

> Jeśli ten monitor i klawiatura są akurat na frontowym panelu w samochodzie
>, to tak, ten pecet jest systemem embedded. Sorry. Nie ja wymyśliłem
definicję.

To nie jest kwesia czy w samochdozie masz embeddeed tylko czy te
miliardy telefonów z java są embedded czy są mniejszymi pecetami? A może
nie ma róznicy i powinniśmy tą rozmowę nie prowadzić o embedded tylko o
mikrokontolerach? To zaraz przyjdzie jakiś misio i zacznie gadać o tym
że SoC to taki uC tylko większy itd itp.

Wyciągasz sobie z embedded dośc szeroki zakres hardware i rzucasz nim tu
i tam jak wygodniej. OK, trudno, co robić. Głuopia definicja to i głupie
trolowanie.

>> Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym
>> falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy.
> Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową.

Ich jest całkiem sporo. O dziwo nie pracuje zawodowo jako programista
embedded.

>> Się pisze testy. A w czym?
> Skup się: w Excelu.
> (oczywiście nie jest to jedyna opcja, ale o tyle ciekawa, że kompletnie oderwana od
dyskusji nt. wyższości C++ nad C)

Interesujące. A w czym sie je implementuje? Zapewne to już nie jest
istotne? A może masz na mysli systemy kontroli specyfikacji i testowania
które z *faktycznym* testowaniem mają tyle wspólnego co referencja z
bazy danych?

>> Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod
>> w C woła właściwą funkcję jest znacznie trudniejsze niż w C++.
> Dalej nie rozumiesz. Jeśli lampka ma zgasnąć, to w jakiejś chwili na jakimś
outpucie ma być LOW (powiedzmy).
> Albo jakaś zmienna lub wartość w jakieś tablicy albo strukturze ma być LOW. Itp.
> Zrobienie testu na takie coś nie zależy od tego, czy ustawianie tej wartości jest w
C czy w C++.

Zależy. W końcu ktoś kiedyś fizycznie musi to coś odczytać z przestrzeni
w której działa C/C++.

> W szczególności, uwaga, test można zrobić *zanim* powstanie ten kod

Nie uzywaj aż takich oczywistości.

> i tym bardziej wtedy widać, że robienie testu nie zależy od tego, czy gaszenie
lampki jest w C, czy w C++.

Dalej nie wyjasnileś jak ten test czyta ten LOW. To jest *istotne* i gdy
zrozumiesz dlaczego UVM trzęsie światem FPGA zrozumiesz rownież dlaczego
jest istotne *jak* się tam implementuje testy i dlaczego 10 lat trwało
dojście do tego. Tak, w aplikacjach krytycznych też.

>> Narzuca bardzo wiele.
> Na przykład?

Na przykład metodykę testowania od dupereli jak raporty, przez sledzenie
specyfikacji po precyzyjne informacje jak testować na poziomie
implementacji pojedynczych machnięć drutami.

>>> Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++.
>> To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++.
> Błąd logiczny. Właśnie dlatego jest łatwiej w C, że C jest (w uproszczeniu)
podzbiorem C++.
> Dzięki temu ilość różnych rzeczy do sprawdzenia w kodzie jest mniejsza (sic!).

Nie, ponieważ w C emulujesz zachowania ktore w C++ masz OOTB. Na tym
polega róznica. Na tym że legacy programmers w C *emulują* zachowania
C++ jak RAII. I to *trzeba* testować intensywniej niż wypociny
kompilatora. Bo wypociny jednostek białkowych są z definicji popsute
*bardziej* niż wypociny kompilatora.

>>> Bo niektóre urządzenia embedded są krytyczne?
>>> W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie?
>> Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z
>> druga osobowością?
> Uzupełniam:
> Jeżeli w danym systemie embedded nie interesujesz się czasem odpowiedzi na
przerwanie
>, to prawdopodobnie jest to system rozrywkowy, np. lustro z Andoridem z prognozą
pogody.

Interesujące. Przecietny DMA w byleczym wymaga krytycznego czasu
odpowiedzi na przerwanie. Od mówiącej chińskiej lalki po sterownik dysku
w klastrze. DMA jest wszedzie poza 8051 i AVR. I wszedzie masz
zagadnienie RT. Oczywiście zawsze można ściemniać że zajmie się tym VM
Javy a kod za to odpowiedzialny piszą krasnoludki.

> Natomiast jeżeli jesteś zainteresowany tym czasem, to prawdopodobnie jest to system
> krytyczny a wtedy chcesz mieć jak najłatwiejsze narzędzia weryfikacji.

Najłatwiejsze narzedzia weryfikacji do C nie istnieją. To nie ten język.
C++ też nie.

Był kiedyś taki język e przeznaczony tylko do testowania o świetlanej
przyszłości. Niewiele można na ten temat znaleźć bo to raczej radosna
twórczość hindusów. Całkowicie poświęcony byciem abstrakcyjnym względem
implementacji i języka ktory testuje. Obecnie można książkami na jego
temat palić w kominku a i to krótko bo była jedna i chyba tyle. Ale za
to ile szumu, konferencji i posterów!

>>> I właśnie ten większy stosunek utrudni weryfikację
>> Nieprawda. Weryfikację utrudnia cieżki do czytania kod,
> Więc pisz kod łatwy do czytania. Standardy kodowania po to są.

Standard kodowania nie czyni kodu latwiejszym w czytaniu na poziomie
algorytmiki. Cieżko popelnić bład jedną spacją za dużo więc standardy
kodowania w niewielkim stopniu wpływają na generację błedów przez
programiste. Wpływa czytelność a więc rozumienie co autor mial na myśli.
W typowych wypocinach embedded zazwyczaj oznacza to przeczesanie sześciu
makr do emulacji RAII zmielone z #define na przemian z #include do
emulacji template.

>> kłopotliwe
>> implementowanie testów
> Testy pisze się z wymagań. N-ty raz to powtarzam.

Jak typowy menager: piszcie tak zeby było dobrze.

>> i kiepski związek kodu (rysowanie z LabView) z
>> wynikiem (generowany C).
> Bingo. Dlatego C++ jest trudniejszy w weryfikacji, niż C
>, bo w C++ jest większy przeskok między kodem (źródłowym) a wynikiem (obiektowym).

Ide o zakład że nie weryfikujesz tego związku żadnym narzedziem i to
tylko puste hasła. W przypadku językow HDL taka weryfikacja zazwyczaj
oznacza wykonanie tych samych czynności na dwóch symulatorach roznych
producentów i komapracje wyników. I to wcale nie oznacza że choć jeden
jest dobry. To nic nie oznacza. Podnosi tylko jakość snu zespołu.

Przeciętny projekt fpga jest na tyle skomplikowany że nie da się go
zweryfikować dowolną metodą jaką znamy. Zakłada się pewien % jakości i tyle.

>> Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia
>> templates mialo byc przeszkodą weryfikacyjną
> To jest tzw. total showstopper a nie przeszkoda.

Serio? A niby jak? Masz swój embedded z 2GB flash. program zajmuje po
kompilacji z 400MB. Każdy bajt Twoj zespół dronów sprawdził, czy zgadza
się z kodem źrodłowym. Teraz masz +20MB więcej. To przeciez tylko
kilkaset lat więcej sprawdzania bajt po bajcie. W czym widzisz problem?

>> Po stronie kodu jest 10x mniej
> Zaraz, zaraz. Powyżej napisałeś, że kodu jest 20MB więcej, teraz piszesz, że kodu
jest 10x mniej. Gubisz się?

Kodu źródlowego mniej, kodu wynikowego więcej. Co poradze na to że to
kod i tamto kod?

> Jeżeli w Twoim projekcie zrobiło się 10x mniej kodu źródłowego a jednocześnie
przybyło 20MB kodu wynikowego, to leżysz na weryfikacji.
> Hasło: traceability.

Puste. Dotyczy ono kodu źródlowego. Nie wynikowego.

Zaznacze też że w przypadku *ogromnych* projektów FPGA korzysta się
rownież z certyfikaowanych syntezerów i symulatorów. Naprawde myslisz że
ktokolwiek jak przybijał pieczatkę to mial pewnośc że takowy działa
poprawnie? Tego nawet w pojedynczym promilu nie da się stwierdzić.
Przechodza jakiś tam zestaw testów. Przejscie wszystkich ściezek jest
niemożliwe fizycznie. Ufa się na jakiś procent. Sorry, tak działa świat.
I co ważne: tam "kod wynikowy" to z grubsza sieć bramek. Każda synteza
robi ją inaczej. Powiedzmy że dostajesz milion bramek i dwa miliony
drutów. Drukujesz to na płachcie wielkości boiska i armia ludzi z lupami
ropoczyna proces weryfikacji. Tak, naprawdę. Zupełnie jak inni bajt po
bajcie oglądaja assembler po każdej kompilacji.

>>> . Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej
>> Pomiędzy jednym a drugim masz kompilator.
> To jest nieciągłość.

Więc jak rozumiem kompilujesz na kartce (notatnikowi tez bym nie ufał!).

>> Możesz wygazać formalnie jego
>> działanie?
> Jeżeli to jest kompilator C++, to nie da się tego zrobić jeszcze bardziej, niż nie
da się gdy to jest kompilator w C.

Ale możesz dla swojego? Ktoś to wykazał? Czy tylko ma pieczatkę?

> Właśnie dlatego lepiej, żeby był C.

Żadna roznica. I jeden i drugi nie jest mozliwy do weryfikacji. Bazujesz
na kompilatorze z pieczatką i tyle. Polepsza może to jakośc snu i
pozwala osiągnąc pewien poziom dupoochrony. Nie ma żadnej magicznej
ciągłosci na którą się powołujesz.

>> Jesli nie to musisz za każdym razem sprawdzać kod
>> w C z kodem w asm. Ręcznie.
> Tak. Sorry, taka branża.

Współczuje. Sprawdź czy nie czeka cie przyszlośc w kopaniu rowów. Z
prostej przyczyny: nie robicie tego. Ewentualnie robicie to w projektach
z gatunku miganie diodą gdzie to jest fizycznie możliwe.

> Dlatego łatwiej się to robi gdy kod źródłowy jest w C.
> Naprawdę.

Nie robicie tego lub robicie pierdołowate aplikacyjki. Tego nie da się
zrobić albo można mówić że się robi a oszukiwać (np. weryfikowac kawałek
i twierdzić bez podstaw że inne kawałki tego nie psują jak się zmienia kod).

>> Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze
>> C z wielką dziurą.
> Nie ma problemu - certyfikował tą resztę wokół dziury.

Nie. Dziurę wykryto po certyfikacji. Bo tak ta certyfikacja wygląda.
Ziutek, na oko działa, przyp... pieczatkę, niech se zarobią. To na oko
to tysiące testów testujących może max kilka procent interakcji w
kompilatorze. Tylko testów tych testów nie ma. I ich testów.

Moment w którym mozna jeszcze bylo formalnie weryfikować kompilatory
czegokolwiek to chyba okolice lat 80tych. Natomiast chyba można ciągle
assemblery. Czy chciałbys może wyciągnąc z tego wniosek że pisanie w
asseblerze jest obaczone mniejszą iloscią błedów niż w C?

>> Zaznaczam przy okazji że w tym czasie kiedy oni w nim
>> pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów.
> Bzdura. Bugzilla pokazuje, że w historii gcc nigdy nie było takiego przedziału
czasu, żeby nie było bugów.

Zapomniałem dopisać: nie miał takich bugów. Chyba nie zakładasz że
jestem aż takim idiotą, co?

>> Bugi pochodzace z kompilatorów to promil promila problemu
>> bugow w ogólności.
> W branży rozrywkowej? Oczywiście.

W każdej. Od bardzo dawna. Już mineły lata 80te. Całkiem przyzwoite
kompilatory mamy.

>> Piszesz o embedded tak jak Ci w danej chwili
>> pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili
>> certyfikowane produkty
> Ty sam ten temat szeroko traktujesz. Raz o Arduino, drugi raz o falownikach...
Próbuję odpisywać wg bieżącego, zmiennego kontekstu.

Akuratnie falowniki i Atmega leża mniej więcej w tej samej przegródce.
Sam mam jeden na Atmega.

>> Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego
>> promila aplikacji embedded obwarowanymi certyfikatami i komitetami
>> wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej.
> Ale ja nie pisałem tylko o promilu certyfikowanych. Również o tej gigantycznej
masie rozrywkowych, z Javą w środku.

Wiec po co argumenty z jednej strony przenosić na drugą? Czy któś uzywa
certyfikowanych kompialtorów do Javy? A może uzywa GC w apliakcja RT w
samolocie? Może i to embedded i tamto embedded ale przeciez to zupełnie
inne embedded!

> Pytanie teraz, czy pomiędzy tymi dwoma kategoriami jest wystarczająco dużo miejsca.
> Pewnie jest, ale nie na tyle, żeby można było pisać o niezastąpionym C++

Ależ tam jest od groma miejsca. Widzisz świat z wlasnego krzesła. Troche
ruchu w lewo, w prawo. ARMy przejęły rynek, w wersjach miniaturowych.
Tam jest w cholere miejsca nawet na zombie 6502. jak wymyslisz za chwile
coś z rdzeniem AVR i ze 100 makrokomórkami to rynek wessa bez zająknięcia.

>, którego nic nie wyprze. Właśnie wypiera (albo nie dopuszcza), z obu tych stron.

Tak, od 15 lat.

> W branży embedded C++ jest w podobnym ścisku i pod podobną presją konkurencji, jak
na desktopie, z podobnych powodów.

Tak na desktopie od 30 lat. Tu wróżbitów było więcej. Co roku coś nowego
jest rewolucją. Bitów szkoda.

>> A przy
>> okazji jesli chodzi o Pascala ...
> Nie widziałem w embedded.

Był. Niestety nie pomnę jaki, ale był. Autor twierdził że nic lepszego
na uC nie wymyślono. Zapamiętałem to bo wtedy łatwiej poznać.