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

Thu Apr 07, 2016 1:58 pm   

To znów ja, i pewnie znów z problemem, który ma jakieś banalne
rozwiązanie. Postawnowiłem się w końcu przesiąść z mocno już leciwego
GCC AVR (pakiet WinAVR) w wersji 20050214 na najnowszą jaka jest
dostępna. Program na Mega 8, napisany na starej wersji, skompilował się
bez błędów i ostrzeżeń (te dotyczące innego umiejscowienia niektórych
bibliotek jak signal.h skrupulatnie wypełniłem). Niestety w rzeczywistym
układzie jest totalna porażka - urządzenie zachowuje się, jakby nie było
taktowane kwarcem 8MHz, lecz co najwyżej 10kHz. Cały program wykonuje
się koszmarnie wolno, np. dane na wyświetlacz OLED wysyłane po I2C
pojawiają się teraz znak po znaku, a wcześniej następowało to bez
widocznego opóźnienia.

Coś się pozmieniało w bibliotekach, czy w w makefile powinienem coś
dopisać bądź zmienić?
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Thu Apr 07, 2016 3:04 pm   

W dniu 2016-04-07 o 15:58, badworm pisze:


To sprawdź ustawienia bitów konfiguracyjnych uC - na jakim oscylatorze
pracuje.

Thu Apr 07, 2016 3:37 pm   

Dnia Thu, 7 Apr 2016 17:04:31 +0200, szod napisał(a):


Kompilator do fusebitów raczej dostępu nie ma. Przed chwilą porównałem
prędkość zegara I2C dla wsadów z obu kompilatorów. Różnica jest
kolosalna - dla nowego GCC to zaledwie 5kHz, dla starego ponad 80kHz.
Kod generujący opóźnienia dla tej magistrali wygląda tak:

#include <avr\io.h>
#include <inttypes.h>

#include "harddef.h"
#include "makra.h"
#include "i2c.h"

// Wyliczenie czasu opóźnienia połówkowego i ćwiartkowego (cykle)
#define I2C_nhalf (F_CPU/I2C_SPEED/2)

// Funkcja dłuższych opóźnień
#if I2C_nhalf < 3
// Nic
#elif I2C_nhalf < 8
static void i2c_xdelay(void)
{
NOP();
}
#else
#define I2C_delayloops (1+(I2C_nhalf-/3)
#if I2C_delayloops > 255
#error Przyspiesz - bo sie nie wyrabiam
#endif
static void i2c_xdelay(void)
{
asm volatile( \
"delayus8_loop%=: \n\t"\
"dec %[ticks] \n\t"\
"brne delayus8_loop%= \n\t"\
: :[ticks]"r"(I2C_delayloops) );
}
#endif //I2C_nhalf >= 3

// Opóźnienia dla I2C
static inline void i2c_hdelay(void)
{
#if I2C_nhalf < 1
return; // To jest funkcja inline, jeśli składa się tylko z "return"
jest usuwana podczas optymalizacji
#elif I2C_nhalf < 2
NOP();
#elif I2C_nhalf < 3
asm volatile(
"rjmp exit%=\n\t"
"exit%=:\n\t":;
#else
i2c_xdelay();
#endif
}
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Thu Apr 07, 2016 4:12 pm   

W dniu 07.04.2016 o 17:37, badworm pisze:

F_CPU masz dobrze ustawione?


--
Pozdrawiam
Grzegorz

Thu Apr 07, 2016 5:01 pm   

Dnia Thu, 7 Apr 2016 18:12:39 +0200, Grzegorz Kurczyk napisał(a):


Tak, F_CPU = 8000000. Rzecz polega na tym, że dokładnie ten sam projekt
skompilowany na starym GCC chodzi prawidłowo, a na nowym - muli się.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Thu Apr 07, 2016 6:02 pm   

badworm pisze:
[..]

Ja nie szprecham w C więc może się mylę, czy Ty nie używasz sprzętowego
I2C ? Atmega 8 ma takowy i działa znakomicie.
[..]


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

Fri Apr 08, 2016 6:58 am   

W dniu 2016-04-07 o 20:02, AlexY pisze:

Mozesz pokazac biblioteki do TWI?

Fri Apr 08, 2016 10:51 am   

wchpikus pisze:

Komu odpisujesz? Bo to raczej nie do mnie pytanie.


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

Fri Apr 08, 2016 1:51 pm   

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

Może to jest kwestia optymalizacji? Czy nie lepiej te opóźnienia generować z
pomocą timera lub też funkcjami bibliotecznymi? Rozumiem, że to jest
programowe I2C i nie możesz użyć sprzętowego?

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

Fri Apr 08, 2016 2:53 pm   

On Thu, 7 Apr 2016 17:37:01 +0200, badworm <nospam@post.pl> wrote:

Co w tym jest?

--
Marek

Fri Apr 08, 2016 4:07 pm   

czyli co, napisałeś program, a kompilator przerobił go sobie na jakiś
inny? dobrze, że nawet nie starałem się pojąć sukcesu kompilatora gcc...

Fri Apr 08, 2016 4:12 pm   

platformowe głupki <NOSPAMtestowanije@go2.pl> napisał(a):

Nic niezwykłego. Z optymalizacjami namęczyłem się trochę portując swój stary
kod z IAR do GCC. Ostatnio też poznałem opcję -fsigned-char, bo okazało się,
że znakowość dla char jest nieokreślona w standardzie i na ARM jest inaczej
implementowana niż gdzie indziej.

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

Fri Apr 08, 2016 4:19 pm   

ale dlaczego tak się dzieje, przeciez jest jakaś norma na język C,
czemu te wstawki dla AVR są takie pojebane, jakieś totalne idiotyzmy jak
się czyta avr-libc-user_manual... i wszyscy sobie to niby chwalą... dla
mnie nie ma czego...

Fri Apr 08, 2016 4:31 pm   

platformowe głupki <NOSPAMtestowanije@go2.pl> napisał(a):

Właśnie podałem przykład gdy norma pozostawia coś bez doprecyzowania:
The three types char, signed char, and unsigned char are collectively called
the character types. The implementation shall define char to have the same
range, representation, and behavior as either signed char or unsigned char.
....
Irrespective of the choice made, char is a separate type from the other two
and is not compatible with either.
-ISO 9899:1999, sekcja "6.2.5 Types"


A są?


To jest całkiem dobry kompilator. Może nie idealny, ale całkiem w porządku i
za darmo.

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

Fri Apr 08, 2016 4:35 pm   

no nie wiem, cały czas odnoszę wrażenie że to jedna wielka prowizorka...