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

do góry

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

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

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

do góry

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

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

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-8)/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

do góry

W dniu 07.04.2016 o 17:37, badworm pisze:
> Dnia Thu, 7 Apr 2016 17:04:31 +0200, szod napisał(a):
>
>> To sprawdź ustawienia bitów konfiguracyjnych uC - na jakim oscylatorze
>> pracuje.
>
> 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)

F_CPU masz dobrze ustawione?


--
Pozdrawiam
Grzegorz

do góry

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

> F_CPU masz dobrze ustawione?

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

do góry

badworm pisze:
[..]
> #include "i2c.h"

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

do góry

W dniu 2016-04-07 o 20:02, AlexY pisze:
> badworm pisze:
> [..]
>> #include "i2c.h"
>
> 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.
> [..]
>
>
i2c masz sprzętowy czy softowy?
Mozesz pokazac biblioteki do TWI?

do góry

wchpikus pisze:
> W dniu 2016-04-07 o 20:02, AlexY pisze:
>> badworm pisze:
>> [..]
>>> #include "i2c.h"
>>
>> 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.
>> [..]
>>
>>
> i2c masz sprzętowy czy softowy?
> Mozesz pokazac biblioteki do TWI?

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

do góry

badworm <n...@p...pl> 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:

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

do góry

On Thu, 7 Apr 2016 17:37:01 +0200, badworm <n...@p...pl> wrote:
> NOP();

Co w tym jest?

--
Marek

do góry