Open source programator, was: programator *ROM/MCU

Středa Září 24 01:10:07 CEST 2008

| Od: "Jan Waclawek" <konfera@efton.sk>
|
| > Pomoct napr. tak, ze zpropaguji, ze nase rozhrani je otevrene. 
|
| Prave som spropagoval. Nase rozhranie je otvorene.
|
| > Ze to rozhrani
| > verejne vystavim 
|
| Vystavil ho za mna NXP. Link som uviedol.
|
| > a pomuzu vzniku nejake komunity tim, ze na svem webu
| > (tj. na webu vyrobce) k tomu udelam nejak diskusni forum, 
|
| Dovolil som si zneuzit diskusne forum hw-list. Kedze sa jedna o nadsenecky
| opensource a ja neviemaky projekt, neexistuje vyrobca - ubastli si sam.

Nejsem tedy presvedcen o tom, ze uvedeni linku na dokumentaci k nejakemu
samodomo programatoru je to same, jako dokumentace k profesionalnimu,
bezne prodavanemu vyrobku.
Ale je to jiste vec nazoru.

| > Prispevek toho pana z Elnecu mi pripadal jako skolni ukazka toho, ze kdyz
| > nekdo chce, tak hleda zpusoby jak to udelat. A kdyz nechce, tak hleda duvody
| > proc to neni mozne.
|
| Ten pan z Elnecu na rozdiel od nas, ktori tu nezavazne tlachame, z toho zije.
| A spolu s nim niekolko desiatok inych panov a dam. Z tlachania sa zit neda.

Souhlasim, ze jim by se asi vyvoj pro Linux nevyplatil, pokud by to vyvijeli
sami a pokud jejich soucasny SW neni koncepcne psan tak, aby byl snadno
prenostitelne. Trh je pro to asi dost maly a zrejme i cim dal tim mensi.

Ja jsem polemizoval s nazorem, ze komunitni vyvoj SW neni mozny. 

| > Prece kdyby skutecne chteli svuj SW nejak otevrit, ale pritom si chteli ochranit
| > sve know-how, tak mohli uverejnit napr. knihovny v binarni podobe, ktere
| > by poskytovaly rozhrani na dost vysoke urovni. Tam je jiz know-how bezpecne
| > skryto, a na druhe strane se to uz docela snadno pouziva. 
|
| A napadlo Vas, ze "by poskytovali rozhrani na dost vysoke urovni" je prave ta velmi
| rozsiahla robota s pochybnou navratnostou, o ktorej ten pan z Elnecu hovoril? 

A verite, ze ani ne ? Oni prece musi ve svem SW mit rutiny typu identifikace obvodu,
mazani, blank check, naprogramovani oblasti pameti do ciloveho chipu atd.,
takze staci jen k nim napsat nejakou obalku, aby byly prilinkovatelne k jinemu
programu. A jak si ten jiny program zaridi, aby se v jeho operacni pameti octnul
obsah, kdery pak nasypu do toho chipu, to uz je jeho prace. Jestli to bude
"prog -f soubor.bin -t 27512 -a algoritmus"
nebo to bude nadherne graficke rozhrani, to uz je jedno. Na konci to vzdy skonci
zavolanim "identifikuj/over chip, blank check, program" s osetrenim vyjimecnych
stavu.

Protoze jsem proboha prehlidnul, ze je to Pascalu. A co to zasadne meni
na meritu problemu (krome obtizneji dostupneho kompilatoru) ?
V pripade knihovny je sumafuk, v cem je ta dana knihovna napsana.
Muze to mit vliv max. na konvenci volani (to ale resi headery).

| > tak preportovani techto knihoven
| > z DOSu/Windows treba do Linuxu skutecne neni zadny dabelsky a neresitelny
| > ukol.
|
| Prepacte pan kolega, ale odkial to mozete vediet? Aj keby to prave bolo v C,
| odkial mozete vediet, aka uloha to je? Neriesitelna nie je - to nie je takmer ziadna
| uloha - ale odkial viete, nakolko je to zlozite?

Vedet to nemuzu. Ale muzu to (pravdepodobne) odhadnout.
Predpokladam, ze jste take mnohokrat ve svem profesionalnim zivote musel
udelat rozhodnuti i bez presne a podrobne znalosti problematiky, ze jste proste
musel udelat kvalifikovany odhad, jestli se nejake dilo da udelat nebo neda
a kolik Vam to zhruba da prace (napr. pro stanoveni cenove a casove nabidky).
A predpokladam, ze jste se vetsinou aspon radove trefil. Jiste to neni nahoda,
je to jen tim, ze nedelate prvni vec a uz proste mate nejaky odhad.

| > Misto toho tam ale pan popisuje, kolik strasne moc penez vydali za studii
| > portovatelnosti do Kylixu (pokud nekdo ten Kylix zna, tak to skoro mohl
| > rict od boku).
|
| A toto mate tiez z tej krystalovej gule? Co ak to portovanie do Kylixu v tom
| case by sa ukazalo jednoduche? A co ak to aj napriek tomu ze "skoro mohl rict
| od boku", to bola ta najjednoduchsia cesta? 

Muze se stat. Ale moc pravdepodobne to neni.
Pokud chcete neco portovat, tak si predpokladam vyzkousite a overite
dve veci - pokud je to GUI, tak jestli ma cilova platforma prostredky,
porovnatelne s vasimi soucasnymi, a jestli bude jejich rychlost a vzhled
vyhovujici. No a druha vec je, jestli jsem schopen na cilove platforme
nejak hybat s HW a jestli muzu napsat nejakou mezivrstvu, ktera mi
umozni, aby vyssi vrstvy SW videly ovladani na vsech platformach
stejne (je treba samozrejme overit i moznost casovani, coz je u programatoru
docela podstatne).
No a to oboje podle me neni neco, k cemu bych potreboval kristalovou
kouli. A pokud oboje bude mozne, tak se asi da opravnene predpokladat,
ze ty univerzalni casti SW budou v jednom Pascalu fungovat stejne
nebo velmi podobne, jako v jinem Pascalu.

| > A mimochodem chlubit se tim, ze stale pouzivam programy napsane
| > v letech 1991/92 - nevim. Asi na tom neni nic spatneho, ale taky to neni
| > nic k chlubeni a uz vubec to neni dobry duvod pro brzdeni dalsiho pokroku.
|
| Dovolim si tip: pravdepodobne netusite co vlastne device programmer znamena, ze?

Je to samozrejme mozne. Ja jsem vzdy od programatoru chtel relativne
trivialni veci (cteni, vymaz, zapis, test). Je samozrejme mozne, ze nevyuzivam
cely jejich potencial, ale ja jsem proste nikdy nic vic nepotreboval.

| > Predpokladam, ze vetsina lidi/firem, ktera stale provozuje nejaky zivy projekt,
| > ho cas od casu vpodstate kompletne obmeni. Ne proto, ze by to delala
| > samoucelne. Ale zivot a vyvoj prinasi dalsi pozadavky a zmeny a velmi casto
| > je strategicky vyhodne treba puvodne monoliticky projekt rozdelit do vrstev,
| > knihoven atd. Navic je to obcas treba delat i proto, aby zustala zachovana
| > kompatibilita a "prelozitelnost" v novych vyvojovych nastrojich.
|
| Dovolim si dalsi tip: Vy ste este na ziadnom projekte viac nez 10 rokov nepracovali, ze?

Muj nejstarsi zivy projekt ma pocatek v roce 1991. Takze ano, pracoval.

Pekny den.
rollfree