STM32Cube

[Petr Labaj]

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
>
>
>
> ----- Original Message ---------------
> Mozna jde o nejake nekompatibility, ktere cinsky klon ma a OpenOCD je
> zvlada. Aktualne tusim IDE pouziva defaultne primo upraveny GDB asi
> vlastnimi silami, ktery nepochybne nebude s Cinskymi klony pocitat. Ale
> zkusenosti s tim nemam, nepouzivam.
> Dne 25.03.2023 v 5:47 Petr Labaj napsal(a):
>> Snaľil jsem se pochopit tento post. Ale nerozumím prakticky ani jedné
>> větě (a uľ vůbec ne té poslední, ale to je asi moje mentální postiľení
>> :-( ).
>>
>> ®e 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.
>> Je to dáno principem, ľe debugger vývojového prostředí očekává, ľe mu
>> někdo bude poskytovat sluľby, které jsou zde realizovány pomocí OpenOCD.
>> A to OpenOCD pak komunikuje s vlastním programátorem STlink (nebo jiným).
>> Malá odbočka: u mého oblíbence Blackmagic Probe to tak není. To BMP
>> rovnou poskytuje i sluľby, které jinak musí dělat OpenOCD.
>>
>> Proč nějaká pilulka jede jen s nějakou verzi CubeIDE a s jinou ne, no
>> tak to rovněľ nechápu.
>> 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.
>>
>> PL
>>
>> ********************
>>
>> Dne 24.3.2023 v 16:42 Prichy napsal(a):
>>> Jen doplním, ľe pokud jde o bluepill z ali atd, tak je třeba zapnout
>>> OpenOCD a hlavně, některé fejkové bluepill jsem rozjel pouze na
>>> dřívějąích STM32CubeIDE verzích. Něco jde například pouze v 1.3 atd.
>>> BlackPill nejsou tak fejkované....a nebo jinak, nemají takové problém.
>>> Cube je opravdu dobrý nástroj.
>