Marek Borowski <m...@n...com> napisał(a):
> To juz plugin wyświetla poprawnie zawartość rejestrów sprzętowych we
> wszystkich odmianach chipow ? Debugowanie krokowe nie zawiesza sie
> jak się za szybko klawisze wciska ? Stos wywołań jest "dekryptowany"
> poprawnie ?

Nie zauważyłem problemów na F4, L0 i L1.

> Init skrypty dla gdb i linker skrypty sa dostepne czy trzeba je reczenie
> pisac za kazdym razem dla nowego ukladu ?

Skrypty linkera zawsze udawało mi się znaleźć Googlem.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 54 days, 4 hours, 7 minutes and 52 seconds

do góry

On 2016-01-11 22:21, Grzegorz Niemirowski wrote:
> Marek Borowski <m...@n...com> napisał(a):
>> To juz plugin wyświetla poprawnie zawartość rejestrów sprzętowych we
>> wszystkich odmianach chipow ? Debugowanie krokowe nie zawiesza sie
>> jak się za szybko klawisze wciska ? Stos wywołań jest "dekryptowany"
>> poprawnie ?
>
> Nie zauważyłem problemów na F4, L0 i L1.
>
No coż, sprawdze jeszcze raz. Uzywasz EmbSysRegView czy cos innego ?

>> Init skrypty dla gdb i linker skrypty sa dostepne czy trzeba je
>> reczenie pisac za kazdym razem dla nowego ukladu ?
>
> Skrypty linkera zawsze udawało mi się znaleźć Googlem.
>
Smutne jest to, że środowiska za spora kase też nie dzialają w pełni
poprawnie.

Kupilem CrosWorks to crashowalo sie przy debugowaniu programu pisanego w
C++. Na rozwiazanie problemu przez support w sumie sie nie doczekałęm.
(Przeszedlem na TrueStudio).

Kupilem TrueStudio który też ma problem z debugowaniem programu C++ jako
tasku FeeRTOSa. I tu też dałem sobie spokój z korespodowaniem z
supportem. Aczkolwiek jeden inny bład zgłoszony przeze mnie został w
nowej wersji poprawiony.

Pozdrawiam

Marek

do góry

On 2016-01-11 22:16, Marek Borowski wrote:
> To tak na
> szybko z przyjemnosci jakie pamietam podczas prob uzywania w/w, a ktore
> prawie nie istnieja przy uzywaniu komercyjnych produktów.

Zapomniałeś jednak o czyms zupełnie innym. Komercyjne kompilatory mają
zawsze coś do dupy. Albo 0 wsparcie dla C++ albo optymializacje które
przedszkolak napisał by lepiej czy kłopoty z kodem trudniejszym niż
miganie diodą. O absurdalnych bugach z gatunku "to akurat nie działa i
co nam zrobicie" nie ma co wspomniać. Już nie mam siły brać nastepny
kompilator i punktować dziecinne braki z gatunku "będzie w wersji N+1
albo nie".

Innymi słowy: każde środowisko ma jakiś feler. Różnica polega na tym że
gcc+gdb zazwyczaj ma support community i bardzo duży zbiór ficzerów
języka. Clang podobnie. Natmiast narzedzia komercyjne mają głeboko w
d... frajera który używa ich bardziej twórczo niż przewidzial producent
(czyli np. templates). Czasem narzędzia komercyjne wygenerują lepszy
kod, ale prawie zawsze będą wymagaly "prostszego" kodu źródlowego. Firmą
robiacym chipy nie opłaca sie inwestować w programistow, w dodatku
elitarnych od tworzenia kompilatorów. Robi się byle jak, na kolanie.

Nikt tu nie pisze o lepszości gdb/gcc. To po prostu inny zbiór
problemów. Mi na SAM7 gdzie naintensywniej używalem Eclipse i gdb nie
udało się znaleźć krytycznych problemów które przekreślają to
środowisko. Wręcz przeciwnie, pracowalo się komfortowo i jestem w stanie
zrobić tam wszystko co niezbędne do debugu.

do góry

Marek Borowski <m...@n...com> napisał(a):
> No coż, sprawdze jeszcze raz. Uzywasz EmbSysRegView czy cos innego ?

Zwykłe Eclipse z wtyczkami z http://gnuarmeclipse.sourceforge.net/updates +
OpenOCD pod Windows.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 54 days, 5 hours, 8 minutes and 45 seconds

do góry

W dniu 2016-01-08 o 13:07, Atlantis pisze:
> Jak jest w przypadku innych rodzin? W przyszłości chciałbym się
> przyjrzeć STM32. Jak wygląda robienie projektów na tę platformę z punktu
> widzenia amatora? Dostępne jest darmowe środowisko i kompilator? Nie ma
> żadnych ograniczeń w optymalizacji i/lub rozmiarze generowanego kodu?
>

Za pomocą STM32cubeMX generujesz projekt
http://www.st.com/web/catalog/tools/FM147/CL1794/SC9
61/SS1533/PF259242?sc=stm32cube
dla środowiska System Workbench
http://www.openstm32.org/System+Workbench+for+STM32
wszystko darmowe, oparte na gcc, eclipse, openocd i projekt robi się
automagicznie.

Oczywiście jest sporo upierdliwości, ale prostsze to na początek niż
szukanie po sieci skryptów linkera, startupu, makefile które potem
okazuje się nie pasują do siebie.

Można też użyć mbed - https://www.mbed.com/en/ - jakaś alternatywa.

--
Michał

do góry

On 2016-01-11 22:58, Sebastian Biały wrote:
> On 2016-01-11 22:16, Marek Borowski wrote:
>> To tak na
>> szybko z przyjemnosci jakie pamietam podczas prob uzywania w/w, a ktore
>> prawie nie istnieja przy uzywaniu komercyjnych produktów.
>
> Zapomniałeś jednak o czyms zupełnie innym. Komercyjne kompilatory mają
> zawsze coś do dupy. Albo 0 wsparcie dla C++ albo optymializacje które
> przedszkolak napisał by lepiej czy kłopoty z kodem trudniejszym niż
> miganie diodą. O absurdalnych bugach z gatunku "to akurat nie działa i
> co nam zrobicie" nie ma co wspomniać. Już nie mam siły brać nastepny
> kompilator i punktować dziecinne braki z gatunku "będzie w wersji N+1
> albo nie".
>
Wydaje mi się, że jednak wspomiałem (patrz druga połowa postu) :-).

> Innymi słowy: każde środowisko ma jakiś feler. Różnica polega na tym że
> gcc+gdb zazwyczaj ma support community i bardzo duży zbiór ficzerów
> języka. Clang podobnie. Natmiast narzedzia komercyjne mają głeboko w
> d... frajera który używa ich bardziej twórczo niż przewidzial producent
> (czyli np. templates). Czasem narzędzia komercyjne wygenerują lepszy
> kod, ale prawie zawsze będą wymagaly "prostszego" kodu źródlowego. Firmą
> robiacym chipy nie opłaca sie inwestować w programistow, w dodatku
> elitarnych od tworzenia kompilatorów. Robi się byle jak, na kolanie.
>
Dlatego brałem pod uwagę te bazujące na gcc, ale i tak jak wspominałem
nie do końca jest wszystko ok.

> Nikt tu nie pisze o lepszości gdb/gcc. To po prostu inny zbiór
> problemów.
Dokladnie tak.

> Mi na SAM7 gdzie naintensywniej używalem Eclipse i gdb nie
> udało się znaleźć krytycznych problemów które przekreślają to
> środowisko. Wręcz przeciwnie, pracowalo się komfortowo i jestem w stanie
> zrobić tam wszystko co niezbędne do debugu.
>
Kto cos co woli, mi tam sie pluginów do eclipsa debugowac/pisac nie chce.

Pozdrawiam

Marek

do góry

On 2016-01-13 21:56, Marek Borowski wrote:
>> Mi na SAM7 gdzie naintensywniej używalem Eclipse i gdb nie
>> udało się znaleźć krytycznych problemów które przekreślają to
>> środowisko. Wręcz przeciwnie, pracowalo się komfortowo i jestem w stanie
>> zrobić tam wszystko co niezbędne do debugu.
> Kto cos co woli, mi tam sie pluginów do eclipsa debugowac/pisac nie chce.

SAM7 debugowalem na gołym eclipse CDT.

do góry

Atlantis wrote:

> Swoją zabawę z programowaniem MCU zaczynałem od AVR-ów. Muszę przyznać,
> że Atmel jest firmą szczególnie sprzyjającą amatorom - udostępnili za
> darmo środowisko i pełnosprawny kompilator.

Niedługo może nie być czegoś takiego jak Atmelki -- będą PICe z rdzeniem
AVR: ;->

http://www.reuters.com/article/us-atmel-corp-m-a-mic
rochip-tech-idUSKCN0UR1UJ20160113


Pozdrawiam, Piotr

do góry

On 2016-01-14 15:51, Piotr Wyderski wrote:
[...]
> Niedługo może nie być czegoś takiego jak Atmelki -- będą PICe z rdzeniem
> AVR: ;->
>
> http://www.reuters.com/article/us-atmel-corp-m-a-mic
rochip-tech-idUSKCN0UR1UJ20160113
To tak przy okazji warto dodać, że Mikrochip niedawno łyknął Micrel-a:
https://www.microchip.com/pagehandler/en-us/aboutus/
acquisitions/micrel-acquisition.html

do góry

JDX wrote:

> To tak przy okazji warto dodać, że Mikrochip niedawno łyknął Micrel-a:

I Supertex. :-)

A Siemens/Infineon łyknął International Rectifier.

Pozdrawiam, Piotr

do góry