RTV forum PL | NewsGroups PL

Problemy z rozmiarem pliku BIN w Keil uVision 8051 dla AT89C2051 - co sprawdzić?

Keil - sdcc (8051)

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Problemy z rozmiarem pliku BIN w Keil uVision 8051 dla AT89C2051 - co sprawdzić?

Goto page 1, 2  Next

Karol Ryfer
Guest

Wed Aug 22, 2018 5:47 am   



Witam

Użyłem w końcu sdcc 8051, ale wcześniej próbowałem w Keil uVision 8051
(v5.25.3.0 - najnowsza):
-------------------------------
#include <REG2051.H>

unsigned char x;

void main (void) {

x = 1;
while(1);

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

P.S. Rady o zastosowaniu innego procka - niepotrzebne.

Zbych
Guest

Wed Aug 22, 2018 6:09 am   



W dniu 22.08.2018 o 07:47, Karol Ryfer pisze:
Quote:
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ć.

Marek
Guest

Wed Aug 22, 2018 6:46 am   



On Wed, 22 Aug 2018 08:09:41 +0200, Zbych <abuse@onet.pl> wrote:
Quote:
Celowe działanie Keila, żebyś wersji demo nie używał do małych
procków.

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.

--
Marek

Zbych
Guest

Wed Aug 22, 2018 7:00 am   



W dniu 22.08.2018 o 08:46, Marek pisze:
Quote:
On Wed, 22 Aug 2018 08:09:41 +0200, Zbych <abuse@onet.pl> wrote:
Celowe działanie Keila, żebyś wersji demo nie używał do małych procków.

Ale co to za utrudnienie, jak wyrzucenie rozpychaczy z hexa jest
banalne?

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

Queequeg
Guest

Wed Aug 22, 2018 1:13 pm   



Zbych <abuse@onet.pl> wrote:

Quote:
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).

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

Zbych
Guest

Wed Aug 22, 2018 1:45 pm   



W dniu 22.08.2018 o 13:13, Queequeg pisze:
Quote:
Zbych <abuse@onet.pl> wrote:

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.

Queequeg
Guest

Wed Aug 22, 2018 4:20 pm   



Zbych <abuse@onet.pl> wrote:

Quote:
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)?

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

Piotr Wyderski
Guest

Wed Aug 22, 2018 8:19 pm   



Marek wrote:

Quote:
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.

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

Pozdrawiam, Piotr

Włodzimierz Wojtiuk
Guest

Wed Aug 22, 2018 9:02 pm   



On 2018-08-22 22:19, Piotr Wyderski wrote:
Quote:
Marek wrote:

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.

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

Byle nie zostać opiekunem sikieradek!

https://www.youtube.com/watch?v=sKYaWtsGQac&ab_channel=KabaRetyHD

Włodek

Karol Ryfer
Guest

Thu Aug 23, 2018 5:04 am   



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


Dzięki

Atlantis
Guest

Thu Aug 23, 2018 5:44 am   



On 22.08.2018 22:19, Piotr Wyderski wrote:

Quote:
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.

Piotr Wyderski
Guest

Thu Aug 23, 2018 7:08 am   



Atlantis wrote:

Quote:
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

J.F.
Guest

Thu Aug 23, 2018 9:14 am   



Dnia Thu, 23 Aug 2018 07:44:32 +0200, Atlantis napisał(a):
Quote:
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.

J.F.
Guest

Thu Aug 23, 2018 9:16 am   



Dnia Wed, 22 Aug 2018 08:09:41 +0200, Zbych napisał(a):
Quote:
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.

Atlantis
Guest

Thu Aug 23, 2018 10:18 am   



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

Quote:
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.

Goto page 1, 2  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Problemy z rozmiarem pliku BIN w Keil uVision 8051 dla AT89C2051 - co sprawdzić?

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map