ATMEGA 644 ukončeno

Zpráva

ross4435897 · #16 Příspěvek od **ross4435897** » 06 led 2015, 19:47

proc myslis ze programatori pouzivaji pokrocile jazyky a ne assembler?

franta22 · #17 Příspěvek od **franta22** » 06 led 2015, 19:53

Mám stejnej názor na C samotné psaní je krkolomné a pisatel programu je svázán terminologii ....vlastní jakoby jednodušši způsob psaní programu v něm vytváři impotenci něco nového vytvořit vymyslet .
......................
Atmegu 644 jsem volil jen proto že se do ní vejde všechno co doposud znám a ještě zbude prostor na novou tvorbu .
.......
Pokud by se našel projekt který by vyžadoval rychle využití všech možností ATMEGY 644 budu se muset asi C rychle doučit.
Doposud jsem zastánce jednoduchosti , spolehlivosti a originality
...
99procent chuti se něco nového naučit je ziskáni SW nástroje který je jednoduchý a výkonný ...a TO je assemblerický překladač spolu se simulátorem pro danej procesor ...viz . METALEX/AT89XXX nebo AVR SIMULATOR IDE /AVR

franta22 · #18 Příspěvek od **franta22** » 06 led 2015, 20:01

programatori zcela evidentne pouzivaji C proto že šlukují programy ze open source a aby byly tvůrci něčeho nového a tajemneho dali tam ty lomitka a nesrozumitelnosti a vše zamotali do birokratické hantyrky .
Svět je jednoduchej proto jsem assemblerista ...z C čka je mi špatně jen z důvodů jak je psanej ....bohužel to je trend stejne tak jako v současné době nemožno spustit programy ve tvaru exe.
Svět se toči dokola a ne po spirále k lepšimu ale k dražšimu

ross4435897 · #19 Příspěvek od **ross4435897** » 06 led 2015, 20:08

programatori pouzivaji pokrocile jazyky predevsim kvuli efektivite vynalozene prace ...

Zmije · #20 Příspěvek od **Zmije** » 06 led 2015, 20:19

Středníky jsou normálka je to tak třeba i v pascalu, php nebo javě. Má to tu výhodu že jeden programový řádek může být jednoduše rozdělen na víc řádků textu (nebo i obráceně více krátkých progr. řádků na jednom textovém, opět odděleno středníkem) a konec je určen až tím středníkem. Originál C komentáře jsou párové /* koment */ problém je že nelze vkládat komentář do komentáře nebo pokud člověk chce třeba při ladění vyřadit jeden řádek je rychlejší krátký koment převzatý z C++ tedy // A podobně je to s ostatní syntaxí člověk si zvykne a už mu to ani nepříde.

Vpodstatě jde o to, že nejcenější co člověk má je zdraví a čas, všechno ostatní si alespoň teoreticky může koupit, takže pokud začneš místo asm více používat C ušetříš čas, viděláš víc peněz (můžes si toho víc koupit) a ještě ti zbyde čas udělat něco pro zdraví (nějaký pohyb třeba).

#21 Příspěvek od **mtajovsky** » 06 led 2015, 21:05

Programy psané v C jsou nesrozumitelné asi tak 1 den, než se na to zvykne. Ale, hlavně, pokud má někdo druhý udělat opravu nebo změnu do kódu, zcela jistě pochopí algoritmus rychleji z přehledně naspaného C než z assembleru.

Druhý kardinální důvod je minimalizace práce při změně platformy. Změnit platformu v assembleru je de facto stejné, jako napsat program znovu. V C je sice vždy potřeba nějaká práce na migraci, ale je to tak o 2-3 řády snadnější, záleží na tom, jak je kód napsán.

franta22 píše:Mám stejnej názor na C samotné psaní je krkolomné a pisatel programu je svázán terminologii ....vlastní jakoby jednodušši způsob psaní programu v něm vytváři impotenci něco nového vytvořit vymyslet.

LOL, to je, s prominutím, blbost. V assembleru jste omezen na nějakou desítku instrukcí a pár direktiv pro překladač. Kde máte možnost nějakých návrhových vzorů, kde je abstrakce, zobecnění a modelování reálného světa? Assemblerista je zahlcen detailem, hlavní jeho starostí je nesplést si registr a způsob adresace. Já jsem programoval 10 let v assembleru na minipočítačích i mikrech a pak 25 let v C/C++ a mohu porovnávat. S pokročilejšími architekturami mikrokontrolérů se dnes řeší úlohy jiného typu, než blikat ledkami nebo pouštět PWM do motorků. Zde už má místo objektové modelování reality a virtuální dědičnost, jinak byste se nikdy nedobrali potřebné funkcionality. Vezměte si takové embedded aplikace jako je front-sensing u auta, počítačová podpora řízení, automatické parkování, samočinné řízení auta. Hafo statistických výpočtů, geometrických transformací, maticových výpočtů ve floating point. A to všechno se musí naprogramovat v reálném čase pro reálný model auta, dokud nezačne vyjíždět z výrobních linek. Navíc na různých platformách, různě funkčně a výkonově škálovatelné podle kategorie automobilu, pro různé kombinace čidel, které výrobce auta bude osazovat v souladu se svou cenovou politikou. V těchto aplikacích dnes C/C++ kraluje a nikdo ani neuvažuje o programování v assembleru. Dokonce existuje soubor pravidel pro bezpečné C, které vyvinuli přední světoví výrobci v oblasti automotive. Viz MISRA C.

lesana87 · #22 Příspěvek od **lesana87** » 06 led 2015, 21:20

Auta se programují v Matlabu, Simulinku, dSpace a podobných šílenostech, pak je na stahování okýnek potřeba 100MHz ARM s 2MB paměti, ale hlavně že rapid prototyping.

Někomu to holt myslí nízkoúrovňově, pak líp programuje v assembleru, někdo má myšlení víc abstraktní, pak mu sedí ty vysokoúrovňový jazyky. Nejde prostě obecně říct, že v C se programuje rychleji. Někdo bude do C čumět týden jak husa do flašky a napíše dva řádky, v asm to samé sice zabere 15 řádků, ale bude je mít napsané za minutu.

#23 Příspěvek od **mtajovsky** » 06 led 2015, 21:35

V Matlabu atd. programují systémoví inženýři, co vymýšlejí a ověřují algoritmy. V reálném autě Matlab není ani generovaný kód se Simulinku. Aspoň u nás ne.

A těch 100 MHz v ARMu bude ztraceně málo. Pokud vidí skenovací laser 20 objektů a kamera 15, budete muset provést v každém snímku cca 150 výpočtů Mahalanobisovy vzdálenosti, výsledky setřídit a pak provést mergování objektů (například v track-to-track fúzi). A to nemluvím o výběru cílů pro jednotlivé funkce, jako nouzové brzdění, podpora v "traffic jam" atd.

lesana87 · #24 Příspěvek od **lesana87** » 06 led 2015, 21:41

Řeč byla o stahování okýnek, na to je 100MHz zatraceně zbytečně moc.
Samozřejmě že v autě není Matlab, v Matlabu to navrhnou a on jim to ten dSpace, nebo jak se ta obluda jmenuje, přechroupe do strojáku, ale aby se to tam vešlo, musí to mít MB paměti.

#25 Příspěvek od **mtajovsky** » 06 led 2015, 21:44

Kdo to takhle dělá je ... U nás se kód do platformy píše v C.

lesana87 · #26 Příspěvek od **lesana87** » 06 led 2015, 21:50

..moderní a pokrokový. Psát v C je zastaralé a neproduktivní, trh si žádá rychlá řešení, všechno nejlépe včera.

Zmije · #27 Příspěvek od **Zmije** » 06 led 2015, 22:03

Ono to C zas tak vysokoúrovňový není, je to spíš vylepšený asm. A když už se někomu po tom asm stýská tak si tam může střihnout inline asm, nebo ještě lépe to slinkovat s objektovým souborem z externího asm překladače, ať to má říz.

#28 Příspěvek od **mtajovsky** » 06 led 2015, 22:08

lesana87 píše:..moderní a pokrokový. Psát v C je zastaralé a neproduktivní, trh si žádá rychlá řešení, všechno nejlépe včera.

Ano, a takový moderní a produktivní přístup pak vyústí v pomalý, drahý a nespolehlivý výsledek.

Zmije << no já se u nás snažím prosadit C++ a generický přístup s použitím šablon. Ale jde to ztuha, s těmi konzervami, které mají v hlavě pořád algoritmy pro klíčenku nebo ovládání tachometru jde hnout těžko.

lesana87 · #29 Příspěvek od **lesana87** » 06 led 2015, 22:11

Ale aut se prodává čím dál víc, tak to asi nevadí.

#30 Příspěvek od **mtajovsky** » 06 led 2015, 22:15

No, já nevím, kdo to takhle dělá, ale naši zákazníci vyžadují dodržování bezpečného programování podle MISRA a systematického vývojového postupu, do kterého chtějí vidět. A taky to chtějí pro co nejlevnější platformy, nejlépe, aby MCU byl za 10 centů a zbytek zadarmo.