Jak zmniejszyć *.HEX'a

SACZI · Postautor: **SACZI** » 21 mar 2004, o 19:15

Witam szanownych Forumowiczów!
Nie jestem jakimś specjalista od programowania i dlatego chcę Was zapytać o radę.

#include <ADUC812.H>
#include <stdio.h>

void main (void)
{
SCON  = 0x50;
TMOD |= 0x20;
TH1   = 0xA0;
TR1   = 1;
TI    = 1;

ADCCON1 = 0x7C;     // 0111 1100

while (1)
  {
    int channel;
    channel=123;
    printf("liczba to:  %d", channel);
  }

}

Piszę kod jak powyżej, a Keil kompiluje mi go i tworzy HEXa o wielkości ... 3.12 kB. Jak ten kod przepisać, żeby sie zmniejszył np 10x (wiem, że to jest mozliwe). Podejrzewam, że jego wielkość jest spowodowana funkcję printf.

radzio · Postautor: **radzio** » 22 mar 2004, o 08:07

Masz rację, to wina printf. Funkcja ta standardowo zajmuje bardzo dużo miejsca. Jedyne wyjście to napisanie jej "po swojemu", gdyż te oferowane przez kompilatory zawierają dużo niepotrzebnego kodu.

SACZI · Postautor: **SACZI** » 22 mar 2004, o 13:04

Próbowałem to robić również, przez SBUF, ale jakoś nie chciało mi działac.
Jakies pomysły ?

Guru · Postautor: **Guru** » 22 mar 2004, o 15:06

Cały czas powtarzam asembler, asembler,
ale każdy zaczyna programować od C lub bascoma i oto są efekty, byle kawałek kodu i tyle problemów.

gawel · Postautor: **gawel** » 23 mar 2004, o 08:49

Właśnie, coś takiego w asm zajęłoby drobny procent tego co bierze C. Spróbój samemu dokonać konwersji liczby na łańcuch znaków i wysłać wynik przez układ szeregowy (nie używać printf).

SACZI · Postautor: **SACZI** » 23 mar 2004, o 10:05

Niekoniecznie, nie ma potrzeby aż tak radykalnie zmieniać jezyka programowania. Taki program napisany w C z wykorzystaniem SBUF zajmuje kilkanaście bajtów HEXa.
Tylko nie wiem dlaczego nie działa mi to na ADuC

gawel · Postautor: **gawel** » 23 mar 2004, o 10:39

Co znacza, że nie działa? Czy jest cisza na wyjściu UARTA?
Czy może jest nezgodność parametrów transmisji?

SACZI · Postautor: **SACZI** » 23 mar 2004, o 16:28

Nie działa, znaczy, że nie odbieram tego na PC.

gawel · Postautor: **gawel** » 24 mar 2004, o 08:31

Jak nie odbierasz tego na PC, to nie znacze, że nie działa. Należy mieć pewność (obejrzeć na oscyloskopie lub w najprostszym wypadku przyłączyć diodę LED + opornik między +5V i sygnał - jak będzie świcić, to znaczy, że transmituje).

SACZI · Postautor: **SACZI** » 25 mar 2004, o 10:50

Nie działało, bo prawdopodobnie coś sknociłem z konfiguracją UART

.

Mam jeszcze jedno pytanie odnośnie plików HEX. Własnie tworzę sobie nowy programik, w którym, na razie jest tylko konfiguracja UART i ADC. Ustawiam tylko bity w rejestrach i wywołuje te funkcje w programia głównym!! HEX w tym momencie wynosi juz 203 bajty!!
Jaka jest rzeczywista wielkość kodu wykonywanego przez procesor, jak z wielkości HEXa zorientować się o rozmiarze kodu ??
No i wreszcie, gdzie jest ta oszczędność pamięci programów pisanych w C (TYLKO 15% większa niż w ams).

gawel · Postautor: **gawel** » 25 mar 2004, o 11:24

Wielkość kodu jest trochę mniejsza niż połowa wielkości pliku hex. Wynika to z tego, że bajt programu jest w pliku reprezentowany przez dwa znaki hex. Do tego należy dodać znaki zawarte w pliku służące do określania rodzaju bloków danych oraz znaki przewidziane na sumy kontrole. Chcąc przekonać się o rzeczywistej wielkości kodu najprościej jest przekonwertować program z formatu hex do formatu binarnego, który zawiera jedynie dane do zaprogramowania (jeden bajt w pliku odpowiada jednemu bajtowi do zaprogramowania) i sprawdzić jego wielkość.
Oszczędność programowania w C wynika głównie z oszczędności czasu poświęconego na opracowanie programu (choć sprawa może być dyskusyjna). Kompilatory C generalnie produkują większy kod wynikający z treści programu. Do tego należy dodać standardowe funkcje biblioteczne dołączone do programu oraz tzw startup (kod rozruchowy). To że napiszesz w C program dwa razy większy nie spowoduje, że wygenerowany kod będzie też dwa razy większy.

Guru · Postautor: **Guru** » 27 mar 2004, o 16:22

Otóż właśnie to w C gdy wywoływana jest jakaś procedura, to miedzy innymi, wiąże się z tym (w zależności od kompilatora mniej lub bardziej inteligentnego) odkładanie na stos wszystkich używanych w procedurze komórek, i tak np. wywołując procedurę która korzysta z rejestrów od R0 do R7, akumulatora otrzymujemy kod:
(przykład dla 8051)
push RSW
push ACC
push 00h
push 01h
push 02h
push 03h
push 04h
push 05h
push 06h
push 07h
........
wykonywana procedura
.........
pop 07h
pop 06h
pop 05h
pop 04h
pop 03h
pop 02h
pop 01h
pop 00h
pop ACC
pop RSW
pomimo że nie zależy nam na zawartości tych rejestrów aby była zapamiętana podczas wykonania procedury. Jak widać kilka takich procedur jedna w drugiej i stos leci do nieba, lub też pozostaje nam ręczne grzebanie w skompilowanym do asmebla kodzie a to nie jest już takie przyjemne.
Życzę więc łatego wyboru: asembler czy C, oto jest pytanie

Jak zmniejszyć *.HEX'a

cały czas powtarzam

Otóż właśnie to

Kto jest online