Dobry wieczór wszystkim

Na wstępie swego wywodu zaznaczam, że nie chcę wywoływać ideologicznych
sporów, zależy mi tylko na merytorycznej dyskusji.:-)

Sprawa ma sie następująco; od wielu lat programowałem uC ze stajni
Microchipa, wcześniej 8080,Z80,51.

PIC jest ok, ma fajne peryferia, etc.

Od jakiegoś czasu zacząłem jednak kleić większe programy, często
wykorzystujące jakieś fragmenty ściągnięte z internetu + własne archiwalne z
innych czasów i platform (np. 51).
Zawsze starałem się stosować do ANSII C.
Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
nowsze wersje, obecnie to chyba jest Microchip) powoduje różne nieoczekiwane
efekty, np. starsza wersja kompiluje OK; nowsza źle, lub odwrotnie.
Działanie programu zależy od wersji kompilatora, starszą wersją działa,
nowszą nie, lub odwrotnie.
Prawdę mówiąc, jest to trochę irytujące.
O ile program się pisze 'od zera' to mozna kombinować aby go uruchomić, ale
jeśli wykorzystuje się kod źródłowy pisany kiedyś lub pisany przez kogoś
innego, to raczej słabo.

Czy Koledzy programujący uC również coś takiego zauważyli?

Prawdę mówiąc skłania mnie ta sytuacja do przesiadki na AVR, który jak sie
wydaje jest bardziej przyjazny dla kompilatora (jest na niego gcc)

Proszę o jakieś opinie.

Pozdrawiam
jp

do góry

jacek pozniak wrote:

> Dobry wieczór wszystkim
>
> Na wstępie swego wywodu zaznaczam, że nie chcę wywoływać ideologicznych
> sporów, zależy mi tylko na merytorycznej dyskusji.:-)
>
> Sprawa ma sie następująco; od wielu lat programowałem uC ze stajni
> Microchipa, wcześniej 8080,Z80,51.
>
> PIC jest ok, ma fajne peryferia, etc.
>
> Od jakiegoś czasu zacząłem jednak kleić większe programy, często
> wykorzystujące jakieś fragmenty ściągnięte z internetu + własne archiwalne
> z innych czasów i platform (np. 51).
> Zawsze starałem się stosować do ANSII C.
> Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
> nowsze wersje, obecnie to chyba jest Microchip) powoduje różne
> nieoczekiwane efekty, np. starsza wersja kompiluje OK; nowsza źle, lub
> odwrotnie. Działanie programu zależy od wersji kompilatora, starszą wersją
> działa, nowszą nie, lub odwrotnie.
> Prawdę mówiąc, jest to trochę irytujące.
> O ile program się pisze 'od zera' to mozna kombinować aby go uruchomić,
> ale jeśli wykorzystuje się kod źródłowy pisany kiedyś lub pisany przez
> kogoś innego, to raczej słabo.
>
> Czy Koledzy programujący uC również coś takiego zauważyli?
>
> Prawdę mówiąc skłania mnie ta sytuacja do przesiadki na AVR, który jak sie
> wydaje jest bardziej przyjazny dla kompilatora (jest na niego gcc)
>
> Proszę o jakieś opinie.

Nie znam się na PICach, więc nie będę się na ten temat wypowiadać, ale jeśli
zależy Ci na darmowym kompilatorze z porządnym wsparciem to polecam uwadze
MSP430. TI objęło jakiś czas temu opiekę nad portem gcc, nowa wersja Code
Composer Studio ma oficjalnie wspierać gcc. Można się spodziewać że każdy
nowy procesor będzie miał wsparcie od pierwszego dnia kiedy będzie dostępny.

pzdr.
j.

do góry

W dniu 04.04.2014 00:07, jacek pozniak pisze:

> Zawsze starałem się stosować do ANSII C.
> Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
> nowsze wersje, obecnie to chyba jest Microchip) powoduje różne nieoczekiwane
> efekty, np. starsza wersja kompiluje OK; nowsza źle, lub odwrotnie.
> Działanie programu zależy od wersji kompilatora, starszą wersją działa,
> nowszą nie, lub odwrotnie.

Jak pokażesz konkretny kawałek kodu, to wtedy można dyskutować czy kod,
czy kompilator jest do dupy. Bez tego to mogę ci polecić tylko wizytę u
najbliższej wróżki.

do góry

Muszę Cię rozczarować, w AVR-ach też różowo nie ma.
Systematycznie pojawiają się posty na różnych forach
że program napisany w AVR Studio 4 nie działają, działają
źle lub w ogóle się nie kompilują w ATMEL STUDIO 6.

do góry

Zbych wrote:

> W dniu 04.04.2014 00:07, jacek pozniak pisze:
>
>> Zawsze starałem się stosować do ANSII C.
>> Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
>> nowsze wersje, obecnie to chyba jest Microchip) powoduje różne
>> nieoczekiwane efekty, np. starsza wersja kompiluje OK; nowsza źle, lub
>> odwrotnie. Działanie programu zależy od wersji kompilatora, starszą
>> wersją działa, nowszą nie, lub odwrotnie.
>
> Jak pokażesz konkretny kawałek kodu, to wtedy można dyskutować czy kod,
> czy kompilator jest do dupy. Bez tego to mogę ci polecić tylko wizytę u
> najbliższej wróżki.
Problem polega na czymś innym.


Np. mam kod, w sumie, 3tys linii, który jest działający (wiem, że to może
być przypadek, że działa).
Następnie dopisuję prostą funkcję, przetestowaną na PC za pomocą gcc;
kompilator(linker) zgłasza mi, że nie może coś tam pamięci znaleźć (mimo że
wcześniej kompilował i wykorzystywał 20% ram, procesor PIC18, 3,5kB ram).
No i się zaczyna kombinowanie, przenoszenie zmiennych globalnych na lokalne
i na odwrót (dobrze, że w PIC18 nie trzba banków deklarować). OK program się
kompiluje ale rzeczona funkcja nie działa poprawnie.
Następnie ściągam kompilator XC8 (60 dniowy) i program się kompiluje i
działa poprawnie (przynajmiej takie mam wrażenie).

Ja wiem, że ponad 99% przypadków niedziałania programu w C to wina
programisty ale martwią mnie takie akcje gdzie linker coś sygnalizuje a ty
się martw o co mu chodzi i kombinuj.

Coraz bardziej skłaniam się ku twierdzeniu, że architektura PIC16, PIC18
(wyższych nie znam) nie pasuje do języka C i w związku z tym ciężko jest
napisać kompilator.

jp

do góry

On Fri, 04 Apr 2014 00:07:59 +0200, jacek pozniak
<j...@f...pl> wrote:
> Czy Koledzy programujący uC również coś takiego zauważyli?

Nie, ponieważ nie zmieniam kompilatora używanego latami,
przetestowanego na wszelkie możliwe sposoby i działającego prawidłowo
(C18} nagle na inny (XC8) bo microchip się nagle zorientował, że ma
mało produktów w ofercie zawierających "X" w nazwie i musiał stworzyć
coś nowego i "lepszego". Jeśli microchip przestanie produkować układy
wspierane przez C18, to zmienię architekturę na coś z poza microchip.
Jeśli programujesz pice 18f używaj C18, jeśli pic32 skompiluj sobie
gcc ze źródeł dostępnych na stronach microchip.

--
Marek

do góry

On Fri, 04 Apr 2014 09:08:26 +0200, jacek pozniak
<j...@f...pl> wrote:
> Coraz bardziej skłaniam się ku twierdzeniu, że architektura PIC16,

Oznaczenie marketingowe produktu, które podałeś nie jest oznaczeniem
architektury (często mylnie podawane), architektura układów
oznaczonych PIC16 F* to pic14 (14 bitowa dlugość rozkazu) a PIC18 F*
to architektura pic16 (16 bitowy rozkaz).
Jeśli chodzi o układy arch. pic16 (oznaczone jako PIC18F*) to były
specjalnie projektowane pod kątem użycia kompilatora C, natomiast
pic14 nie. Oczywiście można złośliwie powiedzieć, że były
projektowane pod C18 (lub na odwrót), który taki strict ansi C nie
jest (trzeba się np. przyzwyczaić, że zmienna wskaźnikową do ram nie
można użyć do wskazywania rom itp).
Jedynie ci Ci mogę polecic to używanie C18 dla arch. pic16. XC8 jest
zbyt świeży, aby stwierdzić teraz jego "długoterminową przydatność do
użycia".

--
Marek

do góry

> pic14 nie. Oczywiście można złośliwie powiedzieć, że były
> projektowane pod C18 (lub na odwrót), który taki strict ansi C nie
> jest (trzeba się np. przyzwyczaić, że zmienna wskaźnikową do ram nie
> można użyć do wskazywania rom itp).
To jak sobie poradzić z ROMem?
Używać TBLRD, TBLWR, TBLADR, TABLAT, TBLPTRU:H:L?
S.

do góry

> Jak pokażesz konkretny kawałek kodu, to wtedy można dyskutować czy kod,
> czy kompilator jest do dupy. Bez tego to mogę ci polecić tylko wizytę u
> najbliższej wróżki.
Binarnie to są jeszcze 2 kobinacje.
Obie mogą nie być "winą" programisty.
S.

do góry

W dniu 04.04.2014 09:08, jacek pozniak pisze:
> Zbych wrote:
>
>> W dniu 04.04.2014 00:07, jacek pozniak pisze:
>>
>>> Zawsze starałem się stosować do ANSII C.
>>> Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
>>> nowsze wersje, obecnie to chyba jest Microchip) powoduje różne
>>> nieoczekiwane efekty, np. starsza wersja kompiluje OK; nowsza źle, lub
>>> odwrotnie. Działanie programu zależy od wersji kompilatora, starszą
>>> wersją działa, nowszą nie, lub odwrotnie.
>>
>> Jak pokażesz konkretny kawałek kodu, to wtedy można dyskutować czy kod,
>> czy kompilator jest do dupy. Bez tego to mogę ci polecić tylko wizytę u
>> najbliższej wróżki.
>
> Problem polega na czymś innym.
>
> Np. mam kod, w sumie, 3tys linii, który jest działający (wiem, że to może
> być przypadek, że działa).
> Następnie dopisuję prostą funkcję, przetestowaną na PC za pomocą gcc;
> kompilator(linker) zgłasza mi, że nie może coś tam pamięci znaleźć (mimo że
> wcześniej kompilował i wykorzystywał 20% ram, procesor PIC18, 3,5kB ram).

Kompilator microchipa to dziadostwo i jak w danej jednostce kompilacji
przekroczysz rozmiar banku, to musisz ręcznie przypisać cześć zmiennych
do innego banku pamięci.

> No i się zaczyna kombinowanie, przenoszenie zmiennych globalnych na lokalne
> i na odwrót (dobrze, że w PIC18 nie trzba banków deklarować). OK program się
> kompiluje ale rzeczona funkcja nie działa poprawnie.

No to trzeba użyć debuggera (pickit3 kosztuje grosze) i sprawdzić co
jest nie tak.

> Następnie ściągam kompilator XC8 (60 dniowy) i program się kompiluje i
> działa poprawnie (przynajmiej takie mam wrażenie).
>
> Ja wiem, że ponad 99% przypadków niedziałania programu w C to wina
> programisty ale martwią mnie takie akcje gdzie linker coś sygnalizuje a ty
> się martw o co mu chodzi i kombinuj.

Masz rację, ja też czekam na kompilator, który zrobi to co chcę a nie to
co napisałem :-).

do góry