On Sun, 23 Oct 2016 03:41:53 -0700 (PDT), g...@g...com
wrote:
> Nie o to chodzi. Jeżeli chcesz korzystać z ich protokołu kom=
> unikacyjnego
> (który jest dość popularnym standardem), musisz używa=
> ć ich czipów.

Nie rozumiem.

Jeżeli jest protokół, jeżeli jest standard... to wuj komu do tego
jakiej produkcji jest chip, jeżeli tylko jest zgodny ze standardem?

Z drugiej strony: jeżeli jest jakiś przymus użycia akurat takiego a
takiego chipa i to tylko od tego jednego producenta to po co
standard? I po co tobie znać protokół, skoro i tak ty nic nie robisz,
bo chip robi to za ciebie?

Z trzeciej strony, jeżeli firma za bardzo bryka, to szukam takiej,
która mniej cwaniakuje. Producentów chipów jest więcej niż jeden.

do góry

On Sun, 23 Oct 2016 03:41:53 -0700 (PDT), g...@g...com
wrote:
> przez nich. A przy milionie wyprodukowanych sztuk Twoje ćwierć
> dolara to będzie ćwierć miliona dolarów. No niestety, t=
> aki biznes.

Myślenie godne Toyoty.

do góry

W dniu niedziela, 23 października 2016 13:10:22 UTC+2 użytkownik Sebastian Biały
napisał:
> > 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?

Tak. Niestety tak. Niestety stadard stworzony przez duńczyków jest
używany, ale jest (czy może raczej do niedawna był) zamknięty, i jedynym
legalnym sposobem korzystania z niego jest korzystanie z czipów
dostarczonych przez producenta. Które można albo oprogramowywać
po szeregowym API, albo zmodyfikować dostarczony przez nich szablon
kompilowany z dostarczanymi przez nich bibliotekami.
Taka polityka. A że rynek to łyknął, to nie moja wina.

> > 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. Chcę powiedzieć, że dwa czipy kosztują więcej, niż jeden czip,
i że dokładanie drugiego czipa tylko dlatego, że dla tego pierwszego
nie ma kompilatora C++ zakrawa o absurd.

> > 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?

Pierwsza sprawa: nie twierdzę, że 8051 są bardziej energooszczędne
od armów. Nie twierdzę też, że nie są. Twierdzę, że można znaleźć
procesory bardziej energooszczędne od armów, które mają mniejsze
możliwości obliczeniowe i są tańsze.

> > Ja mówię tylko tyle, że środki należy dobierać do celów.
>
> Pascal nie jest środkiem dla jakiegokolwiek sensownego celu.

Kto określa, które cele są sensowne?

do góry

On 2016-10-23 13:38, g...@g...com wrote:
>> 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?
> Pierwsza sprawa: nie twierdzę, że 8051 są bardziej energooszczędne
> od armów. Nie twierdzę też, że nie są. Twierdzę, że można znaleźć
> procesory bardziej energooszczędne od armów, które mają mniejsze
> możliwości obliczeniowe i są tańsze.

Banał. Wszyscy to wiemy. Skąd więc w tej dyskusji pojawił się 8051?
Przecież nie istnieje ani jedno zastosowanie gdzie byłby lepszy od
czegokolwiek. Poza pewna duńską firmą.

>>> Ja mówię tylko tyle, że środki należy dobierać do celów.
>> Pascal nie jest środkiem dla jakiegokolwiek sensownego celu.
> Kto określa, które cele są sensowne?

Rynek. Sugeruje sie rozejrzeć za pracą dla programisty w Pascalu. Nawet
ofert dla Algola i Cobola było więcej jak sprawdzałem kilka lat temu.

do góry

On Saturday, October 22, 2016 at 8:27:36 PM UTC+2, Sebastian Biały wrote:
> Przeszkodą jest jedynie biologia, inercja i Linus Torvalds.

Dzięki, dawno się tak nie uśmiałem. :) Do fortunek.

w.

do góry

W dniu 2016-10-22 08:04, slawek pisze:
> On Fri, 21 Oct 2016 16:17:05 +0200, krolikbest <k...@w...pl> wrote:
>> i używam do wielu innych projektów. Moim skromnym zdaniem czy do
> budowy
>> używam młotka czerwonego lub zielonego nie ma kompletnie znaczenia.
>
>
> Niby tak. Ale czy teraz używa się młotka? Większość rzeczy wokół nas
> wydaje się nie potrzebować młotka do swojego istnienia.
>
> Czerwony czy zielony... Pascal czy Cobol...?!
> Używanie Pascala do czegoś - jak dla mnie - to tak jak nitowanie
> karoserii zamiast zgrzewania i klejenia.
>
> W dodatku z C można bezproblemowo przejść do C++ i względnie łatwo C#
> oraz Javę. Delphi? Raczej przeniesienie projektu do Ady nie będzie.


Wbrew pozorom, C# ma więcej wspólnego z Delphi niż z C.... Pewnie
dlatego, że projektanci to podkupieni programiści z Borlanda...

--
Kaczus
http://kaczus.ppa.pl

do góry

W dniu 2016-10-22 22:07, Sebastian Biały pisze:
> On 2016-10-22 21:13, g...@g...com wrote:
>>> Jego banalność. Nigdy nie był dostarczony z jakąkolwiek sensowną
>>> bibliteka do algorytmiki. Stada studentów przez dziesięciolecia na
>>> uczelniach pisały nastepny program do sortowania bąbelkowego, listy
>>> dwukierunkowe, "bazy danych z uzyciem writeln", itp, zawsze w złym stylu
>>> (np. na tablicach albo niegenerycznie). I tak w kółko, banały które
>>> powinny być częścią języka.
>> Mówisz poważnie? Ale masz świadomość, że powodem, dla którego
>> owe stada studentów piszą programy do sortowania bąbelkowego,
>> nie jest brak istniejących implementacji funkcji sortujących?
>
> Nie. Efektem pisania wszystkoego na nowo w kółko błednie jest później
> masa programistów którzy nie potrafią inaczej jak wynajdywać kwadratowe
> koła. W Praktikerze do dzisiaj uzywają programu napisanego
> prawdopodobnie w Pascalu który wyszukuje ludzi w fakturach, liniowo bez
> żadnego indeksu. Ot taka jedna z miliona ofiar nauczania sortowania
> babelkowego i baz danych z writeln. Firma jak sprawdzałem kilka lat temu
> istnieje do dzisiaj i chyba dalej pisza to samo czyli "programy do faktur".

Trochę pojechałeś... Nawet zaawansowanym programistom, nop Wujek Bob
zaleca trening w pisaniu znanych algorytmów od czasu do czasu, nie po
to, aby tego uzywać, tylko dla treningu...


> Programowanie nie polega na tym że piszesz codzienne nastepne sortowanie
> bąbelkowe. Programowanie polega (i polegało wtedy rownież) na umiejętnym
> wykorzystaniu algorytmiki zamiast grzebania w szczegółach implementacji
> trywializmów.

Bzdura - nie znając różnic między listą, a wektorem, czasami użycie
niewłaściwego typu danych dla danego problemu zabije wydajność.
Oczywiście, przy tworzeniu formatek w javie nie ma znaczenia, ale
własnie w bardziej rozbudowanych problemach ma. Może być istotny czas
dostępu/fragmentacja pamięci/szybkość dodawania - więc należy rozważyć
wtedy który kontenerr będzie lepszy, ale by to wiedziec, trzeba mieć
choćby trochę informacji jak moga być one utworzone.




--
Kaczus
http://kaczus.ppa.pl

do góry

W dniu 2016-10-23 13:02, slawek pisze:
> On Sun, 23 Oct 2016 03:41:53 -0700 (PDT), g...@g...com wrote:
>> np. daje swój kompilator do mspków. I ogólniej, łatwiej=
>> stworzyć
>> autorski kompilator C, niż C++.
>
> Mit.
> Tworzysz kompilator C. Bierzesz kompilator C++ napisany w C.
> Kompilujesz. Masz kompilator C++.

W pełni zgodny ze standardem, na embeded - wątpię.... Szczególnie jak
dołożono do standardu takie głupoty jak wątki itp, które na danym
systemie mogą być realizowane w zupełnie inny sposób (jeśli chodzi o
komunikację itp) Ktoś się zapędził za bardzo.


--
Kaczus
http://kaczus.ppa.pl

do góry

On Sun, 23 Oct 2016 13:52:45 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Banał. Wszyscy to wiemy. Skąd więc w tej dyskusji pojawił się 8051?
> Przecież nie istnieje ani jedno zastosowanie gdzie byłby lepszy od
> czegokolwiek. Poza pewna duńską firmą.

Spokojnie.

Trzeba byłoby udowodnić że w każdym jest gorszy.

Samo "nie lepszy" nie jest argumentem przeciw. Bo może jest równie
dobry? I co wtedy?

do góry

On Mon, 24 Oct 2016 08:15:26 +0200, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> W pełni zgodny ze standardem, na embeded - wątpię.... Szczególnie
jak

A co tam zgodność ze standardem! Zresztą standard jest tolerancyjny:
może chyba być ograniczona dostępność bibliotek na np. embeded?

do góry