Szerintem 16 bitesnel kisebb PIC nincs arra a celra es feltetelezem abbol 20+ pin a minimum. De egy ideje nem kovetem a PIC vonalat, lehet azota van valami kisebb, nagyon cel kivitel.

De van, viszont 28 láb a "legkisebb". Mármint ami 8 bit és CAN.

Sokan tudják rólam, hogy kommunikáció terén én az 1-Wiret favorizálom. A CAN buszról csomó rémtörténetet hallottam már autószerelőktől. Ezért most kicsit utána olvastam.
Nos az egész lényege, hogy nincs mester-szolga viszony. Mindegyik eszköz mondja a magáét. Minden eszköz adás közben is figyeli az adatvonalat, így azonnal észreveszi, hogy vele egy időben más is "pofázik". Ilyenkor beszünteti az adást és ha szabad a vonal újra próbálkozik. Tehát mindenki ad, és minden adást mindenki vesz. A címzésekből ki-ki leszűri, ha neki szól.
Ezt írja róla a szakirodalom:

Idézet:
„Mennyi lehet a hibázás? Hogy ezek az alarm-üzemmódok nem túl gyakran váltogatják egymást egy jól üzemelő rendszerben, azt a következő adatok bizonyítják: Egy 25%-os terheltségű buszon, 500 kbps sebesség mellett, a hibázás statisztikai gyakorisága: 200 év.”

Hú de jól hangzik. Mindjárt megtérek.
De akkor mi a helyzet a rémtörténetekkel?
Talán az, hogy ha valamelyik eszköz meghibásodik, és adás közben nem ellenőrzi az adatvonalat, akkor csak ad folyamatosan, blokkolva a rendszert? Vagy a kényes két végi lezárás sérül? Vagy netán a folyamatos ugatás miatt az egyes eszközök állandóan az adatokat elemzik, mi szól nekik és mi nem, ezért a saját dolgukra nem marad idejük?
Nem tudom, csak tippelgetek, mert nem értek hozzá. Csak azt tudom, hogy amiket hallok, meg a statisztika nem fedi egymást.

Jelenleg a legkissebb 28 lábú, amiben van.

Igen, tevedtem. Hosszu ido utan elovettem a mcu selector-t es latom van nehany tipus a 18F csaladbol. A legkisebb is 28pin es 32kb (program) memoria.
En a labszamot nem latom problemasnak amig aruljak 6x6-os vagy 4x4-es qfn/uqfn tokban, bar az en hobby kategoriam a CDIP/PDIP (surubbeknek mar adapter kell, hogy tudjak veluk jatszani)
..es a 32k-ba azert belefer par sor C program is, igaz eletemben nem hasznaltam CAN bus-os interface-t de nem gondolom hogy rettentoen bonyolult lenne.

Na igen.... Nem merültem bele nagyon, de a picekben lévő kommunikációs hardvereket meg lehet valósítani szoftveresen is. Nem hiszem, hogy a CAN lenne ez alól a kivétel.

A rémtörténetek legtöbbször hozzá nem értésből, elektronikában nem túl jártas autószerelőknél keletkeznek, egy sima szkóppal legtöbbször felderíthetőek a can hibák. Leggyakoribb a táp/test zárlat valamelyik vonalon, az még multival is szinte. Ilyenkor persze blokkolva van a can vonal. Az 1Wire teljesen más dolog mint a can, zavarvédettség, hatótáv, sebesség. Mindkettőt másra találták ki.

Szia. A cikkedhez hozzászólva:
"... ne alkalmazzunk már 40 lábú Arduinot ... "
Pont nem ezt fejtetted ki abban, hanem a C fordítás utáni kód méretét. Aminek az összehasonlítása az asm-el abszurd. Minden valamilyen más nyelven írt kód hosszabb lesz, mintha azt asm-ban írták volna. Ezen elcsodálkozni azt kissé furcsának találom. A cikkednek ezt a részét nem is értem, hogy mi szükség volt rá. Ráadásul nincs is konklúziója, hiszen rögtön rátérsz egy 8 kivezetéses tok programozására. Amúgy a PIC-ek C fordítóját is megnézted? Mert az is jó nagy kódot generál.

Szia!
Köszönöm, hogy megosztották velem a véleményedet.
Szeretném megválaszolni a felvetéseidet.
Tisztában vagyok vele, hogy bármilyen nem assemblyben írt program jóval hosszabb lesz. Én azért emeltem ki ezt külön, mert a hardverpazarlást, ami egyenesági következménye a könnyen írható programoknak, ki nem állhatom. Az csak az egyik ok, hogy minél bonyolultabb a hardver, annál sérülékenyebb. A másik ok az, hogy zavar, ha valami kihasználatlan. Azaz el lehet hozni a sarki boltból egy kiló kenyeret kamionnal is, de szerencsére viszonylag kevesen vetemednek ilyesmire. A számítástechnikában pedig a programozók, és sajnos a hobbisták legtöbbje ezt teszi.
Maradva a sarki bolt-kenyér párhuzamnál.
Ha elmegyek érte gyalog, sok energiát fektetnek be, de gazdaságos. Ez az assembly.
Ha előszedem a raktárból a motoromat, sisakot húzom és elmotorozok érte, jóval kevesebb a befektetett energiám, de már nem nevezném gazdaságosnak. Ez a C nyelv. Ha csak bepattanok a ház előtt álló autómba alig fektetnek be energiát, és kifejezetten gazdaságtan. Ez a blokkos programozás, vagy más igen magas szintű programozási nyelv.
Természetesen a havi nagybevásárlást már én sem intézem gyalog.
Ezt próbáltam kifejteni a cikkben, és erről szólnak a bemutatott kapcsolások.
Tisztelettel: János

Én ezt használom de tisztellek az assembly miatt ...

Teljesen egyetértek a pazarló programozásról írt véleményeddel, de vannak kategóriák, esetek amikor érdemesebb azt választani. Pld.: nagyobb bonyolult pic program assembly módon igencsak komoly erőfeszítés, gyakorlat kell hozzá, hogy optimálisan kicsi és gyors legyen kihasználva assembly lehetőségeit. Ugyanez basicben töredék munka, és mondjuk 500 Ft.-al drágább nagyobb proci kell mert pazarlóbb, de sokkal kevesebb időm megy rá.
Lehet assemblyben nagyobb rosszabb programot írni mint basicben, ha nincs kellő gyakorlat hozzá.
Nem cáfolni akarlak, profi szinten más kategóriákban valóban nagyon-nagyon pazarló a programozás.

Köszönöm szépen a tartalmas választ.
A pazarlás ellen vagyok én is, de a példádhoz azért nem tudok hozzászólni, mert szerintem nem összehasonlítható a 2 dolog. A bemutatott programjaid alapján látszik, hogy jól értesz hozzá, ezért mondanom sem kellene, hogy a leggyakrabban (de nem mindig) 2 féle optimalizálást szoktak alkalmazni, vagy sebességre, vagy pedig méretre (csak a példa kedvéért egyszerűsítem le ennyire). Melyik lesz a pazarló? Ha a sebességre, akkor a tárhelyből pazarolsz, míg ha méretre, akkor meg az időt pazarlod. De másként is meg lehet közelíteni. Azzal, hogy egyre olcsóbbá válnak a chipek, szabadabban lehet bánni a mérettel. Ez nekem is eleinte elég nehezen volt elfogadható, mivel én még Z80 gépi kóddal kezdtem, első gépem egy 16k-s Spectrum volt. Emlékszem, a 64k*1 bites DRAM ára akkor 800 Ft/db volt, amikor egy havi fizetés kb. 5000 Ft. De nem kívánom vissza azt az időt, mivel a fejlődés iránya megváltozott. Már nem a "vas", az eszköz az értékesebb, hanem az idő. Annyira felgyorsult minden (ezen lehet sajnálkozni, de ez van, tudomásul kell venni), hogy az idő szorításában élünk. Annak ellenére, hogy világ életemben ASM-ot programoztam, még elsőként a PIC16C84-et. Én is csak pislogtam, amikor elkezdtem Arduinoval foglalkozni, hogy mekkora pazarlás ez. De nekem megváltozott a véleményem, mivel a támogatottsága sokkal nagyobb, egyszerűbben, könnyebben lehet rá fejleszteni, azaz sokkal gyorsabban készen vannak a feladatok. Ennek ellenére maradtam valamelyest a PIC-eknél, de már egyre kevésbé. Ennek talán az is a része, hogy az MPLAB-ot szerintem "elbarmolták", a C fordítójával rengeteg bajom volt, nem is használom (a régi nekem stabil volt, de megszüntették a támogatását), de erre nem térnék ki, lehet bennem van a hiba. Szóval visszatérve a pazarlásra, én inkább az idő pazarlását tekintem előrébb, mint az olcsón, lényegesen nagyobb hellyel rendelkező eszközök használatát. Mondom ezt úgy, hogy ismerőseimmel rendszeresen azon versengtünk, hogy 1-1 feladatot ki tud kevesebb BASIC sorral megoldani. Természetesen tiszteletben tartom a véleményedet, de én már egy kicsit másként vélekedek. Ez azért is lehet, mert nekem a programozás soha nem a megélhetésem volt, pusztán passzióból, a sikerélményért csinálom (persze ha van érte fizetés, azért azt elfogadom).

Sokat segiteni ha ismernel tobb programnyelvet. Es tobb problemat.
Es esetben nem irnal ilyen cikket.
Sok esetben keveredik (keveredhet) a hobbi es a munka, sok esetben kifejezetten tilos keverni. Amit hobbibol megengedhetsz magadnak (elgyalogolsz Budapestrol Romaba) azt nem teheted meg a munkad soran.
Ez pedig az en velemenyem

Valami elkerülte a figyelmedet a cikk olvasása során!

Nem unod még ezt az assembly mantrázást? Nincs abban semmi szégyen, ha nem tudsz, nem akarsz, nincs rá időd más programnyelvet megtanulni. Véleményt írtál egy olyan fejlesztőkörnyezetről, amiről láthatóan halvány lila gőzöd sincs.

Szerintem nincs értelme azon vitázni, jobb e, rosszabb e manapság assemblyben programozgatni?! A tendencia egyértelmű, ha kicsit is komplexebb feladatokat kell megvalósítani, már otthoni, amatőr célra sem megfelelő választás az assembly! Egyszerűen normál halandó nem fogja átlátni már a saját kódját sem, és akkor(pl USB kommunikáció, vagy ethernet, esetleg TCP-IP, vagy hasonlók...) még nem is beszéltünk! Meg lehet csinálni, nem lehetetlen, de az átlag programozók igen kis hányada lenne erre képes(ahová jómagam is sorolom). A 2000-es évek közepéig sokat programoztam assemblyben, köztük voltak nagy és bonyolult programok is. De kb 2008 magasságától kezdve, mikor végre rávettem magam a C nyelv használatára, kevéssel utána nem voltam hajlandó assemblyt a kezembe venni, még led villogtatáshoz se! Nincs értelme ma már ennek... Letűnt kor letűnt eszköze csupán....

Szerintem azt hiszitek hogy a magasabb szintű nyelvek minőségi változást jelentenek.
Az assembly és a magasabb szintű nyelvek kiegészítik egymást. Az, hogy kevesebbet kell gépelni, nem feltétlenül hozza magával az egy program fejlesztéséhez szükséges idő csökkenését.

Teljesen egyet értek.
De úgy látszik, a trollkodás nem írtható ki sehonnan.
Ide jön rolandgw egy fórumra, aminek a címe "PIC assemblyben" és leszólja az assemblyt. Valamint leszól egy cikket, aminek az első soraiban az áll, hogy ha nem érdekli a téma, ne is olvassa el!
De ha már elolvassa, épp csak azt értette meg belőle, amiről szól!
Azok kedvéért, akik szintén nem értették meg, annak ellenére, hogy jól le van írva benne, valamint Josi777-nek írt válaszomból is kitűnik, (amit ő meg is értett, és értelmesen megválaszolt) az én bajom avval van, ha valaki inkább mérőhasábokkal és hézagoló lemezekkel támaszt alá egy billegő szekrénylábat, mert lusta több rétegre összehajtogatni egy újságpapírt!
Avagy két LED felváltva villogtatásához azért használ agy Arduino UNO-t, mert ahhoz csak 83 billentyűt kell lenyomnia a billentyűzeten, hogy működjön, míg agy PIC10-es assemblyben 213 billenyű lenyomás! Ugyanezen emberek rövídítenek egy "hogy" szócskát h-ra a facebookon. Csak tudnám, mit kezdenek az így felszabadult rengeteg idővel?
Ja, tudom! Elmennek trollkodni!

Sziasztok!

Remélem nem veszitek bántásnak, ha megpróbálom mindkét oldalt pártolni és ellenezni

Bár lehet sonajkniz fogalmazása durva, hogy miért is kell ~900 byte egy LED villogóhoz, de egy erre tévedő kezdőt mozdíthat az ASM felé.
Szerintem egy vérbeli programozónak tisztában kell lennie némely assembly utasítással, a hardware felépítésével én a 8 bites PIC-nek köszönhetem, hogy megértek PIC32/ARM/x86 assembly-t is többségben és mindez miért jó?
Az egyetemen nagyon jól jött az assembly a 8085-höz

Egy led villogóhoz lehet felesleges, de DSP, RTOS, stb... könyvtárakban sűrűn fogunk assembly-vel találkozni mivel a C már nem ad lehetőséget effektív kezelésre/hardware specifikus definíciók használatára.
És persze ezek meg vannak írva, de nekem szükséges volt ezen libek megértésre és nem tudom mennyire lett volna érthető 0 assembly-vel.

High-level oldalrol, hogy miért is kerül 900 byte-ba az a led villigó
- A C-nek használ inicializál stack,heap,static területet, nem feltétlen tudod, hogy a dinamikus memória kezelés, (ardun) soros port könyvtár, és sok más egyéb befordul-e a kódba alapból.
- 8 bitre "nem" létezik C, főleg microchip-en egy accumulatorral (WREG) szemben 32 biten ahol az int register és van 16-32 accumulator.
- És ne felejtsük el hogy GCC/XC/Keil/Clang mind mind rendelkezik optimalizációval, amely lehet nagyobb kódot eredményez, de 32 darab registert lehet egy automatizált fordító jobban tud kezelni
(-XC8 igen selejt kódot szeret fordítani, szegény néha azt tudja melyik bankban van)

Azzal viszont nem értek egyet, hogy a C-kód tele lenne ütközésekkel ez hozzáértés/hozzáállás kérdése mivel egy jó kódot lehet több idő megírni, de ha fel van készítve "mindenre" akkor ezt csak 1x kell megtenni. Persze ez kicsit lib szinnt, de alkalmazás szinten, ha a libek megfelelően megvalósították, konzisztens kódolást használnak akkor alkalmazás szinten kétlem, hogy túlzott ütközéssel találkozol.

A kezdők sokan választják a C-t mert osztani szorozni nem kell, olvashatóbb (stb...) *, de a típus/objektum orientált nyelveknek nem ez a legnagyobb fegyvere, hanem a megfelelő adatmodell/adatmodellezhetőség, rétegezettség.
És ennek nem 100x sornál van lényege hanem 10000x sornál, ahol minden része kapcsolatban van minden részével a kódnak.

*: És azért ne felejtsük el azt, hogy 5-10 GB-os software-eket nehéz lenne assembly-ben megírni így a softwarefejlesztés is C/C++/C#/Java "nyomás" alatt tartja az egész világot.

"*: És azért ne felejtsük el azt, hogy 5-10 GB-os software-eket nehéz lenne assembly-ben megírni így a softwarefejlesztés is C/C++/C#/Java "nyomás" alatt tartja az egész világot."

A meret lenyegtelen, a feladat az ami fontos.
Szerintem senki nem vitatja az assembly szuksegesseget, viszont tisztaban kell lenni a nagyon is letezo korlataival. Ezt vitatni szerintem felesleges.
Megegyszer: feladathoz a nyelvet.

A cikkben nemi lenezessel emlitett arduino emberek ezreinek (talan millioinak) segitett az alapok elsajatitasaban es bizony profik is hasznaljak. Vannak hibai, korlatai, de azokkal egyutt is nagyon hasznos.
Led villogtatas pedig felejtos. Pontosan nulla byte kell hozza.

Erősen ki léptünk az assembly témakörből, de ennek a témának a pontos kiértékeléséhez nem tudunk másképp tenni.

Persze lehet egyoldalú az álláspont a cikkben, mivel a másik végletre nem tér ki (komplex kódok).
De én viccnek tartom, hogy profik is használják. *
Mivel a mainstream example-ök próbálják elfedni a hardware-t, nem feltétlen van megfelelően hangsúlyozva az interrupt-ok jelentősége és az egyszerűség miatt a legtöbb dolog blokkoló algoritmussal van megvalósítva, ami egy komplex többfolyamatos rendszerben nem megengedhető.

* Persze ez is két oldalú, mert egy alapnak nagyon jó tud lenni amiből lehet némi időráfordítással nem-blokkó portolást írni.

Nekem nagyon tetszik a cikk illetve a szellemisége Sajnos megértük, eljutottunk a pazarlás (vele együtt a hülyeség) korába, és ami a legnagyobb probléma, hogy szinte mindenben és mindenhol, amelyért k.rva nagy csekket hoz majd a "postás" a legvégén...
Én jelenleg Commodore Amiga és PC közötti USB-s adat és fájlátvitelhez fejlesztem a HW-t és SW-t, és számomra magától értetődő, hogy MC68000-ra kizárólag az assembly jöhet szóba! A Motorola asm kifejezetten szép, én imádom!

Mondjuk az x86-ról ez már koránt sem mondható el, és bevallom azt is, manapság PIC-hez mikroBasic-et használok, mert gyors, egyszerű, de erre nem vagyok büszke...

Majdnem 40 eve irtam eletem elso gepi kodu (nem volt assembler,mert nem volt szamitogep hozza, legalabbis nekem nem) programjat.
Utoljara mult heten hasznaltam, mert kellett. Emellett viszont hasznalok arduino board-ot, mert kenyelmes es minden rajta van ami kell egy gyors(an megirt) kodhoz. Nem feltetlen hasznalom a fejlesztoi kornyezetet, mivel nekem a standard c kenyelmesebb es tobbnyire eleg, de van amikor eloveszem akar azt is.
Mint feljebb irtam feladattol es rendelkezesre allo idotol fugg.
A "profik is hasznaljak"-at komolyan gondoltan, meg ha neked vicces is. Nem vagyunk egyformak. Es nem tudom neked mit takar a "profi" mint jelzo.
De ez tenyeleg nem pic es meg csak nem is assembly tema. (Mondjuk nem tudom hol mashol lehetne ra reagalni.)

Kit értesz a profi alatt?
Több mint 45 éves programozói múlttal, közel száz számítógéptípus/nyelv/fejlesztőkörnyezet ismeretével én már annak számítok, vagy még kell egy kicsit fejlődnöm a profi szinthez?

Profi alatt ilyen szövegösszefüggésben azt szokták érteni, aki ebből él, ellentétben az amatőrrel, aki szórakozásból csinálja.

Egyik gimnáziumi osztálytáram az almás cégnek fejleszt programokat... Igen, assembly -ben, mert fontos a futási idő.

Régi anekdota:
Egy programozó le tudott faragni az indulás időből pár tized másodpercet.
Nem sokkal később kapott egy üzenetet a cég vezetőségétől:
"Gratulálunk! Évszázadokat spórolt meg az országnak!"

Köszönöm, de magyar az anyanyelvem, elég jól megértem.

Félreértettél. Sokáig használtam AVR assemblyt, kb. olyan hívő voltam mint te.
Mint mindenhol itt is fontos a sikerélmény és összetett feladatoknál már inkább nyűg volt, mint élmény. Pláne mikor megírtam ugyanazt C-ben és pár százalékkal lett nagyobb kód, mint a sokkal hosszabb idő alatt megírt assembly.
Nekem semmi bajom a cikkeddel, a tudásod is elismerem, de ez az assembly kontra C++ bevezető felesleges volt, szerintem.

A livejasmin (Gattyan Gyuri cege amibol kesobb milliardos lett) indulaskor tartalmazott assembler-ben irt kodot is (C/C++, Perl, PHP, Java es JavaScript mellett) 2000-2001-ben, pedig az egy website volt.
Sosem tudni mikor van ra szukseg de ha abban kellett volna megirni az egeszet sosem keszult volna el...

Azt kell mérlegelni, hogy mi lesz a drágább, a hatékonyság akadályozója. Érdeme-e fejlesztéskor többet ráfordítani és gyorsabb kódot előállítani. Nem mindegy, hogy egy adott rutinnak hetenként, óránként, másodpercenként vagy másodpercenként több ezerszer kell lefutnia. Az utóbbinál érdemes minden lehetőséget megragadni a kód futási idejének csökkentésére. Ameddig csak hobbi szinten vagyunk, az első korlát az, hogy belefér-e a program memóriába.