> Tak wiem, najzwyczajniej zastanawia mnie co można spieprzyć w zwykłym
> debugu pod Eclipse że podgląd zmiennych jest koślawy...

1.
Podgląd jest OK, koślawa (przynajmniej dla mnie) jest obsługa programu
STM32CubeMonitor.

2.
Nie wydaje mi się, żeby STM32CubeMonitor też był oparty o Eclipse.

do góry

stary grzyb <s...@o...pl> napisał(a):
> 1.
> Podgląd jest OK

Zależy od humoru IDE i fazy księżyca.
Failed to execute MI command
Nie mamy pańskiej zmiennej i co nam Pan zrobi?
Co ciekawe po jakimś czasie samo się naprawia. Eclipse ma jeszcze inne
niedoróbki, więc może trzeba będzie spróbować VSCode.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 14/07/2022 20:53, Grzegorz Niemirowski wrote:
> Failed to execute MI command

Akurat protokół MI to wina gdb. Troche to ogarniałem od strony
programistycznej i MI po prostu jest spieprzony, więc nie wincie Eclipse
że gdb pisze banda ignorantów nie potrafiących prawidłowo escapeować
znaków specjalnych.

> Nie mamy pańskiej zmiennej i co nam Pan zrobi?

Można zgłosić buga na MI. Zazwyczaj olewają.

> Co ciekawe po jakimś czasie samo się naprawia. Eclipse ma jeszcze inne
> niedoróbki, więc może trzeba będzie spróbować VSCode.

To nie wina Eclipse ;) Niektóre odpowiedzi MI z gdb wymagaja szklanej
kuli. Niektóre debuggery mają lepsze od Eclispe.

do góry

On 14.07.2022 15:04, Cezar wrote:
> On 14/07/2022 13:23, JDX wrote:
>
>>
>>> Ciągle mam wrażenie, że Rust to taki odpowiednik <foo> w dziedzienie
>>> telefonów. Był, zmieniał świat w 2 lata i umarł.
>> Przez klasę robotniczą Rust jest ciągle kochany:
>> https://survey.stackoverflow.co/2022/#section-most-l
oved-dreaded-and-wanted-programming-scripting-and-ma
rkup-languages. I chyba ma tendencję wzrostową. Aczkolwiek zdaję sobie sprawę, że
branży embedded (zwłaszcza bare metal) jego użycie jest zapewne praktycznie zerowe.
>>
>
> To sie może zmienić bo Linus T. jakoś ostatnio przyznał że Rust się w
> końcu pojawi w kernelu. Nie jest to baremetal ale już coś...
Mnie się wydawało, że dowolny kernel z definicji jest bare metal. :-)
Chociaż wiem, że ilość kodu zależnego od CPU i okolic w jądrze systemu
ogólnego przeznaczenia, do tego potężnego ze względu na rozmiar kodu
źródłowego, jest mała czy wręcz znikoma.

> Jest jeszcze TinyGo, który z Go ma tyle wspólnego że składnia jest
> identyczna i większość bibliotek PureGo będzie działała.
> Plusem jest przenośność kodu pomiędzy platformami. Może być przydatne do
> prototypowania :-)
Na temat Go wiem tyle, że istnieje taki język programowania. W każdym
razie zauważyłem, że istnieje jakaś ,,wojenka" Go vs. Rust, tzn. że
często są one porównywane.

do góry

On 15/07/2022 08:46, JDX wrote:
> On 14.07.2022 15:04, Cezar wrote:
>> On 14/07/2022 13:23, JDX wrote:
>>
>>>
>>>> Ciągle mam wrażenie, że Rust to taki odpowiednik <foo> w dziedzienie
>>>> telefonów. Był, zmieniał świat w 2 lata i umarł.
>>> Przez klasę robotniczą Rust jest ciągle kochany:
>>> https://survey.stackoverflow.co/2022/#section-most-l
oved-dreaded-and-wanted-programming-scripting-and-ma
rkup-languages.
>>> I chyba ma tendencję wzrostową. Aczkolwiek zdaję sobie sprawę, że
>>> branży embedded (zwłaszcza bare metal) jego użycie jest zapewne
>>> praktycznie zerowe.
>>>
>>
>> To sie może zmienić bo Linus T. jakoś ostatnio przyznał że Rust się w
>> końcu pojawi w kernelu. Nie jest to baremetal ale już coś...
> Mnie się wydawało, że dowolny kernel z definicji jest bare metal. :-)
> Chociaż wiem, że ilość kodu zależnego od CPU i okolic w jądrze systemu
> ogólnego przeznaczenia, do tego potężnego ze względu na rozmiar kodu
> źródłowego, jest mała czy wręcz znikoma.
>
Dla mnie baremetal to raczej coś co działa bez OSa lub jakieś
minimalistyczny OS. RTOS już się chyba nie zalicza do bare metal.
Coraz więcej projektów wychodzi na RPI bare metal


>> Jest jeszcze TinyGo, który z Go ma tyle wspólnego że składnia jest
>> identyczna i większość bibliotek PureGo będzie działała.
>> Plusem jest przenośność kodu pomiędzy platformami. Może być przydatne
>> do prototypowania :-)
> Na temat Go wiem tyle, że istnieje taki język programowania. W każdym
> razie zauważyłem, że istnieje jakaś ,,wojenka" Go vs. Rust, tzn. że
> często są one porównywane.

W Go siedze głęboko od 8 lat a początki miałem jeszcze przed wersją 1.0
chyba.

Do Rusta miałem kilka podejść i jakoś nigdy sie nie mogłem przekonać.
Zawsze wyszło że w Go zrobie to prościej a wydajność nie jest wielkim
problemem.



c.

do góry

On 15.07.2022 10:49, Cezar wrote:
[...]
> Do Rusta miałem kilka podejść i jakoś nigdy sie nie mogłem przekonać.
> Zawsze wyszło że w Go zrobie to prościej a wydajność nie jest wielkim
> problemem.
Ale jeśli ktoś celuje w niski poziom, to już drugie zdanie z artykułu na
temat Go w angielskiej Wikipedii jest zniechęcające: ,,It is
syntactically similar to C, but with memory safety, garbage collection..."
O ten odśmiecacz chodzi...

do góry

On 15/07/2022 10:16, JDX wrote:
> On 15.07.2022 10:49, Cezar wrote:
> [...]
>> Do Rusta miałem kilka podejść i jakoś nigdy sie nie mogłem przekonać.
>> Zawsze wyszło że w Go zrobie to prościej a wydajność nie jest wielkim
>> problemem.
> Ale jeśli ktoś celuje w niski poziom, to już drugie zdanie z artykułu na
> temat Go w angielskiej Wikipedii jest zniechęcające: ,,It is
> syntactically similar to C, but with memory safety, garbage collection..."
> O ten odśmiecacz chodzi...
>

No wiadomo - GC w Go jest ale jak się troche popisze to można działanie
GC zminimalizować do minimum. Z resztą GC w Go działa wyjątkowo dobrze.
Jak czasami sobie porównujemy z Javą to nie wiem kto jeszcze ten syf
(Jave) używa...

do góry

On 15/07/2022 11:35, Cezar wrote:
> Jak czasami sobie porównujemy  z Javą to nie wiem kto jeszcze ten syf
> (Jave) używa...

Ciągle używają "wszycy", tzn pare miesiący temu widziałem oszacowanie
ilosci Javy w embedded i kiedy podliczono np. karty SIM itp duperele,
wyszło im rzedy wielosci więcej niż cokolwiek innego. Nie wiem czy
zdołam odkopać link, nawet nie pamiętam tytułu.

Tak, że Java Javą, ale ignorować nie należy.

Co do wydajności GC ... java coś tam w rękawie ma.

https://en.wikipedia.org/wiki/Real_time_Java
https://www.youtube.com/watch?v=lXct7Bzdhzw

Akuratnie uzywany w Javie GC ejst jaki jest - nadaje się do innego typu
aplikacji. Nie ma problemu z wymianą na taki Real-time albo bardziej
kernelowy. To wszystko jest w Javie abstrakcyjne i wymienne.

do góry

On 15/07/2022 10:56, heby wrote:
> On 15/07/2022 11:35, Cezar wrote:
>> Jak czasami sobie porównujemy  z Javą to nie wiem kto jeszcze ten syf
>> (Jave) używa...
>
> Ciągle używają "wszycy", tzn pare miesiący temu widziałem oszacowanie
> ilosci Javy w embedded i kiedy podliczono np. karty SIM itp duperele,

tylko że to zupełnie inna Java


> wyszło im rzedy wielosci więcej niż cokolwiek innego. Nie wiem czy
> zdołam odkopać link, nawet nie pamiętam tytułu.
>
> Tak, że Java Javą, ale ignorować nie należy.
>
> Co do wydajności GC ... java coś tam w rękawie ma.
Ma tyle że średni programista nie wiem jak to działa a jak coś nie
działa to się woła konsultanta żeby sprawdził i skasował ?2k za dniówkę.


> https://en.wikipedia.org/wiki/Real_time_Java
> https://www.youtube.com/watch?v=lXct7Bzdhzw
Takie coś to Arduino potrafi

>
> Akuratnie uzywany w Javie GC ejst jaki jest - nadaje się do innego typu
> aplikacji. Nie ma problemu z wymianą na taki Real-time albo bardziej
> kernelowy. To wszystko jest w Javie abstrakcyjne i wymienne.

No widzisz ja tego nie czaje ale ja to z tych co truskawki cukrem posypują.
Teraz piszemy wszystko cloud native pod k8s i nie czaje tego że
konterner (mikroserwis) Javowy musi mieć 500MB, używać 8GB ramu minimum
2vcpu i potrzebuje 30s żeby się zgłosił gotowy.

c.

do góry

On 15/07/2022 12:42, Cezar wrote:
>> Ciągle używają "wszycy", tzn pare miesiący temu widziałem oszacowanie
>> ilosci Javy w embedded i kiedy podliczono np. karty SIM itp duperele,
> tylko że to zupełnie inna Java

Ciągle Java ;)

No dobra, ta w kartach SIM to żenada, faktycznie. Ale Java ;)

>> Co do wydajności GC ... java coś tam w rękawie ma.
> Ma tyle że średni programista nie wiem jak to działa a jak coś nie
> działa to się woła konsultanta żeby sprawdził i skasował ?2k za dniówkę.

To samo mogę powiedzieć o embedded. Smart pointers? Nikt nie słyszał.
Szablony? Za mało flasha. Klasy? Zabronione bo Staszek się nie zgadza.
Silne typowanie? To dla ciot. Itp debilizmy.

Wszędzie są ludzie niechętni do burzenia własnych kokonów ignorancji.

>> https://en.wikipedia.org/wiki/Real_time_Java
>> https://www.youtube.com/watch?v=lXct7Bzdhzw
> Takie coś to Arduino potrafi

Tutaj chodzi o to, że ta ślamazarna Java może być jezykiem RT. Wystarczy
troche chcieć i zmienić kilka abstrakcji.

Prawdę mówiąc, imponujące, że w ogóle się da do tego stopnia odmienić
język. C w tym przypadku wygląda jak beton zbrojony asemblerem.

>> Akuratnie uzywany w Javie GC ejst jaki jest - nadaje się do innego
>> typu aplikacji. Nie ma problemu z wymianą na taki Real-time albo
>> bardziej kernelowy. To wszystko jest w Javie abstrakcyjne i wymienne.
> No widzisz ja tego nie czaje ale ja to z tych co truskawki cukrem posypują.
> Teraz piszemy wszystko cloud native pod k8s i nie czaje tego że
> konterner (mikroserwis) Javowy musi mieć 500MB, używać 8GB ramu minimum
> 2vcpu i potrzebuje 30s żeby się zgłosił gotowy.

Myślę, że to taka sama nieprawda jak bredzenie embedowców że aplikacje w
C++ mają kilkset MB.

Najzwyczajniej widzisz kiepskich programistów uzywających kiepskiego
zestawu biblitek do niewłasciwych zastosowań.

To samo można osiągnąc w każym innym języku.

Czepiasz się Javy, ale to raczej leniwy styl pisania w Javie jest
problemem, nie sam język. Tak, z jakiegoś powodu programy w Javie pisze
się w sposób niespcjalnie zwaracający uwagi na zasoby.

Dla równowagi: napisałem panel sterujacy urządzeniem, w Javie, na
maluteńkim procesorze Samsunga który ledwo ciągnie Linuxa. Wymagało go
kernelowania kompili, ale dało radę. Responsywnośc zaskakująca. Bazuje
na Swingu + touchscreen, sporo kontrolek, wskaźników, kilka wątków,
komunikacja z urządzeniem, zagadnienia realitme.

Ta zła Java...

Na tym samym cpu można było odpalić QTopię. Takie GUI w C++ udające
system operacyjny. Responsywnośc gorsza na oko.

Zła, niedobra Java.

do góry