Milyen self-hosted programozási nyelvet pereferálnál egy mikrovezérlőnél?

Programozás

Ismerősökkel való ötletelés közben merült fel egy Arduino jellegű mikrokontroller panel, aminek az extra képessége az lenne, hogy a ROM-jában tartalmazna egy beépített editort és interpretert. Ennek segítségével, mindenféle extra szoftverkörnyezet nélkül, gyorsan, és könnyen lehetne egyszerű programokat írni a kártyára.

A kérdés az lenne, hogy milyen programozási nyelvre lenne a nagyközönség leginkább vevő? A listában szerepelnek fordított nyelvek is, ez esetben, értelemszerűen, az adott nyelv, egyszerűsített, interpreteres változatáról lenne szó.

C,C++
28% (153 szavazat)
BASIC
5% (28 szavazat)
PASCAL
3% (16 szavazat)
LUA
5% (28 szavazat)
Python
31% (166 szavazat)
Forth
3% (15 szavazat)
Rust
5% (29 szavazat)
Javascript, ECMAScript
5% (29 szavazat)
PHP
4% (21 szavazat)
Tcl/Tk
0% (2 szavazat)
Perl
2% (13 szavazat)
Rexx
0% (2 szavazat)
Lisp
1% (8 szavazat)
Fortran
1% (7 szavazat)
Egyéb, leírom a hozzászólásokban
4% (21 szavazat)
Összes szavazat: 538

( NagyZ v | 2021. 06. 06., v – 10:21 )

hianyzik az opcio hogy "nem kell meg egy", igy muszaj volt az egyebre kattintanom ;)

Én pl. ezt úgy jeleztem, hgy nem kattintottam.

Speciel most is van Micropython-nal felvértezhető mikrokontroller board ( ESP8266 és ESP32 és RpiPico pl.) - meg nyilván egy halom másik, amiről én nem is hallottam.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( uid_6201 v | 2021. 06. 06., v – 10:38 )

Szerkesztve: 2021. 06. 06., v – 10:56

Arduino jellegű mikrokontroller panel, aminek az extra képessége az lenne, hogy a ROM-jában tartalmazna egy beépített editort és interpretert

Ennek a feltételnek, mármint hogy mikrovezérlőbe beleférő interpretert építs és mégis a BASIC-nél jobban használható nyelvet rakjál bele, arra az eLua felel meg.
Az itt látható mikrovezérlőkre és ezekkel a modulokkal készen van, a többire faragni kell.

Kíváncsiságból lefordítottam stm32-re a friss LUA-t. Szükséges _close_r() és a többi Posix függvényt emuláltam neki:

lua-5.4.3/src$ arm-none-eabi-size lua
   text       data        bss        dec        hex    filename
 240147       2602        128     242877      3b4bd    lua

Ahol:
    .text : > FLASH
    .data : > SRAM
    .bss : > BSSRAM

Az olcsó ARM Cortex M3-akba a legkisebbektől eltekintve a teljes LUA értelmező belefér.

Hát, "python-szerűnek" tűnik, de nem tűnik "Python 3.4" kompatibilisnek.

$ python3

>>> a = [10, 20, 30, 40]
>>> del a[0:4:2]
>>> print(a)
[20, 40]

micropython-1.15/ports/unix$ ./micropython
MicroPython v1.15 on 2021-06-07; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> a = [10, 20, 30, 40]
>>> del a[0:4:2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError:

Apropó kis méret: FORTH ebben tuti nyerő. Interaktív, amit gépelsz azt kezeli / új parancsként fordítja.
https://gist.githubusercontent.com/lbruder/10007431/raw/4b87f81da0adddb…

Lefordítva ARM Cortex mikrovezérlőre :

$ arm-none-eabi-size lbForth
   text       data        bss        dec        hex    filename
  12584       2416      66100      81100      13ccc    lbForth

Ebből a bss azért nagy, mert:

#define MEM_SIZE 65536 /* main memory size in bytes */
byte memory[MEM_SIZE];

Levéve 4096-ra a FORTH memóriát:
$ arm-none-eabi-size lbForth
   text       data        bss        dec        hex    filename
  12584       2416       4660      19660           516a    lbForth

Tehát 16 kB flash + 8 kB RAM nagyságú mikrovezérlő elég a FORTH-hoz, ebben pedig marad annyi flash + RAM, amiben pl. I2C és egyéb rutinok is elférnek.
Ez egy kisebb STM32F1xx-ben (ARM Cortex M3) is rendelkezésre áll.

Ugyanez 8 bites AVR esetére szintén 4096 byte-os FORTH memória esetén ennyi erőforrást igényel:

$ avr-size lbForth
   text       data        bss        dec        hex    filename
   7742       3498       4408      15648       3d20    lbForth

A text flash részben van a 3 kB-nyi lbForth-ban levő FORTH alaputasítás forráskód is. Ezt ha előfordított módon illesztjük be, kb. 2,3 kByte megtakarítást jelenthet.

AVR8-ra egy igen takarékos, ennek ellenére teljesnek tűnő FORTH + hardverlib: https://sourceforge.net/projects/amforth/files/
Megírták assemblyben, ahogy a FORTH fénykorában is. Tömören, sallang nélkül.
Méretét (még) nem tudom, de atmega8 (8k FLASH + 1k RAM) is támogatva van. Lásd: amforth-6.9/avr8/devices/
Innentől a további bővítése FORTH kóddal is történhet, ahogy például a floating point utasítások is: https://github.com/lnmaurer/amforth-float/

Szemléletes. Itt vannak a FORTH utasítások tömören leprogramozva: amforth-6.9/avr8/words/
És itt van dokumentálva, hogy a mikrovezérlő melyik assembly regisztere milyen feladattal rendelkezik: http://amforth.sourceforge.net/TG/AVR8.html#cpu-forth-vm-mapping

( bucko | 2021. 06. 06., v – 10:38 )

sql

A portokra készítünk egy vjút, aztán lehet benne matatni. :-D

( Caro | 2021. 06. 06., v – 12:02 )

Ez az editor+interpreter hogy lenne elérhető? (Virtuális) soros porton?

Játéknak nem rossz ötlet, de szerintem ennek a megvalósítása nem lesz egy egyszerű menet. Sokan írnak itt C-t, de interpreteres C az nem lesz egyszerű, a vezető python pedig még inkább nem.

Persze attól függ, mit értünk mikrovezérlő alatt. Egy 8 bitesen vérizzadás, egy 32-esen külső memóriával, amin már linux is megy (STM32F4 elvileg már képes rá), ott meg triviális.

Hat, valahogy igy, igen. Mondjuk azert a 8 biteseket se irnam le. Pl egy atmega128-as + 64k kulso RAM, abba mar sokminden belefer. Igy inkabb ugy fogalmaznek, hogy lehet, de persze minek ha van mar integraltan is sok RAM-mal megaldott 32-bites vezerlo. Najo, oke, elvileg van. Gyakorlatilag nem lehet kapni, majd 2026-ban. Szoval igen, marad a 8 bites.

atmega128-as + 64k kulso RAM

Ez így már drágább és főleg macerásabb, mint egy olcsóbb ARM Cortex M0 vagy ARM Cortex M3 ára.
Az árugrás ma nem a 8 bit és 32 bit között van valójában, hanem a hardveres lebegőpontos egység (ARM Cortex M4) dobja meg erőteljesen ma (még) a mikrovezérlő értékét.

LUA-t láttam AVR8-ra is, de ahogy elnézem, csak a token futtató környezetet. Kérdés hogy mennyi többlet erőforrás kellene, ha oda lenne beépítve a tokenizer.
Ellenben az utasítás értelmezőben switch helyett a computed goto-t érdemesebb használni. Gyorsabb futást eredményez.
Előny, hogy a Lua interpreter relatív könnyen implementálható, a nyelv maga egyszerű.

Nyilván Z80-on meg 6510-en is volt anno BASIC. De azoknak volt külső memóriabuszuk.

A mai 8 bitesekből ez jellemzően hiányzik (de azért van amiben van). Mivel éred el a memóriát? SPI-on? Az már rendesen visszaveszi a teljesítményt.

És nem véletlen volt ezeken jellemzően BASIC, mert egy komolyabb interpreteres nyelv már elég lassan futott volna, és ezeknél is assembly-ben csináltak mindent, ami gépigényes volt.

Félig OFF.

Attól, hogy Linux kernel fut, még nem biztos, hogy a Linux userland is. A kernel maga elmegy MMU nélkül, de akkor nincs mmap() hívás, ami viszont sok library-nak kell, pl. a glibc-nek is. A gyakorlatban ez azt jelenti, hogy amit használni akarsz userland progit, azt magadnak kell lefordítanod uClibc-vel. Csodálkoznék, ha ez a Python esetében könnyű lenne.

( dotnetlinux | 2021. 06. 06., v – 12:57 )

Nem adsz minden CPU melle fejlesztokornyezetet sem. Egy devboard-on fejlesztesz, tesztelez, majd a tomegtermekre a binarist toltod fel. Neha meg bootloader nelkul mert kell a hely es atlag user otthon nem frissit.

Minden masra vannak kis libek, de nem dev environmentek: debug, terminalwindow (github), ota. 

Kivéve az IoT.
Bézik Géza saját maga akarja megírni a kapuvezérlést, a kerti lámpák kapcsolgatását, az öntözőrendszer vezérlést a szaunavezérlést, a tököm tudja milyen vezérlést.
És csak pár darab vason fog ugyan az a kód futni.

A probléma ezzel, hogy ehhez érteni kell. A mai világ oylan szinten komplexxé vált, hogy sokszor van az  amikor már egy szakmabelinek is problémás, egy 30 másodperces feladat gyors megoldása. Az ötlet lényege, pont az, hogy ne kelljen IDE-t telepíteni, ne kelljen a használatát megtanulni, ne keljen minden egyes verziófrissítésnél a change notesokat túrni, hogy az adott funkció épp hova került. És legfőképp ne kelljen linuxos, windowsos, whatever gép mellé, mert szokszor ezek agyfaszsága ami elveszi az időt. Pl. Amikor egy rendszerfrissítés után, az arduino eszköztől elveszi a user RW jogosultságát. Jó érzés egy nappal korábban még működő rendszert fél napig debugolni.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( kuszi | 2021. 06. 06., v – 14:08 )

Smalltalk

Manjaro - Android - Smalltalk - Flamenco - OSMC

( nullptr | 2021. 06. 06., v – 14:12 )

Lua egyértelműen, az értelmezett nyelvek között kb a leggyorsabb.

Psszt, elárulom az IP-címemet: 192.168.0.14

( Raynes | 2021. 06. 06., v – 18:16 )

Lehetőleg ASM. De mivel az nem opció a szavazásban, ezért C, mert még ez a leg lowlevelebb nyelv a felsoroltak közül, a legszélesebb körű támogatással, legjobb compilerökkel. Editort meg interpretert is hagynám, mikrokontrollerben a hardver mindig gyenge, nem elég combos, hogy editorral meg interpreterrel tudjon extrán szórakozni. A mikrokontroller sose a fejlesztési kényelemről szólt, arra kicsi, hatékony, bare metal, natív bináris kódok valók, amik nem futnak semmilyen OS, környezet, API „fölött”.

Ha esetleg valami kényszer miatt ASM/C-t nem használhatnék, akkor Fortran, Pascal, BASIC, Forth, ezeket próbálnám a listáról, ebben a sorrendben, amelyikre ráadja a projektvezető az áldást, ha lenne ilyen korlát. Bár azt nem tudom, hogy ezekből milyen compiler van Arduino-ra. Meg sokszor az is dönt, hogy ha valami lib-et kell használni, akkor az milyen nyelven elérhető, és arra lehet csak szorítkozni, ha nem akar az ember mindent újraimplementálni saját maga, meg a kereket feltalálni.

Aki ilyen scriptnyelvekre szavazott, az tudja is hogy miért? Vagy csak úgy beírta, mert épp azt ismeri?

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Aki ilyen scriptnyelvekre szavazott, az tudja is hogy miért?

Igen. Előfordulhat, hogy tudja.

Te viszont sajnos nem tudod, hogy anno
létezett BASIC STAMP,
létezett Pascal MicroEngine, 
létezett VTL és VTL2,
létezett UCSD p-System,
de még JAVA ring is.
És azt sem tudod, hogy ezeket a rájuk való igény hívta életre. Mert ha tudnád, akkor nem írtál volna ilyen zöldségeket, hogy: 

A mikrokontroller sose a fejlesztési kényelemről szólt, arra kicsi, hatékony, bare metal, natív bináris kódok valók,

( bazso | 2021. 06. 06., v – 20:17 )

Mivel ez leginkább játék/kezdő kategóriában játszana, így blockly.

A többi nyelven beszélő felhasználó általában eljut arra a szintre hogy nem szeretné, ha a kódja az eszközzel együtt veszne el

( uid_6201 v | 2021. 06. 07., h – 08:05 )

Szerkesztve: 2021. 06. 07., h – 08:20

Itt egy lista a pehelysúlyú versenyzőkről, amik a kicsi memóriaigényük miatt mikrovezérlőre ideálisak (brainfucktól eltekintve):
    https://en.wikipedia.org/wiki/Lightweight_programming_language

Bármelyik nyelv választása esetén fontos, hogy jól használható alap LIB-eket célszerű mögé kidolgozni, például timer, gpio, i2c, spi, ..., hogy könnyen lehessen szkriptből használni.
Innentől kezdve a legegyszerűbb minimalista szkriptnyelv lehet a legjobb, hiszen vélhetőleg aki világegyenlet megoldásába akar kezdeni, az valószínűleg nem szkriptnyelvvel akarja tenni.
Egyéb egyszerű feladatra, például 2 nyomógomb figyelésére, 2 relé vezérlésére, továbbá egy-két akár I2C buszos szenzor kiolvasására és if x > 100 then ... else ... kifejezésre egy egyszerű szkriptnyelv bőségesen elég.
Továbbá egy szájbarágós kézikönyv, benne megfelelő mennyiségű teljes példakóddal.

Talán ezek jöhetnek szóba?

„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”
"Az Antikrisztus ledarálja Mészáros Lőrincet."

( Des | 2021. 06. 07., h – 08:20 )

Itt lehet nem leszek ezzel népszerű, de C#
Igen tudom hogy létezik már ilyen.

( STP | 2021. 06. 07., h – 08:38 )

Szerkesztve: 2021. 06. 07., h – 09:40

Egyébként az ötletelés előtt nem ártott volna tisztázni, hogy mit is értett a topicnyitó mikrovezérlő alatt.
Elsősorban mennyi RAM, mennyi flash?
Pl egy kisebb Cortex M0-ba (mondjuk 4K RAM és 32K flash) még egy Lua-t is szinte lehetetlen bepasszírozni, miközben a C-ben megírt firmware tökéletesen teszi a dolgát.
Egy Cortex M3/M4 vagy PIC32 az az alsó határ, ahová egyáltalán érdemes elkezdeni befaragni ezeket a scriptnyelv támogatásokat.
Lua és MicroPython a játékosok ezen a területen.
A Forth a BASIC és a Pascal is megvalósítható, csak hát már nem nagyon használják ezeket. Sok értelme/előnye nem lenne a Lua vagy uP-nal szemben.

Pedig odaírta:

Arduino jellegű mikrokontroller panel

Ez a kijelentés eleve feltételezi a sokregiszteres + stack = magasszintű nyelvek futtatására alkalmas arch.

Ha befér az interpreter, akkor az sem baj, ha néhányszor 100MHz az órajel. ;)

A mikrovezérlőn belüli hardver elemek konfigurálásában bármilyen nyelv hátrányos, mert a szintaktika miatt eltorzítja az eredeti neveket. Így az adatlap alapján nehéz meghatározni mit is csinálsz. Most éppen egy mikrokonrollerben konfigurálok és kötözgetek össze 11 db perifériát. Program nem lesz, de kíváncsi vagyok, ebben milyen segítséget nyújtana egy interpreter. Talán, ha lusta vagyok megtervezni, vagy bizonytalan vagyok és sokat szeretnék próbálkozni, ahhoz jó lenne. Szóval olyan női dolog. :-D

:-D

Hát igen, mégha az "egyjávás" Velorex is beleszámít.

Arról ne is beszéljünk, hogy még a C is roppant nehézkessé teszi a perifériák közvetlen kezelését! Ennek ellensúlyozásaként szoftverben megfogalmazták pl. a std timert. Ez csak két dolgot jelent: Elvesznek a feladat megoldásához szükséges fícsörök (nincs sükség céleszközre), viszont magasszintű nyelven "a hülye is tudja programozni". Ez maga után vonja a hozzáértés csökkenését, a szoftver bonyolódását, az órajel növekedését - viszon a megbízhatóság csökkenését is.

Végül érkeznek a szoftveresek, akik a hardverrel könnyedén megoldható dolgokat tákolják össze szoftverből - hiszem ekvivalens - majd csodálkoznak.

( Uhum2004 | 2021. 06. 07., h – 09:20 )

Szerkesztve: 2021. 06. 07., h – 09:28

Jó 5 éve elkövettem egy ilyesmit, AT90USB162-re. Semmiféle hw környezet nem kellett pluszban, csak a chip. A cucc Forth-ban futott, de a felhasználót kímélendő, Basic szintaktika szerinti aritmetikát fogadott. Amit lehet megköpködni: minden változó 16 bites volt, amitől elmaradt a típuskonverzió, de minden művelet 5-6 assembly utasításra csökkent, a stack mozgásokkal együtt, így bődületesen gyors lett.

Igaz, a fordítás a PC-n történt, de csak annyi, hogy a kedvenc editorod kimenetét kellett a fordítónak adni, az meg rögtön tolta le usb-n a futtatható kódot.

( turul16 v | 2021. 06. 07., h – 09:55 )

Szerkesztve: 2021. 06. 07., h – 10:13

5$ tol van linux kepes SBC, amin elfer egy python  32MB/64MB/512MB ram, 16MB flash, olcsobb mint egy rendes micro vezerlo.
Ha mindenkeppen self-hosted kell nincs ertelme micro controller profilal szorakozni.

Varhatolag python erdekli a kozonseget ilyen teren, de eleg nagy szinte barmihez.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+1

A mikrovezérlőnek az az előnye a komplexebb gépekkel szemben, hogy real-time követelményeket meg lehet valósítani vele. Ellenben egy interpretált rendszerrel ez a lehetőség hamar elhalványul a sokkal nagyobb késleltetések miatt. Ezért írtam én C-t, persze úgy értettem, hogy fordítani kell, nem interpretálni azt is. Persze értem az igényt szkript nyelvekre is.

Én a saját hobbi karrieremben elég gyorsan elértem az Arduino lib határait is, és hamarosan bare metál programozásra tértem át azért, mert real-time-ra szinte teljesen alkalmatlan az Arduino library is. Például egy pin billentés kb 100x lassabb a standard Arduino hívással, mint lehetne. Vagy szabályzót csináltam volna, és debug értékeket ki akartam küldeni serial out-on. A bitrate-be bele fért volna periodusonként 1-2 érték kiiratása, de mivel az Arduino serial szinkron hívás, ezért nem lehet real time programból használni. Ehhez hasonló korlátok miatt lassan minden komponensét újra kellett írnom már, amikor nagyobb teljesítmény kellett.  Az Arduino hardver viszont lényegében csak egy mikrokontroller, az tökéletes.

Ha túrja az ember az Arduino-s fórumokat, akkor tele van olyan javaslatokkal, hogy egyszerű kis számítás igényű feladatokkal is teljesítmény problémába ütköznek emberek, és az első hozzászólás mindig az, hogy vegyen az illető egy gyorsabb MCU-t, és azzal dolgozzon! Miközben aki ért hozzá az tudja, hogy a feladatot bare metál az adott MCU röhögve tudja, csak éppenséggel Arduino-ban programozva nem fog működni.

Nem tudom milyen rendszer kell ahhoz, hogy a C fordító önmagán futhasson, de nekem úgy tűnik, hogy egy ilyen rendszer vezérlőnek meg már overkill volna. A legtöbb fordítót/interpreters óriási erőfeszítés lehet oprendszer nélküli beágyazott rendszerre portolni. Talán van amit eleve erre terveztek, azt talán egyszerű (Lua). De a többséggel én nem küzdenék, hogy Linux nélkül elindítsam.

Esetleg olyat tudnék elképzelni, hogy duál CPU-s rendszer van egyetlen kártyán: egy mini Linux képes SBC, ami GUI képes is (USB hoszt és HDMI kimenet), és mellé egy mikrokontroller, ami valami UART-on fixen fel van drótozva a Linuxos procira, illetve a programozása is működik. A program fordítása/előfeldolgozása így egy Linux rendszeren történne, ami már apt-get install szerűen összerakható a legtöbb vezérlőhöz. Mindezt meg lehetne úgy is csinálni, hogy a mikrokontroller egy csatlakozón keresztül kapcsolódik az SBC-re, így ha a "termék" elkészült, akkor ki lehet venni az alap gépből, én önállóan működhet tovább. Kb mintha az RPI-hez adnál egy HAT-et, amin meg egy mikrokontroller van.

A legtöbb fordítót/interpreters óriási erőfeszítés lehet oprendszer nélküli beágyazott rendszerre portolni.

Azért nem ilyen reménytelen a dolog.
AtMega328-ra van BASIC interpreter, ami remekül dolgozik, még automatikusan betölti a [max. 1k-s] progidat is az eepromról reset után.
És ez a basic ráadásul pure arduino [tehát c jellegű] megvalósítás, nem is assembly.

 

( sigellef | 2021. 06. 07., h – 13:30 )

interpreter, editor... mi a francnak egy mikrovezérlőbe? PC-re kell egy vagy több compiler, ami akármilyen programnyelvből előállítja azt a binárist, amit a mikrovezérlő meg tud enni... meg kell még egy JÓ DOKUMENTÁCIÓ a mikrovezérlőről és a rajta lévő rendszerről.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( Nyosigomboc v | 2021. 06. 07., h – 16:14 )

Nem sok ertelmet latom. Ahhoz, hogy hozzaferj, kell valami billentyuzet (lehet virtualis is), meg (erinto)kepernyo (ezek nelkul maceras kodot faragni, bar utobbi helyett lehet sornyomtato is). Ezt a kettot vagy a mikrokontroller hajtja meg, akkor viszont valoszinuleg egyebkent is van benne boven eroforras tetszoleges interpreterre vagy forditora. A masik lehetoseg, ha a bill+monitor (esetleg eger) valami egyeb eszkozhoz kapcsolodik (tetszoleges szamitogep, de lehet helyette okostelefon, tablet, akarmi). Ebben az esetben az utobbin futhat a fordito, es akkor annak az eredmenyet kell feltolteni az eszkozre. Esetleg ha van netelerese, lehet valami online forditot is alkotni hozza, ami a textarea-ba irt kodot leforditja, es az eredmenykent kapott .hex-et mar fel lehet tolteni.

Miert kene az editort es a forditot/interpretert a mikrokontrolleren futtatni? Nem koltseghatekony. Ami a kommentekben felmerult, hogy IoT, meg telefonrol felkonfiguralni, hogy ha benyomnak egy gombot, akkor nyiljon ki a garazskapu meg hasonlo logikakhoz felesleges a kodeditor. Valami egyszerubb felulet celravezetobb lehet, amibol a vegen valami egyszeru bytekod lesz, amit a kutyu mar tud ertelmezni (es elfer akar az EEPROM-jaban is).

Ha meg a fejlesztoi gep frissitese a gond, akkor kell egy eszkoz, ami a programozo funkciojat latja el (mondjuk egy Raspberry), kapcsolodik a mikrokontrollerhez, a telefon/PC meg az ezen futo editort/forditot/egetot hasznalja. Akar bongeszobol, mindegy.

Az egesz koncepcionak a lenyeget nem ertem. Ez ki es mire fogja hasznalni, es miert valasztana ezt valami koltseghatekonyabb konkurens helyett (akinek sokkal gyengebb uC is eleg, mert nem azon fut az editor meg a fordito).

A strange game. The only winning move is not to play. How about a nice game of chess?

( gabor2 | 2021. 06. 08., k – 05:47 )

Én a C és a C++-t külön választanám.

( Tassadar v | 2021. 06. 08., k – 10:39 )

Szerkesztve: 2021. 06. 08., k – 10:41

Jó lenne egy benchmark-ot látni arról, hogy az ezeken tipikus use-case esetén járnak-e szignifikáns teljesítmény növekedéssel a compiled nyelvek.

Ha nem, akkor Python. 

( locsemege v | 2021. 06. 09., sze – 23:03 )

Ebben mi a jó? Ha PC-t illesztesz hozzá a fejlesztés idejére, akkor fusson azon az IDE meg a compiler, ne az MCU-n. Vagy legyen saját billentyűzete és kijelzője? De akkor meg miért mikrokontrollerből akarunk notebookot csinálni, amikor nem arra való?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Megis az IDE-ben mi az Integralt, ha nem ez?

 

Egyebkent meg:

https://hackaday.com/2021/01/09/the-shell-and-the-microcontroller/

https://hackaday.com/2020/07/05/your-microcontroller-is-your-ide/

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Rengeteg olyan eset van, amikor egy feladat egyszerű automatizálása kellene, de a mai világ olyan szinten el van bonyolítva, hogy az nem megoldható egyszerűen és gyorsan. Különösen nem egy félig-meddig laikus embernek.

A mikrokontrollereknél kell fejlesztői környezet, programozó és kell hozzá olyan szintű ismeret, hogy tudja az ember, hogy adott esetben a PC OS-e, az IDE beállítása vagy épp a programozó frimware a hibás. Lehet hivatkozni, hogy de az Arduino, de az MPLAB ilyen, meg olyan egyszerű, de ez nem igaz. Aki napi szinten programozik ilyen eszközöket, tudja, hogy egy szoftverfrissítés után napokat lehet szopni az előző nap még működő rendszerrel. Erre egy fenti embernek nincs sem ideje, sem energiája.

A mobiltelefonoknak, laptopoknak nincsenek olyan perifériái amikre könnyen, egyszerűen tudsz eszközöket lógatni és ezeket az eszközöket könnyen egyszerűen el tudod érni. Nincs GPIO, nincs analóg bemenet, stb. Plusz adott felhasználásban (pl. melegház hőmérsékletének monitorozása és egy ventillátor kapcsolgatása) nem hagyná ott az ember az ilyen eszközöket.

Elhangzott feljebb a számítási teljesítmény, memória, valósidejűségek, stb. agymenések. Könyörgöm, zx spectrummal és c64-el csináltak komplett laborautomatitázálásokat, otthonvezérléseket, BASICben. Dolgoztam olyan ICT gépen, aminek a programja szintén BASICben volt megírva és összesen 32kB memóriája volt. 30+ évet működött és mért autórádiótól kezdve videómagnóig mindent. Hány olyan mikrokontroller van, ami erre köröket képes ráverni memóriában, számítási teljesítményben?

Igen, a billentyűzet és a kijelző alap lenne. És lehet azon pörögni, hogy az ennyi és annyi pénz, de a valóság, az hogy 5000 darabnál a egy 61x43mm-es resisztív touchos kijelző 3 dollár alatt van, mint ahogy egy egyedi gyártású szilikon tasztatúra 1 dolláros tétel. Arról nem beszélve, hogy nagyon sok projectnél azért van, teljesen feleslegesen, ipari PC használva, mert a legtöbb mikrokontroller kártyán nincs alapban HMI és a rendszer tervezője nem akar időt elcseszni ennek a reszelésével. (Arról soha senki nem beszél, hogy mennyi idő van elcseszve az ipari PC-re történő HMI felületek reszelésével.)

Tehát, a célközönség nem a 1000+-os szériájú mikrokontroller projectek, nem a vas utolsó MIPSét is kitekerő agyonoptimalizált assembly mágiák megalkotói lennének. Hanem az egyszerű, "két hétre elutaztam és kell valami ami meglocsolja a virágokat az 1000 Ft-os kínai szivattyúval és elmegy egy USB adapterről","kell a gyerek bulijába egy kódzár a kalózkincses ládára", "valami csipogjon ha esik az eső és 4 fok alatt van a hőmérséklet", "megdöglött a szerelőszalagon a csavaradagoló kontrollere, valaminek rángatni kellene a retesz mágnesét az optokapu jelére, amíg megjön a csere kontroller" jellegű, eldobható  kis dolgok.

Amúgy közben kihullott a projectből a többi ötletelő, úgyhogy többé-kevésbé tárgytalanná vált a dolog.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Egyébként amit fentebb írtam, az ezekre a követelményekre megfelelne: > Esetleg olyat tudnék elképzelni, hogy duál CPU-s rendszer van egyetlen kártyán: egy mini Linux képes SBC, ami GUI képes is (USB hoszt és HDMI kimenet), és mellé egy mikrokontroller, ami valami UART-on fixen fel van drótozva a Linuxos procira, illetve a programozása is működik. 

Ha már van egy SBC akkor felesleges a mikrokontroller. Plusz, ezzel az elrendezéssel megint csak a komplexitását növeled a rendszernek.

Újraolvasva a hozzászólásokat az jött le, hogy a fejek többségében a mikrokontroller valamilyen korlátozott képességű eszközként él, holott a kifejezés  csak azt takarja, hogy egy olyan generikus processzor mag amihez egybeintegráltál a feladatának elvégzéséhez szükséges külső perifériáit. Ha megnézzük a korai mikrovezérlőket, voltak amiknél a ROM vagy  adott esetben még a RAM sem volt integrálva. És így nézve a SBC-k processzorai is mikrovezérlők.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Az én megközelítésem szerint nem a teljesítmény a gond (tudom hogy belefér egy interpreter egy ilyen kütyübe), hanem a real time dolgok (ami végső soron teljesítmény, de nem nyers számítási kapacitás, hanem válaszidő), amik nagyon hamar előjönnek ha mikrokontrollerezünk. Erre persze megoldás az, ha úgy mint az Arduino-nál később magunk léphetünk feljebb, és akárhogy is programozhatjuk ugyanazt a hardvert, nem csak az eredetileg megálmodott módon. És ettől még jogos, hogy ha nincs komoly real time igény, akkor lehessen szkriptelni.

Amúgy működhetne úgy is, hogy egy fizikai kapcsolóval lehet "IDE" módban indítani, a másik állásban pedig áram alá kerülve a betáplált program indulna el. Ahogy ízlelgetem a gondolatot elkezdett kicsit tetszeni.

Ilyen kis OLED kijelzőt már én is használok 8 bites mikrovezérlőről és teljesen elegendő hozzá a teljesítménye valóban. Ha csak karakter-mátrix módban használnám, akkor nem is kellene sok RAM hozzá, jelenleg a teljes bitkép RAM-ban van, ha jól emlékszem 512 byte a puffer, amibe rajzolok.

A nem valós idejű Oled és LCD kijelzőkhöz (cca. 20 évvel ezelőttiek) nem kell RAM pluszban. A legtöbbnek van saját buffere ami a buszon kétirányban elérhető. Csak a legtöbb felhasználónak büdös azt a 3 regisztert beállítani, amivel vissza lehet olvasni. Mérésadatgyűjtőnél játszottam el, hogy a kijelző egyik részét  buffernak használtam. Kicsit mátrixosan nézett ki, de adott szenzorhibát egy idő után ránézéssel lehetett diagnosztizálni.

Igen, a kapcsolós dolog nálam is felmerült. Elkezdtem nyálazni az olcsóbb, nagyobb flasshel rendelkező M3, C0 ARM-ok doksiját és onnan jött az ötlet, hogy lehetne olyan bootloadert írni, ami egy külső állapottól függően vagy az interpretert, vagy a lapra szerelt flash tartalmát, vagy egy SDKártyáról behúzott filet indítaná.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> A legtöbbnek van saját buffere ami a buszon kétirányban elérhető.

Két nagyságrenddel lassabban... Bár ez lehet elegendő a célnak. Én becéloztam, hogy 50FPS-t tudjak csinálni :-)

Ja, és ilyen gagyerák modulban vettem a kijelzőt, amiről nem volt visszavezetve a vissza irányú busz. (Tudom magamra vessek, de előre el sem tudtam képzelni, hogy ilyen vacak lesz, nem is néztem.) Úgyhogy nem tudtam olvasni a kijelzőt, csak írni. Ahogy néztem rengeteg ilyet lehet kapni, és csak kevés normálisat.

Valamiért baromira nehéz megtalálni az interneten, de tavaly szeptemberben az Intel is bejelentett egy procit, amiben ARM (!) Cortex M7 mag van a real-time feladatokra. https://www.intel.com/content/www/us/en/products/platforms/details/elkh…

Az Elkhart Lake családról van szó, és Programmable Service Engine (PSE)-nek hívják benne az ARM magot. Ők is rájöttek, hogy real-time feladatokra egyszerűbb betenni egy plussz magot, amin nem Linux fut (vagy nem Windows).

Miért ne lenne alkalmas real-time dolgokra egy SBC?

Más tényezőért nem mindig célszerű. Például mert túl sokat fogyaszt ahhoz az egyszerű vezérlési, adatgyűjtési feldathoz.
A többi már csak annak kérdése, hogy időosztásos Linux (előnyeivel hátrányaival) vagy natívan bare metal programming módon, gyors reakcióidővel van használva.

Ha belegondolsz, a mikrovezérlőket ezért szeretjük. Itt az 1..2 mA-es vagy akár nagyságrendekkel kisebb áramfelvétellel játszunk, nem a sokszáz mA körüli kategóriával.
https://www.st.com/content/st_com/en/products/microcontrollers-micropro…
+ mélyaltatás

Az már csak járulékos, hogy méretben kellemes a mikrovezérlőben, hogy egyetlen IC méretről beszülünk.
Minden egyes feladatra célszerű az arra megfelelő eszközt használni.

Ha megnézzük a korai mikrovezérlőket, voltak amiknél a ROM vagy  adott esetben még a RAM sem volt integrálva. És így nézve a SBC-k processzorai is mikrovezérlők.

Ez így is van. A korai CPU-k, mint a 8008, a 8080, a 6800, z80, stb. mind beágyazott rendszerekbe lettek szánva. 
A legjobban maguk a fejlesztők voltak meglepve, amikor azt találták, hogy ezekből a kis teljesítményű processzorokból mások hobbi számítógépeket építettek. Egyébként, szomorú, de ezeket a sufnis építgetőket nagyon lenézték akkoriban. 

Innen ered az a mondás is, hogy ne bízz olyan számítógépben, amit egyedül is fel tudsz emelni.

Ezzel a mondattal a korabeli kisgépek silányságára*, tákolmány jellegére akartak utalni. Hangsúlyozva, hogy nem képzett szakemberek, hanem inkább amatőrök, elektrotechnikusok, netán villamosmérnökök** tervezték és építették őket. 

* akkor, a hetvenes évek elején, közepén nagyon sok, több száz magánúton megépített kisgép látott napvilágot, különféle számítógépes kluboknak köszönhetően még utánépítők is akadtak. Ezeknek meg aztán, nem mindegyike volt "kossuth díjas" termék. 

** akkoriban a "sima" villamosmérnök sem számított érdemi számítógépes szakembernek.

 

A korai CPU-k, mint a 8008, a 8080, a 6800, z80, stb. mind beágyazott rendszerekbe lettek szánva.

Hát nem. Az akkori számítógépek egy vagy több szobányi helyet is elfoglaltak.  Ezeket pedig mikroszámítógépnek szánták. Tartozottt hozzájuk busz és periféria rendszer, amivel a többszobányi gépet kis helyen össze lehetett rakni. Ha nem a maximális buszkiépítést használtad (pl. S100), akkor persze jóval kisebb kiépítésű mikrogép lett a végeredmény, amely lehetett számítógép vagy vezérlő rendszer is.

** akkoriban a "sima" villamosmérnök sem számított érdemi számítógépes szakembernek.

Igen, emléxem, akkoriban a szakácsok voltak az informatikusok. :-D

Hát nem. Az akkori számítógépek egy vagy több szobányi helyet is elfoglaltak.  Ezeket pedig mikroszámítógépnek szánták.

Hülye vagy te ehhez, de nagyon.  Az első cpu-t is kis készülékbe szánták, véletlenül sem számítógépbe, ahogy a többit is. Folyadék viszkozitás mérőbe, diagnosztikai készülékbe, hasonlókba. Még a fogalom amire hivatkozol [mikroszámítógép], sem létezett akkor. Eszükbe nem jutott az intel vagy a motorola mérnökeinek, hogy a magánembereket is érdekelheti a számítógép. Az még cégeknél is ritkaság volt. Ugyanakkor, az 1970-es években már nem nagyon üzemelt olyan számítógép, amely szobákat foglalt volna el.  
Az is mutatja, hogy mire szánták a korai 8 bites CPU-kat , hogy nem volt bennük szorzó áramkör, sőt, akadt amelyik bitenkénti címzést is lehetővé tett. Maga a nyolc bit is soványka volt. A korabeli kisgépek rendre 14,18 vagy még nagyobb bitszélességgel lettek tervezve, de hát, honnan lenne bármi közöd is neked ehhez?

Igen, emléxem, akkoriban a szakácsok voltak az informatikusok. :-

Nem, bunkó bácsi. Akkoriban a villamosmérnökség az analóg rendszerek ismeretét jelentette, az meg vajmi kevés, mivel a számítógépek digitális rendszerek. Most tekintsünk el a három darab analóg számítógéptől, ami akkoriban leledzett. 
Matematikai logikát igényeltek, mellé komoly matematikai tudást, szóval, posztgraduális képzés nélkül akkor még nem létezett számítástechnikus szakmérnök. 

 

Az első cpu-t is kis készülékbe szánták, véletlenül sem számítógépbe, ahogy a többit is. Folyadék viszkozitás mérőbe, diagnosztikai készülékbe, hasonlókba.

Azt hogy? Legjobb tudomásom szerint az első CPU az vagy az AL-1-es volt, amit az IV/70-es és IV/90-es számítógépekbe pakoltak, vagy pedig az MP944-es, ami pedig az F-14-esek központi számítógépének - a Central Air Data Computer-nek - volt a CPU-ja.

Oldschool Computer - http://oscomp.hu

Úgy, hogy terminálba, asztali kalkulátorba, automatikába, flipperekbe lettek szánva.
Senkinek eszébe nem jutott akkoriban, hogy magánemberek számára számítógépet építsen. 
Amikor a kicsit feltörték a piacot a 8 bites kisgépekkel, akkor jelentek meg a nagyok, elsőként az IBM, de az már 1981-ben volt.

És mitől a 4004-es nálad az első CPU? Az csak az első kereskedelmi forgalomban kapható CPU volt, nem az első en-bloc. Még maga az intel is csak "az intel első mikroprocesszorának" hívja. Még ha ki is kötöd az "egychipességet" (akkor a külön FPU-s, külön MMU-s CPU-k sem CPU-k?), akkor is Texas Instruments TMS 1802NC: 1971 szeptember 17, intel 4004: 1971 november 15.

Oldschool Computer - http://oscomp.hu

Elég nehéz számítógépet gyártani olyan cpu köré, amit még kapni sem lehet a kereskedelmi forgalomban.

A mondandóm lényege egyébként az volt, hogy a klasszikus 8 bites processzorokat beágyazott rendszerekbe szánták, afféle korabeli mikrovezérlőként. Erre a szándékra bizonyíték van elég. A MOS 6502 mellé kifejlesztett KIM először fejlesztési segédlet volt a 6502-höz, később mikroszámítógép gyanánt árulták ugyanazt. 

"The KIM-1 was created in 1975 as an engineering development board for the brand new low cost 6502 microprocessor "

Ezeket a processzorokat 8 bitesre gyártották fél-egy MHz frekin dolgoztak, holott, 2-4 MHz-es TTL alapú processzorok 14,18,22,24 de még 36 bitesek is voltak.

64 bites processzor például 1961 óta létezik. 

A házi számítógépet mint fogalmat akkor még nem ismerték. A számítógépeket lényegében adatfeldolgozásra, számításra használták és ebbe a milliőbe nem fért bele az még gondolat szintjén sem, hogy Robert Cash autószerelő, vagy Vanda Curtis varrónő számítógép után áhítozna. 
A nevük viszont árulkodó ezeknek a 8 bites cuccoknak, MIKRO processzornak hívták valamennyit.

A gyártó is csinálhat vele számítógépet: ezt is tették, a 4Ph az IV-szériával az amcsi hadsereg a CADC-vel, a TI TMS-e pedig akár önálló számítógépnek is tekinthető "computer on a chip", ill. hívták a TMS szériát microcomputernek is.
De ez igazából mellékes. Azt mondtad, hogy neked a 4004-es az első CPU, de arra még nem adtál választ, hogy miért, mi nálad a CPU definíciója, aminek a 4004 megfelel, de az AL1, az MP944 és a TMS 1802NC meg nem, az egy évvel korábbi - csak prototípusokig jutott, gyártásba végül nem került - TMX 1795-ról nem is beszélve.

Oldschool Computer - http://oscomp.hu

Egy érdekes színfolt az 1 bites CPU volt.

4 lábon kívülről kapott utasítás
1 lábon adatbit be (DATA), 1 lábon eredmény ki (RR) + belső bitállapot tárolás.
további opcionálisan felhasználható impulzus kimenetek: JMP RTN FLAG0 FLAGF

Ökoszisztéma:
     külső számláló a ROM címzéshez
     8 bites ROM, ebből felső 4 bit művelet alsó bitekből 1..4 bit alábbi multiplexálás bitszelektora
     szószélesség bitenkénti beolvasásához MUX, továbbá a bit kimenet szószélességre alakításához demux & bitLATCH

Innentől a N bites értéket bitenként tudtad beolvasni és az előző bitállapotot figyelembe véve sok egyszerű bitlogikás utasítással az 1..N bit széles eredményt előállítani.
Ennek a tipikus alkalmazása N digitális jelzés bemenet fogadása, majd az igény szerinti logikai kapcsolat mentén N kimenőbitet, mint relék vezérlőszintjeit megvalósítani.

Lásd: http://www.brouhaha.com/~eric/retrocomputing/motorola/mc14500b/

A soros feldolgozás egyáltalán nem egyedi. Volt soros processzora a Texasnak is, meg másoknak is.

Ha nem ragaszkodunk az egycsipes verzióhoz, akkor az előzmény ott van a TTL sorozatban. Az alapelem az egybites összeadó, szorzó, tároló, stb. Akkoriban tervezési szempont volt, hogy kiépíted-e az N bitet, vagy a sebesség rovására spórolsz az árral, a tokokkal és vezetékekkel.

A soros kapcsolat annyira népszerű, hogy van pl. RS232, ETHERNET, és a 64 bites pécédben a BIOS egybites SPI flashból töltődik. De még az IBM eServer p615-ös (POWER4+, 2004) belépő szintű szerveremhez is rakhatsz 8db diszk és kártyabővítő dobozt, ami 2db (elfelejtettem hány) Gb/s vezetéken kapcsolódik. Ezt a két vonalat közvetlenül a CPU kezeli.

Sőt, két i2c buszon összekötött mcu is felfogható soros buszon összekötött mikroprogramozott CPU-ként. ;)

Az adatlapját néztem csak, meg az utasításkészletet futottam át, és a könyvét böngészgetem most.
Nagyon jónak tartom. Csodálom, hogy nem lett népszerűbb, pedig nem mai darab, legalábbis a könyv kiállításából itélve. 

 

Be is illesztem ide a könyv (.pdf) linkjét:  https://tinymicros.com/mediawiki/images/e/ec/MC14500B_Handbook.pdf

Tudom, hogy mi az intel 4004, nem tudom feltűnt-e. A kérdés, hogy mitől ez az első neked? Annyitól, hogy ez volt az első, amit megvehettél külön a boltban? (Csak mert még szimplán a kereskedelmi forgalomba kerülés sem állja meg így a helyét, csak úgy, hogy az első ami önálló termékként kereskedelmi forgalomba került. Az AL1-esek a szintén kereskedelmi forgalomban kapható IV-kben voltak, a TMS 0100 (mert a TMS 1802NC az nem az TMS 1000-es, hanem a TMS 0100-as széria prekurzora volt) pedig kalkulátorokban, azaz mindkettőt megvehetted a boltban, csak nem önálló termékként, de semmi nem tiltotta, hogy kiszedd a gépből és építs belőle valamit).
Szóval nem, az intel 4004 nem az első mikroprocesszor, még távolról sem. Ennek megfelelően az első CPU-król nyugodtan elmondható, hogy számítógépekbe szánták.

Oldschool Computer - http://oscomp.hu

Végülis az AGC-ben is volt mikroprocesszor ... repült is néhány darab a Holdra meg vissza. :)
Az pedig nem 1971-ben csírázott ki. Akkortájt már a sokadik repülésen túl volt.

AGC:
   36K (16-bit) words ROM (ferritgyűrűs)  - 1 ferritgyűrűt 24-szer használtak újra ROM bitekhez.
   2k (16-bit) words ferritgyűrűs RAM       - 14 bit adat + 1 előjel + 1 paritás
   37 Normal instructions, 10 Involuntary instructions, 8 I/O instructions
   Instructions average 12-85 microseconds

Proci utasítás spec 1965-ből: https://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/apollo/publ…
Assembly forráskódja: https://github.com/chrislgarry/Apollo-11/

Ennek megfelelően az első CPU-król nyugodtan elmondható, hogy számítógépekbe szánták.

Ha ez téged megnyugtat, akkor úgy módosítom a hozzászólásomat, hogy az általam sorolt, mára klasszikussá vált, első nyolc bites processzorokat nem tipikus számítógépek építésére, hanem inkább beágyazott rendszerekbe, vezérlő egységekbe szánták.
Azt hangsúlyoznám, hogy azokkal a mikro-gépekkel, amelyek meg lettek építve 1973-79 között, a hivatkozott processzorok tervezői, gyártói nem kalkuláltak. Ez a terület, hogy home computer, számukra ismeretlen volt. Nem csoda, hiszen nem is létezett.

Hülye vagy te ehhez, de nagyon.

Bizony, én is ezt mondanám a helyedben, ha fingom sem lenne a témáról. Ilyenkor mindig a másik a hülye, mert az sokkal egyszerűbb, mint utánaolvasni valaminek.

Képzeld el, az első programomat a 70-es években Odra 1204-re írtam, konzol írógépen, lyukszalagra! A központi egysége (gyengébbek kedvéért CPU) 0,77 köbméter volt. Ebben a naaaagy számítógépben sem volt szorzó áramkör, és hiába volt 24 bites, mégis a 8 bites 8080 közeli számítási teljesítményt tudott elérni. Kicsit később volt már a kollégiumnak 6800 alapú mikroszámítógépe is. A másik kollégiumnak volt egy egész szobát elfoglaló gépe, de a szoba közepén volt egy EMG 666 is - egyik sem mikroprocesszor alapú.

Eszükbe nem jutott az intel vagy a motorola mérnökeinek, hogy a magánembereket is érdekelheti a számítógép.

Biztosan így volt, de ennek bármihez is semmi köze sem volt. Egész egyszerűen az olcsóbb alkatrészek előéllítására kell törekedni. Annak kisebb a térfogata, fogyasztása. Tehát az ára a működtetés költsége és megbízhatósága is jobb, ezért jobban és nagyobb példányszámban eladható.

Bezzeg a 80-as években már volt logikai analizátorunk - benne 8db Z80. Volt 8088, 8086, 80286, 80386 és 68xxx alapú számítógépünk, 80186 és 68000 alapú nyomtatónk. Közben a világon legnagyobb példányszámban eladott CPU 4 bitesre sikeredett. Pedig milyen jó lett volna, ha ott vagy és kioktatod a hülyéket! :-D

Maga a nyolc bit is soványka volt. A korabeli kisgépek rendre 14,18 vagy még nagyobb bitszélességgel lettek tervezve, de hát, honnan lenne bármi közöd is neked ehhez?

Tényleg semmi közöm, nem én terveztem. Bár a kisgépek (magyarul: miniszámítógép) árát - már ha ilyenről már hallottál - összevetve egy 8 bites vacak rendszerrel, inkább az utóbbiból venne az ember gyereke egy csomót. Lehet, hogy ezt más is hallotta. Talán ezért is könyveltek nálunk először C64-en (gondolom alkalmatlan volt könyvelésre szorzóegység nélkül ;)), majd pécén. Közben a sógorok már AS400-at használtak, mert abban volt szorzóegység.

posztgraduális képzés nélkül akkor még nem létezett számítástechnikus szakmérnök

Van egy barátom, úgy a nyudíj előtt. A 70-es években tanult olyan könyvelés félét. A prosztatája sem granulált (nem említette ;)), sem nem villamosmérnök, oszt mégis számítástechnikus. Zavart érzek az erdőben! De az is lehet, hogy komoly matematikai tudással az agyában született. Bár ezt sem említette.

A központi egysége (gyengébbek kedvéért CPU) 0,77 köbméter volt. Ebben a naaaagy számítógépben sem volt szorzó áramkör, és hiába volt 24 bites, mégis a 8 bites 8080 közeli számítási teljesítményt tudott elérni.

Nem a központi egysége, hanem az egész gép. Szorzó áramkör meg bizony volt benne. Az pedig nem jelent sokat, hogy lassú volt. Akkoriban a dolgok között nem mindig a sebesség volt az elsődleges prioritású. Ha egy köteg számítást a gép nem 36 hanem 52 perc alatt tejlesített, az sem számított annyira. Néha fontosabb volt a gép megbízhatósága, a szolgáltatásainak sokrétűsége és hasonlók.

 

Bár a kisgépek (magyarul: miniszámítógép) árát - már ha ilyenről már hallottál - összevetve egy 8 bites vacak rendszerrel, inkább az utóbbiból venne az ember gyereke egy csomót.

A gépek informálisan lettek kategorizálva, de a kisgép és a minigép nem volt ugyanaz.
Létezett nagy gép, kisgép, minigép és később megjelent a mikrogép. Ha megnézed a PDP gépcsaládot, akkor ott fogalmat alkothatsz erről, mert most még láthatóan bajban vagy.

 

Talán ezért is könyveltek nálunk először C64-en (gondolom alkalmatlan volt könyvelésre szorzóegység nélkül ;))

Tudod, ez úgy van, hogy lett volna a c64 helyett alkalmasabb gép is, de lehet, hogy csak azt tudták megvenni.
Amúgy, arról a hülye szokásodról lemondhatnál, hogyí olyasmit próbálsz sugalmazni, amit a vitapartnered nem is mondott. A c64 is alkalmas szorzási műveletek elvégzésére ha már összeadni tud, csak a 6502 tervezői úgy gondolták, hogy a felhasználók nem nagyon akarnak majd szoroztatni egy beágyazott rendszerbe szánt eszközzel, így nem is terveztek bele szorzót.
 

sem nem villamosmérnök, oszt mégis számítástechnikus. Zavart érzek az erdőben!

Ja, te meg vagy a napóleon. Ezért is vagytok barátok, nemde?

Neked nem zavart kéne érezned, hanem szégyent, ugyanis messze nem vagy az az üvegkeményre edzett szaki, mint aminek itt a nagy füstfüggönyön keresztül igyekszel előadni magad. 

Nem a központi egysége, hanem az egész gép.

Ha olvastad volna: A központi egység (a háttértároló mágnesdobok nélkül)...ettől független volt a kisméretű kezelőpult, a monitor írógép az asztalával és a többi periféria.

Szorzó áramkör meg bizony volt benne

Ha olvastad volna: Az ODRA 1204 a mikroprogramozott, 24 bites aritmetikájával ...

Házi feladat: WTF mikroprogramozott? Ha erre rájössz, akkor talán megérted miért beszélsz marhaságot.

Ha egy köteg számítást a gép nem 36 hanem 52 perc alatt tejlesített, az sem számított annyira.

Fiatal barátom! Akkoriban a géphasználatot CPU időben számláztak.

Amúgy, arról a hülye szokásodról lemondhatnál, hogyí olyasmit próbálsz sugalmazni, amit a vitapartnered nem is mondott.

Ez ebben a kontextusban cinizmus - ami hülye szokás ugyan, de mindjárt kiderül, hogy mégsem ;)

A c64 is alkalmas szorzási műveletek elvégzésére ha már összeadni tud, csak a 6502 tervezői úgy gondolták, hogy a felhasználók nem nagyon akarnak majd szoroztatni egy beágyazott rendszerbe szánt eszközzel, így nem is terveztek bele szorzót.

Akkor most tud-e szorozni dedikált szorzó áramkör nélkül, vagy sem? És ha lehet rá olyan programot írni, amivel lehet szorozi - miközben nincs szorzó áramkör, akkor az az? (GOTO Odra 1204)

Tudod, akkoriban nem azért nem terveztek a mérnökök szorzót, mert nem voltak előrelátók, hanem nem tudtak még annyi tranzisztort egy csipbe integrálni. De még a 8086 és 80286 esetében sem. Még az órajelet is könnyebb volt növelni, mint az integrált alkatrészek számát. Ezért fanyalodott az Intel is a mikroprogramozásra.

A számítástechnikát pedig tanították már a 70-es években, és nem csak táltosképzőn. Külöben is a Scientific American kiderítette, hogy a legjobb szoftveresek a bölcsészek. Biztosan sok-sok matematikát tanultak. ;)

Szóval akár kemény, akár puha szaki vagyok, továbbra is hordod össze a marhaságokat. Miközben abban a korszakban tanultam, dolgoztam, lazán elmagyarázod: Nem is úgy volt. :-D

Az SBC+uC is egy teljesen ertelmes felallas, az SBC csinalja a high level dolgokat, kapcsolatot a kulvilaggal, kijelzo, ethernet, stb. A uC meg a low-level, real-time vezerlest. Egy kicsit meg mindig vicces, amikor valaki az RPi tuskesorat hasznalja valamire, aztan csodalkozik, hogy idonkent a kernel kihuzza a programja alol a CPU-t.

A strange game. The only winning move is not to play. How about a nice game of chess?

+1, az SBC-k nem alkalmasak real-time-ra. Látom sokak szerint értelmetlenül lovagolok ezen, de szerintem kellemes tulajdonsága egy platformnak, hogy ha _kell_ vagy _akarjuk_, akkor tudunk rendes valós idejű működést csinálni vele. Mondom, Arduinoval ezt eljátszottam én is, hogy először csináltam programot rá Arduino IDE-vel, aztán kellett real-time működés, és akkor plain C-re átváltottam. És egy viszonylag egyszerűen megléphető volt.

Tehát ha csinálnék egy új platformot, akkor az is képes volna erre a trükkre.

RPI+Arduino - tele van ezzel a kombóval a padlás és igazából értelmes és jó dolog ez. Meglévő szoftveres és hardveres komponensekből össze lehetne rakni ezekből egy "standard" platformot.

Mondjuk Arduinonal az egeszet megkonnyiti, hogy egy gcc van alatta, es elered a sima Atmel-es regisztereket. Szoval ha akarod, akkor visszamehetsz arra a szintre, es sokkal gyorsabb I/O-d lesz, meg hasznalhatsz interruptokat, timereket (kiveve amit a millis()-hez mar hasznal), stb..

Persze ha bitvadaszattal kihasznalod, hogy Atmega328P van alatta, akkor nehezebben portolod masik Atmelre vagy STM32-re.

A strange game. The only winning move is not to play. How about a nice game of chess?

de szerintem kellemes tulajdonsága egy platformnak, hogy ha _kell_ vagy _akarjuk_, akkor tudunk rendes valós idejű működést csinálni vele.

De egyrészt, ebből van kevesebb, másrészt: Nem erről beszélünk.
Egy mosógépben, KV főzőben értelmüket veszítik a nanoszekundumok. Ha egy átjelzőt kell működtetni, relét behúzni, szobát temperálni, kutyatápot adagolni, akváriumot bizgetni, ahhoz nem kell RT oprendszer, meg magas reszponzivitás.
Azok az emberek, akik meg a felsoroltakhoz hasonló dolgokat akarják, nem kiváncsiak az asm-mel való zsonglőrködésre.
Tudod hol lenne az arduino, ha csak asm-ben lehetne programozni? Sehol. 
Ha jól megnézed, egy atmega328 16 Mhz-en járatva, tinybasic-ből felprogramozva is elég üde, fitt eredményekre képes. Korábban, ehhez hasonló feladatokra ott volt a 6502 ami 1 MHz-en zümmögött. 

Nézd meg ezt:

https://github.com/fgalliat/BasicAr

 

Rengeteg olyan eset van, amikor egy feladat egyszerű automatizálása kellene,

Egyetértek. 
Sok feladatra elég lenne egy nyolc bites kontroller is, valami BASIC, vagy VTL2-szerű aprócska interpreterrel.
De ennél husosabb feladatokra is jól jönne ilyesmi.
Nekem lesz egy munkám, ott adatot kell majd mérni, tárolni két percenként, több mint egy éven át, plusz egy gépet vezérelni, majd egy másikat, az előző állapotának függvényében. Mindezt megvalósítani olyan környezetben, ahol nincs vezetékes áramforrás, tehát egy tanyán.
Ez asm-ben merész három nap szivacs, már ha bírná eddig a laptop, de egy embedded c-vel, vagy basic-kel 4-5 óra, max. egy nap alatt meglenne a finomhangolás, teszt, minden.
Itt pl. abszolút előny az interpreter.

 

Köszi. Ez se rossz. Elég barátságos az ára is [4-10 USD], egy baja van, hogy PIC alapú, én meg születési rendellenességgel jöttem világra, ami az atmel kontrollereihez, processzoraihoz való végzetes vonzódásban fejeződik ki. :)

Szerintem az atmel gyártja a világ legjobb processzorait. Még az ARM-ot is bealázza.

AVR32 a csúcs. Egyedül azzal van bajom, hogy big endian.

 

 

“Elég barátságos az ára is [4-10 USD], egy baja van, hogy PIC alapú, én meg születési rendellenességgel jöttem világra, ami az atmel kontrollereihez, processzoraihoz való végzetes vonzódásban fejeződik ki. :)“

Nem kell tudnod, hogy PIC van benne. ;)

Tekints úgy rá, mint egy basic MCU-ra. 

FYI: Az Atmelt mar megvette a Microchip. Szoval mar ok gyartjak a legjobbakat. :)

Amugy a PIC elegge hulye architekturakat hozott ossze regen (6+8 bites 12F vonal pl.), az egetoik meg a fejlesztoi kornyezetuk megint borzalom, szoval megertem az idegenkedest. (nekem viszonylag keves kozom volt hozza, de aki sokat hasznalta, ritkan mondott jokat) AVR8 vonalon van teljesen jol mukodo GCC-d, az egetes meg alapvetoen annyi, hogy a resetet lehuzod, es SPI-on feltoltod a kodot.

A strange game. The only winning move is not to play. How about a nice game of chess?

A Microchip vásárolta ... valami 1970-es évek végi "Peripherial Interface Controller" nagyon egyszerű alapjára épült. Egszerű, olcsón gyártható. Érdemes volt vele a Microchipnek foglalkoznia.
A norvég ATmel-féle AVR 1995 körüli meséje, akkori 8 bites technológia. Sokkal fejlettebb.

Szerintem egyszerubb rendben tartani a gepen az Arduino IDE-t (legrosszabb esetben ujra feltenni a next-next-finish jellegu telepitojevel), mint uC-n fejleszteni. Ha nekem kene dontenem, hogy akkor irjak-e kodot egy 61x43mm-es rezisztiv szaron vagy a laptopomon egy normalis IDE-ben, akkor szerintem 10 esetbol 10-ben az utobbit fogom valasztani. Ha a laptop nincs nalam, meg mindig inkabb kodolok a telefonomon, valoszinuleg talalok neten valami hasonlo peldakodot, amit csak at kell alakitgatni.

Ami peldakat irtal, arra meg pont tokeletes az Arduinos rendszer, a shieldekkel es egyeb modulokkal, es az ezekhez tartozo SW modulokkal. Osszekotod a szivattyudat a rele vagy FET modullal (esetleg H bridge is lehet), radugod az Arduinodra, kotsz melle egy talajnedvessegmerot, SW szinten meg megnyitod a nevessegmerod peldakodjai kozul az egyiket (ami mondjuk kiir egy erteket a virtualis soros portra), oda beteszel egy elagazast (vagy kettot a hiszterezishez), es ha tul szaraz, bekapcsolod x masodpercre az ontozest. A kodzarhoz gyakorlatilag csak GPIO-kat kell kezelni, esetleg ha van valami numerikus gombos modulod, amiben matrixba vannak kotve, akkor azzal megint nem bonyolult. A csipogos homerod megint nem nagy dolog, a csavaradagolod meg elegge alul van specifikalva, de valoszinuleg az sem lenne nehezebb.

Szerintem mindegyik ilyen projecthez hasonlot csinaltam mar Arduinoval, es nem volt nehez.

A HMI-s meglatasod viszont erdekes. A szoveges kijelzok uC-re is teljesen jok, de neha tenyleg lehet, hogy tobb kell. Ilyen projectnek tobb ertelme lenne akkor mar, ami egy grafikus kijelzot+valami input eszkozt is tartalmazo dev board, akkor mar praktikusa ARM alapon. Megfelelo driverrel lehetne ertelme. Amugy volt egy olyan projectunk regen, amit LinuxCNC vitt, de nem akartak teljes meretu kijelzovel szorakozni, ugyhogy egy 20x4 karakteres kijelzot kapott a kutyu (meg par gombot). Ilyenre jo is lehetne.

A strange game. The only winning move is not to play. How about a nice game of chess?

Aki napi szinten programozik ilyen eszközöket, tudja, hogy egy szoftverfrissítés után napokat lehet szopni az előző nap még működő rendszerrel.

Jaj, hogy ez mennyire igaz! Nem túl rég jött ki az XC32 v3.0 compiler. Lefordítottam vele a kódom. Szigorúbb volt a fordító, így kijavítottam egy rakás dolgot. Végre lefordult, letöltöttem az MCU-nak. Az USB kommunikáció kivételével működött, azaz semmire sem tudtam használni.

Ezután az így megszépített kódot lefordítottam a régi compilerrel, elsőre futott hibátlanul. Az USB stack-et viszont nyilván nem én írtam, hanem fejlesztői környezetből jött, szóval ki van zárva, hogy azt én debugolni akarjam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_21476 | 2021. 06. 10., cs – 08:39 )

Szerkesztve: 2021. 06. 10., cs – 11:22

https://github.com/robinhedwards/ArduinoBASIC

https://github.com/PatrickHead/ucBasic

https://github.com/BleuLlama/TinyBasicPlus

  • Arduino - ATMega 168 (~100 bytes available)
  • Arduino - ATMega 328 (~1100 bytes available)
  • SD cards (via SD Library, for FILES, LOAD, SAVE commands, uses 9k of ROM)
  • EEProm (via EEProm Library, uses 500 bytes of ROM)
  • Serial IO - command console

https://hackaday.io/project/3537-avr-basic-computer-v01

És egy eddig számomra is ismeretlen, de igéretes dolog:

https://github.com/fgalliat/BasicAr

180 Mhz Teensy, 256 K RAM, stb.