Ot van minden forras a repository-ban:
- eagle: kapcsolasi rajz es board
- gui: Programozo software. Ezt magadnak kell leforditani, eredetileg linux alatt tesztelve (Qt van Windows-ra is)
- sketch: ezt kell a nano-ba proramoznod (illetne ennek a leforditott valtozatat)

A negyedik keresre: Ez az epromba egeti a kivant kodot, soros porton keresztul. USB-n keresztul azt jelenti, hogy USB-s serial eszkoz.( A peldaban ttyUSB0)

Picit pilotavizsgas a project, de ez surun elofordul ebben a temakorben

Köszi az infót! Az eagle fájlokat már el is kezdtem átrajzolni, mert házilag fotózva rettenetes lenne azt elkészíteni...
Elnézést a további kérdésekért, ha nagyon amatőrnek tűnnek! Tudok 8 bites PIC-et assemblyben programozni, valaha az egyetemi éveim alatt TP-ban is tudtam programozni, de egyszerűen a PC világa számomra sosem volt érdekes, nem is vagyok benne járatos.

-gui: Az itt lévő állományokból miféle fordítóval tudok egy olyan Windows 10 alatt is működő exe-t generálni, amit csak elindítok a gépemen és EPROM-ot írok?

-sketch: Ezt ICSP-n keresztül egy AVR programozóval beégetem a Nanoban lévő ATMEGA kontrollerbe vagy pedig valami bootloaderrel kell betölteni?

Ez most nem teljesen világos számomra. A gui-ban lévő forráskódból generált program akkor alkalmas USB-n keresztül történő programozásra vagy sem?

Köszönöm!

Szia! Esetleg tudnál segíteni nekem az utánad kettővel leírt hsz-emben szereplő kérdésekben?

Szia!

A GUI fordításához egy Qt creator -ra lesz szükséged.
(Hacsak nem írod át a forráskódot.)

A sketch az arduino nano -hoz írt firmware c kódja. Ez arduino keretrendszerben készült. Ezért szükséged lesz hozzá a PC -n erre a fejlesztő környezetre is.

Az arduino panelek általában tartalmaznak egy USB-TTL (soros port) átalakító chipet, aminek a segítségével fel lehet tölteni a lefordított sketch-et.

A számítógépen lévő program (ablakos program, csúnyán "gui") és az arduino nano panellal épített eszköz (természetesen a felprogramozás után) egymással kommunikál a cél érdekében. Ami jelen esetben az EPROM adatainak továbbítása. Mindkét irányba.

Szia!

Ahogy látom ebben a hozzászólásban leírt kérdéseidre kapott rövid válaszok, újabb kérdéseket szültek.
Jelenleg úgy látom, hogy 2 járható út van. Az egyik hosszabb és sokat lehet tanulni közben.

1 - Valaki lefordítja gui-t és a windows-os progit elküldi neked. Illetve generál egy *.hex fájlt, amit egy ISP programozóval feltöltesz az arduino panelre. Ezután használod az eszközt.

2 - Telepítesz a gépedre pár programot, hogy el tudd készíteni magadnak a windows-os progit és fel tudd tölteni a firmware-t az arduino-ra.

Kérdésem, hogy melyikben opcióban szeretnél segítséget?

Auf, köszönöm az infókat! Bár nem szeretem a "fórumra beírok, hogy gyorsan dobják a sült galambot a számba" felvetéseket, de ezúttal az 1) változatban szeretnék segítséget kérni.
Jelenleg a 8080 programozását igyekszem elsajátítani, illetve azzal tervezek egy vezérlő rendszert (nosztalgiából...), így az időm és energiám az emészti fel. Tehát az EPROM égető mögötti know-how csak egy "szükséges rossz" ebben a projektben. Vagy mondhatom úgy is, hogy a 8080 túl izgalmas ahhoz, hogy mondjuk a QT-t is megtanuljam közben.

Azért lenne egy műkedvelő kérdésem: Nézegettem a kódokat és felmerült bennem, hogy az arduinoban az égető impulzus időzítése hogyan van megoldva. A sketch 359 sorában látok egy delay(15) függvényt, ami a 2716 égetése esetén időzít, de ez a delay() függvény vajon hol van deklarálva? Ez valami beépített függvény, amit az Arduino IDE-ben fog majd megtalálni a fordítóprogram és akkor annak segítségével végül lefordítja gépi kódra, hogy hány óraütemnyit várjon a kontroller az égető impulzus miatt?
Csak azért kérdem, mert arról több helyen találtam utalást, hogy a rossz időzítéssel el lehet rontani a programozást vagy akár magát az EPROM-ot is.

Igen, ez egy beépített függvény, és addig nem csinál semmi mást, mint vár.
Időzítéssel tényleg el lehet rontani az EPROM írást (és magát az eszközt is). Ha túl rövid, akkor bizonytalan hogy beírta-e rendesen, ha meg túl hosszú, akkor "megsül".

En mindig csak probapadon dugom ossze az EPROM egetot speci epromokhoz es gyorsan faragok hozza kodot
Ez altalaban ket reszbol all:
1. Maga az MCU kod (Ez tobbnyire ArduinoMega-ra)
2. Egy rovid, alatalban python kod, feltolteni a beegetni kivan eprom kodot a soros porton.

Az idozitest, az impulzusokat elotte persze szkoppal ellenorzom.

Milyen 8080 fejlesztőrendszer áll rendelkezésedre?
A leghatékonyabb megoldás szerintem az, hogy létrehozol egy adatátviteli szoftvercsomagot, ami a PC-ről átküld egy, vagy több bájtot, amit RAM-ba tárol, futtat.
Ezután megoldandó ezek EPROM-ba égetése.
Ezek az alapfunkciók pár tucat bájtban megírhatók, amit kézzel is be lehet vinni.

BTW, nekem van ket MiniMax8085-osom is osszerakva, kicsi modositasokkal.
Ez az egyik legjobb, igazan lightweight jatszo/fejleszto 'rendszer' i8085-re.
Termeszetesen a 8080-as az 'igazi' ferfimoka, de hat ugye a sok sallang korulotte...
A kifejlesztett kod, azonban siman lehet 100% kompatibilis (nagyon keves a kulonbseg a 8080 es 8085 kozott ilyen teren)

A mellekelt kepeken latszik egy ilyen fejlesztopanel, a masikon egy hozza epitett 'extra' panel (RTC, I/O, kijelzo(k))
Ezzel a modszerrel akar EPROM egetesre is hasznalhatod, mellekesen pedig tanulod a 808x assembler-t

Szia!

A PC program elindul, viszont minden funkcióját nem probáltam ki. Az arduino-ba töltendő HEX fájlt is exportáltam. Csatoltam a bootloader-es változatot is és a standardot is.

Szerencsére a forráskódot a szerző nagylelkűen megosztotta, így van lehetőség a kód szebbé és okosabbá tételére. Sajnos én nem tudok most időt fordítani rá.

Nagyon köszönöm! Próbáltam és is futtatni a PC-n, de a win32 és win64 változat indítása után az alábbiakat hiányolja:
libstdc++-6.dll
libgcc_s_seh-1.dll win64 esetében
libgcc_s_dw2-1.dll win 32 esetében
Qt5Gui.dll
Qt5Core.dll

Némi guglizás után úgy tűnik, hogy a fordításnál valamilyen C könyvtárakat nem fordít bele (jelentsen ez bármit is), ezért keresi a gépemen ezeket a dll-eket. Esetleg Te ezt átlátod? Tudsz olyat fordítani, hogy ezeket nálam már ne keresse?

Az OshonSoft 8085 Simulator IDE programot használom, nekem ez tökéletes. Két beágyazott mikroszámítógépet szeretnék csinálni olyan helyre, ahol már jól működő, alaposan kipróbált PICre épülő kártyáim működnek, így hardveres debuggolást, tesztelgetést, EPROM emulálást nem tartok szükségesnek ehhez.

Köszönöm mindenkinek a hozzászólásokat, segítséget, eléggé inspirálóak voltatok! Annyira, hogy elkezdtem az Arduino programozás elméletébe elmélyedni, ezáltal a korábban hivatkozott sketchet már megértem. Ennélfogva számos hibát vagy gyanús megoldást is találtam.

Tehát a téma továbbra is az itt található égető projekt, ami elvileg egy USB-s Arduino Nanora épülő kapcsolás révén 2716-tól 27512-ig mindent írna-olvasna. Na hát nekem komoly kétségeim vannak, hogy ez tényleg teljesül. Leginkább azt gyanítom, hogy az alkotó olvasásra tesztelte a csipeket, írásra pedig csak 2716-ot. Ezeket szeretném felsorolni, hátha valaki meg tudja e kételyeimet erősíteni vagy cáfolni. Illetve hasznos lehet, ha esetleg X idő múlva valaki ugyanebbe a projektbe botlik.

1) Kétlem, hogy az égető impulzust definiáló függvény korrekt lenne:

1a Tudtommal a 2716 EPROM-nak 50msec hosszú H impulzus kell a CE lábra, ez itt csak 15 msec.
1b A program az összes többi esetben csak 110 usec hosszú L impulzust tesz a CE lábra, ami messze nem felel meg az adott IC-k adatlapjának.
--> 2732 EPROM: 50 msec L szintű impulzust kíván a CE lábon
--> 2764 és 27128 EPROM: Az égetés alatt a CE lábat állandóan L-re kell húzni és a PGM lábra adott 50 msec hosszú, L szintű impulzus végzi az égetést.
--> 27256 és 27512 esetén pedig 1 msec L impulzus jön a CE lábra, de az égetés egy sokkal összetettebb folyamat (égetés, ellenőrzés, ha nem jó, akkor még egy égetés, aztán amikor végre jó, akkor az addigi égetési impulzushosszak háromszorosának megfelelő ideig égetés)
1c A teljes sketchben rosszul van inicializálva a CE láb értéke, mert az kezdetben L értékű. Ha tehát kezdésnek egyből 2732 vagy efölötti EPROM-ot írunk, akkor a legelső bájt írásakor nem is teljesül a H-to-L a CE lábon. A CE csak akkor lesz H, amikor kilépünk a read üzemmódból vagy pedig a write üzemmódban az első beírt bájt visszaellenőrzését követően.

2) Nem tudom, mekkora probléma, de egy bájt beírása után a verifikációt mindig read módban végzi, azaz lekapcsolja a V_pp feszültséget:

Az egyes IC-k adatlapja szerint a 2716, 2764, 27128 és 27256 esetében a visszaellenőrzéskor is égetőfeszültségen kell tartani a V_pp-t. Vajon mekkora gond, hogy a program nem így működik?

3) A csatolt kapcsolási rajz szerint az EPROM foglalat A11, A13 és A15 lábainak meghajtása két helyről is jöhet: a 74HC595 shiftregiszterről (amikor ezeket a lábakat címvezetékként használjuk), illetve a lenti kapcsolótranzisztorokról (amikor az adott EPROM típus V_pp vagy V_cc lábai kerülnek ide). Ellenben az A14 láb a 2764 és 27128 EPROM esetén a PGM pin, ahová a programozóimpulzust kell adni. A kapcsolásban semmi nyoma (szoftverben van, lsd. 4. pont) efféle meghajtásnak, tehát szerintem e típusok írására biztos nem jó így ez a kapcsolás.

4) A shiftregiszterekről és a kapcsolós tranzisztorokról is táplálható kétfunkciós lábak esetén a prgramban van arra utaló jel, hogy a költő szerette volna ezt kezelni, azonban nekem ez is gyanúsan rossz. A gen_address függvény néhány vezetéket tud manipulálni (fixen H-ba állítani) az alábbiak szerint:

4a Az első if függvény az A11-es lábat akarja H-ba állítani 2716 típusú EPROM esetén, de miért? A 2716 típusnál ez a V_pp láb, ahová olvasáskor valóban +5V kell, de ezt az adott kapcsolásban a Q5 tranzisztor biztosítja. Amit meg az Arduinonak a ReadVoltageEnable néven becézett D13 lába vezérel. Akkor mi értelme van ebbe "belebeszélnie" a shiftregsizternek a folyamatos H szinttel? Nem az lenne az elegáns, hogy a regiszter kimenetét lenullázom, aztán a kapcsolótranzisztor hadd tegye a dolgát, ahogy a szoftver vezérli?
4b Csak most szaglászom a C nyelvet, de egész véletlenül a case C16:-ot egyből követő break utasításnak nem az az eredménye, hogy ha chip=2716, akkor a switch-ből ilyenkor úgy lép ki, hogy el se jut az if függvényig, ami pedig pont ennek az IC típusnak a kiolvasásakor szeretné (a 4a pontban leírtak miatt egyébként feleslegesen) H szintűre állítani a shiftregiszter A11 lábát?
4c Szerintem a case C128 eset annak a jól látható jele, hogy a szerző le akarta kezelni a 2764 és 27128 változatoknál az A14 helyén lévő PGM lábat, de csak odáig jutott, hogy magasba állítsa a shiftregiszter lábát, a további kezeléssel (H-->L-->H programozó impulzus) már nem bajlódott.

Szia!

Ezeket a dll fájlokat holnap csatolom. Csak az exe mellé kell másolni. Ez Qt-ban íródott progi...

A sketch tele van lehetőségekkel. Egy elírást javítottam benne, a többi részét nem néztem meg.

EPROM égetésekor az Intel több módszert említ. Nem kell feltétlenül 50 ms impulzus, rövidebb is elég lehet. A felelősség a program írójára hárul, általában a programozás a sikeres visszaolvasás után még egy programozó impulzus elég.
A trükk/buktató az EPROM törlésében van. Túl rövid törléskor előfordul, hogy "félig" töröltük a csipet, így fals eredményt kapunk.

Most az a középtávú tervem, hogy az ominózus kapcsolást átalakítom úgy, hogy tényleg le tudjon minden típust kezelni 2716 és 27512 között, aztán majd nekifutok az Arduino kód kipofozásának is. Ha meglesz, majd közzéteszem.

Segítséget szeretnék kérni a témában jártas kollégáktól!
A téma továbbra is ez az EPROM égető kapcsolás, amit elkezdtem átdolgozni, mert az eredetinek van némi gyermekbetegsége (lsd. négy hsz-szel fentebb).
A fenti github linkről letöltöttem a PC-n futó programot, illetve beszereztem egy Arduino Nanot, amire feltettem a sketchet is. Mindenféle áramkör nélkül, pusztán a csupasz Arduinot összedugva a PC-vel elkezdtem játszadozni.
Ennek során azt tapasztaltam, hogy ha beolvasok egy hex fájlt, majd rányomok az írásra, akkor a PC-n futó program szerint lefut az írás és az rendben végbe is megy. Igen ám, de a sketch szerint az Arduinonak minden egyes bájt beégetése után vissza kéne olvasnia azt a címet és hiba esetén jelezni azt:


Hülye vagyok a PC architektúrához, nem tudom, hogy pontosan hogyan zajlik a Nano és a PC közötti kommunikáció, de azt azért gyanítom, hogy a beírni próbált bájt visszaellenőrzése során észlelt hiba esetén a serial.print("Error on address") utasítás hatására valami hibaüzenetet csak kéne kapnia a PC-n futó programnak, amit csak ki kéne írnia. Márpedig a csupasz Arduinot mindenféle áramkör (pláne EPROM nélkül) használva ugyebár azt biztosan kijelenthetjük, hogy a beírni próbált bájtot biztosan nem olvashatja korrektül vissza, hiszen nincs hová írnia, ill. honnan visszaolvasnia.

Valaki rá tudna nézni a szóban forgó projekt gui és sketch mappájában lévő állományokra, hogy vajon hol lehet a hiba?

A kiírt és visszaolvasott érték egyezhet, ha ugyan arról a portról olvas, amire írt ( jó eséllyel ez teljesül) és gyorsan egymás után történik a két esemény. Esetlegesen valamely adatlábat egy ellenállással húzd el egyik irányba, hogy ne a kiírt értéket kapja vissza. Én ez okból jobban szeretném a kiírok egy blokkot/egészet , utána visszaolvasom, mert úgy a címzési és egyéb anomáliák is megelőzhetők. ( a kiírom visszaolvasom módszerrel egy hibás címzésű eprom simán jónak minősül, bár a beírt adatnak köze nincs a tartalomhoz....
Persze programhiba is lehet, ez csak egy apró szösszenet.

Köszi az ötletet, erre nem gondoltam, pedig megszívlelendő felvetés! Ki is próbáltam, az egyik adatlábat lehúztam egy ellenállással. Ha kiolvasok a programmal, akkor jól is látszik az adatbájton, hogy épp lehúztam valamelyik bitet. Sajnos azonban az írásnál továbbra sem fut hibára

A PC oldali program mibenlétét nem látom át, de az gyanús, hogy az Arduino sketch szerint a sikeres írás után "Write success." üzenetet küld a kontroller, de a program mégis "Writing successful" szöveget jelenít meg. Olyan, mintha az Arduino által küldött üzenetek nem lennének hatásosak, de mindenesetre nem azt váltják ki, mint amit a sketch alapján gondolok.

Sziasztok!

Bár korábban írtam, hogy feltöltöm a dll fájlokat, sajnos elszaladt az idő velem. Nem működik másik gépen a hiányzó dll -ek pótlásával sem. Ezt még kipróbáltam.

Sajnos át kell nézni, ami több időt vesz igénybe. A nyaralásnak is vége és a munkahelyi leterheltség is megszűnt. Szívesen átnézem, ötletelhetünk új opciókon is.

A kód 17-es sorában

az összehasonlításhoz hibásan használ virify változó a pár sorral feljebbi 13-as sorban van létrehozva.

Bár gondolom ezt javítottad, különben nem fordult volna le a kód. (Ellenben lehet ez a hiba forrása.)

Igen, a verify/virify hibát kijavítottam a kódban, ezt töltöttem rá az Arduinora.
A PC-n futó program exe formátumban fent van a projekt "release" könyvtárában, azt használtam. Számomra telességgel érthetetlen, hogy ha látszólag rendben kommunikál egymással a PC és az Arduino, akkor hogy lehet, hogy az Arduino kódban lévő üzenetek (pl. az írás sikeres lezajlását követően) miért nem úgy jelennek meg a PC programban, lsd előző az előző hozzászólásom. Ha tippelnem kéne, azt mondanám, hogy az Arduino hibára fut az írást követő ellenőrzés során, de a PC program valamiért ezt nem veszi figyelembe.