Ne haragudj, de erre miből következtettél?
Mondjuk arra sincs utalás, hogy 8 bites lenne, mint én gondoltam.
Épp ezért én nem is gondolkodtam többszáz byteos állományokban.

Bocsánat, a összekevertem a PIC kezdőknek topikban futó beszélgetés típusával.

Szia sonajkniz,

A Miért éppen assembly? cikkedhez egy apró megjegyzés, hogy a PIC memóriája nem byte, hanem szavas szervezésű, így az összehasonlítás nem teljesen korrekt. 8 bit vs. 14 bit, de ha megduplázom a programjaid méreteket akkor is ugyanazt a következtetést vonhatod le, hogy assembly-ben kisebb programot tudsz írni. Ez tény.

Egyébként ilyen kaliberű programokra tökéletesek ezek a kis lábszámú kontrollerek. Én is írtam már 8 lábú PIC-re programot, meg nagyobbakra is sokat assembly-ben, a max. 2 kWord / 4 kByte volt, azaz a page méret. És ennél tovább soha nem szerettem volna menni, nem akartam a lapozással foglalkozni, kényelmetlen, hibalehetőséget okozhat. Rengeteg assembly macro-t írtam (weboldalamon megtalálod), amivel akár 16/24/32 bites számokat tudtam műveleteket végezni, szorzás, osztás, stb.
Ezeket (és még sokkal többet) egy magasabb szintű programnyelvvel megkapod, nem kell magadnak megcsinálni.

Bizonyos komplexitás felett már sokkal kényelmesebb, haladósabb C-ben programozni. Nem arduino-ra gondolok, mert ott nincs normális debug lehetőség. (Tudom, van egy fizetős plugin eclipse-szel, de az nem a standard arduino környezet.)

C-ben is meg kell írni az embernek sok mindent, de nem az aritmetikai műveletektől kell kezdeni. Assembly-ben egy formázott szöveg kiírása az LCD-re is megoldandó feladat (nem az LCD kezelésre, hanem a formázásra gondolok), C-ben ezt megkapod, cserébe fixen ott lesz a lefordított kódod méretében a clib, ami ezt nyújtja. Mindkettőnek meg van a helye.

Üdv,
M.

A fentiekben igazad van, ameddig csak viszonylag rövid programokat készítesz. Megnézted egyszer is milyen kód jön ki a Microchip C fordítókból.
Egy példa, amit az XC16 free verziója készített (számtalan hasonló rész közül egy kiemelve):

Vajon miért kell elvégezni egy műveletet háromszor - négyszer? Hogyan lehet így futási időre kritikus programrészt írni? Az XC8 ingyenes verziója még elfogadhatatlanabb kódot fordít.

Előre nem tudható, hol és milyen műveletekkel szórja tele a programot.
A propeller óra általam assemblyben megírt programját átírtam XC8-re az ingyenesen használható verzióval. Az eredmény szerint, ami bőven befért a 2k szóba assemblyben, az nem fért bele a 8K szóba. Akkor nem gyártottak még nagyobb program memóriával rendelkező 16F kontrollert. Persze megfizethettem volna az optimalizálásért a 370 000 HUF + áfa -t. Azonban az első 30 nap alatt fordítva sem fért bele a 16F648 -ba (4 k szó).

Amit irtal azt bizonyitja, hogy mennyire gyenge minosegu a microchip XC forditoja es semmi teendo a ket nyelv (assembly es c) osszehasonlitasaval
Miota kihoztak (de mar elotte is egyre csokkeno szamban) nem hasznalok PIC-et, pedig hosszu ideig favorit volt. Most is van meg vagy 100 darab kulonfele elfekvo mcu-m.
Mondjuk en foleg a kenyelem miatt valtottam ATMEL-re (ami mostmar ugye microchip...)

Szia!

Köszönöm, hogy megosztottad velem az észrevételeidet.
Valóban nem helyesen adtam meg a programok hosszánál a byte kifejezést. Természetesen 14 bites szavakról van szó. A fordító is szavanként is kezeli.

Valószínűleg nálam sokkal jobban ki van tolva az a határ, ahol a ráfordított időtöblet, vagy komplexitás miatt lemondanék az assemblyről. Elvégre a hobbiból elkövetett tevékenység nem lehet határidőhöz kötve. Így viszont készíthettem magamnak megfelelő makrókat, behívható kezelőprogramokat. Például a 2x16-os LCD kezelő programom, amit PIC18-hoz ítam, sokszor többet nyújt, mint a C-ben fellelhető lehetőségek. Csak behívom, és a C-hez hasonló módon "PRINT" utasítással külön tudom írni az alsó és felső sort, de akár 1-1 karakter cseréje is lehetséges, akár változóból is. Állítható felülírási sebességgel látványossá tehető a szöveg cseréje, valamint automatikusan hozzáigazíítja az időzítőket a processzor órajeléhez, mégpedig 250KHz-tól 16MHz-ig. Ettől hobbi, hogy ilyeneket megírok. Na és persze nem utolsó szempont, hogy mivel ezek a rutinok, makrók assemblyben vannak megírva és hardverspecifikusak, kevesebb programmemóriát foglalnak és gyorsabb lefutásúak.
Ha pedig az ember rászánta az időt és energiát ezen makrók, behívható rutinok megírására, utána már assemblyben is lehet olyan gyorsan programot írni, mint C-ben. Az eredmény viszont jobb lesz.
Természetesen vannak olyan programozási feladatok, amit már agyrém lenne assemblyben írni. De ezen feladatokhoz már a C nyelv is kevés.
A munkám során csak addig használok mikrovezérlőt amíg a PIC18F14K22-esnél komolyabb hardvert nem igényel. Utána PLC-re váltok.
Hobbi szinten pedig amihez nem elég az assembly, ahoz már én is kevés vagyok. Így a magam részéről kényelemből (és-vagy) lustaságból sosem fogok C-ben programozni, vagy arduinora váltani.

Üdv: János

Egyetértek, én is az asm fan vagyok.
Bár azért tényleg van pár dolog, amit érdemesebb C-ben csinálni, pl. az USB kezelés. Mondjuk volt itt a fórumon egy srác, aki azt is megcsinálta asm-ben.
Én anno szögpercben megadott GPS koordinátát alakítottam át decimális formába. És hogy biztosra menjek, az összes értékre kiszámoltattam a megírt függvénnyel az átalakítást (csak a szögperc értékeket 0-60 fokig, tízezredes törtrésszel), ami 600 000 db variációt jelent. Na ezeket elküldtem PC-re, ahol excelben összevetettem a valós és PIC által számolt értékeket, és mindegyik jó volt.
Ez utóbbira azért volt szükség, mert pár számoló rutint a netről vadásztam, és muszájnak éreztem ellenőrzni, hogy minden számmal jól működik-e.

Szia!

USB-vel még nem foglalkoztam. Nem volt rá szükségem. De szerintem nem is lesz. Ha netán PC-vel kell kommunikálni, egyszerűbbnek gondolom ennek az eszköznek a használatát, mint váltani egy olyan PIC-re, ami tud USB-t.
Egyébként sem használom soha a PIC beépített hardveres kommunikációit. Ha egy eszközzel UART-on, vagy I2C-n kell kommnikálni, inkább megírom szoftveresen. Két PIC között viszont csak 1-Wiret-t használok. Sokkal gyorsabb, és gond nélkül átvisz akár 10m-t is 1millió bit/sec-en. Bár ennyin csak a WS2812-es ledet járattam eddig. Jóval kisebb (100000 bit/sec) sebességen, megnövelt jelárammal 3 éve működnek a szigethalmi vadasparkban az álltalam készített szemaforok. A legnagyobb vezetéktáv 26m.

Ez a GPS dolog nekem idegen, nem tudom mit takarnak számszakilag ezek a dolgok. De ha a változások lineálisak, akkor egy linearizációs algoritmus lehet egyszerűbb lenne a táblázatnál.

Mindenre van már külön hardveres kész megoldás, de ha megoldható tokon belül, akkor miért ne. Legutóbb pl. nekem arra volt szükségem, hogy a PIC-et PC oldalról HID billentyűzetként lássam. Biztos van USB HID - serial konverter, de úgy néz ki a C kód jól működik (mármint az USB miatt).
A GPS-es dolgot csak azért irtam, hogy érzékeltessem, azt is lehet jól kezelni asm-ben.

A 8 bites PIC-ekre nem is lehet normális C fordítót készíteni. Egyszerűen az az architecetura erre nem alkalmas. A szabad RAM bankokba van szervezve és nem összefüggő terület. Csak hívási stack van az is fix méret. Paraméter átadás a függvényeknek ha csak 1 byte akkor mehet a W-ben, de felette csak INDF/FSR varászlással lehet valamennyire az adat stack-et kiváltani, mert nincs HW adat verem támogatás. Nincs stack pointer. Ott ezt nem kell erőltetni, de más normális 8 bites kontrollerek, pl. ATmega családra, egész jó a C fordítás eredménye. (És ebből ne legyen PIC vs. AVR vita, a PIC is normális csak másképpen

XC16-ot használtam, nem nagyon nézegettem a fordított kódot, csak az elején amikor még nem is ez volt a neve, de amit beraktál az milyen optimalizációval van? Debug-hoz 0-ás esetén elég sok felesleges kód keletkezik, de a debugger tudja mi melyik C kódból lett fordítva, így a törésponton ott áll meg ahol kell, stb. fejlesztéshez jó, persze gáz ha emiatt nem fér be a kontrollerbe. A végén meg le kell fordítani mondjuk -O s -sel. Azzal is látsz ilyeneket?

Csak az ingyenes módot hasonlítom más megoldásokhoz. Családonként a 300 - 400 ezer forint szerintem sok a hobbihoz.

Nem lesz semilyen vita. A C vagy bármi más csak egy assembly makro gyűjtemény, amit a fordító a forrás igényei szerint rak össze. Belátható, hogy mindig írhtó rövidebb, hatékonyabb assembly kód, ha valaki veszi a fáradságot.

Nem is a sima szövegek kiírása a lényeg, az mindenhol egyszerű, hanem például egy előjeles számot akarsz kiírni egy szöveg közepén. (Ha menüt csinál az ember, akkor sok ilyen kell, mindenhol más paraméterrel.) Assembly-ben kiírod a szöveg elejét, majd átalakítod a számot bcd-re, majd foglalkozol az előjellel, majd azzal, hogy a szám elején lévő nullák ne jelenjenek meg, végül kiírod a számot, és a szöveg második részét. C-ben ez 1 függvény hívás, printf vagy sprintf egy megfelelő format string-gel és a változóddal. Persze megcsinálhatod az assembly-s printf függvényedet is, ami mondjuk csak a legegyszerübb format paramétereket fogadja és mondjuk max 1-et, mert neked nem kell több, de a C kód azért lesz hosszabb alapból mert ha felhivod egyszer a printf-et akkor bevágja a formatálást, ami combos, viszont utánna ha sokszot használod akkor már nem nő ilyen mértékben a kód.

Kiskapacitású kontrollereken az első két függvény, amit kihagynak a terjengőssége miatt az a printf és a sprintf. Ugyan kinek kell egy olyan kiírató, ami 3 -as számrendszerben is működik, de pl, a float számokra egyszerűen nincs is megírva.
Egy 10F322 kontrollerbe írt egyszerű program (FREE verzió) elviszi a program memória 65.2% -át, az adat memória 65.6 % át. Egy 16F628 kontrolleren már csak a program memória 16.8% -át, az adat memória 18.8 % át. Hurrá, a 2/3 ill. 1/6 kapacitással el tudunk küldeni egy vacak 0x32 kódu karaktert az LCD -re.



Ezzel szemben a 10F322 belefér assembly-ben egy dátum és idő kijelzős (74HC595) hétszegmenses óra, DCF szinkronnal.

Akkor egy észrevétel általam is.
Nagyszerű cikk, szuper példákkal, de szerintem az összehasonlítás nem kellett volna bele, nem egyenrangú a két oldal. Csak magában annyi, hogy mi minden megoldható egyszerűen, pár lábbal gyors és okos ASM programokkal.
És ahogy írtad, egy bonyolultságon túl meg el kell felejteni a PIC-et. Én is PIC-eztem sokáig, de elegem lett a végtelen erratákból.
Akartam némi pluszt írni, de látom itt megy közben a szakmai vita, és nem akarok belefolyni.

Játszogattam egy kicsit:

Ez a program XC8 free módban 98.6% -ra megtölti a 10F322 -t, 26.1% -ra a 16F628 -at, 5.4% -ra a 18F242 -öt.

Az internet sok mindent fel lehet leni én is sokalltam érte...

Bevallom, hogy mivel nem programozok C-ben, így fogalmam sincs, hogy amiket leírtál mit csinálnak.
Hogy az én saját segédprogramom mit csinál, azt a mellékelt dokumentumban leírtam. Bár ez sem nevezhető pár sorosnak, de szerintem jóval rövidebb annál, amiről te írtál. Lehet, mások szerint többet is tudhatna, szerintem 2x16 karakterből nemigen lehet többet kihozni.

193 szó 37.9% -ot jelent. Azonban meg kell jegyeznem, hogy egyetlen (s)printf hívással nem igen lehet programot írni, bár meg lenet próbálni.

Ez már sehogy sem fér el a 10F322 -ben.

A printf-et én hoztam fel példának, ha valami komolyabb dolgot kell csinálni, es egyáltalán nem a legkisebb PIC-kel kapcsolatban. És azt is irtam, hogy a 8 bites PIC családokra nem igazán lehet jó C fordítót irni. A clib-et nem kell használni, de ott van mint lehetőség. Én is megirtam a ltoa függvényemet C-ben, mert sokkal kisebb, mert csak decimális számokra kell nekem. Maga a C forrás sokkal átláthatóbb, gondolj bele egy egyszerű feltételes elágazásba:



Ugyanez macroimmal teletüzdelt jól olvasható assembly-ben is sokkal több sor, és később nehezebb értelmezni:



És könnyü hibázni egy CMP8-at írok a CMP8C macro helyett és már kereshetem is a hiba okát egy darabig. Nehéz észrevenni.
Ha van else ág akkor meg tele lesz ugrással.
Macro nélkül meg totál káosz olvasni.

Nem nagyon latom ertelmet az osszehasonlitasodnak.
A C nem vetheto ossze az assembly-vel, mert egyszeruen mas celra van es persze mas megkozelites.
Az ember a feladathoz valaszt nyelvet es bizony nagyon ritka az az eset, amikor a leforditott program merete szamit. Ha leragadsz a 10F322-nel, akkor termesztesen nem kerdes, mert a hardware maga a korlat.
Mondok mast:
A kedvenc kijelzom a VQC10D pontmatrix (DDR). Jo regen irtam hozza vezerlot PIC-re (PIC18F252), C-ben. Emlekszem, hogy eleg gyorsan megvolt hasznaltam is sokaig.
Aztan harom vagy negy eve jott az igeny, hogy mukodnie kellene RPi-n is. Atirtam, kb par perc de mindenkepp nem nagyon volt tobb, mint 1 ora, vagy akorul.
Tavaly ugyanezt csinaltam ATmega328P-re.
Tudom, megoldhato C nelkul is, de mennyi do alatt? Es ez azert fontos, mert az elvezet resze nem maga a kijelzo driver megirasa, hisz az nem volt kerdes vagy kihivas, egyszeruen a hasznalni akartam az alkatreszt.
Azt sem mondhatjuk, hogy az ido nem erdekes, mert ez nem mindenkire igaz.
Nem mindenknek van ideje megirni mindent assembly-ben, hisz legtobb esetben azert nem cel a mikrovezerlo , hanem csak eszkoz.
Termeszetesen van, amikor a C maga lassu mert esetleg par (tucat) ns-rol beszelunk, ekkor a egyertelmuen nincs mas megoldas. Emlekszem, amikor utoljara hasznaltam assembly-t fizetos munkara, az kb 20 eve volt, BSD-hez kellett video streamer. Az a megoldas tartalmazott assembly beteteket (annak ellenere hogy a vas alatta bivalyeros PC volt) de maga a driver az C-ben volt. Es soha nem fejeztuk volna be a munkat ha az egeszet assembly-ben kellett volna megirni.
Ennek az egesznek amit irtam az elso sora a lenyeg:
A ket nyelv nem osszevetendo, mert nemhogy alma es korte hanem paradicsom es melegszendvics.

Macro nélkül valami ilyesmi lenne:

Szerintem te valamiről lemaradtál!

Az egész abból indult ki, hogy én azt fejtegettem a cikkemben, hogy egy olyan feladatra, amihez a mikrovezérlőnek csupán 1-3 I/O portját használjuk fel, ne alkalmazzunk már 40 lábú Arduinot 20 millió utasításciklus/másodperccel, 28 kilobyteos tárhellyel. Márpedig ha szükséges hardver oldaláról közelítjük meg a dolgot, azaz erre a feladatra egy PIC10F322-est választunk, ami tuning nélkül csupán az 1/5-ét tudja utasításciklus/másodpercben, a tárhelye pedig mindössze 0,512 kWords, akkor az esetek java részében lehetetlen rá C-ben fejleszteni. Pedig sokszor lényegesen jobb választás egy ilyen mütyűr, mert az egyszerű hardvere végett megbízhatóbban teljesít.

Erről pont az jut eszembe amivel most kínlódok. Van egy CAN vezérlés ami egy STM32-re épül. Maga a CAN 2 lábat használ, ezen kívűl van még 3db nyomógomb. És ehhez van egy 48 lábú kontroller.

az esetek java részében lehetetlen rá C-ben fejleszteni
Most java vagy C?
Bocsi, nem hagyhattam ki

Nem maradtam le es nem a cikkedre valaszoltam. A tobbi stimmel.
De ez itt amugy is off.

Még pár gondolat, ami talán érthetőbbé teszi az én hitvallásomat.

Na itt van a kutya elásva. Az időnél. Azért vannak tele hibákkal az operációs rendszerek, a különböző programok, és sajnos a céleszközök (jármű elektronika és társai) mert talán egyedül az űrtechnológiában nem ütik a programozó fejét állandóan azért, hogy miért nincs még kész a szoftver.
Egy hobbista ne tűzzön már határidőt maga elé. És ne törödjön bele az első változatba, ha az már majdnem jó. Ha egy modellező csak összedobál egy repülőgép modelt, lehet, hogy fel fog szálni, de nehéz lesz irányítani, esetleg valami letörik róla a levegőben aztán lepotyog. Ezért inkább rászánja az időt és megcsinálja rendesen.
Miért lenne ez más az elektronika világában?
Természetesen vannak olyanok, akiknek megtetszik valami és utánépítik. Esetleg kicsit más formában, más csomagolásban, majd rátöltik a kész szoftvert. Nincs evvel semmi baj. Nekik maga az építés adja az örömet. Mások esetleg új dolgot találnak ki, de nekik az áramkör tervezése, élesztése ad örömet, mellékes, szükséges kiegészítő a program. A megírása inkább gyötrelem mint öröm. Ők használjanak nyugodtan C-t vagy egyebet. Legfeljebb, ha valami nem működik, többet mérgelődnek vele.
Valamint vannak olyanok, akik minden részletet maguk akarnak kifejleszteni mint én. Még akkor is, ha az ötletet az eszközre másoktól vették. Azok viszont ne nyúlkáljanak Arduinoért, hanem válasszák ki a szükséges legkisebb hardvert és tisztességgel agyalják ki hozzá a programot a hardver saját nyelvén, azaz assemblyben. Ott ugyanis olyasmit is meg lehet csinálni, amit más nyelven, előre megírt komplett szoftverrészekkel nem.
Kíváncsi lennék, hogy magas szintű programnyelven létezik-e olyan előre definiált rutin, vagy parancsok, amivel ezt a játékot a 128x64-es GLCD kijelzővel meg lehet csinálni.
Amúgy ennek komoly gyakorlati haszna is van. (mármint ha rászánjuk az időt a szoftverre)
Valós dolog!
Olasz elektromos kerékpár motor vezérlő. Áll a szokásos 6 FEt-ből, 1 stabkocka, 4 valamilyen ic. Tudása: Érzékeli a pedál tekerését és a fék meghúzását. Fékezés esetén lekapcsolja a hajtást. Ha a pedált tekerik, némi késleltetéssel max. energiával megy a motor.
Ugyanez kínaiba. 6 FET + stabkocka + 1db mikrovezérlő.
Tudás: Pedálról vezérlés, gázkarról vezérlés, fékkar visszajelzésre elektromos fékezés fékenergia visszatöltéssel, analög sebességjel kiadása még tolásra is, rükverc, tempomat.
Vajon melyik tervezésébe fektettek több energiát?
Nem utolsó szempont, hogy az olasz vezérlő még egy évig sem működött, a kínai meg 4 éve teszi a dolgát.

Nem dol ossze a vilag ha nem egyezik a velemenyunk.
¯\_(ツ)_/¯

Létezik 20 lábú stm32 is amiben van CAN periféria (STM32F042F6).
Én pont a szándékosan butított C fordítók miatt fordultam el a PIC-től és álltam át ARM-re. Az ST szerintem nagyon jól csinálja, hogy ingyenesen butítás nélküli fejlesztőeszközöket tesz elérhetővé. 8 bites PIC-re még írtam tisztán ASM-ben programot, sőt még a 16-bitesbe is belevágtam, de aztán teljesen átálltam a C-re (pic18xxx-en először C18-al, később XC-vel, néha feltételes betétekkel -#ifdef- mindkét fordítóval fordítható kódot is írtam). Az ARM utasításkészletet már csak érintőlegesen ismerem, de azért néha ránézek miből mit fordít a C fordító. Egy C nyelvre alkalmas architektúra esetén már igen ritkán van szükség ASM betétekre.

Az áramkör 5 IO-t igégyel, tehát egy 8 lábú bőven elég lenne. A 20 lábú is ágyúval verébre csak kisebb ágyúval.

Bár nem néztem utána, de esélyesnek tartom, hogy a 8 lábú PIC-ek vagy 8 lábú ATMEL-ek között sem fogsz találni CAN vezérlőt tartalmazó típust.