W dniu 2013-06-23 00:09, Marek Borowski pisze:
> On 6/22/2013 8:57 PM, Mario wrote:
>> W dniu 2013-06-21 18:26, sundayman pisze:
>>>
>>>> Fajnie, ale powiedz mi, dlaczego nie wybrałeś stajni Atmela?
>>>> Wydawać by się mogło, że to najrozsądniejsze, skoro AVR-y stosowałeś,
>>>> znasz środowisko.
>>>
>>> No właściwie właśnie dlatego trochę :)
>>> Bo nie znam ST zupełnie - więc żeby nie być uwiązanym do jednej firmy,
>>> no i z tego co widzę, to to chyba niezły produkt jest, ten STM.
>>>
>>> Po drugie - mam zamiar pisać w MikroC for ARM ; a tam nie ma dużych
>>> atmeli (niestety ?).
>>
>> A jakie ma zalety microc względem gcc?
>>
> Chociazby takie ze MikroC to caly pakiet a gcc to czysty kompilator ?
>
>
> Pozdrawiam
>
> Marek
>
> BTW: Wiem ze mozna Eclipse + gcc + OpenOCD skonfigurowac -tez mam, ale
> biorac pod uwage czulosc na detale w/w rozwiazania wole miec komercyjne
> srodowisko i skupiac sie na projekcie a nie srodowisku developerskim.

Ale masz wiele gotowych środowisk z gcc za grosze. Na przykład dla NXP
kupując za 90 zł płytkę uruchomieniową LPCXpresso (zawierającą
programator JTAG) masz gotowe środowisko. Są też darmowe jak CoIDE (Coocox).
Oparte są na dobrym, ciągle rozwijanym kompilatorze, do którego są
dostarczane sterowniki CMSIS (dla Cortexów).


--
pozdrawiam
MD

do góry

> Ale masz wiele gotowych środowisk z gcc za grosze. Na przykład dla NXP
> kupując za 90 zł płytkę uruchomieniową LPCXpresso (zawierającą
> programator JTAG) masz gotowe środowisko. Są też darmowe jak CoIDE
> (Coocox).
> Oparte są na dobrym, ciągle rozwijanym kompilatorze, do którego są
> dostarczane sterowniki CMSIS (dla Cortexów).

No i dobrze. Jak będę chciał NXP , to wtedy pewnie skorzystam.
Ja akurat lubię kompilatory Mikroelektroniki, bo są wygodne, proste,
mają sporo przydatnych bibliotek. Niekłopotliwe są.
A ja nie bardzo mam czas i chęć na "dłubaninę", generalnie spieszy mi się :)

Nikogo nie namawiam, kwestia gustu.

A, że akurat mam takie wrażenie że STM są rodziną bardzo popularną,
dlatego postanowiłem trochę je wykorzystać, przy okazji mając ten plus,
że w MikroC są.

do góry

W dniu 2013-06-23 01:32, sundayman pisze:
>
>> Ale masz wiele gotowych środowisk z gcc za grosze. Na przykład dla NXP
>> kupując za 90 zł płytkę uruchomieniową LPCXpresso (zawierającą
>> programator JTAG) masz gotowe środowisko. Są też darmowe jak CoIDE
>> (Coocox).
>> Oparte są na dobrym, ciągle rozwijanym kompilatorze, do którego są
>> dostarczane sterowniki CMSIS (dla Cortexów).
>
> No i dobrze. Jak będę chciał NXP , to wtedy pewnie skorzystam.

Sterowniki CMSIS są na wszystkie Cortexy, w też STM. Są po to żeby
uniezależnić obsługę peryferiów w programie od producenta procka.
O NXP wspomniałem w kontekście zestawu i środowiska LCPXpresso.



--
pozdrawiam
MD

do góry

W dniu piątek, 21 czerwca 2013 18:26:54 UTC+2 użytkownik sundayman napisał:
> Bo nie znam ST zupełnie - więc żeby nie być uwiązanym do jednej firmy,
> no i z tego co widzę, to to chyba niezły produkt jest, ten STM.

Poczytaj erraty i dokumentację zanim zaczniesz cokolwiek projektować.
Niestety te uC nie są pozbawione wad i niespodzianek i to czasem dość poważnych.
Zwróć uwagę na remapowanie peryferiów, może być np. tak, że nie da się używać
jednocześnie remapowanego I2C2 i SPI2 (i nie dlatego, że współdzielą piny), jest parę
błędów w krzemie. Do tego jakiś glitche na ADC itp.
Jeżeli chodiz o komunikację to taka niemiła niespodzianka - w F103 (chyba) bufor CAN
i USB jest współdzielony, nie można używać obu peryferiów jednocześnie.
I2C jest poza tym bardzo upierdliwe.

Nie wiem jak w tym MikroC, ale do gcc w internetach proponują toolchain Code
Sourcery, standardowa biblioteka C (newlib) jest tam tragiczna jeżeli chodzi o
rozmiar kodu, wygląda jakby była kompilowana z -O3 i dodatkowymi "przyśpieszaczami",
w niektórych funkcjach (podstawowych, typu memcpy, strlen) pętle porozwijane są na 16
iteracji, operacje na floatach też jakoś dziwnie spuchnięte. Od jakiegoś czasu noszę
się z zamiarem przekompilowania tego z -Os i wyłączonymi turbo optymalizacjami, chyba
że ktoś zna jakąś zastępczą bibliotekę.

do góry

> Poczytaj erraty i dokumentację zanim zaczniesz cokolwiek projektować.

ech, wy to potraficie każdą przyjemność popsuć...

> Niestety te uC nie są pozbawione wad i niespodzianek i to czasem dość poważnych.
> Zwróć uwagę na remapowanie peryferiów, może być np. tak, że nie da się używać
jednocześnie remapowanego I2C2 i SPI2 (i nie dlatego, że współdzielą piny), jest parę
błędów w krzemie. Do tego jakiś glitche na ADC itp.
> Jeżeli chodiz o komunikację to taka niemiła niespodzianka - w F103 (chyba) bufor
CAN i USB jest współdzielony, nie można używać obu peryferiów jednocześnie.
> I2C jest poza tym bardzo upierdliwe.

no dobra, poczytam :)

do góry

On Monday, June 24, 2013 10:52:50 AM UTC+2, shg wrote:

> Poczytaj erraty i dokumentację zanim zaczniesz cokolwiek projektować.
Od tego nalezy zawsze rozpoczac prace.


> Nie wiem jak w tym MikroC, ale do gcc w internetach proponują toolchain Code
Sourcery, standardowa biblioteka C (newlib) jest tam tragiczna jeżeli chodzi o
rozmiar kodu, wygląda jakby była kompilowana z -O3 i dodatkowymi "przyśpieszaczami",
w niektórych funkcjach (podstawowych, typu memcpy, strlen) pętle porozwijane są na 16
iteracji, operacje na floatach też jakoś dziwnie spuchnięte. Od jakiegoś czasu noszę
się z zamiarem przekompilowania tego z -Os i wyłączonymi turbo optymalizacjami, chyba
że ktoś zna jakąś zastępczą bibliotekę.

Czas najwyzszy zapoznac sie z RTOS-ami, np.
eCos -> http://ecos.sourceware.org/
(system jest "wysoce" konfigurowalny i aby uzyc funkcji printf nie trzeba
linkowac calej biblioteki newlib)
ChibiOS -> http://www.chibios.org/dokuwiki/doku.php
itd.

do góry

W dniu 2013-06-24 17:00, brak pisze:
> On Monday, June 24, 2013 10:52:50 AM UTC+2, shg wrote:
>
>> Poczytaj erraty i dokumentację zanim zaczniesz cokolwiek projektować.
> Od tego nalezy zawsze rozpoczac prace.
>
>
>> Nie wiem jak w tym MikroC, ale do gcc w internetach proponują toolchain Code
Sourcery, standardowa biblioteka C (newlib) jest tam tragiczna jeżeli chodzi o
rozmiar kodu, wygląda jakby była kompilowana z -O3 i dodatkowymi "przyśpieszaczami",
w niektórych funkcjach (podstawowych, typu memcpy, strlen) pętle porozwijane są na 16
iteracji, operacje na floatach też jakoś dziwnie spuchnięte. Od jakiegoś czasu noszę
się z zamiarem przekompilowania tego z -Os i wyłączonymi turbo optymalizacjami, chyba
że ktoś zna jakąś zastępczą bibliotekę.
>
> Czas najwyzszy zapoznac sie z RTOS-ami, np.
> eCos -> http://ecos.sourceware.org/
> (system jest "wysoce" konfigurowalny i aby uzyc funkcji printf nie trzeba
> linkowac calej biblioteki newlib)
> ChibiOS -> http://www.chibios.org/dokuwiki/doku.php
> itd.
>

Jest jeszcze FreeRTOS i CooCox. Oba są dostępne w wersji darmowej, która
nie wymusza licencji GPL na aplikację.

--
pozdrawiam
MD

do góry

W dniu poniedziałek, 24 czerwca 2013 17:00:54 UTC+2 użytkownik brak napisał:

> Czas najwyzszy zapoznac sie z RTOS-ami, np.
> eCos -> http://ecos.sourceware.org/
> (system jest "wysoce" konfigurowalny i aby uzyc funkcji printf nie trzeba
> linkowac calej biblioteki newlib)
> ChibiOS -> http://www.chibios.org/dokuwiki/doku.php
> itd.

Ale co ma system operacyjny do standardowej biblioteki C?
printf() to akurat najmniejszy problem. Potrzebuję małe funkcje standardowe
(string.h, stdlib.h itd.). Te nie są w tych OS-ach zrobione na nowo, ani w tych,
które proponuje Mario. Wszędzie sugerują linkowanie z newlib.
Całej biblioteki się nigdy nie linkuje (to ma chyba ze 2 MB). Pisanie czegoś na
klocki z 64 kB flasha na pokładzie z taką "tłustą" biblioteką jest lekkim
nieporozumieniem, bo więcej miejsca zajmują banalne funkcje z bibliotek niż mój kod.
Gdybym te funkcje napisał sam i to nawet w C (co zresztą w niektórych przypadkach
zrobiłem), to robią się dużo mniejsze, ale zwyczajnie nie chce mi się, za dużo czasu
trzeba by na to poświęcić.
OS niczego w tej kwestii nie rozwiązuje.

do góry

> Czas najwyzszy zapoznac sie z RTOS-ami, np.

Na razie na tym poziomie mi to niepotrzebne.
Jak potrzebowałem coś, na czym można zapodać androida, to są fajnie
różne gotowce w postaci np. Samsunga S3C2440 (starawe już), itp ARM9.

do góry

On Monday, June 24, 2013 7:12:15 PM UTC+2, shg wrote:
> W dniu poniedziałek, 24 czerwca 2013 17:00:54 UTC+2 użytkownik brak napisał:
>
>
>
> > Czas najwyzszy zapoznac sie z RTOS-ami, np.
>
> > eCos -> http://ecos.sourceware.org/
>
> > (system jest "wysoce" konfigurowalny i aby uzyc funkcji printf nie trzeba
>
> > linkowac calej biblioteki newlib)
>
> > ChibiOS -> http://www.chibios.org/dokuwiki/doku.php
>
> > itd.
>
>
>
> Ale co ma system operacyjny do standardowej biblioteki C?
To iz zwykle jest w jakis sposob dostarczona/zintegrowana oraz przetestowana
i nie ma potrzeby jej "dotykania". Biblioteka C jest jednym z komponetow
systemu i od jej jakosci zalezy jakosc systemu.

>
> printf() to akurat najmniejszy problem. Potrzebuję małe funkcje standardowe
(string.h, stdlib.h itd.). Te nie są w tych OS-ach zrobione na nowo, ani w tych,
które proponuje Mario. Wszędzie sugerują linkowanie z newlib.
Niekoniecznie, np. eCos:
"eCos provides compatibility with the ISO 9899:1990 specification for the standard C
library, which is essentially the same as the better-known ANSI C3.159-1989
specification (C-89)."

eCos przekazuje flage -nostdlib do linkera.

Co do newliba to znajomy uzywal jej podobnie tj. startup z "sieci" + wlasny kod
+ newlib. Niestety nie bylo to takie proste (kompliator gcc oczekiwal jakiegos
konstruktora) i narzekal, iz po uzyciu funkcji printf rozmiar programu istotnie
wzrosl.


> Całej biblioteki się nigdy nie linkuje (to ma chyba ze 2 MB).
Yyy. Przeciez od dawna juz linker usuwa nie uzywane obj-ty. Tak wiec nie uzywajac
"namietnie" biblioteki, likner nie dolaczy jej w calosci.

>Pisanie czegoś na klocki z 64 kB flasha na pokładzie z taką "tłustą" biblioteką
jest lekkim nieporozumieniem, bo więcej miejsca zajmują banalne funkcje z bibliotek
niż mój kod. Gdybym te funkcje napisał sam i to nawet w C (co zresztą w niektórych
przypadkach zrobiłem), to robią się dużo mniejsze, ale zwyczajnie nie chce mi się, za
dużo czasu trzeba by na to poświęcić.
>
I wynalazl bys kolo, piszac kolejna bibliteke standartowa C dla mikrokontrolerow.

> OS niczego w tej kwestii nie rozwiązuje.
W przypadku eCos biblioteka C jest jednym z jego komponentow, ktory jest
konfigurowalny aby zmniejszyc rozmiar kodu ponad to co jest wstanie zrobic linker -
co rozwiazuje problemy z biblioteka C.

do góry