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

Thu Apr 03, 2014 10:07 pm   

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

Fri Apr 04, 2014 3:10 am   

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.

Fri Apr 04, 2014 6:16 am   

W dniu 04.04.2014 00:07, jacek pozniak pisze:


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.

Fri Apr 04, 2014 7:08 am   

Zbych wrote:




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

Fri Apr 04, 2014 7:10 am   

On Fri, 04 Apr 2014 00:07:59 +0200, jacek pozniak
<jacek.pozniak@flowservice.pl> wrote:

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

Fri Apr 04, 2014 7:46 am   

On Fri, 04 Apr 2014 09:08:26 +0200, jacek pozniak
<jacek.pozniak@flowservice.pl> wrote:

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

Fri Apr 04, 2014 8:00 am   

Używać TBLRD, TBLWR, TBLADR, TABLAT, TBLPTRU:H:L?
S.

Fri Apr 04, 2014 8:02 am   

Obie mogą nie być "winą" programisty.
S.

Fri Apr 04, 2014 8:13 am   

W dniu 04.04.2014 09:08, jacek pozniak pisze:

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 to trzeba użyć debuggera (pickit3 kosztuje grosze) i sprawdzić co
jest nie tak.


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

Fri Apr 04, 2014 8:34 am   

W dniu 2014-04-04 00:07, jacek pozniak pisze:

Jeśli nie popatrzysz na ARM jak na armatę na wróble, to może o nich
pomyśl. Piszę (teraz coraz mniej) na AVR w C jak i na ARM (STM32) więc
mam jako takie porównanie.

W mojej opinii na niekorzyść AVR (w stosunku do ARM) przemawia:
- pitolenie się ze stałymi umieszczanymi we flash, cały zbiór funkcji
operujący na stringach jest powielony tylko z powodu innego sposobu
dostępu do pamięci programu
(http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html)
- pitolenie się z dostępem powyżej magicznej granicy 64k (RAMPZ), prosty
wskaźnik do pamięci jest tylko 16-bit
- debugowanie - jest niby jtag (którego raz mi się udało użyć), czy
debugwire (takiego sprzętu już nie miałem); w moim przekonaniu te
narzędzia u Atmela dobrze działają jak się ma oryginalne (drogie)
sprzęty i tylko ich AtmelStudio. Ja mam tylko programator ISP+PDI+TPI.

Trzeba mieć też na uwadze, że w przypadku AVRów nie jest też tak różowo
z kompilacją. Wraz z wersją 5.x, czy 6 AS zmiany w toolchainie są na
tyle duże, że wiele kodów już napisanych i działających trzeba
poprawiać. Na pierwszy strzał idzie dodanie const do wszystkich stałych
umieszczonych w pamięci programu (wreszcie uczy się "programistów"
takich jak ja , bo inaczej kompilacja kończy się błędem. Jednak nie
pamiętam przypadku, żeby kod kompilował się dobrze dla dwóch wersji
kompilatora, a przy jednym z nich nie działał.

Korzyści AVR to... głównie że istnieją malutkie procki, które mogą
posłużyć do migania diodą, jako jakieś interfejsy między czujnikiem a
magistralą i... wiele innych.
Jednak stosowanie ATmega128 już jest kiepskim pomysłem, bo jest 5x
droższa i z 15 razy mniej wydajna od prostego Cortex M0.

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.

--
Michał

Fri Apr 04, 2014 8:48 am   

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)"
Zna jego wady i zalety i pracuje mu się z nim skutecznie.

Jeśli chodzi o Microchip, to sytuacja jest wydaje mi się jeszcze gorsza.
np. z ostatnich dni.
Chciałem sobie zrobić sortowanie napięć.
Bąbelkowe - najprostrze, ale nie wypada, bo niemal prawie najgorsze z
możliwych.
No to quic sort.
Fajnie. Biorę C32 i jest piękna funkcja qsort() w bibliotece. Ale ja mam
18F.
W C18 już jej nie ma.
Lepiej jednak mi pasuje metoda zliczania.
Myślę sobie - co za problem - kopiuję z Wikipedii i mam.
Jednak coś mnie zatrzymało. Jak to będzie działać na 8-bitowym z rekordami
danych, bo oprócz wartości napięć są i ich adresy?
Musi być to strasznie czasochłonne i nadmiarowe zrobić na 8-bitówce.
Więc zrobiłem w asm. Zaraz uruchomię.
Nie zdecydowałem się w pierwszej kolejności w C i podpatrzeć, tylko
sprawdzić od razu w ASM nie sugerując się.
Jak to zrobię zapuszczę w C18 poniższy fragment z Wikipedii i porównam.
W międzyczasie, jakby mi ktoś powiedział, czy widzi jakieś spowolnienia w
tym kodzie, to byłbym wdzięczny.
S.



# variables:
# input -- the array of items to be sorted; key(x) returns the key for
item x
# n -- the length of the input
# k -- a number such that all keys are in the range 0..k-1
# count -- an array of numbers, with indexes 0..k-1, initially all zero
# output -- an array of items, with indexes 0..n-1
# x -- an individual input item, used within the algorithm
# total, oldCount, i -- numbers used within the algorithm

# calculate the histogram of key frequencies:
for x in input:
count[key(x)] += 1

# calculate the starting index for each key:
total = 0
for i in range(k): # i = 0, 1, ... k-1
oldCount = count[i]
count[i] = total
total += oldCount

# copy to output array, preserving order of inputs with equal keys:
for x in input:
output[count[key(x)]] = x
count[key(x)] += 1

return output

Fri Apr 04, 2014 8:52 am   

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.

Fri Apr 04, 2014 8:52 am   

On Fri, 4 Apr 2014 10:00:32 +0200, Sylwester Łazar<info@alpro.pl>
wrote:

Przypominam, że rozmawiamy o kompilatorze C . Tymi rejestrami to
ma zarządzać kompilator a nie programista.
Przykład, użycie funkcji:
strcpy(a,b);
będzie prawidłowe, jeśli oba wskazniki a i b są typu char* i oba
wskazują na bufory w ram.
Nieprwawidłowe będzie użycie np. strcpy (a,"test"), ponieważ string
"test" zostanie umieszczony przez kompilator w rom przez co będzie
niezgodność drugiego argumentu, (który jest rom char* a nie char*), b
musi być wskaznikiem na ram w przypadku tej funkcji.
W takich przypadkach trzeba użyć dedykowanej funkcji
strcpypgmram(a,"test") ;
C18 dostarcza wszystkie funkcje, które zastępują klasyczne przy
operacjach na stringach, gdy są mieszane argumenty (char* i rom
char*) np: strstrrampgm, ststrpgnram itd.
Porąbane, prawda?
Ale pomijajac tą upierdliwość (którą pozbyto się dopiero w XC8), C18
jest bardzo dobrym kompilatorem dla arch. pic16 i nigdy mnie nie
zawiódł a kompilowałem nim projekty, które sumarycznie przekroczyły
steki tysięcy linii kodu. 100% problemów z nieprawidłowym dzialaniem
kodu były związane z moimi błędami a nie błędem C18. Natomiast tego
nie można powiedzieć no. o sdcc, ostatnio przeze mnie zgłoszony błąd
dla pic14 był chyba w lutym, (mieli poprawić przy najbliższym wydaniu
sdcc).

--
Marek

Fri Apr 04, 2014 9:10 am   

Użytkownik Marek <fake@fakeemail.com> w wiadomości do grup dyskusyjnych
napisał:almarsoft.2303867967653108837@news.neostrada.pl...



Przypuszczam tylko, że setki osób ma taki dylemat na początku i tylko
szkoda czasu na nerwy i walenie w klawiaturę :-)


A jaki numer wersji C18 używasz?
S.

Fri Apr 04, 2014 9:22 am   

W dniu 2014-04-04 11:10, Sylwester Łazar pisze:

Przenieś teraz ten kod na(z) inny uC - AVR, albo na Cortex Mx. Pewnie
Marek takie (mniej więcej) przesłanie kryje za słowem "porąbane".

--
Michał