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

do góry

platformowe głupki <N...@g...pl> napisał(a):
> czyli co, napisałeś program, a kompilator przerobił go sobie na jakiś
> inny? dobrze, że nawet nie starałem się pojąć sukcesu kompilatora gcc...

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

do góry

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

do góry

platformowe głupki <N...@g...pl> napisał(a):
> ale dlaczego tak się dzieje, przeciez jest jakaś norma na język C,

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"

> czemu te wstawki dla AVR są takie pojebane,

A są?

> jakieś totalne idiotyzmy jak się czyta avr-libc-user_manual... i wszyscy
> sobie to niby chwalą... dla mnie nie ma czego...

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

do góry

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

do góry

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?

do góry

Dnia Fri, 8 Apr 2016 15:51:41 +0200, Grzegorz Niemirowski 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?

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

do góry

badworm <n...@p...pl> napisał(a):
> Swoją drogą - spróbowałem manewru polegającego na skopiowaniu
> odpowiedniego pliku nagłówkowego dla MEGA324PA z nowego GCC do starego,

Którego pliku i po co?

> z czystej ciekawości. Po zmianie wpisu o typie procesora w makefile

Z czego na co?

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

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

do góry

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

> Którego pliku i po co?

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.

> Z czego na co?

# MCU name
MCU = atmega8

na

# MCU name
MCU = atmega324pa
> 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.

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

do góry

On 2016-04-07 15:58, badworm wrote:
> pojawiają się teraz znak po znaku, a wcześniej następowało to bez
> widocznego opóźnienia.

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.

> Coś się pozmieniało w bibliotekach, czy w w makefile powinienem coś
> dopisać bądź zmienić?

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.

do góry