Wydajność programu na AVR Mega 8 po aktualizacji GCC - co nie tak?

Fri Apr 08, 2016 4:37 pm   

pogadajmy o dokumentacji do avr-gcc...
ja znam jedną (której nie byłem w stanie przeczytać bo była tak
niechlujnie napisana): avr-libc-user_manual...
gdzie znajdę te wszystkie rozszerzenia gcc dla AVR?
istnieje jakiś w miarę kompletny tutorialek? doc?

Fri Apr 08, 2016 7:28 pm   

Dnia Fri, 8 Apr 2016 15:51:41 +0200, Grzegorz Niemirowski napisał(a):


Tak, to jest programowe I2C, na bazie bibliotek z kursu C, jaki był w
EdW już dosyć daawno temu. Wygląda na to, że najszybciej będzie mi
przejść na TWI, bo z tego, co widzę, to mam taką możliwość - odpowiednie
piny są do zagospodarowania. Programowe I2C zostawię sobie docelowo do
obsługi SHT11, bo ten układ zdaje się, że ma interfejs nie w pełni
kompatybilny z prawdziwym I2C, a wolne taktowanie SCL raczej nie
przeszkodzi.

Swoją drogą - spróbowałem manewru polegającego na skopiowaniu
odpowiedniego pliku nagłówkowego dla MEGA324PA z nowego GCC do starego,
z czystej ciekawości. Po zmianie wpisu o typie procesora w makefile
program się niby skompilował i nawet bez błędów, ale mam poważne
podejrzenia, że to tylko ściema. Nazwy rejestrów obsługujących np. porty
USART różnią się, więc nie ma siły, by nie było błędów na etapie
kompilacji - przerabiałem to kiedyś zmieniając MEGA 8 na MEGA162.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Fri Apr 08, 2016 10:26 pm   

badworm <nospam@post.pl> napisał(a):

Którego pliku i po co?


Z czego na co?


Trudno coś powiedzieć bez kodu. Zwykle robi się tak, że dołącza się plik
<avr/io.h>. W pliku tym są warunkowe dołączenia plików nagłówkowych danego
procesora na podstawie makra generowanego przez wybór danego mikrokontrolera
parametrem -mmcu:
#elif defined (__AVR_ATmega324PA__)
# include <avr/iom324pa.h>
Jak sobie na siłę dołączysz avr/iom324pa.h to się pewnie skompiluje
niezależnie od wyboru -mmcu.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 16 days, 22 hours, 57 minutes and 43 seconds

Sat Apr 09, 2016 6:42 am   

Dnia Sat, 9 Apr 2016 00:26:27 +0200, Grzegorz Niemirowski napisał(a):


Plik iom324pa.h w katalogu /avr/include/avr/ - to chyba w plikach tam
się znajdujących są definicje np. rejestrów we wszystkich obsługiwanych
typach procesorów.


# MCU name
MCU = atmega8

na

# MCU name
MCU = atmega324pa

Początek pliku main.c wygląda u mnie tak:

#include <avr\io.h>
#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
#include <avr\signal.h>
#include <avr\interrupt.h>
#include <avr\pgmspace.h>
#include <avr\eeprom.h>
#include <avr\delay.h>

A w wersji, która kompiluje się w najnowszym GCC bez błędów tak:

#include <avr\io.h>
#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
//#include <avr\signal.h>
#include <avr/interrupt.h>
#include <avr\pgmspace.h>
#include <avr\eeprom.h>
#include <util/delay.h>

Jak wspomniałem, kiedyś próba bezpośredniego przeniesienia kodu z Mega 8
na Mega 162 tylko poprzez zmianę przytoczonego wyżej wpisu w makefile
skończyła się błędami przy kompilacji, bo 162 ma dwa porty USART, a w
związku z tym inne są nazwy rejestrów, obsługujących ten interfejs.
Tutaj więc oczekiwałem podobnej reakcji, ale widzę iż zarówno nowe, jak
i stare GCC żadnych problemów nie zgłaszają :/

Z obsługą TWI mam chwilowo jakiś problem, przykładowe funkcje znalezione
w sieci (np. tutaj http://radzio.dxp.pl/twi/) choć są bardzo proste, to
chyba nie do końca mi działają. Mam wrażenie, że program się z jakiegoś
powodu wysypuje dokumentnie. Póki co zostawiam ten temat do ogarnięcia
na później, będę chciał najpierw przetestować funkcje obsługi TWI na
spokojnie a dopiero potem dodać je do docelowego programu. Najważniejsza
jest dla mnie teraz przesiadka na MEGA 324, bo z programowym I2C jakoś
to wszystko działa, a nie załaduję przecież kodu dla Mega 8 do większego
procka.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl

Sat Apr 09, 2016 11:23 am   

On 2016-04-07 15:58, badworm wrote:

Skompiluj:

DDRA = 0xff;

while(1)
{
PORTA = 0x00;
PORTA = 0xff;
}

I oceniaj częstotliwość na wyjściu. Powinno być bodaj f/4 bo cała pętla
zajmuje 4 cykle. Pozwoli to wyeliminować oczywisty problem z fuse bitami.


Sprawdź czy masz w ogóle -O1/2 jako flagi kompilacji.

Ponadto pamiętaj że zazwyczaj delay() jest pisana przez ignorantów i
wydziargana ręcznie aby działała na jakimś konkretnym kompilatorze.

Sat Apr 09, 2016 7:14 pm   

"badworm" <nospam@post.pl> wrote in message news:gw1gebsw4p3q.dlg@badworm.pl...

Jeśli TWI jest sprzętowe, to jednoznacznie wskazuje na oscylator.
W jakiś cudowny sposób CKDIV8 i/lubCKSELx są różne.
Ewentualnie można (zdaje się) z poziomu softu mnipulować zegarem.

Pozdr

Sun Apr 10, 2016 1:06 am   

PcmOl pisze:

załadowanie rejestru wewnętrznego zegara po inicjalizacji TWI
spowodowało że wyświetlacz przestał mi reagować lub pokazywał kaszanę.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

Sun Apr 10, 2016 9:57 am   

Dnia Sat, 9 Apr 2016 13:23:47 +0200, Sebastian Biały napisał(a):


Zegar jest ok. Wyjście, którego stan jest zmieniany w przerwaniu od
timera wywoływanym co 1 sekundę, działa jak trzeba niezależnie od tego,
którym kompilatorem skompiluję program.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Sun Apr 10, 2016 11:47 am   

On 2016-04-10 11:57, badworm wrote:

Więc szukaj:
a) problemów z jakimś delay(), prawdopodobnie jest napisana przez dyletanta
b) zainteresuj się czy przerwania "wyrabiają" się poprzez ich eliminacje
c) Zwróć uwagę czy aby na pewno poprawnie ustawiasz bity, np., stary gcc
mógł gdzieś dawać zero a nowy uninitialized w wyniku błedów w kodzie.
Sprawdź warningi.

Nie mialem problemów tego typu z kodem przy migracji gcc na avr i arm.
Zazwyczaj było lepiej lub tak samo poza corner cases jak liczenie
floatów gdzie często są bugi.

Sun Apr 10, 2016 12:21 pm   

badworm pisze:

Ale timer jest sprzętowy, jego przerwania muszą działać jak trzeba. Może
coś się zmieniło w programowym I2C i trzeba go inaczej
obsługiwać/inicjalizować.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

Sun Apr 10, 2016 4:29 pm   

mam taki szalony pomysł, może Ktoś spoza po napisać jak podejrzeć kod
assemblerowy na jaki została przetłumaczona problematyczna funkcja?

Sun Apr 10, 2016 5:10 pm   

On 2016-04-10 18:29, platformowe głupki wrote:

Niestety poza PO sami tumaniści. Prawdziwi iluminaci i powolni murarze
tylko w PO. Ale uchylę rąbka tajemnicy:

https://en.wikipedia.org/wiki/Objdump

Sun Apr 10, 2016 9:58 pm   

badworm <nospam@post.pl> napisał(a):

Czy mógłbyś wystawić gdzieś całość kodu?

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 18 days, 23 hours, 54 minutes and 41 seconds