o tai nebus, kad ignoruoja septintą bitą ir skaito vėl nuo pradžių? On 8/5/2019 7:16 PM, Shadowed wrote: > Nu kaip ir ejs komentare rašiau, sprendžiant pagal datasheetą, gaunasi > kad turėtų būt 64, tai galinės celės adresas būtų 003F. Bet mano > programatorius (senukas TOP2048) rašo ir po to nuskaito duomenis iš 006X > ir 007X adresų. Ir kas įdomiausia, tas EPROMas gyvena devaisiuke su > prociuku, kuris susirašo sau reikalingus atsiminimui duomenis. Ir > panašu, kad jis rašo į adresus virš 0030. Taip galvoju, nes kai visiškai > ištrinu EPROMą ir nuskaitau, jis būna pilnas FF, pajungiu devaisiuką ir > po kiek laiko pažiūriu kas prirašyta - nu yra duomenys ten, kur jų pagal > adresavimo galimybes negali būti. Dėl to ir pasimečiau, nesuprantu kas > čia per monai. Ar gali būti, kad duomenys virš 003F yra kokie tai > parazitiniai, atsirandantys dėl bandymo nuskaityti neteisingus adresus? > Bet duomenys įsirašo su programatorium ir nuskaitomi normaliai. Blin, > pabandysiu ryt dar ant Arduino pasirašyt greitai programikę, nuskaityt > teisingą adresų sritį nuo 0000 iki 003F ir pažiūrėsiu ar sutampa > duomenys. Bet šiaip ar taip - manau, programatorius turėtų irgi veikti > teisingai. > > "Dainiushas" parašė naujienų news:qi9e9h$aeb$1@trimpas.omnitel.net... > > tai jis ne 64 adresus turi? Kas ir yra 6 bitai. > > On 8/5/2019 5:16 PM, Shadowed wrote: >> Turiu pažaidimui keletą 93C46B epromiukų, pagal aprašymą 1Kbitas, 64 x >> 16 bitų organizacija. Kaip ir viskas OK, su programatorium nuskaitau >> ir turiu tokius adresus: >> 0000 >> 0010 >> 0020 >> 0030 >> 0040 >> 0050 >> 0060 >> 0070 >> ir tada po šešiolika FF prie kiekvieno, tai taip suprantu adresas >> kiekvienos celės gaunasi, pavyzdžiui su trečia eilute 002X, kur X gali >> būti nuo 0 iki F, šešiolika reikšmių. Paskutinės celės adresas būtų >> 007F Man kas nesuprantama - aprašyme duota, kad: >> image >> Adresui skirta tik tik 6 bitai, tai jeigu būtų 111 111 tai Hexu >> gaunasi tik 3F, tai tik pusė visos atminties gali užadresuoti... Tai >> kaip jis toliau pasiekia ? >