On 2016-10-23 12:41, g...@g...com wrote:
>> I wtedy nie bierze się dziadowskiego 8051 tylko CPU przeznaczone do
>> kolsalnych zastosowań jak niski pobór prądu. Jest tego trochę na rynku.
> Owszem. I raczej nie chodzi to na armach. Texas Instruments
> np. daje swój kompilator do mspków. I ogólniej, łatwiej stworzyć
> autorski kompilator C, niż C++.

No i masz dokladnie to oczy mówie. Vendor-lockin. Twoj program pisany
pod 8051 albo MSP i stosuje idiotyczne niestandardowe konstrukcje
wynikające albo z ograniczeń hardware albo imbecylizmu programistów
kompilatora albo z powodu dobrze przemyślanego planu marketingowego.
Bierze ARMa - problemów nie ma, przynajmniej nie w takiej skali. Ale
ARMa nie bierzesz bo wierzysz w teorie spiskowe popularne wśrod legacy
programmers.

> Nie o to chodzi. Jeżeli chcesz korzystać z ich protokołu komunikacyjnego
> (który jest dość popularnym standardem), musisz używać ich czipów.

To sugeruje żeby sobie je wsadzili w dupę skoro nie są w stanie
dostarczyć algorytmu generycznego kompilowalnego na byle czym. Czy już
wspominałem że programiści embedded są głównie skansenem technik
programowania z lat 60tych? Dlaczego muszę? Czy ten czip musze
oprogramować? Musi być 8051 na czytaniu danych?

> A wtedy możesz oczywiście dodawać swojego czipa, który komunikuje
> się z ich czipem po uarcie, albo -- jeżeli logika jest prosta i zmieści
> się w dostepnej pamięci -- możesz zmodyfikować program dostarczony
> przez nich. A przy milionie wyprodukowanych sztuk Twoje ćwierć
> dolara to będzie ćwierć miliona dolarów. No niestety, taki biznes.

Chcesz powiedzieć że 8051 kosztuje mniej niż ćwierć dolara i że ma to
jakiekolwiek znaczenie przy produkcji urzadzeń gdzie cała reszta jest o
kilka rzedów droższa?

> Nie. ARM byłby w tym przypadku overkillem.

Wyjaśnij dlaczego. Jest szybszy więc oszczędza prąd. Jest wygodniejszy
bo są kompiltory wspóczesnych jezyków. Jest rownie drogi/tani co 8051.
Ma lepsze narzedzia debugowe. Projektowany poza Intelem więc nie jest
obarczony kretynizmami. W czym jest overkillem?

> Ogólnie ARM to jest bardzo dobra architektura, ale nie nadaje
> się do wszystkiego -- w niektórych zastosowaniach jest zbyt
> kosztowna albo zbyt prądożerna.

Już Ci wyjaśnilem że mówisz głupoty. 8051 jest bodaj najbardziej
prądożerną architekurą z powodu clk/12. Kiedy 8051 wlasnie zabiera się
za obsługę przerwania, AVR, PIC, ARM już dawno ją zakończyły i poszły spać.

>> Niewiele jak widać. Jesteś typowy legacy embedded. Posługujesz się
>> mitami w celu usprawiedliwienia głupich wyborów.
> Z całym szacunkiem, ale ton, w jakim się do mnie odnosisz, jest
> obraźliwy, a Twoje stwierdzenie całkowicie niemerytoryczne.
> Żeby określić, że jakiś wybór jest "głupi", trzeba mieć nieco
> większą wiedzę odnośnie okoliczności, w jakich był dokonywany.

Oczywiście, dlatego wniskując nad ogólnym "8051 przydaje się w
plikacjach o malym poborze prądu" można się tylko puknąć w głowę i to
solidnie. Napisz o szczegołach, z chęcią zobaczę ten *argument* który
powoduje że 8051 jest lepsze bezwzglednie od czegokolwiek innego. Tak
wiem, bo kod już był napisany. Badziewie-lockin. Takie zycie i ja to
nawet rozumiem.

>> Nie. Nie masz pojęcia o C++ i nie rozumiesz dlaczego tego błedu nie da
>> się popelnic jesli tylko zrezygnujesz z #define i zaczniesz pisać kod
>> silnie typowany.
> Ależ rozumiem. Zazwyczaj jeżeli widzę define'y tam, gdzie
> mogłyby być użyte enumy, szukam tego, który to zrobił.

Nie chodzi o enumy.

> Zasmuca mnie to, że pola bitowe w C są tak źle obsługiwane
> (i rzeczywiście w C++ można to z pewnością zrobić lepiej)

Nie chodzi o pola bitowe.

> A może to Ty nie masz pomysłu na to, jak użyć makr dla osiągnięcia tego celu?
> Na przykład, mam takie makra w kodzie w C (nie-embedded):
> https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/video.h?at=default&
fileviewer=file-view-default#video.h-16

To nie działa jak RAII. To działa pi razy drzwi jak opakowanie funkcji w
niewidzialną funkcję. Ma dokładnie takie wady jak napisanie tego
ręcznie. Zrob z action jakieś return. Albo lepiej goto, ulubiny szit
embedowców.

> i jeżeli chcę sobie użyć zasobu, nie martwiąc się o jego dealokację,
> robię to w taki sposób:
> https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/image.c?at=default&
fileviewer=file-view-default#image.c-573
> ten sam cel jest osiągnięty. Czy coś pominąłem?

Tak. RAII i pojęcie scope.

> Raczej mam wrażenie, że to Ty masz religijne podejście do C++.

Pragmatyczne.

> Ja po prostu mam świadomość, że kompilatory C++ nie są dostępne
> na wielu systemach, z którymi jest mi dane pracować, i wiem,
> że to się nie zmieni.

Nie. Wybierasz idiotyczna architekturę 8051 na podstwie mitów i bajek a
potem narzekasz że nie ma tam kompilatora. Tak, na to nic nie da sie
poradzić. Dębowe pudełko, położyć się i czekać.

> Ja mówię tylko tyle, że środki należy dobierać do celów.

Pascal nie jest środkiem dla jakiegokolwiek sensownego celu. 8051 nie
jest środkiem dla jakiegokolwiek sensownego celu. C nie jest środkiem
dla jakiegokolwiek sensownego celu.

To wszystko archeologia. I doskonale sobie zdaje sprawę że Duńczycy mają
takie same firmy jakie my mamy w Bytomiu. I bardzo dobrze, media mają o
czym pisać a świat ma przynajmniej poczucie że pojecia dna można znowu
przesunąc nieco niżej.

> A co do Twojego argumentu z biologii, to spodziewam się, że
> pierwotniaki wyginą jako ostatnie.

O jak miło :D