Nekem nem. Feladat es ismet csak feladat.
Itt egy memoriamodul, hobby kategoria, tesztelnem kellett, gyorsan. Erre az arduino board tokeletesen megfelel, C/C++-ban. Hobby, raadasul olcso, gyors. (A kepen nem latszik de az van radugva)
Teszteles, tartalom ellenorzes, hexa, formazott lista soros terminalra. Ez barmi de nem assembler. (Es igen, kerlek hidd el abban is megtudom irni de nem az MCU programja a cel, az csak egy eszkoz)
A tobbiben egyetertunk

A "Miért éppen Assembly" cikkre reagálnék. Erre: https://www.hobbielektronika.hu/cikkek/miert_eppen_assembly.html?pg=2

A második oldalon lévő példaprogram 49 bájt és szabályozni lehet vele! Hogyan lehetséges ez? Sehogy! Ez ugyanis nem szabályoz, hanem csak vezérel! A szaknyelvben akkor beszélünk szabályzóról, amikor a vezérlés hatását mérjük és ezt visszacsatoljuk a beavatkozó jelbe valamilyen számítás szerint. A szabályozás emiatt a visszacsatolás miatt általában bonyolultabb, mint az egyszerűbb vezérlések. Szerintem nem is lehet 49 bájtban megcsinálni.

Én is ASM rajongó vagyok, de a cikkben lévő C kritikával nem tudok egyetérteni. Egyrészt a példák túl egyszerűek, a való életben sokszor eljön az a bonyolultsági szint, ahol már nem kifizetődő ASM-et írni. Másrészt pedig illene érteni ahhoz, amit kritizálunk! Az Arduino valóban nagyon nagy kódot csinál, de ez korántsem jelenti azt, hogy ne lehetne például a "villogós" feladatot (ami egyébként túl egyszerű ahhoz, hogy benchmarknak használjuk) egészen picire is megcsinálni GCC AVR-rel C nyelven. Csak sajnos a szerző nem ismeri ezt, és arra következtetett, hogy a C ennyit tud. Az Arduino valóban nagy programot csinál, de az bevallottan egy kezdőknek szánt megoldás. Egy profi le tudja csupaszítani arra, ami kell neki, és az az ASM-hez sokkal jobban közelíteni fog méretben.

A szoftver fejlesztésben a kimenet mérete, de akár még a futásideje is sokszor nem a legfontosabb szempont, például a beágyazott fejlesztésben is előny lehet, hogy a tesztjeink jelentős részét akár PC-n is tesztelhetjük. Vagy akár egy újfajta HAL réteggel ugyanazt a programot PC-n is futtathatjuk. A legutóbbi eszterga mérő projektemhez készítettem például webes szimulációt is: https://rizsi.com/programs/eszterga/emscripten/lathe.html Ezt csinálja utánam valaki ASM-ben! (Nem lehetetlen, de nehéz volna...)

Ezért van, hogy fogalmuk nincs hogy hogy is működik valójában a mikrovezérlő. Valószínű soha ki nem nyitják az adatlapját, nem érdekli sokukat. Ez szerintem nagy hátránya az arduinonak. Rosz úton indítja el őket.

Hányan programozgatnának hobbi szinten ha kikötnék, csak teljes ASM ismeret után kapnának egyszerűbben kezelhető fejlesztőkörnyezetet? Nem kell a szílicium egykristály szintjén ismerni egy processzort/mikrokontrollert hogy használható, értékes programok szülessenek. Nem egy ismerősöm van aki azt mondta, letudta a kötelező ASM leckéket de ezáltal annyira megutálta az egész programozósdit, hogy még az Arduino-t sem hajlandó elővenni.

Akit érdekel az alacsonyabb szintű programozás és lát benne fantáziát, lépni fog.

A gépikódú és ASM szinteket már meghaladtuk. Általánosságban elmondható, hogy a feladatok és az arra szánt idő már nem engedi meg ezt. Túlléptük már a 8080-as processzorszintet amikor nem is nagyon volt más lehetőség. Leírták már korábban is, ma már nem igazán tétel egy nagyobb kontroller vásárlása.

Az külön érdekesség (nem csak itthoni jelenség), hogy az alacsonyabb szintű programozási módszereket használók szinte mindig lesajnáló módon tekintekenek a "többiekre".

Mindenbe bele lehet kötni. Sebaj, hogy a Magyar nyelvben fogalom szinten ez terjedt el.
Sehol nem láttam még pl. fényerő vezérlős kapcsolót! De ha már ilyen kritikusan szemléljük a motor fordulat szabályzását, akkor inkább úgy kellett volna fogalmazz, hogy szabályzás az, amikor úgy vezérlünk egy motort, hogy annak fordulata akkor sem változzon, ha a terhelése változik. Ezt ugyanis már az elektronika előtti korban is megvalósították egy primitív röpsúlyos kapcsolóval.

Ezt a csontot már annyiszor lerágtuk, és annyiszor megválaszoltam, hogy már unalmas.
Idézet a cikk első oldaláról:

Szerintem ez pont az, amit te is írtál.
"Ktulu" jól fogalmazta meg a lényeget.
Mellesleg ez is benne van a cikkben:

Pont egy kezdőnek adni olyasmit a kezébe, amit nem lát át még egy haladó sem, nem olyasmi amivel tanulni, tanítani lehetne.
Arról nem is beszélve, hogy a "mindent készen kapás" leszoktat a gondolkodásról.

Tulajdonképpen a megrendelőt nem érdekli, hogy milyen nyelven írtam a készülék programját.
Minél előbb, vagy általa megadott időre kész legyen, minél olcsóbban, tökéletesen tudja az igényeket.
Ezt a feltételt manapság sok esetben könnyebb (szerintem mindig) magasabb szintű nyelven, vagy csak úgy lehet teljesíteni. Olcsóbb lesz a kissé drágább hardver következményeként esetleg sokkal kevesebb emberi munkaidő.

Igen lehet ez "kemény" megfogalmazás nem a profin van a hangsúly, mert ha "otthonra" kell legyen szó kezdő/haladó/profi bárkiről mindegy, nem feltétlen lényeg, hogy van OS nincs OS (/bármi) én csak a "jó lesz az" elvnek szoktam hívni.

Ezen vélemény igaz nem arduino kapcsán, de egy PIC-es program átvételből alakult ki ahol minden blocking polling-al volt megírva 1-2 dolog ment ISR-ből, de kb a kód nem tudott 2 dolognál többet csinálni egyszere így ezt kellet mókolni majd újra lett írva az egész ez elég negatívan érintett.
De ez már nem hobbi hanem munka volt a viccnek tartás inkább arra vonatkozik, ha valaki egy UNO-val akar fejleszteni beágyas rendszert
1. mert 8 bites (nem lenézés, még mindig használom, "centes" feladatokra)
2. mert már kb az összes gyártó azonos áron dob ki 32-bites kártyákat használhatóbb stack-el és például M-éknél sok sok example-el (ment a Harmony-ra is a szörnyülködés, nekem tökre bevált)
(3.) Az is tény, hogy én bármennyire is még csak egyetemen vagyok, de inkább ipariasabb próbálom tekinteni a dolgokat.

De felróható ellenem, hogy a másik oldalt nem írtam le, hisz az arduinoval is mindent meg lehet csinálni számomra a gond ott van, hogy ezt nem igazán hangoztatják.
És ez megint mindegy egy kezdőnek, csak a későbbiekben úgy látom nincs a másik világ megmutatva.

A másik tapasztalat az, hogy akik arduval kezdtek, többségben, nem tudnak egy UART/SPI/I2C inicializálni, ez sem baj, de én azt gondolom aki kicsit is komolyabban veszi a controller programozást neki illik azért képen lenni, hogy milyen lehetőségek vannak a perifériában.
A másik oldalról meg már minden egyéb gyártónak van configurator ami már legenerálja az initet és csak pár függvényt kell hívogatni utána, csak ne felejtsük el, hogy jó alapra "könnyű" (/könnyebb) házat építeni.

Ha nehezen is, de kezdem érteni, mit állítasz. Légy továbbra is ilyen türelmes velem.
A baj szerintem ott van, hogy a hardver ismeretét elfedi a magas szintű nyelv.
Egy periféria, vagy regiszter/láb kezelése assembly nyelven könnyen érthető, míg azt C nyelven meglehetősen erőltetett feladat elmagyarázni.
Mindkettőnek megvan a helye, de az lenne az igazi, ha könnyebb lenne az átjárás. Ezt azonban sokszor akadályozza a hardver architektúrája.

Szia!

Idézet:
„A baj szerintem ott van, hogy a hardver ismeretét elfedi a magas szintű nyelv.”

Nem a nyelv fedi el alapvetően, hiszen C-ben is megírhatod azt, amit assembly-ben, hanem amikor elkezded használni az előre megírt függvényeket !

Port állítás assembly-ben:

C-ben:

Mi ebben az erőltetett és mit fed el?
Nézz bele egy STM32 Low Layer könyvtárba, C-ben, regiszter szinten kezelheted az egész MCU-t.
Szabadon választott gyakorlatok.

Nem a c vel van a gond hanem az előre megírt libekkel. De amúgy azokkal sincs, csak tanulásra kevésbé alkalmasak

Cserébe megvéd a gondolkozástól...

Ezzel azt allitod, hogy aki nem assembly-ben programozik az nem gondolkodik.
Szerintem ennek fuss neki megegyszer.

Az előre megírt libek használata, nem a magas szintű nyelv...

Talán tudunk egy összehasonlítást csinálni, alábbit írtam -jó régen- basicben, assemblyben szerintem nem sokkal lenne rövidebb.
Vetésellenőrző figyeli vetőgépen 6 különálló csatornán a magpotyogást, 6 szenzor adja a négyszögjelet mag érzékelésekor. Számol csatornánkénti magszámot, ebből százalékosan kiírja folyamatosan a csatornánkénti eltérést, összes magszámot számol, kihagyás és nagy százalék eltérés esetén hangjelzést ad, figyeli kapcsolatot a szenzorokkal -kábelszakadás esetén hangjelzés. Menüben beállíthatók jelzési paraméterek, stb.. Két soros karakteres LCD. A kiírt szövegek vannak külön eepromban.
A lényeg, hogy ez basicben 2K foglal, PIC 16F628 ment benne, most 648A, ennek fele üresen marad.
Mennyivel lenne kisebb assemblyben?

Az eddig írtak lényege röviden, azt érzem sokan nem tudják a feladatnak megfelelő környezet, eszközt kiválasztani (kinek nem inge nem hordja)

A hardware elfedés kétélű dolog, mert C-ben is írhatsz bit szintű piszkálást *, de C-ben sokkal inkább az irányba megy, hogy rétegeket hoznak létre, ahogy rolandgw is említette STM LL könyvtár bit szintre ad olvasható függvényeket (de a Harmony 2.xx PLIB is ilyen) amire sokkal könnyebb egy abstractabb layer-t felhúzni.
És itt már nem az a cél, hogy 1 vagy 3 sor egy bit set, hanem, hogy nem kell újra írni és némi porttal használható bármilyen architektúrán.
Én például LL fölé húztam egy C++ layert (mert jobban teszik elven) UART/SPI.. fölé és így mégis csak én írtam, de többször nem kell megírni.

*: ez megint függ hardware-től is mert PIC 8/16 bit ismer BSF/BCF-et míg PIC32 (MIPS), ARM nem itt az assembly annyiban sokat segít, hogy tudod, hogy 32-bites architektúrán nem használsz bit struktúrát (PIC32 - SET/CLR/INV, M3 - fölött van bit banding region)

A bajt inkább úgy fogalmaznám, hogy sokan nem látják a hardware-t mielőtt egy friendly api-t kezdenek el használni, mert ha már eljut az ember arra a szintre hogy nincs ideje/lusta mindent maga megcsinálni akkor is tudja kb miről van szó.

Ezzel azt állitom, hogy sok mai tömegtermelt imformatikusok egyrészére, habár lehet akár doktori végzettségük is, a kutyámat nem biznám rá sétáltatni.
Assembly-ben is lehet jó kódot irni, Java-ban meg lehet nem jót.

Az utolsó mondatot feszegetem egy ideje, egyetértünk.

Ezt a véleményt azért érdekesnek tartom így leírva.
Ha azt írtad volna, hogy az illető már az assemblyn elbukott, és mikor szembekerült a C kusza összevisszaságával (kapcsos zárójel, sorkihagyás, beljebb folytat, újabb zárójel stb.) végképp feladta, azt inkább elhiszem.
Mint többször leírtam, azt elfogadom, hogy egy adott szint fölött már mazochizmus asm-ben programozni. Sőt bizonyos szint után már én is lehetetlennek tartom, mert sosem készül el, (pl. én sem írok PLC-re másban, mint létrában), de ha valaki a legalapabb programnyelv logikus és formailag is tiszta kezdő szintjétől hátrál meg, az nem is akart soha programozni.
A hangsúly kimondottan a kezdő szinten van!
Bizonyos bonyolultsági fok alatt semmilyen programnyelven nem kerül kevesebb befektetett energiába és kevesebb billentyűlenyomásba egy program megírása, mint assemblyben.
Az az én bajom, hogy vannak akik büszkén hirdetik, hogy ők programoznak, holott nulla gondolkodás árán egymásra dobálnak könyvtári fájlokat valamilyen magas szintű programnyelven, és a leg halványabb fogalmuk sincs arról, mit is csináltak voltaképpen.
Tegyék, ha nekik ez okoz örömet és ettől van sikerélményük. Csak ne gondolják azt, hogy ők tudnak programozni, ne legyen belőlük szoftverfejlesztő és ne barmolják szét az internetet, a telefonok operációs rendszerét, ne készítsenek és töltsenek fel a playstore-ba olyan programot, amitől még a legerősebb telefon is betérdel.
Egy szó mint száz, ne álljon programozónak az, aki nem tanult meg vért izzadva assemblyben párezer soros hibátlan programot írni! Mert az nem tud, nem tanult meg programozóként gondolkodni.

Nem akartak programozni a kurzus után, rá se néztek a C semmilyen variánsára, de előtte kíváncsiak voltak a dologra. Kötelező tantárgy volt, részleteket nem tudok, annyira nem érdekelt a dolog.

Ettől függetlenül továbbra is azt mondom, ne ASM-ben kezdjenek programozni az újoncok. Attól a C (vagy valamilyen magasabb szintű nyelv) érthetőbb, egyszerűbben átlátható.

Figyelem! Nem keverendő össze a dolog a bit, bájt, logikai kapcsolatok, ciklusok stb. ismeretével! Utóbbiak nélkül tényleg értelmetlen bármilyen programozást tanítani. Az ilyenek hiányánál jön elő pl. az, hogy egy weblap motorjában Double méretű változó van lefoglalva egy 3000 Ft-os termék árának vagy lebegőpontos változó egy mikrokontrollerben miközben csak egy tizedesjegyig érdekes az eredmény.

Itt keverjük a hobbi és profi hivatásos tudású programozást. A profinak nyilván ismerni kell a gyökerektől sokmindent. A hobbistának vagy van kedve belemélyedni assemblerbe, vagy a programozáson legegyszerűbben túl akar jutni.
Én a Z80 -on kezdtem assemblert, majd látva a közel 700 utasítást, vagy alutasítások nem is tudom már, kimenekültem a témából. Pic basicnél visszajöttem, így már érdekes.
Pic basicnél is a proci regisztereket piszkáljuk, annak működését teljesen ismerni kell, nem feltétlenül jelenti a procitól való elidegenedést a magasabb szintű nyelv. Visszább írtam mi fér basicben a pic 2K-ba. Ehhez assemblerben ügyesnek kell lenni.

Elore megirt libek-ek csak magas(abb) szintu nyelveken (nem assembler) hasznalhatok/hatekonyak.
Amikor magadnak irogatsz/gyujtogetsz asm rutinokat, fuggvenyeket,akkor gyakorlatilag a sajat programnyelvedet fejleszted.
Szep feladat, elobb utobb majd minden programozo nekifut, aztan tobbseguk belatja, hogy ha nem maga az asm kod a cel, akkor talan erdemesebb szazezrek/milliok altal hasznalt, fejlesztett, tesztelt nyelvet hasznalni.
Es ismet: Ha a feladat ugy kivanja.

Vagy csak valaki már gondolt előre az euró bevezetésére

A kedvencem az a telefonos zseblámpa app, ami root jogot kér.
Mert aki ilyet ir, az:
- vagy nagyon gonosz,
- vagy nagyon hülye

Miért nem lehet assembly nyelvben egy előre megírt függvényt/libet hatékonyan használni?
Az a sokmilliárd veréb sem tévedhet, ugye?

1. Mert csak adott mcu/cpu eseten tudod hasznalni, minden esetben ujra kell irnod (adott csaladon belul is elterhet az mcu-k utasitaskeszlete).
2. Iszonyou sok idot emeszt fel a bonyolultabb altalanos lib-ek fuggvenyek megirasa.
3. Minden esetben meg kell irnod, nagyon ritka mikor mas kodjat valtoztatas nelkul tudod hasznalni. (sajat kodnal lasd elso pont)
+1. Sok tesztelo biztosan kevesebbet teved mint egy, raadasul sajat kodot korrekt modon tesztelni eleg nehez, de ezt egy programozonak talan nem kellene magyaraznom.

Ebben neked tökéletesen igazad van. És el is érkeztünk a magas szintű programnyelvek legnagyobb hibájához. Álltalános! Tehát hosszabb és bonyolultabb (azaz több helyet foglal és lassab) mintha célzottan az adott hardverre készült volna.
Ám itt jön a DE!
Erről nem a szoftverfejlesztők tehetnek, hanem a gyártók! Mi a fenéért kell csak a PIC18F szériából kb. 500 fajtának lennie? Miért nem lehet az új fejlesztést úgy csinálni, hogy többet tudjon, mint a régi, de visszafelé kompatibilis legyen, hogy a régit meg lehessen szüntetni.
Illetőleg úgy, hogy ha van egy jól kitalált függvény az az összes PIC18-ra kompatibilis lehessen, és ezt ne szoftverből keljen megoldani? Nem akarom elhinni, hogy a gyártó cégnek gazdaságos ennyi fajtát gyártani.

Tényleg nem látod át, amiről beszélsz! Pont hogy ez az általánosság a legnagyobb előnye az assemblyhez képest, mivel csak egyszer kell jól megírni/implementálni mindenre(amit nem te fogsz megtenni, hanem csak használni fogod), és többé elfelejtheted a mókuskerék kínlódásokat családról családra, platformról platformra! Mert ezeket helyetted megteszik mások, nem egy személyben, így a hibalehetőség nagyságrendekkel kisebb lesz, mint amikor te írsz meg egy sajátot! Arról nem is beszélve, ezeket az implementációkat legtöbbször valóban profik írják, akik erre vannak ráállva! Nem hinném, hogy hirtelen csak úgy partszélről beesve, amatőr programozóként, vagy hobby programozóként ezt túl tudnád szárnyalni.... Persze, nem lehetetlen ez, de csekély a valószínűsége, hogy sok-sok programozó agytevékenységét, egy személyben hirtelen valaki felülmúlná záros határidőn belül...
Általánosságban elmondható - az első komolyabb programnál mindenki belátja, hogy az asm nagyon nem hatékony(idő/eredmény), vagy szinte lehetetlen/átláthatatlan/hibáktól hemzsegő kód lesz a végeredmény, így 99%-ban a C valamilyen variánsánál köt ki!

Hogy látná át? Félig vakon ecseteli a térlátás tudományát.