AVR GCC lub inny.

Pewnego dnia Ania i Grześ przemówił ludzkim głosem:

Nie, projekt jest cały czas rozwijany.

Zależy co masz na myśli pisząc współpraca. Jeśli informacje dla debugera wygenerujesz w formacie dwarf-2, to da się to bez problemu wczytać w AVRStudio i debugować na poziomie kodu źródłowego.

Bo pewnie użyłeś printfa i zmiennego przecinka. Niestety nawet puts w wydaniu dla avr zajmuje jakieś koszmarne ilości pamięci, dlatego najlepiej jest napisać własne funkcje do wyświetlania stringów i zamiany liczb na ciąg ascii.

Dnia 2005-01-24 13:15, Zbych napisał(a):

No ostatnia aktualizacja to jakos Lipiec 2004. Biblioteki libc zmienily sie bardzo in plus:

Jako wspolpraca rozumiem mozliwosc pisania programow w C korzystajac ze srodowiska AVRStudio. Tak, jak bylo to mozliwe w AVRStudio 3.xx.xx.

Raczej tak sie stalo:

#include <90s2313.h>

#include <stdio.h>

#include <delay.h>

#asm .equ __w1_port=0x12 ;PORTD .equ __w1_bit=2 #endasm #include <1wire.h>

#include <ds1820.h>

#asm .equ __lcd_port=0x18 ;PORTB #endasm #include <lcd.h>

main() { int temp; char lcd_buffer[33]; PORTB=0x00; DDRB=0x00; PORTD=0x00; DDRD=0x70; TCCR0=0x00; TCNT0=0x00; TCCR1A=0x00; TCCR1B=0x00; TCNT1H=0x00; TCNT1L=0x00; OCR1H=0x00; OCR1L=0x00; GIMSK=0x00; MCUCR=0x00; TIMSK=0x00; ACSR=0x80;

w1_init(); lcd_init(16); lcd_clear();

while (1) { if (w1_init()) { temp = ds1820_temperature_10(0); lcd_gotoxy(0,0); lcd_putsf("Temperatura"); lcd_gotoxy(0,13); sprintf(lcd_buffer,temp/10); lcd_puts(lcd_buffer); delay_ms(1000); } else { lcd_clear(); lcd_putsf("Blad"); } }; }

o tak, printf, nawet w najbiedniejszej postaci, zajmuje sporo flasha :(.

Pewnego dnia Ania i Grześ przemówił ludzkim głosem:

Wystarczy, że ściągniesz najnowsze libc i skompilujesz, "zainstalujesz". Pytanie tylko czy potrzebujesz obsługi tych najnowszych procesorów ?

W wersji 4 AVRStudio MSZ się nie da. Zresztą programmers notepad, który jest w pakiecie WinAvr jest naprawdę dobry (choć udało mi się go już wykrzaczyć).

^^^^^^^^^^^^^^^^^^^^^^^ tu _może_ być winowajca

Sprawdź raport po linkowaniu i zobacz jakie procedury ile miejsca zajmują.

Zamiast połączenia sprintf i dzielenia ze znakiem (linia, którą podkreśliłem) użyłbym procedury z noty aplikacyjnej

Mozna wypróbować np.

Tylko nie wiem, czy lipcowe WinAvr ma zaszytą obsługę wszystkich nowości ujętych w avr-libc ( na pewno jest błąd mnożenia dla attiny 13 i 2313 ).

Dnia 2005-01-24 18:26, Jurek Szczesiul napisał(a):

Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

Apache/1.3.27 Server at avrfiles.luna.kyed.com Port 80

I na probowaniu sie zakonczylo, bo google milczy podajac nazwe pliku :)

Tydzien temu skompilowalem sobie avr-gcc4.0 i cala tego otoczke. (poprawiony bug z Attiny13 i Attiny2313) Wystawilem to dzisiaj na

Umnie zrobilem poprostu tak ze wrzucilem to do katalogu winavr nadpisujac pliki. Wg mnie dziala ok. ale nie jestem tego w 100% zagwarantowac.

Z moich obserwacji (gdzies to na necie tez przeczytalem) wynika ze linker dla avr-gcc (a moze i nietylko) nie wyrzuca NIEUZYWANEGO kodu z pliku wynikowego. Co powoduje wlasnie tak wielkie rozrastanie sie kodu, ktory nic nie robi.

Pozdrawiam Willy.

Mon, 24 Jan 2005 20:04:18 +0100, na pl.misc.elektronika, Ania i Grześ napisał(a):

Sorry :-( nie sprawdzałem osobiście - to namiar wzięty z avrfreaks.

Mon, 24 Jan 2005 20:32:20 +0100, na pl.misc.elektronika, Willy napisał(a):

Czy musiałeś jakoś dodatkowo patchować czy 4.0 poszedł bez bólu ? Mnie na lekko wcześniejszym mingwie wszystkie snapshoty 4.0 regularnie się wywracają.

Dokładnie to jest tak, że linker avr-ld jeśli znajduje jakąś funkcję skompilowaną do pliku relokowalnego *.o to zawsze dołącza cały kod z pliku, niezależnie od jego wykorzystania. Radą na to jest składanie bibliotek z małych pliczków relokowalnych zawierających pojedyncze funkcje. Wtedy unikamy takiego balastu. Avr-libc jest właśnie tak przygotowane i ten efekt jest zminimalizowany - gorzej jeśli korzystamy z jakichś dodatkowych bibliotek skompilowanych bez zwrócenia na to uwagi .

Jurek Szczesiul napisał(a):

Toszkę musiałem z tym powalczyć ale udało mi się. Przedewszystkim trzeba gcc budowac w podkatalogu jakimś, inaczej sie wywala na samiutkim początku. Potem pojawiły sie problemy z jakimiś liczbami 32 bitowymi których niema obsługi w avr-gcc, ale znalazłem tymczasowy patch na bugzilli który to poprawia to. Ostatni problem polega na tym że gdy buduje się kompilator w podkatalogu ... niemoże on kilku includow znaleźć z config/avr. Lekarstwem na to jest podlikowanie tych kilku plików w odpowiednie miejsca.

Generelnie 4 dni walczyłem z tym, ale wkońcu się udało :D Jakbyś był zainteresowany to jak wrócę z pracy poszukam linka do tych patchy (ręcznie je trzeba nanieść) albo poszukaj w bugzilli pod hasłem avr data chyba z okolic 5 stycznia - ale mogę się mylić !

Pozdrawiam Willy.

bo i skąd ma wiedzieć, że dany kod nie będzie używany? dostaje binaria i nie wie, czy to przypadkiem nie jest kod asemblerowy, który napisano tak, że wyrzucenie kawałka kodu rozwali skoki względne, albo że któryś symbol nie jest nieużywaną funkcja tylko tablicą danych?

inna sprawa, że użycie printf() faktycznie może dodać całe mnóstwo kodu, którego nie będziesz używał, chociażby do wyświetlania liczb zmiennoprzecinkowych. dlatego w avr-libc są różne warianty funkcji printf().

w.

Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:

Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany, tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej funkcji). I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma takiej funkcjonalności.

Bo to chyba obowiazuje dla bibliotek a nie poszczegolnych obj.

W obj to chyba nawet nie bardzo ma mozliwosci wyselekcjonawania poszczegolnych funkcji - jest symbol i jest jego adres, nie ma "dlugosci kodu".

J.

Użytkownik Zbych napisał:

Nie może mieć. Funkcje wywołuje się nie tylko jawnie, ale np. przez wskaźnik zawarty w zmiennej. A tą zmienną mogę ustawić na wartość powodującą wywołanie tej "nieużywanej" funkcji sporo po kompilacji.

Albert

Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:

Masz rację. Ale i na to znalazłaby się rada. Nikt przecież nie wpisuje ręcznie adresu funkcji do wskaźnika, tylko zleca uzupełnienie tego adresu linkierowi (bo na etapie kompilacji adres funkcji nie musi być znany). Czyli linkier może sprawdzić, czy gdzieś nie musi wstawić adresu funkcji, a jeśli musi to stawia parafkę "ta funkcja jest potrzebna".

Ale wartosc do ustawienia musi ci linker wstawic, wiec wie ze odwolanie jest.

J.

Sprawdza, nazywa sie to "dead code elimination" i jest przeprowadzane przez optymalizator, jesli potrafi on udowodnic, ze dla danego zbioru parametrow nie istnieje sciezka przeplywu sterowania prowadzaca do tego kodu. Ale oczywiscie nie jest to az tak rozbudowane, by umiec wyrzucic pewne fragmenty kodu z printf(), tu masz racje.

Pozdrawiam Piotr Wyderski

Nie mozesz, bo bez wskazania nazwy tej funkcji nie bedziesz znal jej adresu, a takie wskazanie wystarcza do stwierdzenia, ze funkcja moze byc uzywana, wiec jej eliminacja jest niedozwolona.

BTW, to bardzo dziwne co mowicie o tym linkerze, w "pelnym" GCC jest przeprowadzana eliminacja nieuzywanych funkcji.

Pozdrawiam Piotr Wyderski

Pewnego dnia J.F. przemówił ludzkim głosem:

Prawdopodobnie masz rację. Przejrzałem trochę pliki *.lst *.map *.lss i w żadnym z nich nie ma informacji o długości (a pewnie by była gdyby takie informacje były zawarte w plikach *.o). W takim wypadku należałoby ustawić adresy funkcji rosnąco i obliczać rozmiar na podstawie adresu funkcji i adresu następnej funkcji (a w przypadku ostatniej funkcji rozmiaru biblioteki).