Készítettem Ardunio Nano segítségével (sok netes példa alapján) egy AT28C64 EEPROM írót, ami rendben működik is. Ugyanez a programkód képes lenne AT82C256 EEPROM írására is, csak a 32KB-os EEPROM tartalom már magam sem fér el az arduino tárterületén.
Az egyik járható út, ha az Arduino Nano helyett az Arduino Nano Every lapot használnám, mivel annak a 48KB-os tárterületén simán elfér a megírandó teljes ROM, bár csak 1 példány.
A másik járható út, ha tömörítem a ROM tartalmát, valami egyszerű tömörítéssel. Ha lemegy 28KB alá, akkor már esélyes, hogy meg lehet csinálni.
Mégis, érdeklődöm, van-e harmadik lehetőség? Van-e valami egyszerű fájlfeltöltési módszer a Serial porton keresztül, amivel röptében olvasás közben már írhatna is a program, így nem kellene a programkódban tárolni a megírandó adatot. Ezzel egy egyszerű Nano is képes lenne 32KB írására, valamint nem kellene minden új íráshoz újra feltölteni a programot, ami jelenleg magában tartalmazza a megírandó adatot is.
Van valakinek erre valami egyszerű ötlete?
- 972 megtekintés
Hozzászólások
Eleve nem világos nekem, miért nem a harmadik megoldást alkalmazod. Egy kódomba belenézve 32 byte-os page-ek vannak, tehát ilyen picike bufferre van szükséged. Egy esetben lehet indokolt RAM-ban előbb összerakni a file-t. Akkor, ha lehet arra számítani, hogy lóugrásban tartalmazza a file az adatot, nem szekvenciálisan. Ha viszont az input egy hex file, akkor ugyan lehet lóugrás, csak nem valószínű, hogy gyakran lesz. Ekkor megteheted, hogy az adott page-et felolvasod, felülírod azt a részt, ami a cím modulo 32 szerinti része a 32 byte-os buffered indexe, törlöd a lapot, majd kiírod azt. Már, ha kell előtte törölni, most nincs kedvem megnézni, de erre azért látok esélyt.
Szóval néhányszor 32 byte elegendő erre akkor is, ha nem optimalizálsz kényszeresen. Egy szinte bármilyen kis PIC-kel meg lehet ezt csinálni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Igazából a feltöltési oldallal van bajom. Ha a PC oldalára is készítenék egy feltöltő programot, ami a soros porton keresztül darabokban küldi az adatot, akkor ez egy működő megoldás lenne, csak nehézkes. Ennél egy fokkal egyszerűbben használható utat keresek, ha van. Ha nincs, akkor lehet, ez lesz a járható út.
- A hozzászóláshoz be kell jelentkezni
Valamilyen program mindenképp kell a PC oldalára. Beszélj erről kicsit többet, mert nem egészen értem!
Úgy képzelem, hogy van egy Intel HEX32 file-od, van egy általad írt programod PC-re, majd kiadsz egy parancsot:
uploadee valami.hex
A program megkeresi, melyik porton van az EEPROM íród, majd valamilyen formátumban, akár a hex file-t text-esen elkezdi leküldeni. A drót másik végén lévő cucc pedig megérti a parancsot, írja az EEPROM-ot, majd ha elkészült az adott lappal, visszaküldi a nyugtát a PC-nek, hiba esetén pedig a hibát. Utána jöhet a következő blokk.
Ebben nem látok semmi nehézséget. Vagy ne így képzeljem ezt?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Jelenleg PC oldalon semmi nincs. Eddig egy Arduino IDE volt, de az elakad, mert azzal csak a programkódot tudom feltölteni. Más PC oldali programom nincs. Ha kell írni, mert nincs rá szokásos eszköz, akkor megírom, csak reméltem, hátha van erre már valamilyen kész megoldás.
- A hozzászóláshoz be kell jelentkezni
SPI-os csippekre jó az iceprog is. Sajna ez itt most nem segít, de ha későbbiekben kell ilyesmivel is foglalatoskodnod akkor érdemes észben tartani.
- A hozzászóláshoz be kell jelentkezni
A fiammal csináltuk ezt jó néhány éve, hátha tudsz belőle hasznosítani valamit:
https://bitbucket.org/mitchnull/eeprom-uploader
https://bitbucket.org/baltitenger/eepromprogrammer
régen volt, nem tudom működik e még :)
- A hozzászóláshoz be kell jelentkezni
Köszönöm!
- A hozzászóláshoz be kell jelentkezni
Itt a kérdés inkább az, hogy hány ilyen programozást is akarsz csinálni. Máshogy állnék neki akkor, ha ez egyszeri alkalom, meg akkor is, ha szériában kéne feltölteni.
Ha egyszeri az eset, akkor simán elvágnám azt a 32K-s tartalmat két részre, 16K már belefér a µC programmemóriába. Először az első felét programozná be egy program, utána meg a másodikat egy másik, és már kész is vagy.
Ha sokszorosítani akarsz így (de miért :) ), akkor meg rá lehet kötni ugyanarra a µC-re két EEPROM-ot is, az egyikből olvasol, a másikba írod, azt' szintén kész.
(Természetesen működik az említett soros kommunikációs verzió is, régen csináltam ilyent egy 24C512-höz (?), ott a 64K-t túl sok macera lett volna annyira szétvagdosni, hogy elférjen a jóval kevesebb prog-memóriás µC-be, de ott kellett a soros port másik felére is elkövetni valami programot.)
- A hozzászóláshoz be kell jelentkezni
Ez is egyfajta tömörítés, ha csak a felét töltöm fel egyszerre. Amúgy ha belefér akkor is kényelmesebb lenne feltölteni. Nem egyszeri írás, de nem is sorozat. Néha-néha kell, olyankor néhány különböző ROM tartalmat kell írnom. Ehhez most mindig berakom a forrásba a tartalmat annyiszor, ahány ROM-ot meg kell írnom. Ez megy, de egyszerűbb lenne, ha csak feltölthetném a megírandó adatot.
- A hozzászóláshoz be kell jelentkezni
Osszedobsz egy programot PC oldalra, ami atkuldi mindig a feltoltendo file-t, az Arduino meg csak az elektronikai reszevel foglalkozik.
Ha sokszor kell par varianst egetni PC nelkul, akkor meg leteznek SD kartya modulok, egy 32GB-os kartyan azert elfer par ROM verzio.
Atmel egetessel mar jatszottam par eve, akkor azt csinaltam, hogy az Arduino kodjat ugy irtam meg, hogy a hex formatumot ismerje, igy a leforditott Intel hex file-t a soros terminalba eleg volt copy-paste-elni. De nem nehez osszedobni ennel szofisztikaltabb megoldast, pl. Pythonban.
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
Simán lehet streamelni az adatot, ezek kellenek hozzá:
* Az írási oldal tudjon várakozni, vagy legyen elég lassú hozzá, hogy beleférjen közben a streamelés is. Például ha IRQ vezérelt a serial kommunikáció a PC-vel, akkor az IRQ-k ideje férjen bele. Ki kell számolgatni. Gondolom ez adott, a programozáskor a programozó szokta adni az órajelet, ami lehet lassú.
* A PC-Serial protokollba bele kell tenni egy folyamkontroll protokollt, ami képes úgy kérni az adatot, ahogy szükség van rá. Például mindig elküldjük, hogy mennyi üres hely van a pufferben, és a PC pont annyit küld. Ehhez vagy kell egy PC program, vagy egy meglévő protokollt kell használni. Pl: avrdude valamelyik protokollját, vagy ilyesmit meg lehet nézni. Én sajátot csinálnék, de kinek mi a preferenciája.
* Érdemes az egészre tenni egy visszaellenőrzést a végén, persze ezt is streamelni kell, vagy az Arduino számolhat hash-t is, akkor az ellenőrzésnél nem probléma a tárterület kérdés.
Én tömörítést nem csinálnék: esetlegessé teszi, hogy az adott dolog végül belefér-e vagy nem. Szemben a streamelés hasonló bonyolultság, és bármeddig skálázódik. A tömörítés talán egyszerűbb lehet persze, ha találsz olyan libet, amit könnyű integrálni, például egy single header tömörítőt, amit csak be kell kopipésztelni és működik. Nemrég integráltam egy programba egy tömörítőt, az nem volt egyszerű, nagyon fejtörős volt az API-ja.
Az egésszel a baj az, hogy tapasztalat függően ez egy elég komplex fejlesztés, sokáig fog tartani hobbi léptékben mérve. Aki már csinált hasonlót, annak is "egyéjszakás kalad" szerintem legalább 1-2-3-4 óra, ami már hobbiból egy teljes nap. Gondolom hobbi.
- A hozzászóláshoz be kell jelentkezni
Nem sokat értek hozzá, egyetlen egy dolgot fűznék ide. A folyamat kontrollra én nem találnék ki új protokollt, mert van már ilyen standard, úgy hívják, hogy XModem. Mocsok régen volt már a betárcsázós modemek korszaka, meg a soros port fénykora, de akkoriban ez mindenkinek megfelelt. Ne kövessük el az XKCD 927-es hibát... (https://xkcd.com/927/)
- A hozzászóláshoz be kell jelentkezni
Ha tökéletes lenne és lenne készen polcról levehető kliens a PC oldalra, akkor talán. Megnéztem a Wiki oldalát, szerintem önszopatás lenne ezt implementálni, elég szar protokol.
- A hozzászóláshoz be kell jelentkezni
Bocsánat, I2C interface-szel rendelkező EEPROM-ot feltételeztem. Ez párhuzamos eszköz, byte-osával írható, ami azt jelenti, hogy a helyzet még egszerűbb. Az adott címre írást kell kezdeményezni, utána olvasgatni ciklikusan onnan az adatot. Amíg nem a kívánt érték jön vissza - írás alatt a felső adatbitet negálva adja vissza, a többi bit ismeretlen -, addig várni kell, amikor a helyes eredmény jön vissza, akkor készen vagyunk. Lehet time out-osra csinálni, mert ha kb. 2 ms után sem jön vissza a jó eredménnyel, akkor baj van, megdöglött az EEPROM.
Tehát így az Intel HEX32 file - már ha ez a formátum - egyetlen sorát kell bufferelni, ami legfeljebb 255 byte, tipikusan 16 byte. 256 byte-os buffert foglalnék statikusan. Amikor kiírta az adott sort - ez tipikusan 16 ms-on belül lesz -, válaszol a hardware MCU-ja, hogy OK, a PC-s program küldi a következő buffert.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Igen, ez egy olyan problema amit szerintem erdemes altalanosan megoldani es tervezni egy fokkal szofisztikaltabb (de azert meg mindig relative egyszeru) PC-oldali frontend programot is. Ha jo az UART-os kommunikacio nyelvezete (pl. ASCII hex + ujsor alapu parancsok, vagy KISS packet-ek) akkor ezutobbit mar tenyleg barmiben meg tudod irni. Az EEPROM programozashoz meg vezess be 3-4 alapveto parancsot:
- torles (page, block, chip szinten is akar)
- iras
- olvasas
- CRC vagy hasonlo ellenorzes
Es akkor az EEPROM irast meg bontsd elemi tranzakciokra. Minden tranzakcio egy master-slave jellegu muvelet: a PC/frontend kuldi a parancsot, az MCU valaszol ha kesz. A page merete megmondja az MTU-t is, annyi RAM meg csakcsak akad az MCU-ban :) Es akkor valami ilyesmi lehet a muveletsor hogy torles - iras - iras - iras - iras - torles - iras - iras - iras - iras - torles - ... iras - CRC. Vagy visszaolvasod az egeszet a vegen, vagy csak ugy random beleolvasol. A CRC az opcionalis, de sajat hardverekhez + frontendekhez mindig teszek a cuccokba egy crc32 kompatibilis implementaciot. Igy ha az upload akarmi.bin utani verify_crc32 ugyanazt mondja mint a crc32 akarmi.bin akkor keszen vagy es minden oke.
Az elemi parancsok meg tenyleg egyszeruek lesznek. Torles eseten: melyik cimtol milyen hosszan toroljon, iras: melyik cimre mit irjon be, olvasas: melyik cimtol kezdve mennyit olvasson ki, CRC: melyik cimtol kezdve milyen hosszan szamolja ki a CRC-t. Az iras meg olvasas maximalis blokkmeretet az UART-os protokoll MTU-ja es/vagy a mikrokontroller memoriaja limital(hat)ja. Meg persze a jozan esz. De mivel az EEPROM iras az mehet akar darabokban is egy page-n belul, tenyleg kb barmi lehet itt a meret(hatar).
- A hozzászóláshoz be kell jelentkezni
ESP alapon? HEX file feltölt LittleFS-be / eeprom kiolvasás úgyszint oda, html hex editor?
ChatGPT segítségével egy óra.
Itt egy komplet egyablakos Total Commander stílusú fájlkezelő, csak az eeprom baszogatót kell hozzáadni meg az editor.html-t megcsinálni hex editorra.
Szerk: most látom hogy AT28C256 nem I2C az alany. ESP32 S3 önmagában elég hozzá.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
ESP nagyon jó, csak az AT28C16 írom arduinoval volt meg, így a C64-et is ilyennel készítettem, és akkor már miért ne legyen C256 is?
ESP-vel a 3.3V a probléma. Biztosan meglehet csinálni több külső portbővítővel, és akkor látom én hogy nagy a boldogság, de az arduino készen van, megy, csak kibővíteném, ha egyszerű. Ha nem egyszerű, akkor lehet, az ESP-s újrakészítés egyszerűbb. Egyelőre az arduino-s feltöltési lehetőségek érdekelnek, de köszönöm.
- A hozzászóláshoz be kell jelentkezni
A címek mehetnek opendrain ellenálláshálóval 5 voltra húzva, 5V toleráns az IC. Az adat kicsit neccesebb (pl 74LVC245). Irtad hogy PC oldalon nincs semmid, akkor szerintem ez a legegyszerűbb, leggyorsabb megoldás.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
Többen is válaszoltatok, így inkább itt pontosítanék: nem a feltöltés logikája érdekel, hanem az, hogy van-e erre bevett eszköz vagy módszer. Ha nincs, és egyedi kódolást igényel, akkor meg fogom tudni oldani, de nem állnék neki fejleszteni, ha erre már van valamilyen bevett szokásos eszköz, program.
- A hozzászóláshoz be kell jelentkezni
Mivel a programozót is te csinálod, annak az MCU-jában az általad írt program fut, így a protokollt is te definiálod, az interface-t, parancsokat, tehát a PC oldali programot is neked kell megírnod. Jó hír, hogy mivel mindkét oldal a kezedben van, ha rájössz, hogy valamit rosszul csináltál, vagy célszerűsíteni volna jó, akkor hoozá tudsz nyúlni az MCU oldalán és a PC oldalán is.
Egyébként így fejlesztettem boot loadert. Nagyjából kitaláltam, mi legyen, megírtam az MCU oldalát, aztán a PC oldalát, majd amikor azt éreztem, valami bonyolult, vagy hiányos, akkor módosítottam, bővítettem mindkét oldalt.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Altalaban igen. Annyit tennek meg hozza, hogy ha van valamire ismert es elterjedt protokoll es program, akkor celszeru azt hasznalni. Ha irsz valami webes dolgot, nem fogsz hozza bongeszot is fejleszteni, mert arra pont van.
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
Bonyolult dolgoknál igen, nyilván a wifi-t nem kellene megint feltalálni. De egy boot loader saját fejlesztésű berendezéshez, saját termékhez, vagy egy EEPROM író berendezésnél szerintem helyénvaló a saját protokoll. Ráadásul élvezetes egy ilyet kitalálni és implementálni. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mi lenne, ha tennél egy SD-olvasót a Nano mellé?
PC-n ráteszed a felírandó file-t, a Nano meg beolvassa az SD-ről.
"Normális ember már nem kommentel sehol." (c) Poli
- A hozzászóláshoz be kell jelentkezni
Köszönöm az ötleteket. Ezek szerint nincs olyan szabvány bevett eszköz, ami erre való.
A minimalista megközelítés miatt azt hiszem, akkor az lesz, hogy kliens oldalon a bináris fájlt Intel hex formátumra konvertálom, amit soronként elküldök az arduinonak, aki minden feldolgozott sor után jelzi, hogy kész a következő fogadására. (Gondolom Serial vonalon nem illő bináris adatot küldeni.) Ez mindkét oldalon minimális kódolást igényel. Kliens oldalon tán elég egy bash fájl is hozzá.
- A hozzászóláshoz be kell jelentkezni
>Gondolom Serial vonalon nem illő bináris adatot küldeni
Azt küldesz amit csak akarsz, nincsenek illemszabályok, se a kábel, se az USB illesztő nem sértődős és 8 bit módban van alapból.
- A hozzászóláshoz be kell jelentkezni
Akkor akár binárisan is feldarabolhatom mondjuk 32 bájtos csomagokra. Talán 64 bájt a maximum, amit elküldhetek egyszerre? A folyamat így lehet, egyszerűbb is. Bár a vége miatt egy hosszbájtot is küldeni kellene. Egyáltalán: bináris adatnál mi jelzi az adathosszt? Benne van a protokollban?
- A hozzászóláshoz be kell jelentkezni
Azok a byte-ok jonnek meg, amit elkuldesz. A protokollt te talalod ki, lehet a csomagnak kerete, header, hossz, crc, barmi.
Amugy ha az iras sebessegevel nincs problema, es nem akarod ellenorizni (vagy max. visszaolvasod, es atkuldod PC oldalra), meg azt is lehet, hogy folyamatosan irod. Mondjuk ha 9600 baud-dal kuldod at az adatot, es ennel gyorsabban tudod irni az eszkozt, nem kell varni, csomagokra bontani, stb.
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
Ez jól hangzik. Akkor lehetne így írni, hogy:
cat binfile > /dev/ttyUSB0Persze ez is csak akkor működik, ha a a protokoll tudja, hogy jön-e bájt egyáltalán.
- A hozzászóláshoz be kell jelentkezni
A serial protokol tudja, hogy küldenek-e éppen. Nem olvas 0-kat, vagy ilyesmit amikor nem jön éppen semmi. Az Arduino oldalon minden karaktert ki tudsz olvasni ami jött, ha nem jön semmi nem kapsz semmit. És a fenti tényleg működne szerintem.
Ahogy az Arduino serialja működik: Van egy külön USB illesztő csip, ezzel beszél a PC USB protokollon. Ez a csip pedig direktben össze van kötve az AVR csippel két vonalon: RX, TX. Plusz van egy olyan rendszer, hogy az egyik forgalm kontroll kimenet jelváltására egy reset jelet ad az AVR-nek, így a PC-ről tudjuk resetelni a csipet, és erre indul el a bootloader, így lehet avrdude-dal feltölteni az AVR programját.
A te programod tehát csak az RX TX vonalakon kommunikál. Stabil állapotban az RX TX vonalak konstansak és nincsen adatküldés. A serial pedig úgy megy, hogy az első lemenő él a vonalon indítja a bájtot. Tehát ameddig nincsen él a vonalon, addig nincsen bájt sem. (Ha elindult a bájt küldés, de nem valid bájt forma jön, akkor kerethibát vesz a vevő, de ezzel nincsen dolgunk.)
Szerintem működne az, hogy az író idő alapon tudja, hogy mikor kezdődik az adat: ha egy ideje csönd volt, akkor a teljes blokkot várja, amiben nem lehet szünet. Tehát onnan tudja, hogy lement az egész fájl, hogy egy adott ideig nem jött semmi.
Erre reakcióként X idő múlva pedig visszaolvassa az adatokat szintén sorban, és elküldi binárisan a PC-nek. Így a PC-n mind az írás, mind az olvasás lényegében a fájl serialba másolásából áll. A kiolvasásnál nem tudom, hogy hogy lehet detektálni azt, hogy elfogyott az adat - ha simán parancssori eszközzel akarunk X bájtot olvasni Y idő alatt, de tuti meg lehet csinálni valahogy. Én amikor timeoutos dolgokat akartam csinálni, akkor mindig végül besokalltam és inkább rendes programot írtam, mert 1000x egyszerűbb és világosabb nekem mint a szkriptelés.
Amire figyelni kell, az a soros vonal konfigurálása: be kell állítani a baudot, a paritást, a bitszámot. Vigyázni kell arra, hogy az írás kezdete ne triggerelje a resetet. Ezeket meg tudod kérdezni chatgpt-től szerintem, hogy pontosan hogy kell, szerintem a stty programmal meg lehet csinálni.
- A hozzászóláshoz be kell jelentkezni
Azért így csupaszon biztosan nem tenném. Egyrészt a HEX32 nem véletlenül terjedt el. Abban van cím, hossz, CRC, entry point - ez utóbbi neked nem kell. A bináris esetében vagy binárisan kell ugyanezeknek meglenni, vagy az üres részeket is át kell küldeni, akkor meg végképp baj van, ha a lyukak helyén már van adat az EEPROM-ban.
Valami protokollt, keretezést, hibakezelést, flow control-t, ellenőrzést csinálj már hozzá, mert ez így nagyjából az utánam az özönvíz esete.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Kuldheted magat a file-t is, ha abban a formaban van.
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
Ezek szerint nincs olyan szabvány bevett eszköz, ami erre való.
Azt el tudom kepzelni hogy a gyarto (Microchip) gyart olyan programozokat amiket ha radugsz PC-re akkor egy celprogram (vsz Windows-os, de lehet akar Linuxos is) programozza ezeket az IC-ket. Vagy akar fuggetlen gyartotol (pl ezt talaltam hirtelen ami tud/hat/ja). Ezeknek biztos van egy sajat interface-e/protokollja ami ha ismert akkor tudsz hozza alkalmazkodni sajat hardveren is, es akkor legalabb a feladat egyik fele konnyebb es/vagy by def keszen van.
Lehet korulneznek ilyen iranyban is. Vagy ezt is megnezheted, hatha. Ha teljesen sajat hw a programozo akkor interface/protkoll szinten persze tudsz alkalmazkodni letezo megoldasokhoz amik ismertek. Ha van valami de facto standard.
Mondom, fentebb azt az iceprog-ot azert emlitem mert az a progi latszolag ugyan egy nagyon celhardver nagyon celfeladatjahoz nagyon celtudatosan lett kifejlesztve - de valojaban egy full altalanos, FTDI alapu SPI flash programozo. Amihez csak egy FTx232 IC breakout board kell, 6 jumper wire, es mar kesz is. Az eredeti celjan felul hasznaltam ezt mar modositas nelkul feltucat sajat hardverre is (odafent repkedo muholdas elektronikatol kezdve sajat devboardon at teglasitott pc-alaplapok bioszanak megmenteseig), szoval eleg altalanos. Sajna a parallel flash-ek lelkivilagat messze nem ismerem annyira jol mint a serial/SPI flash-eket, de siman lehet hogy erre is talalsz valamit, valahol. Ld. fentebbi linkek, akar kiindulasnak is. Ez a fentebb linkelt Revelprog cucc is lehet hogy azert sorolja fel 10+ oldalon a tamogatott IC-ket mert valojaban ez az interface (mind a fizikai parallel flash, mind a programozo szintjen) az SPI-hoz hasonloan elegge standard.
- A hozzászóláshoz be kell jelentkezni
Előre is elnézést kérek ha hülyeséget írok, és jérlek is titeket hogy javítsatok ki, mert az OP módszere nekem nagyon furcsa.
Ahogy én csinálnám: arduinoISP-t raknék az arduinora, a kábelesést nyilván meg kell csinálni egy ZIF csatlakozóval, és aztán a "flashrom" -ot használnám.
valami ilyesmire gondoltam: https://flashrom.org/supported_hw/supported_prog/serprog/arduino_flashe…
Mit hagyok ki?
- A hozzászóláshoz be kell jelentkezni
Lehet én is hülyeséget írok, de mintha túlbonyolítást látnék a dologban.
Mi a cél?
1db EEPROM-ot 1x (vagy max párszor) meg akarsz írni, mert kell valamibe és kész, vagy sorozatban akarod az eepromokat írni, vagy mindenáron szeretnéd megérteni a dolgok működését, és egy saját programozót szeretnél csinálni?
Ha az első, akkor rendelsz aliexpress-ről 1db arduino megát (2500-6000ft között mozog) és az alábbi módon felprogramozod az eeprom-ot:
https://github.com/crmaykish/AT28C-EEPROM-Programmer-Arduino
Apropó, ezt már a megépített NAS-ról programoznád? :D
(Mert az is lóg még a levegőbe)
- A hozzászóláshoz be kell jelentkezni
Az a rajz fájdalmas. Próblémát okozott volna a szerzőnek egy normális elvi kapcsolási rajzot készítenie, amelyen tettenérhető ennek a működése?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az Arduino-fanok imádják Fritzinggel összekattintgatni a művüket, és ezt még schematicnak is nevezik.
"Normális ember már nem kommentel sehol." (c) Poli
- A hozzászóláshoz be kell jelentkezni
Azert annyira nem nehez ertelmezni. Az EEPROM-nak van 3 laba: GND foldon van, VCC a tapon, a /WP egy 10k-s ellenallassal van tapra huzva. Minden mas pin (cim, adat, vezerles a /WP-vel egyutt) meg megy az Arduino Mega (ATMEGA2560) 1-1 GPIO labara. Gyakorlatilag minden software-bol megy. Ha hosszu a vezetek, a VCC-GND koze meg tettem volna kondit az EEPROM kozelebe, de ettol eltekintve nagyjabol rendben van.
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
Attól még lehetne rendes rajz, ne olyan, amelyet vissza kell fejteni. Ez így nem dokumentáció. A hidegítő kondenzátor az én felfogásomban kötelező.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Becsülöm és nagyra tartom a szakmaiságodat, és részben egyetértek az észrevételeddel, de pont te írtad le, hogy az ember machbox autót kér, és egy 1:100-hoz modell autót kap ajánlatnak.
Azaz lehet hogy ez így neked móricka rajz, mert te mélyebben benne vagy, és a léc fentebb van, de egy amatőrnek/hobbistának meg pont elég ahhoz, hogy pontról pontra mit hova kössön be.
Nekem pl ez szimpibb, minthogy egy 2 oszlopos N soros táblázatban legyen felsorolva az egyik|másik eszköz lába amit össze kell kötni. Az viszont igaz, hogy a sok sárga vezetéktől kiugrik a szemem is, használhatott volna több színt.
Röviden: egynek elmegy, elég informatív, és ha előrébb akarod vinni a világot, akkor készítesz egy általad preferált képet, amit beküldesz, és nagy valószínűéggel az is meg fog jelenni. Ezután egyaránt boldog lesz a kezdő és a haladó szakember :)
- A hozzászóláshoz be kell jelentkezni
Na igen, épp arra gondoltam, hogy nem az a baj, hogy ez itt van, hanem az, hogy nincs kapcsolási rajz.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ennek 8 adat, tizenx cím, RW, CE, OE, megafasztudja milyen lábai vannak, amit a nyitó szeretne programozni.
Bocs, nem olvastam végig, a 3 lábnál elakadtam.
σ→0, SNR<1 (A semleges részecskékkel nincs mérhető kölcsönhatás)
- A hozzászóláshoz be kell jelentkezni
A NAS-tól elvettétek a kedvemet. :( A lényeg, hogy túl sok szempont van, és túl buta vagyok ahhoz, hogy ennyi pénzt rosszul költsek el ... tehát még rágom. Addig meg marad a külső HDD.
Itt pedig nem egy darab EEPROM-ról van szó, de nem is sorozatgyártás. Néha kell, de akkor több is. Ezekbe most tipikusan diagnosztikai kódokat töltök fel, lehet, hogy egy napon akár 10-20 féle külön kódot is, attól függően, hol tart a gép javítása.
Amúgy ilyenkor szeretek olyan megoldást találni, aminek én is örülnék, ha megtalálnám a neten, és azt publikálni a végén. Arduino nano-t használok.
Jelen esetben a bináris feltöltés nagyon kényelmes lenne, de az intel hex formátum mellett meg az szól, hogy a jelenlegi kód megtartása mellett azt ki lehetne bővíteni, hogy ha feltöltés van, azt automatán észre tudja venni, és megcsinálni.
- A hozzászóláshoz be kell jelentkezni
>ha feltöltés van, azt automatán észre tudja venni, és megcsinálni.
Ezt kifejted, hogy hogy kell érteni?
- A hozzászóláshoz be kell jelentkezni
A többiek tanácsaival - ideértve a sajátjaimat is - sokszor az a baj, hogy ha valakinek tapasztalata van azon a téren, túl mélyen lát a kérdésbe, s aszerint tesz javaslatot. Szükséged van egy vitorlázó repülőre, de a vadászpilóta vadászgépet ajánl, mert annak mennyivel jobbak a képességei. Szerintem a NAS-t a saját képességeid, szinted alapján rakd össze. Mondjuk egy picike PC-be RAID-be tett SSD-k vagy HDD-k egy Linuxszal, rajta valamilyen file szerver. Persze, aki látott közelről NAS-t, nyilván már most röhög, és sorolja a hátrányait, de én ezt csinálnám, és hidd el, elégedett lennék az eredménnyel.
Ugyanez igaz az EEPROM íróra is. Olvasd el a pecifikációt, illessz hozzá egy mikrokontrollert, másik oldalán USB vagy RS232 interface-szel, írd meg a kódját, és ne foglalkozz a világgal!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Én láttam NAS-t (meg mást is) és nem röhögök. Otthonra, nem kritikus környezetbe nem kell több, mint egy alsópolcos gép, néhány winyó RAID -ben (ideálisan: hardveres RAID-ben, hogy maradjon több kraft a CPU-ban), Ext3/Ext4, Samba, csókolom. Az összes elképzelhető operációs rendszert, és az összes elképzelhető eszközt ki tudod szolgálni ezzel a setuppal.
A MediaCenter már erre tud építeni, lényegében csak plusz szoftvereket kell feldobálni.
A rule of thumb az, hogy otthon nem akarsz üzemeltetősdit játszani a szabad idődben, ha nem muszáj. És itt nem a vas bizgatására gondolok, hanem a Doom3 közbeni "Drágám! Nem érem el a Barátok Közt következő epizódját" mondattal kezdődő zavaró tényezőkre. Azaz Keep It Simple & Stupid (KISS).
- A hozzászóláshoz be kell jelentkezni
Van benne valami, de a hardveres RAID-et kerülném. Nem sokat eszik egy sw-RAID, főleg, ha 1, vagy 10. De nekem a desktop gépben lévő Raid5 sem nagyon terhelte a CPU-t, ha meg egy NAS-ként használt gépben van, aminek túl sok CPU-feladata nincs, végképp nem probléma. A hw-RAID könnyebben okozhat problémát, ha megkattan a kártya.
- A hozzászóláshoz be kell jelentkezni
Én most bután és régimódinak érzem magam. Illetve sajnálom a NAS témát.
Szóval vagy az van, hogy van 1-nél több berendezésed, melyekbe legalább 1db ilyen EEPROM IC van, és azon csinálsz/kérsz valami csatlakozási pontot, amire rádugva az akármilyen programozót feltöltöd a kódot, vagy amikor kell, akkor kiveszed az IC-t a szerkezetből, és a saját által magad készített programozó környezetbe elhelyezve egy gombbal/kattintással felviszed a programodat az eepromba, és visszarakod a gépbe.
Vagy mi a környezet? Annyira nem áll nekem ez össze, hogy milyen környezet van eme probléma/feladat körül.
Őszintén nem kukacoskodni szeretnék, csak érdekel. Az meg hogy mid van, és mi kell a feladat elvégzéséhez, különválasztanám. Nekem is van raspi, amivel tök jól lehet a flashrom-ot használni, arduino mega amivel másik arduino atmel ic-t lehet programozni, meg arduino akármi, ami USB HID eszköznek tudja magát behazudni, ezáltal egy olcsó stream deck-nek tudom használni. Barátságosan azt tanácsolom, ne akarj fából vaskarikát készíteni, mert az baromi sok drága időt elvisz. Szerintem :)
- A hozzászóláshoz be kell jelentkezni
Nincs semmilyen íróm. Amikor kell valamit tesztelni vagy programozni, akkor arra szoktam készíteni egy eszközt, ami ezentúl delegáltan teszi a dolgát. Ezeket vagy ESP vagy arduino vezérli. Ez utóbbi leginkább arduino nano, mert elég sok lába van, elég pici és olcsó.
Ha akarok csinálni egy ilyet, akkor nagyon örülök, ha valaki ugyanebből a megközelítésből már csinált ilyet, figyelve arra, hogy minél kevesebb hardver összerakásával minél többet tudjon. Jelen esetben egy arduino nano, egy IC és egy foglalat összedugdosva elég. Ha ezzel lehet nagy fájlt írni, akkor ez sokaknak segíthet, akiknek nincs céleszköze. Akiknek van, úgyis azzal fogják csinálni.
A sok időt elvisz, az lehet, de hát a hobbikkal már csak így van.
- A hozzászóláshoz be kell jelentkezni
Így már értem. Hobbi és érdeklődés.
Hirtelen keresésből felindulva találtam 2 találatot, sőt, ha jobban összebandzsítom, akkor egyik a másiknak a profibb kivitelezése.
https://forum.arduino.cc/t/arduino-based-parallel-eeprom-programmer/159892
https://github.com/wagiminator/ATmega-EEPROM-Programmer
Sok szerencsét és kitartást kívánok hozzá!
A NAS témához még annyi, hogy te már eldöntötted hogy saját OS és megoldás lesz rajta. Ehhez már neked csak egy HW kell. Azt meg irdatlan sokat találsz. Összeállításnál meg kinézel egy alaplapot, és megnézed milyen proci és memória való bele, esetleg milyen BIOS mit támogat rajta. Menni fog az is :)
- A hozzászóláshoz be kell jelentkezni
Pár éve nekem is ugyanez a setup volt: Arduino és egy megírandó EEPROM.
Nekem ezzel sikerült megírnom/kiolvasnom egy hasonló EEPROM-ot: https://share.fejes.dev/s/eeprom
Kezdetleges, és nem is a te EEPROM-odhoz van hanem AT25256-hoz, de szerintem datasheet alapján át tudod alakítani. Arduino sketch az író/olvasót tartalmazza és utána a python alkalmazás ami az arduino felé serialon küldi az adatot. Fentebb mások is küldtek kódot, azok profibbak, ez viszont nagyon rövid, talán segít kiszürni a lényeget mi az a bare minimum ami ehhez kell.
- A hozzászóláshoz be kell jelentkezni