STM32Cube

Petr Labaj labaj na volny.cz
Sobota Březen 25 20:25:07 CET 2023


Co je pozitivní vlastnost? Že je tam defaultně "něco jako OpenOCD", ale 
osekané?

Asi jsem divnej, ale když něco vyvíjím, tak se vždy snažím, aby to bylo 
co nejkompatibilnější s běžným vybavením zákazníků.
Nebo když už dostanu zadání, že tam musí fungovat vendor-locking, tak 
prostě udělám skutečný vendor-locking.
Ale nějaké takové podivné polovičaté řešení?
(pokud to tedy je tak, jak jsem to z postu pana weka pochopil)

No co už. Je toho víc, co dneska nechápu. Tak zřejmě přibyla další položka.
Když může mít někdo fluidní pohlaví, tak proč by nějaký SW nemohl mít 
fluidní GDBserver, že.

PL

********************

Dne 25.3.2023 v 20:00 Jaroslav Buchta napsal(a):
> To je snad naopak pozitivni vlastnost ne? Je to vsechno zalozeno na 
> open source software, on by nebyl problem tam OpenOCD pridat i 
> naprosto nezavisle na STM ale musi se to umet nastavit. Proc by 
> nasi.ali potencialni odberatele jejich produktu. Jednou koupi klon, na 
> vyvojove nastroje si zvykne a uz bude treba jako profik kupovat 
> originaly, typicky...
> Dne 25.03.2023 v 19:11 Petr Labaj napsal(a):
>> Pochopil jsem prosím z Vašeho textu správně, že STM si do Cube 
>> strčilo nějakou
>> svou verzi OpenOCD (nebo jiného DGBserveru)? A že umožňuje spustit 
>> buď běžné
>> OpenOCD (a tím pádem podporovat všechno, co i jen vzdáleně připomíná 
>> STM32)
>> nebo použít nějaké své řešení, kde záměrně potlačí možnost použít klony?
>>
>> Pokud to tak je, tak mi to připadá trochu zvláštní a nesystémové.
>> Buď chci klony vyloučit, pak přece nepovolím jejich použití nějakým 
>> univerzálním
>> OpenOCD. Nebo je potlačovat nechci, a pak je taková kulišárna trochu 
>> zbytečná.
>>
>> Každopádně zajímavé. A další argument pro to, se tohoto vývojového 
>> prostředí
>> nedotknout ani klackem.
>>
>> Díky.
>> PL
>>
>> ********************
>>
>> Dne 25.3.2023 v 9:35 Jan Waclawek napsal(a):
>>>> Ze je třeba zapnout OpenOCD přece vůbec nesouvisí s tím, jestli mám
>>>> procesor STM32 na Blue-pill z Číny, nebo STM32 na pozlacené desce z 
>>>> NASA.
>>> Nie. Suvisi to s tym, ze na na pozlatenej doske z NASA je STM32 a na 
>>> tom
>>> tom bluepill nie je STM32.
>>>
>>>> Mně fungují vąechny, kupované v rozpětí mnoha let od mnoha prodejců.
>>>> Kdyby mi nějaká nejela, tak bych se tedy určitě nespokojil s tím, ľe
>>>> pouľiju jinou (navíc starąí) verzi vývojového nástroje. Ale snaľil
>>>> bych se zjistit proč a kde je odchylka.
>>> To je chvalyhodne a uprimne sa tesim na to diskutovat to ked k tomu 
>>> pride
>>> (resp. ak k tomu pride); ale toto vlakno predpokladam stale mieri na
>>> zaciatocnika (pana kolegu Andela), ktory momentalne bojuje s inymi
>>> zaciatocnickymi problemami. Pan kolega Prichy preto spravne 
>>> upozornuje na
>>> mozne zadrhele.
>>>
>>>> Aktualne tusim IDE pouziva defaultne primo upraveny GDB
>>> GDB je "len" interpreter debug informacii z .elf-u a command 
>>> processor (1),
>>> t.j. na jednom konci mu clovek (alebo v pripade toho CubeIDE samotny
>>> Eclipse v debugovacom rezime (0) ) dava prikazy typu "vloz 
>>> breakpoint na
>>> riadok 18", a na druhom konci z neho vypadavaju prikazy typu "vloz
>>> breakpoint na adresu 0x08001234". Medzi tym druhym koncom a debugovanym
>>> mcu musi byt nejaky medzikus (2), ktory prikaz "vloz breakpoint na 
>>> adresu
>>> 0x08001234" zmeni na seriu zapisov do internych debug registrov, a 
>>> dalsi
>>> medzikus (3), ktory tie prikazy zmeni na prud nul a jedniciek priamo na
>>> debugovacich pinoch mcu.
>>>
>>> Na (2) a (3) je niekolko rieseni. (2) byva obvykle kus softwaru 
>>> priamo v PC
>>> a (3) je hardware, s ktorym sa (2) rozprava obvykle cez USB.
>>>
>>> V pripade CubeIDE (ktory nepouzivam), ak dobre viem, je (2) 
>>> standardne tzv.
>>> GDBServer (znova, je dolezite pouzivat vsetky slovicka, to "server" 
>>> je tu
>>> dolezite, je to uplne iny program nez gdb), co je program ktory si 
>>> ST sam
>>> napisal. Ak sa v CubeIDE da nastavit OpenOCD, tak to je znova volba pre
>>> (2), ktora je open source, mimochodom tu podporu pre STM32 do neho pise
>>> tiez ST (lebo si treba vyhodit z hlavy myslienku, ze open source robia
>>> predovsetkym nadsenci, nie, nerobia). Ale je open source, takze tam je
>>> pravdepodobne moznost nejake kontroly originality vyhodit, resp. 
>>> mozno ich
>>> tam ST prave kvoli tej moznosti ani nedava.
>>>
>>> (3) je prave spominany STLink, alebo znamou alternativou su rozne 
>>> varianty
>>> JLink od Seggeru.
>>>
>>> Pomerne unikatne riesenie, co spomina pan kolega Labaj, je BMP, ktory
>>> kombinuje (2) a (3) do jedneho hardwaru.
>>>
>>> Pridajme k tomu este editor (-2) a prekladac (-1) a mame kompletne 
>>> vyvojove
>>> prostredie.
>>>
>>> Aj pre (0) a (1) su alternativy, aj ked pravdepodobne s vynimkou 
>>> "tradicne
>>> drahych rieseni" ako su IAR a Keil (u toho Keila je ten "community
>>> edition" ako bol pan kolega Janis spomenul), ktore integruju vsetko od
>>> (-2) po (2) v sebe (co sa snazi CubeIDE ale trebars aj Raisonance, 
>>> Atollic
>>> pamati blahej apod. emulovat vyskladanim z komponentov) sa ako (1) vzdy
>>> pouziva gdb. Segger ma nieco klikacie co kombinuje (0)..(2) (s cielom
>>> podporovat ich vlastne (3), pochopitelne); a existuje taka vec ze
>>> VisualGDB co je kombinacia (0)..(2) ale samostatne nie je zivotaschopna
>>> ale je to plugin do Visual Studia, ktore k tomu potom dodava 
>>> (-2)..(-1).
>>>
>>> Ja ako (-2) pouzivam lubovolny programatorsky editor (konkretne moj
>>> oblubeny psickovsky Crimson Editor), ako (-1) binarny balik s gcc od 
>>> ARMu,
>>> ako (0) pouzivam seba, ako (1) pouzivam holy gdb v rezime prikazovy 
>>> riadok
>>> (ako protiklad k rezimu ovladania z ineho programu), ako (2) pouzivam
>>> OpenOCD a ako (3) pouzivam STLink z Nuclea/Disca.
>>>
>>> wek



Další informace o konferenci Hw-list