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ó.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
hianyzik az opcio hogy "nem kell meg egy", igy muszaj volt az egyebre kattintanom ;)
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Jó cucc volt, kár hogy kb 5 éve megdöglött. És a Lua 5.1 is kb 9 éve EoL.
- A hozzászóláshoz be kell jelentkezni
Ennek ellenére a Lua tovább él a mikrovezérlős cuccokban.
https://nodemcu.readthedocs.io/en/release/
- A hozzászóláshoz be kell jelentkezni
Nem állítottam olyat hogy nem. Ugye?
De a fenti példa is Lua 5.3-as.
5.1-ben bitművelethez is varázsolni kellett.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ezt kitehetmed cikkben vagy blogbejegyzesben. Tanulsagos lenne.
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
'MicroPython can run in 16KB of RAM using 256KB of ROM;'
micropython is kb. ennyi a mese konyv szerint.
Azt hittem LUA kisebb, de ha nem, akkor inkabb python felet a nepnek.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Igen, a teljes Lua nem pici. Azt nézem, hogy mi az ami Linux felett fontos, de mikrovezérlőnél elhagyható.
Ez teljes Python 3.9, vagy valami "python-szerű", de limitált verzió?
- A hozzászóláshoz be kell jelentkezni
„MicroPython implements Python 3.4 and some select features of Python 3.5.”
Kb 6 évvel ezelőtti Python az alap.
- A hozzászóláshoz be kell jelentkezni
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:
- A hozzászóláshoz be kell jelentkezni
A Lua viszont nem Lua szerű, hanem az.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
sql
A portokra készítünk egy vjút, aztán lehet benne matatni. :-D
- A hozzászóláshoz be kell jelentkezni
INSERT INTO AnalogA2 (analog) VALUES (12); COMMIT;
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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ű.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ma meg a 32 bites mikrovezérlőknek több memóriája van, mint ami a 6510 memóriabuszán lógott.
- A hozzászóláshoz be kell jelentkezni
De annyi nem lesz benne, hogy linuxot futtass, vagy OOB python-t, C fordítót használj.
Persze ebben is van kivétel, pl. SAMA5D27, de az meg már megint nem éppen mikrokontroller.
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egy 8 bitesen vérizzadás
A BASIC STAMP-re nem emléxel?
Vették mint a cukrot.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
... azt majd cloud jellegu felhobol, az egesz Foldet megkerulo interwebes drotmadzagokon at, oksytelcsyrol. Legalabbis mostanaban igy illik ezt, ha jol kovetem a temat.
- A hozzászóláshoz be kell jelentkezni
Kb igen.
Aztán lekönyököl az ISP és leolvad a hűtő, nem indul a mosógép, garázskaput nem lehet kinyitni, lakásajtó kinyílik, kazán megáll.
- A hozzászóláshoz be kell jelentkezni
De erre ott vannak az IDE-k, amelyek részben már webesek, csak az Upload gombot kell megnyomni. Az IDE meg futnak linux/win/ios gépeken.
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
Szoval akarsz valamit ami mindenre is jo es vegul nem lesz jo semmire? Ilyen is van mar rengeteg :)
- A hozzászóláshoz be kell jelentkezni
Lua egyértelműen, az értelmezett nyelvek között kb a leggyorsabb.
Psszt, elárulom az IP-címemet: 192.168.0.14
- A hozzászóláshoz be kell jelentkezni
MicroPython / CircuitPython
- A hozzászóláshoz be kell jelentkezni
„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."
- A hozzászóláshoz be kell jelentkezni
/bin/ksh
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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,
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
„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."
- A hozzászóláshoz be kell jelentkezni
Debian Sid: PicoLisp, newLISP, Elk, Guile, Jim Tcl binárisok vannak SH4 arch-ra is.
„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."
- A hozzászóláshoz be kell jelentkezni
Hol van ebből a listából a C?
- A hozzászóláshoz be kell jelentkezni
Itt lehet nem leszek ezzel népszerű, de C#
Igen tudom hogy létezik már ilyen.
- A hozzászóláshoz be kell jelentkezni
Biztosan elég erőforrás takarékos egy mikrovezérlőhöz?
- A hozzászóláshoz be kell jelentkezni
Anno volt egy ilyesmi kezdemenyezes, de sose terjedt el. Legalabbis nem olyan szinten, hogy a legtobb random ember akivel eddig beszeltem az tudna, hogy mirol motyogok epp.
- A hozzászóláshoz be kell jelentkezni
Erre gondoltam. A GHI electronics átvette és a mai napig erre épít. Használtam is, sőt adtunk is el ezzel fejlesztett terméket.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Szeretnék motort cserélni egy autóban. Mit javasoltok?
- A hozzászóláshoz be kell jelentkezni
:-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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ez publikus? Basicesitett Forth nagyon retro.
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Bash
Más nem kell. :-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Én a C és a C++-t külön választanám.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Akkor a valaszod nem python. ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
Miért ne lenne alkalmas real-time dolgokra egy SBC?
Szabad ám azt is bare metal programozni. Semmiben nem lesz rosszabb, mint egy kontroller.
De ezekre az aggályokra is fejlesztenek processzort: https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series…
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Sőt, felprogramozod a perifériákat, elaltatod az MCU core-t, s a perifériák önjáróan teszik a dolgukat.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ú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.
- A hozzászóláshoz be kell jelentkezni
Mind az AL1-es, mind az MP944-es számítógépekben volt használva, még be is linkeltem őket. A CADC katonai projekt lévén valóban nem magánemberek cucca volt, de a Four Phase gépeiből többszáz kelt el a "normál" piacon.
- A hozzászóláshoz be kell jelentkezni
Szerintem beszéljünk már azokról a processzorokról, amelyeket én soroltam fel.
- A hozzászóláshoz be kell jelentkezni
Dehát te hivatkoztál az első CPU-ra, hogy azt nem számítógépekbe szánták, miközben az első CPU az vagy az AL1-es, vagy az MP944-es és mindkettőt számítógépekbe szánták. Én csak erre akartam rákérdezni.
- A hozzászóláshoz be kell jelentkezni
Nálad az az első cpu, nálam meg a 4004-es, majd a 8008-as.
Tettem egy felsorolást is, azt próbáld meg használni sillabusz gyanánt.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az Intel 4004-es egy 4 bites CPU, amit az Intel vállalat adott ki 1971-ben. Ez volt a második teljes, egy lapkára épített CPU (ezt megelőzte a Texas Instruments TMS 1000-es mikrovezérlője), azonban ez volt az első kereskedelmi forgalomba került' mikroprocesszor.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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. ;)
- A hozzászóláshoz be kell jelentkezni
Most olvastam csak alaposabban utána ennek az ICU-nak.
Hát ez zseniális.
Hogy nem terjedt ez el eddig?
- A hozzászóláshoz be kell jelentkezni
Nézted a VHDL kódját is? Fogpiszkáló is szinte bonyolultabb ennél.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni
Tényleg, az AGC is processzoros gép volt, bár nem tudom, hogy a processzorát mennyire lehet "mikro"-nak hívni. :)
Viszont bitkójnt azzal is lehet bányászni. :P
- A hozzászóláshoz be kell jelentkezni
Az is egy szép sztori, hogy a kevés Apolló repülés után miért van teli a Youtube AGC-kkel?
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Applications_out…
Hosszú utóélete volt az AGC-nek. A holdprogram után sok más helyen alkalmazták.
- A hozzászóláshoz be kell jelentkezni
Szintén ugyanezekben az években HP2116:
http://www.bitsavers.org/pdf/hp/2116/02116-9010_2116A_Vol1_Mar67.pdf
Rackbe szerelhető számítógép, van hozzá rack mount kit. :)
- A hozzászóláshoz be kell jelentkezni
Egyáltalán nem meglepő, hogy másra is alkalmazták, ha egyszer alkalmas volt másra is.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ez így már korrekt, de azt még mindig nem mondtad el, hogy neked mitől az első mikroprocesszor a 4004-es.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
+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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"Voici une mauvaise rencontre" (:
Jól néz ki az a Thomson M05.
„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."
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Esetleg nezd meg a MicroMite-t is.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
“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.
- A hozzászóláshoz be kell jelentkezni
Igen, a gombot megnyomva már nevettem is, hogy ott akarnék kötözködni [BASIC], ahol épp az architektúra nem is jut érvényre. :))
- A hozzászóláshoz be kell jelentkezni
Nem úgy van, hogy az AVR-t megvette a Microchip, akihez a PIC tartozik? ;)
Nem mintha azt akarnám mondani, hogy a kettő ugyanaz... PIC-et én is kerültem.
- A hozzászóláshoz be kell jelentkezni
Igen, úgy van.
De az AVR-eket akkor sem a Microchip szülte meg. :)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni