Harmony nisam probao ali planiram kada uhvatim malo vremena.
Kao ostali slazem se sa konstatacijom da je taj (ili bilo koji drugi) frejmwork prosto postao nametnuti nacin rada i za ljude koji su nekad pisali u ASM, Forth i ostalim low-level jezicima i okruzenjima, stvarno igleda preglomazan, nepouzdan, komplikovan itd.
Medjutim, postavite se u ulogu developera koji pise te frejmwork-ove, kome je posao da po ceo dan u tome pise nekakav code, jos u timu da se "slozite" i namirite sve "zelje-i-cestitke" koje se tu traze, naravno da je bezuslovno potrebno da se ceo tim programera sinhronizuje i da ra radi svako na svom zadatku, ne ugrozavajuci code drugih developera i tada je neophodno da se uvede jedan "vislji" nivo organizacije code-a gde sad u ovom spomenutom slucaju sa Harmoni imamo jedan relativno prost API sa kojim komuniciramo sa periferijama.
Takodje, alati, pisalo se nekad i u "ed", "vim", pa UltraEdit …
Ne vredi, potrebno je da se koriste ova nova GUI okruzenja, IDE koji pod svojom kapom imaju (uglavnom) sve sto treba da se vodi jedan projekat, od source repozitori (SVN, GIT), preko build skripti, debug i ostalo.
Nivo programiranja je sad prakticno isti za bilo kakve SW i HW aplikacije, unificiran je work-flow, mnooooogooo code-a je vec napisano za jedne te iste stvari (sad koji je dobar je drugo pitanje) ali generalno pisali za PIC, STM ili nesto trece svodi se na isto, code baza jednih isti LCD, I2C, SPI, GPIO drivera itd.
Sedite pa napisite u "svom" pseudo jeziku ove funkcije i napravite parser i compajler za C/C++ ili ASM pa ce da radi fino, a sto ce se potrositi stotine sati rada to niko ne pita … i da bude cross-prevodivo …
Moze i u Forth, moze i u Luna, C, Python, JavaScript … moze i ceo Linux da se potera (embeded linux), zavisi sta vam treba …
Ozbiljno i profesionalno programiranje zahteva ozbiljnu posvecenost i podosta vremena i realno bez svih ovih moternih alata pisati code za MCU je realno mucenje, nisu oni za dzabe napravljeni, ima tu dobrih koncepta i pristupa, stedi se dosta vremena na nekim stvarima.
Pa dalje, ko od vas radi Unit Testing ili slican code-base testing patern? Slabo?
Pa naravno, zato sto programiramo, letujemo, busimo, idemo na teren da montiramo, popravljano umesto da se ozbiljno posvetimo pisanju code-a a to zahteva vreme …
Znam ja sta sve moze u 1K da stane sa Forth vrlo dobro i tu nema sumlje ali na srecu ili na zalost prinudjeni smo da koristimo ove nove alate, ne sad ovaj konkretno Harmony (treba da se testira) pricam uopsteno za npr Eclipse, NetBeans i slicnih IDE okruzenja.
Izbor samog framework-a je vrlo bitan korak kod nekog projekta, ako se koristi mora da bude dobro testiran, pouzdan, brz a sad ako nam se potrefi da bude i "citljiv" tim bolje
Kao ostali slazem se sa konstatacijom da je taj (ili bilo koji drugi) frejmwork prosto postao nametnuti nacin rada i za ljude koji su nekad pisali u ASM, Forth i ostalim low-level jezicima i okruzenjima, stvarno igleda preglomazan, nepouzdan, komplikovan itd.
Medjutim, postavite se u ulogu developera koji pise te frejmwork-ove, kome je posao da po ceo dan u tome pise nekakav code, jos u timu da se "slozite" i namirite sve "zelje-i-cestitke" koje se tu traze, naravno da je bezuslovno potrebno da se ceo tim programera sinhronizuje i da ra radi svako na svom zadatku, ne ugrozavajuci code drugih developera i tada je neophodno da se uvede jedan "vislji" nivo organizacije code-a gde sad u ovom spomenutom slucaju sa Harmoni imamo jedan relativno prost API sa kojim komuniciramo sa periferijama.
Takodje, alati, pisalo se nekad i u "ed", "vim", pa UltraEdit …
Ne vredi, potrebno je da se koriste ova nova GUI okruzenja, IDE koji pod svojom kapom imaju (uglavnom) sve sto treba da se vodi jedan projekat, od source repozitori (SVN, GIT), preko build skripti, debug i ostalo.
Nivo programiranja je sad prakticno isti za bilo kakve SW i HW aplikacije, unificiran je work-flow, mnooooogooo code-a je vec napisano za jedne te iste stvari (sad koji je dobar je drugo pitanje) ali generalno pisali za PIC, STM ili nesto trece svodi se na isto, code baza jednih isti LCD, I2C, SPI, GPIO drivera itd.
Sedite pa napisite u "svom" pseudo jeziku ove funkcije i napravite parser i compajler za C/C++ ili ASM pa ce da radi fino, a sto ce se potrositi stotine sati rada to niko ne pita … i da bude cross-prevodivo …
Moze i u Forth, moze i u Luna, C, Python, JavaScript … moze i ceo Linux da se potera (embeded linux), zavisi sta vam treba …
Ozbiljno i profesionalno programiranje zahteva ozbiljnu posvecenost i podosta vremena i realno bez svih ovih moternih alata pisati code za MCU je realno mucenje, nisu oni za dzabe napravljeni, ima tu dobrih koncepta i pristupa, stedi se dosta vremena na nekim stvarima.
Pa dalje, ko od vas radi Unit Testing ili slican code-base testing patern? Slabo?
Pa naravno, zato sto programiramo, letujemo, busimo, idemo na teren da montiramo, popravljano umesto da se ozbiljno posvetimo pisanju code-a a to zahteva vreme …
Znam ja sta sve moze u 1K da stane sa Forth vrlo dobro i tu nema sumlje ali na srecu ili na zalost prinudjeni smo da koristimo ove nove alate, ne sad ovaj konkretno Harmony (treba da se testira) pricam uopsteno za npr Eclipse, NetBeans i slicnih IDE okruzenja.
Izbor samog framework-a je vrlo bitan korak kod nekog projekta, ako se koristi mora da bude dobro testiran, pouzdan, brz a sad ako nam se potrefi da bude i "citljiv" tim bolje