> > A jaki numer wersji C18 używasz?
>
> 3.42
>
> --
> Marek
Dzięki.
S.

do góry

On Fri, 4 Apr 2014 11:58:34 +0200, "tusk, donald tusk"
<N...@g...pl> wrote:
> mogę o coś zapytać?
> jak dokładnie brzmi nazwa kompilatora C dla 18F?
> PICC? czy C18? MPLAB? trochę się pogubiłem...

C18 (stary) lub XC8 (nowy). To dwa różne kompilatory.

MPLAB to całe środowisko (starsze, już nie rozwijane) które uruchamia
m.in. kompilator C18, C18 jest kompilatorem działającym z linii
komend.
C18 to "starszy" i dedykowany do 18F. W tej chwili chyba już został
oficjalnie zastąpiony przez XC8, który jest częścią nowego środowiska
mplab X.

--
Marek

do góry

Marek wrote:

> On Fri, 04 Apr 2014 11:46:23 +0200, jacek pozniak
> <j...@f...pl> wrote:
>> kompilowałem kompilatorem wywodzącym się z HiTech, XC8 bardziej
> jest HiTech
>
> A XC8 to nie jest właśnie wykupiony przez microchio HiTech?
>
Chyba tak właśnie jest i to jest właśnie niedobre.

Wyobrażam to sobie tak:
1. Firma Hitech robiła dość dobre kompilatory, mam z nimi (kompilatorami na
PICe) kontakt od 1996.
2. Microchip ich wykupił, może oszukał.
3. Ludzie sobie poszli/obrazili się a Microchip posadził czterech
programistów i nakazał przejęcie i rozwijanie kompilatorów, i jest jak jest.
4. Może tak nie było ale przy przejęciach taki scenariusz jest
prawdopodobny.

jp

do góry

> Wyobrażam to sobie tak:
> 1. Firma Hitech robiła dość dobre kompilatory, mam z nimi (kompilatorami
na
> PICe) kontakt od 1996.
> 2. Microchip ich wykupił, może oszukał.
> 3. Ludzie sobie poszli/obrazili się a Microchip posadził czterech
> programistów i nakazał przejęcie i rozwijanie kompilatorów, i jest jak
jest.
> 4. Może tak nie było ale przy przejęciach taki scenariusz jest
> prawdopodobny.

Nie ma i nigdy nie będzie idealnego kompilatora, dlatego, że każdy ma swój
sposób pisania kodu
i swoje preferencje.
Mi to nawet assembler nie chce robić tego co ja chcę :-)

Jak Ci Zbych napisał:
My nie znamy Twojego kodu.

Ale Ty go znasz, więc możesz:
a) zainstalować sobie środowisko dla AVRx;y;z; MPLAB x;y;z; Freescale, ST,
ARM 0..13 itp.,
b) spróbować skompilować swój kod,
c) wybrać ten, który generuje najmniej problemów dla Ciebie, najbardziej go
polubiłeś, dobrze Ci się z nim pracuje,
rozumie Cię, a Ty jego.

Jak tak wybrałem żonę. I jestem zadowolony z jej kompilatora :-)

S.

do góry

Adam Wysocki wrote:

> jacek pozniak <j...@f...pl> wrote:
>
>> Czy Koledzy programujący uC również coś takiego zauważyli?
>
> Z PIC-ami nie mam doświadczeń, ale od ok. 10 lat programuję AVR-y używając
> avr-gcc (różne wersje się przez ten czas przewinęły) i nigdy nic takiego
> się nie zdarzyło - co najwyżej były zmiany w API avr-libc (ISR, SIGNAL,
> avr/signal.h, avr/interrupt.h itd).
No właśnie. Wydaje mi się, że avr-gcc jest bliższy poprawnie działającemy
softowi.
Nigdy wcześniej go nie używałem (tak jak procesorów AVR zresztą) aż razu
pewnego postanowiłem skompilować dość złożony program i jakież było moje
zdziwienie; zadziałał praktycznie od razu (na Atmega32).
Ten sam kod kompilowany na PIC działał źle, i w zależności od wersji
kompilatora, różnie się w swojej wadliwej pracy zachowywał; pewne fragmenty
działały a pewne nie.
Dodam, że program, wg zapewnień autora, był pisany z dużym naciskiem na
przenośność, czyli zgodnie ze standardami.

Sam nie wiem co o tym myśleć.

jp

do góry

Sylwester Łazar wrote:

>
>> Wyobrażam to sobie tak:
>> 1. Firma Hitech robiła dość dobre kompilatory, mam z nimi (kompilatorami
> na
>> PICe) kontakt od 1996.
>> 2. Microchip ich wykupił, może oszukał.
>> 3. Ludzie sobie poszli/obrazili się a Microchip posadził czterech
>> programistów i nakazał przejęcie i rozwijanie kompilatorów, i jest jak
> jest.
>> 4. Może tak nie było ale przy przejęciach taki scenariusz jest
>> prawdopodobny.
>
> Nie ma i nigdy nie będzie idealnego kompilatora, dlatego, że każdy ma swój
> sposób pisania kodu
> i swoje preferencje.
> Mi to nawet assembler nie chce robić tego co ja chcę :-)
>
> Jak Ci Zbych napisał:
> My nie znamy Twojego kodu.
>
> Ale Ty go znasz, więc możesz:
> a) zainstalować sobie środowisko dla AVRx;y;z; MPLAB x;y;z; Freescale, ST,
> ARM 0..13 itp.,
> b) spróbować skompilować swój kod,
> c) wybrać ten, który generuje najmniej problemów dla Ciebie, najbardziej
> go polubiłeś, dobrze Ci się z nim pracuje,
> rozumie Cię, a Ty jego.
>
> Jak tak wybrałem żonę. I jestem zadowolony z jej kompilatora :-)
>
> S.
To nie takie proste.
Kiedyś zainwestowałem z PICe, teraz m.in. z tego żyję.
A przestawienie się kosztuje.

Do tej pory było tak, że sprawdzony sprzęt, np. oparty o PICa, w obudowie
so28, rozwijam dodając procesor z większą pamięcią ale w takiej samej
obudowie, zaszywając w nim większą funkcjonalność.

No i bronię się rękami i nogami przed istotnymi zmianami sprzętu. Jak się
nie da to trudno.

I stąd ten założony przeze mnie wątek.


jp

do góry

Sylwester Łazar wrote:

>> Proszę o jakieś opinie.
>>
>> Pozdrawiam
>> jp
> Wydaje mi się, że praca z kompilatorem (C czy czymkolwiek w przyszości, co
> też nie będzie spójne),
> jest jak praca z drugim programistą.
> Toż przecież kompilator też napisał człowiek.
>
> Wygląda mi na to, że decydując się na C, zgadzasz się jak gdyby na pracę w
> grupie.
> I naturalnym będzie, że są różnice w wizji - jak to ma działać.
>
> Inny kompilator - inny programista.
>
> Zmieniając kompilator, to tak jakbyś zmieniał współpracownika.
> Nowy może być lepszy, ale te "docieranie".
> Dlatego bardzo rozsądne wydaje mi się to co robi MAREK:
> "nie zmieniam kompilatora używanego latami,
> przetestowanego na wszelkie możliwe sposoby i działającego prawidłowo
> (C18} nagle na inny (XC8)"

No chyba, że pojawia się nowy chip, który chcesz zastosować a nie masz
czasu/możliwości na grzebanie w plikach opisujących hardware(kiedyś, dla
PIC16F... tak czyniłem, nie wiem czy nadal to możliwe).


jp

do góry

> Do tej pory było tak, że sprawdzony sprzęt, np. oparty o PICa, w obudowie
> so28, rozwijam dodając procesor z większą pamięcią ale w takiej samej
> obudowie, zaszywając w nim większą funkcjonalność.
>
> No i bronię się rękami i nogami przed istotnymi zmianami sprzętu. Jak się
> nie da to trudno.
>
> I stąd ten założony przeze mnie wątek.
>
Mogłeś zaprojektować w DIP28.
Wtedy łatwiej na przejściówce umieścić 4 szt. PIC32 :-).
S.

do góry

W dniu 2014-04-04 10:34, Michał Lankosz pisze:

> Do ARMów jest obecnie kilka darmowych toolchainów GCC, tylko środowisko
> trzeba sobie skompletować. A! jest CooCox, co się go ściąga, klika w
> jakimś wizardzie i już - nie używam, ale wydaje się dość przyjazne.

Kupujesz Zestaw uruchomieniowy LPCXpresso za 90 zł i masz z nim
połączony programator/debuger. Programator możesz odłamać i wykorzystać
do swoich płytek. A w ramach licencji masz całkiem porządny eclipsowy
toolchain z ograniczeniem bodajże do 256K.


--
pozdrawiam
MD

do góry

On Fri, 04 Apr 2014 14:19:02 +0200, jacek pozniak
<j...@f...pl> wrote:
> No i bronię się rękami i nogami przed istotnymi zmianami sprzętu.
Jak się
> nie da to trudno.

No ja robię identycznie, z tym, że nie daje się wciągnąć w ewolucję
kompilatora. I nie zmienię kompilatora, aż do zakończenia życia
okresu produkcji mcu, które obsługuje (lub własnego).

--
Marek

do góry