PIC vs ATMEL #2

[VF]

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

>> 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.

Itt van elottem a tobb mint 500 oldalas programozzunk C nyelven.
A prepocesszor a 248 oldalon kezdodik. Nem emlitik meg hogy van
ilyen lehetoseg. Szerintem sincs, en nem lattam ilyet soha.
Ha megis, irjatok mar meg!
Mar csak azert sem jo a #if, mert annak a sor vegen van vege,
a sorveg pedig a #define-t is bevegzi.
Tehat?

>> Ezt meg ki mondta? Ha en megertem az asm-et, masok is meg fogjak.
>> 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.

En ilyet irtam? Idezd! Csak annyit, hogy karbantartaskor nem ehhez
a reszhez kell majd hozzanyulni altalaban. Biztos ezer dolgon lehet
javitani, de speciel egy optimalizalt szorzashoz vagy egyeb
algoritmushoz minek? Ha olyan dolog lenne, amit kethetente modositani
kene, akkor egye fene, legyen C-ben.

> 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!).

Hogy lenne szabvany, amikor ez lesz az elso ilyen keszulek a vilagon,
ami kereskedelmi forgalomban kaphato, otthon hasznalhato??

> 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'.

Ezt most nem ertem. A teszteles azt jelenti, hogy a programnak
beadunk minden elkepzelheto bemeno adatot, es ellenorizzuk hogy minden
adatra a vart valaszt adja-e. Mi pontosan ezt csinaljuk.
Szerinted hogy kene? Es azt miert csak C-ben lehet?

>> Na ezt most nem ertem. A keszulek mer valamit, az alapjan allitja fel a
>> diagnozist. Amit mer, nem lehet rossz, folyamatosan latjuk a kepernyon,
>> illetve a kutyu kijelzojen. Az algoritmust ezen, vagy virtualis meresek
>> eredmenyet letoltve tudjuk tesztelni.
>> 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?

Igen. Hol csuszhat be a hiba? A meresnel nem. A feldolgozasnal nem.
Akkor hol? Minden reszleteben teljes koruen tesztelt.

> 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 ez mire lenne jo nekem?

>> Lehet. En csak annyira ismerem, hogy lefordul es fut a progi, optimalizalni
>> 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.

En nem programozo vagyok, keszuleket, termeket kell csinalnom.
Pillanatnyilag nem kulonosebben erdekel hogy leteznek mas processzorok is.
Ha valamiert procit valtanank, az egesz megborulna, lehetne elolrol
kezdeni mindent, a nyaktervezestol.
Ami valoban sokat segitene, ha az EKG analizalo algoritmus meglenne C-ben.
(Persze akkor valoszinuleg nem jutottunk volna el idaig, mert Z80-on,
80c552-n nem futott volna le emberi ido alatt, hasznalhatatlan lett
volna a cucc) Most mar teljesen mindegy, a legbonyolultabb algoritmus
amit le kellett kodolnom, a szuresek. A tobbi szinte mind a hardverrel
kapcsolatos, eszkozmeghajtok stb... Terjedelmes progi, es ha procit
valtanank, soronkent ujra meg kene irni az egeszet.
Maximum nehany header fajlt lehetne megtartani, pl ami a kommunikacios
protokollt irja le :)

> Ez nem igaz, ilyet ne terjessz. Egy jol megirt programnal a torzsnek
> nem resze a periferiakezeles. Az adott periferia kezelojet csak hozza

Akkor nalam nincs torzs egyaltalan. Csak millio kis periferiakezelo
modul. Ez nem linux kernel...

> 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.

Nem felejtetted el megint, hogy 8 bites mikrovezerlokrol van szo?
Irjam le minden sorba?
TCP/IP-t nem fogok asm-ben irni, valoszinuleg.

> 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).

:))) Mit layerezzek, amikor igy is alig birtak az eddigi procik?
OpenGL-ben kellett volna kezelni a 2x16 LCD-t??
Ne rohogtess mar...
Jelenleg egy 160x80 kijelzo van, T6963C vezerlovel.
Sajnos vezerlo nelkuli verziot ebbol nem tudtunk szerezni.
Nem igazan mozgokepek megjelenitesere talaltak ki, rengeteget kell
varni ra a procinak. Ezert ossze van keverve az lcd kezeles mas
programreszekkel, amig var az lcd-re, csinalhat mast. Most pl a HP
algoritmus szerinti csucskiemelest stb... csinalja.
Ha holnap kiderul hogy le kell cserelni a kijelzot egy masik
tipusra, gaz van, csomo mindent ujra meg kell irni.
Mit lehet tenni?
Draga megoldast en is tudok...

> Gyorgy Varga

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
" ... USE KOTEL ON KAMPO WITH NYAK"