W dniu 2014-04-04 00:07, jacek pozniak pisze:
> 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)

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__a
vr__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ł

do góry

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

do góry

On Fri, 4 Apr 2014 10:00:32 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> To jak sobie poradzić z ROMem?
> Używać TBLRD, TBLWR, TBLADR, TABLAT, TBLPTRU:H:L?

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

do góry

Użytkownik Marek <f...@f...com> w wiadomości do grup dyskusyjnych
napisał:a...@n...neostrada
.pl...
> On Fri, 4 Apr 2014 10:00:32 +0200, Sylwester Łazar<i...@a...pl>
> wrote:
> > To jak sobie poradzić z ROMem?
> > Używać TBLRD, TBLWR, TBLADR, TABLAT, TBLPTRU:H:L?
>
> Przypominam, że rozmawiamy o kompilatorze C :-). Tymi rejestrami to
> ma zarządzać kompilator a nie programista.
No właśnie. Inaczej nie ma to sensu.

> 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? ;)
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ę :-)

> 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

A jaki numer wersji C18 używasz?
S.

do góry

W dniu 2014-04-04 11:10, Sylwester Łazar pisze:
>
> Użytkownik Marek <f...@f...com> w wiadomości do grup dyskusyjnych
> napisał:a...@n...neostrada
.pl...
>> 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? ;)
> Fakt. Ale jak się wie, to już żaden problem.

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ł

do góry

Marek wrote:

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

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

do góry

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

do góry

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

--
SELECT finger FROM hand WHERE id = 3;
http://www.chmurka.net/

do góry

On Fri, 4 Apr 2014 11:10:31 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> A jaki numer wersji C18 używasz?

3.42

--
Marek

do góry

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?

--
Marek

do góry