Re: HW aj SW vyvojove prostriedky pre STM32, Was: STlink programátor - bylo Re: perspektiva řady Xmega od Atmelu

[František Burian]

Zdravim,

  Jelikoz jsem aktivnim autorem libopencm3 tak reaguji. Snad nikoho 
neurazim.

Libopencm3 je podle meho nazoru prozatim to nejlepsi co jsem zatim nasel, 
ale tahne za sebou velmi dlouhou historii s bourlivym vyvojem, a kazdy napad
je dlouho probirany nez se dostane do masteru. Ja jsem mel dost problemu s 
obhajobou disertace tak jsem se odmlcel, pravda uz dlouho jsem ty stm32 
nemel v ruce, takze bych se mel pripojit.

Od libopencm3 ve skutecnosti maji klice tri lide, karlp, esden, a ja. Esden 
mel hodne prace a karlp je proti nejakemu hlubsimu cisteni knihovny ve 
smyslu narovnani prehistorickych API ktere funguji jen na F1 kde to vsechno 
zacalo. Bohuzel toto je presne ten duvod jakym funguje opensource - kazdy 
strom roste, do doby nez narazi na prekazku a od te doby roste do vice stran
aby obesel prekazku. A jen cas ukaze ktera vetev je silnejsi a uchyti se.

Soucasny stav je takovy:

- API je navrzeno tak ze je nekompatibilni mezi F1 a zbytkem (F02347) - 
zejmena nastaveni GPIO porad kritizuji a posledni pull requesty delaji hodne
noveho a dobreho ale nikdo je nechce schvalit. Dale je nekompatibilni 
nastaveni RCC clocku, ikdyz diky me se to podarilo aspon castecne narovnat.

- Vetsina modulu je zapsana dle datasheetu, velmi malo je skutecne testovano
! Kdyz se podivate do F1 knihovny, objevite i pouhym okem diry v deklaracich
a nesrovnalosti v pozicich bitu ! V tomto vidim velky problem, pokusy o 
vytvoreni testu tu nejake byly (jsou v maintainer-tools) a opet vedeme s 
karlp hruby spor o to co je to TEST a co je to EXAMPLE, kdy karlp by to rad 
mel v jednom a ja separovane. Proto nejdeme dal protoze nas nikdo dalsi 
nerozsoudil (Esden toho casu mel mnoho prace a nereagoval).

- Examply jsou jen na F1 a vzhledem k nekompatibilite API mezi F1 a zbytkem 
nejdou pouzit jinde. Na zbytek jsou ale je jich jako safranu. Je malo 
dobrovolniku kteri by psali dobre pochopitelne a jednoduche examply. Spor s 
karlp TEST vs EXAMPLE (on tlaci variantu ze example by mel byt jeden c 
soubor zamakrovany do pate urovne, zkompilovatelny pro uplne vsechny 
platformy, ja tlacim variantu ze example by mel byt ladeny na architekturu 
(napr STM32, SAM3 ..) a pouzivat api na nejnizsi urovni, primo volani API 
funkci, co mozna nejmene skryvani se za makra - spor zatim bezi neni 
rozresen)

- Knihovna si historicky ssebou tahne prasarnu jako dynamicky generovane 
headery z nejakych "datovych" souboru, ktere jsou stejne architekturove 
zavisle, a diky tomuto generovani si ssebou tahne zavislost na docela 
konkretni verzi Pythonu coz nese velke komplikace pro sestrojeni windows 
toolchainu ktery to schrousta. Opet karlp zablokoval jakykoliv pokus tuto 
zavislost odstranit a kod vycistit. Resenim pro me bylo ze studentum nabizim
jeden exe ve kterem je vsechno predchystane a nainstaluje to vse potrebne 
vcetne spoluprace s IDE CodeBlocks (ale jde to pouzivat i s makefile). Na 
githubu mam forky kde je v gitu i s vygenerovanymi headery takze je ocistena
zavislost na Pythonu - jenze v masteru probehly mezitim zmeny, byly pridany 
architektury tak tato vetev zastarala.

- Knihovna si ssebou tahne hodne necisty zpusob buildovani jednotlivych 
knihoven, kdy neni zaruceno ze vsechny budou mit stejne parametry 
kompilatoru (napriklad f1 je kompilovana s mene warningy nez f4 a z toho 
plynouci prekvapeni ze ruzne architektury se chovaji ruzne). Muj pokus to 
sjednotit byl zastaven (pravda uznavam, ja to o hodne prekomplikoval jeste s
linker script generatorem a dalsimi moduly ... chce to revizi a vic smeru)

- DOKUMENTACE - kdo nekdy pracoval s knihovnou, ktera ma dokumentaci jen v 
Doxygenu, pochopi.

- Navaznost na jine knihovny - zeleny je strom zivota, a uplne stejne 
plesnivy je svet dalsich knihoven. Udelat API takove, aby se dobre 
navazovalo na dalsi knihovny, a fungovalo to spolehlive je prace na plny 
uvazek. Ja se zasekl na spolupraci s lwIP, musel jsem prvne prepsat celou 
nizkou uroven lwIP, odstranit tam hrube memleaky (co si vzpominam, byly v 
ARPu ale tim CodingStyle kterym je to psane, s makry v makrech byly okem 
neodhalitelne) aby mi to fungovalo spolehlive. Jenze to nemohu prohlasit, ze
pouzivam lwip, kdyz z lwip je pouzito pouze par vyssich funkci, takze 
ethernet je tam stale rozpracovany, byt mi to jiz na stole a v robotech jede
docela slusne.

Toto jsou zatim jedina negativa, na kterych se snazime zapracovat - a jak je
tomu u opensource zvykem - vsechno chce cas, delame to po praci, ve svem 
volnem case. Kazdy mame ten volny cas nekdy jindy, a holt jsou problemy, 
jejichz reseni v pullrequestech se nam libi, ale nemame odvahu je dostat do 
masteru. 

Jdu si opeci spekacek, nez bych sedel za monitorem,

mejte se

Franta.




---------- Původní zpráva ----------
Od: Jan Waclawek <konfera na efton.sk>
Komu: HW-news <hw-list na list.hw.cz>
Datum: 29. 5. 2015 17:14:03
Předmět: Re: HW aj SW vyvojove prostriedky pre STM32, Was: STlink 
programátor - bylo Re: perspektiva řady Xmega od Atmelu

">> Potom existuje aj nejaka open-source iniciativa urobit SPL open-source 
>> protikus, ale jednak neviem ako sa to vola, a druhak sa mi zda, ze to 
>> ustrnulo v pohybe, ale nesledujem to. 
>
>libopencm3? http://libopencm3.org
>

Ten, dakujem. Sledujete to? V akom je to stave?

wek




_______________________________________________
HW-list mailing list - sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20150529/f17995be/attachment.html>