<html><body>Zdravim,<br><br> Jelikoz jsem aktivnim autorem libopencm3 tak reaguji. Snad nikoho neurazim.<br><br>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.<br><br>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.<br><br>Soucasny stav je takovy:<br><br>- 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.<br><br>- 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).<br><br>- 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)<br><br>- 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.<br><br>- 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)<br><br>- DOKUMENTACE - kdo nekdy pracoval s knihovnou, ktera ma dokumentaci jen v Doxygenu, pochopi.<br><br>- 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.<br><br>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. <br><br>Jdu si opeci spekacek, nez bych sedel za monitorem,<br><br>mejte se<br><br>Franta.<br><br><br><br><p>---------- Původní zpráva ----------<br>Od: Jan Waclawek <konfera@efton.sk><br>Komu: HW-news <hw-list@list.hw.cz><br>Datum: 29. 5. 2015 17:14:03<br>Předmět: Re: HW aj SW vyvojove prostriedky pre STM32, Was: STlink programátor - bylo Re: perspektiva řady Xmega od Atmelu</p><br><blockquote>>> Potom existuje aj nejaka open-source iniciativa urobit SPL open-source <br>>> protikus, ale jednak neviem ako sa to vola, a druhak sa mi zda, ze to <br>>> ustrnulo v pohybe, ale nesledujem to. <br>><br>>libopencm3? http://libopencm3.org<br>><br><br>Ten, dakujem. Sledujete to? V akom je to stave?<br><br>wek<br><br><br><br><br>_______________________________________________<br>HW-list mailing list - sponsored by www.HW.cz<br>Hw-list@list.hw.cz<br>http://list.hw.cz/mailman/listinfo/hw-list</blockquote></body></html>