PIC vs AVR

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.

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.

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.

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

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.

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

To jak sobie poradzić z ROMem? Używać TBLRD, TBLWR, TBLADR, TABLAT, TBLPTRU:H:L? S.

Binarnie to są jeszcze 2 kobinacje. Obie mogą nie być "winą" programisty. S.

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

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

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.

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)" 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

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

Użytkownik Marek snipped-for-privacy@fakeemail.com w wiadomości do grup dyskusyjnych napisał: snipped-for-privacy@news.neostrada.pl...

No właśnie. Inaczej nie ma to sensu.

Fakt. Ale jak się wie, to już żaden problem. 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.

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

Do tego raczej się nie przyzwyczaję, że po rzutowaniu wskaźnika, kompilator nie zgłasza błędów a program po prostu nie działa bo nadal próbuje pobierać z innej przestrzeni adresowej. Prędzej zmienię architekturę/kompilator.

Trochę nieprecyzyjnie się wyraziłem co do tego PIC18, ja kompiluję i zawsze kompilowałem kompilatorem wywodzącym się z HiTech, XC8 bardziej jest HiTech niż C18 (chyba).

mogę o coś zapytać? jak dokładnie brzmi nazwa kompilatora C dla 18F? PICC? czy C18? MPLAB? trochę się pogubiłem...

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

3.42

A XC8 to nie jest właśnie wykupiony przez microchio HiTech?