PIC vs ATMEL #2

[Gyorgy Varga]

Hello VF,

Friday, February 13, 2004, 2:02:55 PM-kor irtad:

VF> Thus spake Gyorgy Varga <gylab at freestart.hu>:

>> Vegyel egy C tankonyvet. Abban le vagyon irva. A #if parametere
>> termeszetesen lehet makro, sot tulajdonkeppen en meg csak makrot
>> talaltam ott.

VF> Irjatok egy peldat, amely csinal egy #define makrot, es a makroban
VF> a makro argumentumaitol fuggo #if elagazast.
VF> A konyv itt van elottem, ilyen peldat nem latok.
VF> Tehat valami ilyesmire gondoltam:
VF> #define szamol(op,arg1,arg2)

VF> #if op='+'
VF> arg1+arg2
VF> #else
VF> #if op='-'
VF> [..]

VF> Ilyet tud a prepocesszor?

Vegyel egy C tankonyvet. Komolyan mondom, nem bantaskeppen.
Termeszetes, hogy tudja. Ez a feladata.  A szintaktika nem jo, de az a
tankonyvbol kiderul.

>> Es ha elut a villamos, akkor lehet bezarni a ceget, kidobni a teljes
>> fejlesztest, Jo ez?

VF> Ezt meg ki mondta? Ha en megertem az asm-et, masok is meg fogjak.
VF> Hiszen itt a listan is mindent jobban tudtok mint en.
Az elozo leveledben irtad, (amire valaszoltam) hogy mindegy, hogy
megerted magad kesobb, vagy sem, mert nem kell hozzanyulni.




>> A kovetkezo mondatodat nem nagyon ertem. Ezek szerint te biztonsagi
>> szoftvert irsz? Az megint egy mas teszta. Akkor megkerdeznem hogy a

VF> Nem, egeszsegugyi szoftvert. Pontosabban csak a mukodteto szoftvert,
VF> az algoritmust asm forras formajaban kapom, nekem azt cross-assemblerrel
VF> kell a procimra leforditanom es futtatnom.
VF> Ha rossz eredmenyt ir ki, az user jol begyogyszerezi magat a teves diagnozis
VF> alapjan, vagy nem megy el a dokihoz a kezdodo ketoldali szivrohamaval, vagy
VF> lyesmi, szoval ciki. Elterjed a rossz hire a keszuleknek, bukas...

Erre nincsen meg szabvany, hogy minek kell megfelelnie???? Ezen le
vagyok dobbenve. De komolyan. Egy vasuti iranyitast sem lehet csak ugy
minden eloiras nelkul csinalni (hala Istennek!).



>> assemblered tesztelt? A programod tesztelt? (nem a hosszas probalgatas
>> modeszerere gondoltam...) A C-hez legalabb vannak tesztelo/analizalo

VF> Persze. Az enyemet en tesztelem, a leforditott progit pedig a fonok
VF> sajat kezuleg (na jo felig automatikusan), egy tobbezer eltarolt tipikus
VF> EKG-t tartalmazo adatbazissal. Maga az algoritmus kb 20 eve folyamatosan
VF> fejlodik, a jelenlegi verzionak nincs (altalam) ismert hibaja.
VF> Amikor o maga fejleszteget, akkor debuggerben teszteli az assemblyt.
VF> Mit lehet tenni, ha csak ahhoz ert :)
VF> Az assembler eleg jol tesztelt, majdnem mint maga a proci.
VF> A progit is igyexem jol megirni.
Azt hiszem teljesen felreertettel. Mint irtam nem a hosszas
probalgatas modszerere gondoltam. Az mint jelent, hogy 'eleg jol
tesztelt' ? A vindoze is 'eleg jol tesztelt'.





>> eszkozok. Lasd pl. lint. Ezek nem is engednek olyan kodot, amit nem
>> ertenek (pl. assembly utasitas). Sot azt is megkerdezem, hogy mivel
>> teszteled? A program (ami ugye meg nem tesztelt) altal adott
>> informaciokkal? Az ugy nem sokat er.

VF> Na ezt most nem ertem. A keszulek mer valamit, az alapjan allitja fel a
VF> diagnozist. Amit mer, nem lehet rossz, folyamatosan latjuk a kepernyon,
VF> illetve a kutyu kijelzojen. Az algoritmust ezen, vagy virtualis meresek
VF> eredmenyet letoltve tudjuk tesztelni.
VF> Mi kene meg, vagy miben tud tobbet ennel a C? Nem ertem.
Banyek, azt hiszem kezd teljesen feleslegesse valni, amit irok, suket
fulekre talal. Kerdeztem, hogy mivel teszteled. "Amit mer, nem lehet
rossz, folyamatosan latjuk a kepernyon". Ez a valaszod ra?
Keress ra neten C analizalo programokra. Mert hogy vannak. Sok. Ellentetben
az assmemblyvel (tisztelet a kivetelnek, mert letezik arra is, de az
processzorfuggo). Sot keress ra szabvanyokra. Az sem rossz.







>>> Es nyilvan gyors is ugye?
>> Igen, sot jol tesztelheto/konfiguralhato/portolhato, sot a magam altal
>> irt konyvtarak is ragyogoan hasznalhatok mas kornyezetben. Azert annyi
>> elonyom van, hogy azt hiszem ismerem a C-t. Igy konnyebb gyors es jo
>> kodot irni. :)

VF> Lehet. En csak annyira ismerem, hogy lefordul es fut a progi, optimalizalni
VF> c-ben nem tudok. Arra jo az asm. A portolhatosag mire jo?
Arra, hogy megirom, akkor az ugyanugy jo lesz motorolan, x86-on,
PIC16-on, pic18-on, egy crc vagy ecc szamitas jo lesz 8-bitre, 16-bitre,
32-bitre stb. Nem kell meg egyszer megirni, letesztelni. Az
optimalizalas sem a te dolgod, az a forditoe.


VF> Az analizalo algoritmus amugy is asm-ben van, a tobbit pedig amugy is
VF> teljesen at kell irni. Eleg valoszinutlen hogy egy masik procin pont
VF> ugyanolyan legyen minden periferia, mexakitasok, stb... ugy is majdnem
VF> soronkent at kell irni az egesz programot.
Ez nem igaz, ilyet ne terjessz. Egy jol megirt programnal a torzsnek
nem resze a periferiakezeles. Az adott periferia kezelojet csak hozza
kell linkelni a kovetkezo szinthez, es ennyi. Azaz hogy az a
(legalabbis c) program, aminek minden sorat bantani kell masik
procihoz, az nemes egyszeruseggel rossz. Erre azt mondjak az
iskolaban, hogy ulj le fiam, egyes. :)
Tudok ra peldat is: a linux kernel (nem kicsi!), es minden programja
igenis fordul x86-ra, 68k-ra, ARM-re, es meg egy rakat procira.
Szerinted pl. a TCP/IP-t befolyasolja a proci????? Hat nem. Nem is
fugg tole. A fenti procik annyiban hasonlitanak egymasra, hogy
feketek, es jo sok labuk van.

VF> Arrol nem is beszelve, hogy ez sok ev alatt a 3. proci, es kozben az
VF> egesz koncepcio is teljesen megvaltozott. Nem nyertunk volna vele
VF> semmit... Sot az eddigi verziok majdnem hogy teljesen ellehetetlenedtek
VF> volna.
Na pont erre jo a portolhatosag. Azon bizony nyertel volna! Az eddigi
verziok is megmaradhattak volna, csak a procfuggo reszeket kellett
volna modositani. (sok helyen HAL-nak hivjak - hardware application
layer).

-- 
Üdv,
 Gyorgy Varga
GyLAB BT.