PIC vs ATMEL #2

[VF]

Thus spake Füzesi Arnold <arno at freemail.hu>:

> Foleg igaz ez az elektronikaval foglalkozokra. Ott mar huszoneves korban
> megfigyelheto ez a jelenseg.

Van egy masik jelenseg is. Mindenhol a C/Java-t tanitjak, az asm-et
kezdik elfelejteni. Sot, egyetemet vegzett okos emberek egyenesen
felnek tole.

> Nem igen valtanak ujabb/jobb dolgokra.
> Kotik az ebet a karohoz, asm-ben programoznak, led-el debugolnak, vacakolnak
> azon, hogy halalra optimalizalt
> kodot tegyenek be a rendszerukbe. Legyen az  uC/CPLD/akarmi.

En nagyon orulok hogy vannak ezek az uj eszkozok.
De meseljetek el, hogy a feljebb gondolom nekem cimzett gyepesseget
hogyan kerulnetek ki! Milyen kompromisszumot ajanlotok?

Pl:
Adott tobb 10000 sor Z80 asm forras. Mar sokan probaltak atirni C-be,
eredmenytelenul, mert nem pont ugyanugy mukodott az algoritmus.
A teszteleshez korulbelul 2000db 128k-s adatcsomagon kell vegigfuttatni
a progit, egyen sem szabad megbuknia. Akkor nagy baj valoszinuleg nincs.
A C eddig legalabb nehany adatcsomagon rosszul mukodott, a hibat sohasem
talaltak meg.
A Z80 asm nagyon konnyen atfordithato AVR-re, es ez kb minden 8 bites
procirol elmondhato. Ebben verhetetlen az AVR. Gyakorlatilag csak egy z80.h
fajlt kell includolni a Z80 forras ele, amit elotte egy nehany soros LISP
progi feldolgozott. (Egyetlen cimzesmodot kell csak korrigalnia, sztring-
peratorok hianyaban a makro-assemblerek nem tudjak kozvetlenul ertelmezni)
16/32 bites procikra is at lehetne forditani, sot, akar C-be is.
A hatekonysag elkepzelheto... Pl 32 bites osszeadast a 32 bites proci
8 bitenkent csinalna, kozben esetleg 10-20 ciklus elmenne a flagek emulacioja
miatt, magyarul semmivel sem tudna tobbet mint egy olcso 8 bites proci, csak
modernebb lenne, es lassabb :) Hasznaljak JAVA procit?

Pl:
Asm-ben optimalizalt digitalis szuro. Biztos lehetne C-ben is, de minek?
Atmel honlaprol letolt az AVR335 appnote, kicsit kijavit, mukodik.
A koefficiensek kiszamitasaval, buffer-kezeles modositasaval, tesztelessel
egyutt talan 2 ora. Kesobb atirtam 24 bites koefficiensek es nodeok
kezelesere, valamint a koefficiensek skalazasat rabiztam a C forditora,
ez talan meg egy ora. (Ez az egy C forras van a projectben, abban sincs
egyetlen futtathato sor sem :)
Irhattam volna C-ben is, de akkor ezen a procin egyaltalan nem ment
volna (ez tuti), dragabb procit kene megvetetni a felhasznaloval, valamint
a keszulekben mondjuk ketszer gyakrabban cserelni elemet a nagyobb
fogyasztas miatt. (Ez majd akkor lesz elhanyagolhato, ha a keszulekben nem
a proci fogja a legtobbet fogyasztani. Erre csak akkor lenne esely, ha
hattervilagitasos lcd-t hasznalnek :)
Lehet hogy nekem 1 oraval tobb munka, de utana felhasznalok ezreinek
nehany ezressel olcsobb a kutyu, havonta par szazassal az uzemeltetes.
(Es ebbol termeszetesen leesik nekem is nemi apro, ha mas okbol nem,
hat az alacsonyabb ar miatti magasabb eladasokbol eredo reszesedes)
Egyaltalan nem vagyok hive a gagyi gyartasnak.

Pl:
FPGA-val valoban bonyolultabb aramkoroket lehet megvalositani.
Aztan jon a szivas, hogy nem konfigolodik fel eleg gyorsan, hogy a
PCI vagy egyeb idoben meglassa.
A Verilog-ot elfelejtetted, a VHDL nem tetszik mert sokat kell gepelni,
a C->Verilog konverter nem ingyenes, szar kodot general, es nem is
mukodik. Ha esetleg mukodik a kutyu, az FPGA progit barmikor barki
ellophatja, semmi lehetoseged megvedeni az IP-d. Bajban leszel az
idozitesekkel, gusztustalan modon kezzel kell routolnod az FPGA-t, stb..
A korszerutlen, draga CPLD-t viszont Abel-ben lehet programozni, amiben
meg sokkal kevesebbet kell gepelni, mint C/Verilog/VHDL/whatever-ben.
Az idozites garantalt mielott egyetlen sort is irtal volna. Ahogy kap
tapot, mukodik, a progi nem olvashato ki, masolhatatlan.
En tudom hogy az FPGA modernebb, de ha vacak, akkor vacak, hasznalom
az elavult technikat, legfeljebb kicsit optimalizalok, meg mindig
nagyobb elmeny igy valami korrekt cuccot alkotni, mint ganyolni egy
modernebb technikat...

> Nekem ez igy jo, mert sokkal gyorsabban, kenyelmesebben dolgozok.
> Konkurrencia meg izzadjon. :)

En is szeretnek ugy dolgozni. Sajnos ezen a szinten mar elvarjak,
hogy a kutyu ne csak mukodjon, hanem hatekony is legyen.

> Marad mellette idom arra is, hogy eljek. Nem asm kod, és led villogtatas
> korul forog az eletem, nem ezzel kelek, nem
> ezzel fekszem. Tized annyi ideig tart megcsinalnom azt, amit a listatagok
> jelentos reszenek.

Sajnalatos dolog, hogy nem ertesz elegge az asm-hez. Akkor nem
talalnad neheznek. A JTAG debug akkor segit, amikor valami hatalmas
lamerseget csinalsz, es fogalmad sincs hol a hiba.
Ha apro, jol attekintheto, sajat hibakezelessel rendelkezo egyszeru
reszletekbol (makro/szubrutin/egyeb) epitkezve haladsz felfele, vagy nem
lesz hiba, vagy pontosan tudni fogod hogy hol.
(Tipikusan az utoljara modositott modulban :)
Megjegyeznem, hogy igy olyan hibakat is le tudok (es le is kell) kezelni,
melyek az idovel kapcsolatosak, debug modban megallitva a progit nem
kezelhetok.
Termeszetesen ha valaki szereti gyorsan osszecsapni a programot, kozben
atnezes nelkul felhasznalva egy csomo ismeretlen kodot, azzal konnyen
elofordulhat, hogy fogalma sincs hol a hiba, es ilyenkor csak a JTAG
debugger segithet.

> Nem azert mert zseni vagyok, hanem mert kepes vagyok kompromisszumokra, es a
> feladathoz megfelelo eszkozt hasznalom.

En is kepes vagyok. A megrendelo es a vevok nem... Pedig milyen jo lenne
azt mondani, hogy ez a ket borond az akku, a szellozot pedig ne takarjak
le, mert felrobban az egesz, es akkor hasznalhatnek tetszoleges
teljesitmenyu, akarmilyen nyelven elegendo sebessegu procit.

> Tovabbá több idom marad a sw tesztelésére, a kényelmi dolgok belerakására.
> Illetve ami fontos: Új dolgok megismerésére alig kell több idot fordítani,
> mintha a cuccot a régi jól bevált
> megoldásokkal csinálnám meg.

Ez a Java, C, vagy Verilog nyelvek egyedulallo, asm-ben nem ismert
specialis tulajdonsaga?

> Igyaztan azt mondom: Gyerekek: A JTAG __NEM__ __JO__ __SEMMIRE___!!!!!!
> Ne hasznaljatok, mert sokkal egyszerubb led-el debugolni!!!

Azzal nem, az igaz, de mit szolsz az lcd-re kiiratashoz, USART-on
debug uzenetek kuldesehez?
Secialisan egy olyan hardveren, mely a JTAG port labait AD bemenetkent
hasznalja, igy normal mukodes kozben a JTAG nem is lenne hasznalhato?
Te biztos valami nagyobb teljesitmenyu, dragabb procit javasolnal.
Sajnos nekem termeket kell fejlesztenem, a leheto legolcsobban.
A fejlesztes koltsege viszont gyakorlatilag nem szamit.

> Talan nalad valamelyest objektivebb kepem van a dologrol, hogy mekkora  a
> kulonbseg a soros port, és
> a JTAG között. Merthogy mindkettot használom/tam, ellenben veled.

Mint emlitettem, az amatorkodeshez biztos jo, nekem eselyem sincs hogy
hasznalni tudjam.
Egyreszt a hardver okok miatt, masreszt mert egy valos idoben mukodo
kutyurol van szo, ha leallitom, lelassitom, kiesik az idoablakbol, mar
nem mukodik. Egy byte kiirasa a sorosra 2-3 ciklus, az belefer.

> De azt az ordenáré nagy baromságot, hogy a JTAG nem sokkal jobb a többi
> debugnál ne terjeszd!

Halljuk mar az elonyeit!!
Megegyszer: ha nem hardver-specifikus programresz vizsgalata szukseges,
mivel tud tobbet mint a szimulator? Semmivel. Csak feleslegesen
korulmenyesebb.
Ha pedig hw-specifikus, kritikus idozitesekkel mukodo progirol van
szo, nem tudod leallitani, tehat nem hasznalhato.
Ennyi.
Halljuk a te erveidet is!

> Avatott kezekben egy PIC-el is porig lehet alázni egy Atmega-t...

Termeszetesen. Pl az AVR-t C-ben vagy Java-ban programozod, a PIC-et
assemblerben, ugyesen optimalizalva.
Az eredmeny nem ketseges.
Csinalhatunk olyan versenyt is, hogy adott koltsegbol kell tervezni
ugyanolyan tudasu kutyut.
En ugy valasztanek, hogy az anyagkoltseg plusz fejlesztesi koltseg osztva
a varhato darabszammal olcsobb eszkozt valasszak mint a konkurrencia.
Persze lehet ugy is, hogy a legkisebb fejlesztesi koltseggel megvalosithato
termek, de ha az lenyegesen dragabb mint a masik, vagy gyengebb
parameterekkel rendelkezik, nem fogod tudni eladni.
Ez itt a problema...
Nyilvan onceluan senki sem fog asm-ben optimalizalgatni, ha nincs semmi
ertelme...

> Egyrészt a kezdoket bizonytalanítod el, akik most próbálgatják a
> szárnyaikat, másrészt a nálad
> idosebb fejlesztokben erosíted meg a hitet, hogy "jó az a régi DOS-os
> editor",
> meg a parancssoros assembler...

Ugye tudod hogy hulyeseget irtal? Ugyanazt a forditot hasznaljuk mind
a ketten... Szo sincs parancssorrol. Pontosabban a te JTAG/ISP
letoltod parancssoros, az enyem nem.
Inkabb teged kernelek meg ra hogy legy szives ne terjeszd, hogy az asm
fapados, meg regi, meg gagyi stb... Nem igaz.
Irtal mar objektumorientalt asm progikat?
Programoztal GUI-t?
Ha akarod, mutathatok egy parat amit en kovettem el.
Nem szivesen csinaltam volna C-ben, mert szerintem ugyanolyan korulmenyes
mint szerinted a Verilog/VHDL.
Csak erteni kell hozza.
Sajna ezt sehol sem tanitjak. Pontosabban az ELTE-n volt egy ilyen speci,
de a legtobbet magamtol kellett megtanulnom.

> De mint mondtam nekem ez jó, kevesebb a konkurrencia, nem is tudom miért
> jártatom a számat... :))

Ha erdekel, szivesen megmutatom az en munkamat, ha meg tudod csinalni
elegansabban, magas szintu nyelvben, sokat kereshetnel vele.
Csak nehogy az legyen, mint a masik listataggal, akinek felajanlottam,
hogy tole fogok INA-t venni, ha olcsobban vagy nem sokkal dragabban
(megis csak magyar termek, szivesen megtamogattam volna egy kicsit)
adja a sajat aramkoret mint az Analog az AD623-at.
Azota sem jelentkezett... Csak a levegobe beszelt. Vajon te is?

> Arnold

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"A lamerek egyik fo ismertetojele, hogy maniakusan felnek a virusoktol"