"badworm" <n...@p...pl> wrote in message news:gw1gebsw4p3q.dlg@badworm.pl...
> 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.

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

do góry

PcmOl pisze:
>
> "badworm" <n...@p...pl> wrote in message
> news:gw1gebsw4p3q.dlg@badworm.pl...
>> 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.
>
> 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.

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

do góry

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

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

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

do góry

On 2016-04-10 11:57, badworm wrote:
> 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.

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.

do góry

badworm pisze:
> Dnia Sat, 9 Apr 2016 13:23:47 +0200, Sebastian Biały napisał(a):
>
>> 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.
>
> 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.

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

do góry

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

do góry

On 2016-04-10 18:29, platformowe głupki wrote:
> mam taki szalony pomysł, może Ktoś spoza po napisać jak podejrzeć kod
> assemblerowy na jaki została przetłumaczona problematyczna funkcja?

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

do góry

badworm <n...@p...pl> napisał(a):
> 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.

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

do góry