eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaPIC vs AVR
Ilość wypowiedzi w tym wątku: 238

  • 1. Data: 2014-04-04 00:07:59
    Temat: PIC vs AVR
    Od: jacek pozniak <j...@f...pl>

    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



  • 2. Data: 2014-04-04 05:10:53
    Temat: Re: PIC vs AVR
    Od: Jacek Radzikowski <j...@s...die>

    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.




  • 3. Data: 2014-04-04 08:16:39
    Temat: Re: PIC vs AVR
    Od: Zbych <a...@o...pl>

    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.


  • 4. Data: 2014-04-04 08:52:41
    Temat: Re: PIC vs AVR
    Od: pytajacy <r...@p...fm>

    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.


  • 5. Data: 2014-04-04 09:08:26
    Temat: Re: PIC vs AVR
    Od: jacek pozniak <j...@f...pl>

    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



  • 6. Data: 2014-04-04 09:10:03
    Temat: Re: PIC vs AVR
    Od: Marek <f...@f...com>

    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


  • 7. Data: 2014-04-04 09:46:47
    Temat: Re: PIC vs AVR
    Od: Marek <f...@f...com>

    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


  • 8. Data: 2014-04-04 10:00:32
    Temat: Re: PIC vs AVR
    Od: Sylwester Łazar <i...@a...pl>

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


  • 9. Data: 2014-04-04 10:02:59
    Temat: Re: PIC vs AVR
    Od: Sylwester Łazar <i...@a...pl>

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


  • 10. Data: 2014-04-04 10:13:08
    Temat: Re: PIC vs AVR
    Od: Zbych <a...@o...pl>

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

strony : [ 1 ] . 2 ... 10 ... 20 ... 24


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: