Keil - sdcc (8051)

W dniu 22.08.2018 o 07:47, Karol Ryfer pisze:

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ć.

Ale co to za utrudnienie, jak wyrzucenie rozpychaczy z hexa jest banalne? Gorzej gdyby generował celowo rozepchniety (ale działający poprawnie) kod wynikowy, jak to robią toolsy mchp.

Kod dla 51 nie jest relokowalny (choćby call ma adres bezpośredni) a wykorzystanie zawijania adresu do 2kB raczej się nie uda, bo kompilator nie wstawia tablicy wektorów do tego segmentu przesuniętego o 2KB, tylko do segmentu zaczynającego się od 0, więc nie możesz po prostu przesunąć kodu o równe 2kB, tylko o (2kB - rozmiar tablicy wektorów).

Pytanie czy nie ma narzędzi, które przelecą ten kod i go zrelokują. Takie coś nie jest trudne do napisania (choć pracochłonne).

Będziesz miał problem, żeby odróżnić stałe zapisane w ROM od prawdziwych rozkazów. Ale jak jesteś kustoszem z zacięciem, to czemu nie.

Ja nie jestem, to Karol ma potrzebę :)

Co do odróżnienia stałych, to pytanie, gdzie te stałe są zapisane. Są wymieszane z kodem? Są zaraz za kodem i oddziela je jedynie flow programu, który nigdy ich nie wykonuje (co będzie trudne do wykrycia, jeśli CPU wspiera skoki pod adres podany w rejestrze a nie bezpośrednie)?

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

Pozdrawiam, Piotr

Byle nie zostać opiekunem sikieradek!

Dzięki

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

Zartujesz. To juz tylko do muzeum sie nadaje.

J.

Dnia Wed, 22 Aug 2018 08:09:41 +0200, Zbych napisał(a):

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

J.

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.

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.

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.

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

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

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.

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.

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.