PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC

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

Mogłeś zaprojektować w DIP28.
Wtedy łatwiej na przejściówce umieścić 4 szt. PIC32 .

On Fri, 04 Apr 2014 14:09:27 +0200, jacek pozniak
jacek.pozniak@flowservice.pl> wrote:
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

Jakie kompilatory generowały Ci zły kod?

Moje obserwacje opieram na:

Marek wrote:

On Fri, 04 Apr 2014 14:09:27 +0200, jacek pozniak
jacek.pozniak@flowservice.pl> wrote:
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

Jakie kompilatory generowały Ci zły kod?

Moje obserwacje opieram na:
HiTech 9.63 i XC8
(nowszych od 9.63, przed XC8 1.30 nie sprawdzałem)

Wcześniejsze miały swoje homory ale generalnie nie miałem zastrzeżeń bo
nie stosowałem Microhipa w bardziej złożonych sprawach.

jp

Mogłeś zaprojektować w DIP28.
Wtedy łatwiej na przejściówce umieścić 4 szt. PIC32 .

Przecież pic32 jest w dip28...

--
Marek
W zasadzie tak, ale już pinowo to średnio kompatybilne

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.

Swoją drogą wyszła dodatkowa zaleta DIPów, że można potem łatwo
dorobić
przejściówkę
do starych projektów.

Mnie natomiast ciekawi dlaczego pic32 w dipie ma obniżona
częstotliwość z 80 MHz do max 50MHz, czyżby obudowa dip28 nie nadaje
do wyższej f?

--
Marek
Pamiętasz może Paralaxa?

Jeśli testowałeś to na C18 microchipa, to pamiętaj że nie jest on do
....
To był kompilator HiTech oraz XC8, który chyba też raczej wywodzi się z

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.
Mi chodzi o sam kompilator i kompilację z linii poleceń.

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)

"jacek pozniak" <jacek.pozniak@flowservice.pl> wrote in message
news:533ddbbb$0$2158$65785112@news.neostrada.pl...
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)

Jak się już przesiadasz to może przesiądź się na jakiegoś dobrego
ARMa zamiast ciągnąć jakieś archaizmy w XXI wieku...
Pewnie tak tylko nie miałem do czynienia z ARM.

jacek pozniak wrote:


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.
Tak to wiem.

"jacek pozniak" <jacek.pozniak@flowservice.pl> wrote in message
news:533ddbbb$0$2158$65785112@news.neostrada.pl...
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)

Jak się już przesiadasz to może przesiądź się na jakiegoś dobrego
ARMa zamiast ciągnąć jakieś archaizmy w XXI wieku...

Masz rację, ja też czekam na kompilator, który zrobi to co chcę a nie to
co napisałem .
Wszyscy programiści, dowolnych języków na to czekają