On 22.08.2018 22:19, Piotr Wyderski wrote:

> Staracie się o posadę w Muzeum Techniki, czy co?

Przecież zarówno 8051, jak i układy produkowane przez Microchip (i nie
mówię tutaj o tych przejętych wraz z Atmelem) ciągle są używane.
Pierwsze głównie przez Chińczyków, drugie raczej na zachodzie. Niemniej
to, że coś nie cieszy się wielkim zainteresowaniem w Polsce wcale nie
oznacza, że już trafiło do muzeum.

do góry

Atlantis wrote:

> Przecież zarówno 8051, jak i układy produkowane przez Microchip (i nie
> mówię tutaj o tych przejętych wraz z Atmelem) ciągle są używane.
> Pierwsze głównie przez Chińczyków, drugie raczej na zachodzie. Niemniej
> to, że coś nie cieszy się wielkim zainteresowaniem w Polsce wcale nie
> oznacza, że już trafiło do muzeum.

Ależ oczywiście, że są używane, podobnie jak maszyna parowa.
W odpowiednich do tego niszach (co, wbrew pozorom, wymaga produkcji
wielkoskalowej) oraz w domach starców, których pensjonariusze odpadli
z peletonu postępu i po 30. latach wszystko ciągle wygląda dla nich
jak 8051.

Wyobraź sobie, że na 32-bitowym ARMie masz dostęp do nieprzebranych
zasobów darmowego oprogramowania wysokiej jakości i często nawet nie
potrzebujesz specjalnego programatora. Cena najsłabszej kostki w detalu
jest zbliżona do 8051 lub PICa, a możliwości obliczeniowe ma bez
porównania większe. Jeśli programujesz coś w małej skali i nie nazywa
się to ARM, to robisz sobie krzywdę. Bez względu na to, jak intensywnie
będziesz się samooszukiwał.

Pozdrawiam, Piotr

do góry

Dnia Thu, 23 Aug 2018 07:44:32 +0200, Atlantis napisał(a):
> On 22.08.2018 22:19, Piotr Wyderski wrote:
>> Staracie się o posadę w Muzeum Techniki, czy co?
> Przecież zarówno 8051, jak i układy produkowane przez Microchip (i nie
> mówię tutaj o tych przejętych wraz z Atmelem) ciągle są używane.
> Pierwsze głównie przez Chińczyków, drugie raczej na zachodzie. Niemniej
> to, że coś nie cieszy się wielkim zainteresowaniem w Polsce wcale nie
> oznacza, że już trafiło do muzeum.

Zartujesz. To juz tylko do muzeum sie nadaje.


J.

do góry

Dnia Wed, 22 Aug 2018 08:09:41 +0200, Zbych napisał(a):
> W dniu 22.08.2018 o 07:47, Karol Ryfer pisze:
>> Witam
>> Użyłem w końcu sdcc 8051, ale wcześniej próbowałem w Keil uVision 8051
>> (v5.25.3.0 - najnowsza):
>
>> Po kompilacji wychodzi plik BIN ponad 2kB, nie mieści się w AT89C2051
>> (ustawiony jako device w opcjach). Na początku są 2-3 bajty, później
>> około 2k zer, albo 0xFF (zależnie który konwerter HEX-BIN) i dopiero na
>> końcu kilkadziesiąt bajtów programu. Próbowałem różnych ustawień,
>> optymalizacji, model: small do 2kB, itd. Czy Keil tak ma czy ja coś źle
>> robię?
>
> Celowe działanie Keila, żebyś wersji demo nie używał do małych procków.
> Jak kupisz pełną wersję, to przestanie się tak zachowywać.

A jakby tak dorzucic troche niepotrzebnego kodu, zeby razem wyszlo
duzo - to moze ten potrzebny bylby na poczatku ?

J.

do góry

On 23.08.2018 11:14, J.F. wrote:

> Zartujesz. To juz tylko do muzeum sie nadaje.

Okazuje się jednak, że 8051 jest ciągle relatywnie popularny na Dalekim
Wschodzie. Jakiś czas temu czytałem książkę "Hardware Hacker" Andrew
Huanga. Amerykański inżynier o chińskich korzeniach, który opisywał
m.in. swoje doświadczenia związane ze współpracą z chińskimi firmami.
Często tłumaczył kwestie techniczne, wspominając o 8051, a nawet
gdzieniegdzie umieszczając fragmenty kodu źródłowego w asemblerze.

Oczywiście 8051 w tym kontekście nie oznacza jakiegoś poczciwego
AT89C2051, ale bardziej współczesne układy oparte na tej architekturze,
dysponujące bogatszym zestawem peryferiów.

do góry

On 23.08.2018 09:08, Piotr Wyderski wrote:

> porównania większe. Jeśli programujesz coś w małej skali i nie nazywa
> się to ARM, to robisz sobie krzywdę. Bez względu na to, jak intensywnie
> będziesz się samooszukiwał.

Ale przecież tak naprawdę nie ma wielkiej różnicy. Czasy pisania całych
programów w asemblerze już dawno minęły. C/C++ na każdej platformie
wygląda tak samo. Na dobrą sprawę coraz rzadziej trzeba odwoływać się
bezpośrednio do rejestrów, bo programista ma do dyspozycji wyższą
warstwę abstrakcji.

O ile parę lat temu przesiadka z AVR-ów na PIC32 była dla mnie obarczona
pewnymi trudnościami, to rozpoczęcie zabawy z STM-ami odbyło się
zupełnie bezboleśnie. Najwięcej czasu zajęło mi zaznajomienie się z
nowymi narzędziami.

Na dobrą sprawę nie pamiętam kiedy ostatnio natknąłem się na problem,
który wiązałby się ze sprzętową specyfiką danego układu. Zwykle
sytuacje, kiedy muszę kogoś pytać o radę albo szukać informacji w Sieci
są związane z konkretnymi bibliotekami.

do góry

Atlantis wrote:

> Ale przecież tak naprawdę nie ma wielkiej różnicy.

Różnica jest gigantyczna: dostępność darmowych narzędzi
programistycznych wysokiej jakości. Od kompilatora i debuggera
zaczynając. Zabawka dostępna na PIC wymaga dopłacenia ~800
dolarów za włączenie optymalizacji, a i tak nie rozumie nawet
języka C, o C++ nie wspominając. A na ARMa mam (co najmniej) GCC
i CLang, i to w jakości poza pojmowaniem ludzi z Microchipa.

Ponadto, są to te same narzędzia , co na pececie. Opanujesz raz
i umiesz tego użyć na wszystkim. Opanujesz MPLABa, to tylko PICe
będziesz programował. Vendor lock-in.

> C/C++ na każdej platformie wygląda tak samo.

Wygląda, tylko się nie kompiluje, bo matoł z Microchipa
nie rozumie nawet, co dokładnie oznacza słowo "const" w C
i jego kompilator odrzuca poprawne, trywialne programy.

Miłej zabawy. :-)

Pozdrawiam, Piotr

do góry

J.F. wrote:

> A jakby tak dorzucic troche niepotrzebnego kodu, zeby razem wyszlo
> duzo - to moze ten potrzebny bylby na poczatku ?

Ale właściwie o czym jest ta rozmowa? Co wyprawia jakiś niszowy
kompilatorek na jakiejś niszowej platformie? Ta informacja to już
jest dostateczny powód, by do tego bagna nie wchodzić.

Pozdrawiam, Piotr

do góry

Dnia Thu, 23 Aug 2018 13:31:03 +0200, Piotr Wyderski napisał(a):
> J.F. wrote:
>> A jakby tak dorzucic troche niepotrzebnego kodu, zeby razem wyszlo
>> duzo - to moze ten potrzebny bylby na poczatku ?
>
> Ale właściwie o czym jest ta rozmowa? Co wyprawia jakiś niszowy
> kompilatorek na jakiejś niszowej platformie? Ta informacja to już
> jest dostateczny powód, by do tego bagna nie wchodzić.

Niby tak, ale:
-on kiedys bylo dobry, wiec zapewne nadal jest,

-on troche kosztowal, ale jest darmowe demo,

... i to demo zlosliwie nie dziala :-)

O ile pamietam, to Keil mial jedna zalete - ujednolicil wskazniki.
Miales po prostu wskaznik i nie trzeba sie bylo zastanawiac, czy
wskazuje na IRAM, XRAM, PROM ...

Oczywiscie ta zaleta byla tez wadą - wydajnosc zapewne na tym
cierpiala, a wskaznik mial 3 bajty.

Tak czy inaczej - zapomniec.
A zeby nie kusilo - przywalic młotkiem :-)

J.

do góry

On 23.08.2018 13:27, Piotr Wyderski wrote:

> zaczynając. Zabawka dostępna na PIC wymaga dopłacenia ~800
> dolarów za włączenie optymalizacji, a i tak nie rozumie nawet

Optymalizacja jest, chociaż co prawda w darmowej wersji nie da się
włączyć wyższych poziomów. Ponoć jest jakiś "workaround", ale osobiście
nigdy nie czułem potrzeby zgłębiania tego tematu. Dostępne opcje w
zupełności wystarczały mi w amatorskich projektach. Współczesne MCU mają
na tyle flasha, że gdy uznawałem konstrukcję za "gotową", pozostawało
jeszcze sporo wolnej pamięci.


> Wygląda, tylko się nie kompiluje, bo matoł z Microchipa
> nie rozumie nawet, co dokładnie oznacza słowo "const" w C
> i jego kompilator odrzuca poprawne, trywialne programy.

Nigdy się z tym nie spotkałem. A zdarzało mi się już przenosić
biblioteki, które wcześniej wykorzystywałem na AVR, tudzież adaptować
biblioteki pożyczone z projektów na Arduino. Jedyne problemy na jakie
ewentualnie trafiłem wynikały z wykorzystania innego standardu języka C.
W tym wypadku zmiany można było bardzo łatwo wprowadzić.

Zgadzam się z tym, że STM32 ma sporo zalet. Nie powiedziałbym jednak, że
sytuacja z PIC32 jest tragiczna.

do góry