A kérdés tömören: egy kb 40 éves működő számítógépnek az órajele mennyire változhat környezeti hatásokra?
Részletesebben: van egy PRIMO számítógépem, amire írtam egy időkritikus programot, ami kívülről érkező jeleket dolgoz fel. A program jól és stabilan működött, több gépen is. Majd pár hónapra félretettem, és amikor újra elővettem, már hibásan működött ugyanaz a kód, mindegyik gépen. A hiba megoldása az volt, hogy 2 db NOP utasítással kb 3us-mal lelassítottam a kódot. Azóta megint rendben fut mindegyik gépen.
Tudom, hogy több oka is lehet a hibának, ezért először a hardveres okot szeretném megérteni vagy kizárni.
Lehetséges, hogy egy ilyen régi, de működő gép órajelének valamilyen külső hatás eredményeként ilyen érezhető sebességváltozása legyen? Mivel a hőmérséklet 2-3 fokos tartományon belül kb azonos volt minden esetben, és a tápegység nem a gépbe van építve, ezért leginkább páratartalomváltozásra gondolnék.
Innentől azonban az okosabbak véleményét várnám. Kizárható a hardveres ok, és valami más áll a háttérben, vagy egy ilyen gép sebessége ennyire nem stabil, és ez a későbbiekben is változhat?
Hozzászólások
15MHz-es kvarcoszcillátor van benne, biztos változhat, de olyan sokat azért nem. 2 NOP az 8 órajelciklus.
Egyéb jelek azért csúszkálhatnak egymáshoz képest ide-oda a hőmérséklet függvényében, ZX Spectrumnál pl. az ULA által generált INT-et melegen van úgy, hogy egy ciklussal később "veszi észre" a processzor (kifut a setup timeból). Primonál nem tudom, vannak-e ilyenek.
A ZX spectrumnál az ULA még le is állítja olykor a CPU órajelét, ezzel orvosolva a DMA hiányát. Szerencsére ez a PRIMO esetében nincs. De a PRIMO-nál is lehet konfliktus a VIDEO és a CPU között közös memóriaelérés esetén.
Engem azonban most az a része érdekel, hogy mennyire stabil maga az alap órajel, változhat-e érdemben külső hatásokra?
De ez az órajel leállítás teljesen determinisztikus, reprodukálható. Akár bele is lehet számolni egy időzítésbe, bár ehelyett inkább a felső 32k-ban szokás időzítés-kritikus kódot futtatni.
A Primo órajelgenerátora egy kvarc-oszcillátoros megoldás, amiből 12 egy tucat, a CPU ennek leosztásával kapja az órajelet, ez hogyan tudna változni? Elöregedett a kristály? Nem hiszem, hogy ezzel van a baj. De Meg kell mérni, mennyire stabil, és akkor kiderül.
A kód stabilan fut, hosszan és sokszor, így nem bizonytalanságra gondolok. Ami az én szembe jutott, hogy talán az elöregedett kondenzátorok reagálnak a levegő páratartalmára. Bár, a kvarchoz nem elektrolit kondenzátor tartozik.
Amúgy nekem az a válasz is tökéletesen megfelel, hogy ezek elég stabil áramkörök, és nem hatnak rájuk érdemben ilyen külső körülmények, keressem máshol a hiba okát. Én azonban ennyire nem értek az elektronikához, hogy ezt magamtól bizonyosan merjem állítani.
Nem csak az elektrolit kondi öregszik. Amennyire tudom, a kvarckristályok szobahőmérséklet környékén nem változtatják a rezgésszámukat néhány fokos hőingadozás miatt, így inkább a kvarc körüli áramköri elemek okozhatják a problémát.
Oxidáció nincs a panelen? (Bottom oldalt is megnézném...)
Mindkettőn ugyanúgy? Bár ezt a kondenzátorra is kérdezhetném... Szemre jónak tűnnek. És menni stabilan mennek, csak a pár hónap szünet alatt történhetett valami általam fel nem fogható.
A ZX spectrumnál az ULA még le is állítja olykor a CPU órajelét, ezzel orvosolva a DMA hiányát.
Ezek erdekes megoldasok. Most pont az elmult hetekben, FPGA-s soft CPU-k kapcsan nezegettuk egy kollegaval azt a temat hogy rendes szinkron "wait cycle" helyett effele orajel lelassitassal (es/vagy egy oraciklus kihagyasaval) varja be a CPU ha valami kulso eszkoz nem elerheto es/vagy arbitration jellegu dolog merulne fel. Aztan az lett a konkluzio hogy ezek (pl wired OR/AND bemenetek a CLK-ra, meg hasonlo trukkok) meg egy alapesetben jol szimulalhato FPGA-s rendszerben is, hat, nem epp a legstabilabbak. Szoval ha hardveresen van osszedrotozva, akkor tenyleg nem kizart hogy idovel valami annyira kiesik a szinkronbol hogy instabilla valik az egesz. Nyilvan ehhez jobban ismerni kellene azt hogy konkretan _mit_ is jelent ez a "megallitjuk az orajelet" megoldas, lehetnek-e a clock-ban valamifele tuskek, vagy van-e valami szekvencialis kozbelso halozat, vagy igy hogy megy az egesz...
Szerencsére ez a PRIMO esetében nincs. De a PRIMO-nál is lehet konfliktus a VIDEO és a CPU között közös memóriaelérés esetén.
Igen, ekkor az a kerdes hogy ki nyeri a versenyt. Ha az arbitrer azt mondja hogy a video nyer, akkor a CPU-ba kell wait cycle (van?), ha CPU nyer, akkor a video mit csinal addig? Ha meg mindketto nyer, akkor valami buszt, 2en is meghajtanak egyszerre, az meg nem jo az almoskonyv szerint.
Na, kiolvastam a hardver leírásból, mit csinál ütközés esetén. Megpróbálja mindig a CPU-nak adni a prioritást, de ha a CPU memóriakérelme akkor érkezik, amikor éppen kiszolgálás alatt van a videógenerátor kérelme, akkor 200ns és 600ns közötti ideig várakoztathatja a CPU-t.
Ennek ellenére nem hiszem, hogy a jelenség ebből az ütközésből fakad. 2 hónapja órákig futott úgy a program, hogy nem volt ütközés egyik gépen sem - vagyis nem zavarta a kód futását -, aztán két hónap múlva folyamatos ütközések lennének rögtön az elejétől, mindkét gépnél, mindig? ... Nem életszerű.
Ennek ellenére nem hiszem, hogy a jelenség ebből az ütközésből fakad. 2 hónapja órákig futott úgy a program, hogy nem volt ütközés egyik gépen sem
Persze, ez nekem is furcsa. Csak azt mondom hogy ez a "clock-megvonassal varakoztassunk full szinkron/szekvencialis logikat" megoldasoknal lehetnek olyan meglepetesek, amikre nehez elore felkeszulni.
mindkét gépnél, mindig? ... Nem életszerű
Azert `tkdiff`-fel hasonlitsd ossze a ~2 honappal ezelotti meg a mostani programkododat :) Hatha kibukik valami hogy "ah, erre nem is gondoltam hogy okozhat ilyen nyigot" :)
Légnyomás esetleg?
" kívülről érkező jeleket dolgoz fel. "
"jelváltozása az időjárás függvényében"
?
"Normális ember már nem kommentel sehol." (c) Poli
A kívülről jövő jel egy fix wav fájl. Mindig ugyanaz, nem változik.
Én biztos sztrájkolni kezdenék, ha mindig ugyanazt a wav file-t kéne feldolgoznom. :)
Nem gondoltál rá, hogy a feldolgozás eredményét elmentsd, és legközelebb csak elővedd, mindenféle fölösleges feldolgozás helyett?
"Normális ember már nem kommentel sehol." (c) Poli
Ez mit jelent pontosan? Lejátszod valamivel? Nem lehet itt van a kutya elásva? A két gépben ez a közös pont.
Szerintem az időközben megnőtt infláció az oka 😉
És ne feledjük, közben a dátum is változott.
"Normális ember már nem kommentel sehol." (c) Poli
meg az óra is átállt
Ha a kvarc rezeg, akkor aztán rezeg. Attól kvarc, hogy stabil a rezgésszáma. Én máshol keresném a hiba okát.
Van ugyan a kvarcnak hőfokfüggése, de ppm/°C nagyságrendű, elhanyagolható.
kivéve amelyik azt szereti, ha fogják
https://www.youtube.com/watch?v=ASouxxQyABk
Gondolom, valami soft modemet csináltál. Ahhoz még a mikrokontrollerek belső RC oszcillátora is megfelelő, a kvarcok frekvenciájának változása elenyésző, nem itt keresném a hibát. Akkor sem, ha mondjuk a mellette lévő 22 pF-os kondenzátor kapacitása 21.87 pF-ra csökkent, mert nam tudja jelentősen elhúzni a kvarc frekvenciáját.
Vagy a video/CPU versenyhelyzet problémájába futottál bele, vagy valami megszakítás, efféle. Ahhoz kevés az infó, hogy abból ezt meg lehessen sejteni.
A két NOP az rengeteg idő, mert ez nyilván nem óránként két NOP, hanem néhány 10 vagy 100 µs-onként, s ott arányokat nézve elég jelentősnek tűnik.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Igen, jól látod, a 2 NOP szerintem is rengeteg idő. Kb 100us-onként hajtódnak végre.
A másik ötletem nekem is a video/CPU lenne, de előtte a hardver problémát akartam kizárni vagy megérteni.
Valószínűleg volt egy programmódosítás, amiről elfeledkeztél.
A konkrét program egy gyorstöltő. A PRIMO eredeti sebesség 800bps. Ez a program 8000bps sebességgel tud betölteni. Ehhez azonban először a betöltő kódot kell normál sebességgel betöltenie. Így a wav fájl tartalmazza magát a kódot is. A legenerált wav fájlok két hónapja még betöltődtek, most már nem. A betöltő kód nem változott, mivel belevolt gyógyítva a wavba.
A legéletszerűbb ötletnek nekem eddig az tűnt, hogy a bemenő jel sebessége változott meg, de a wav fájlt egy laptop játsza le, aminek még kisebb az esélye, hogy változzon a sebessége.
> a wav fájlt egy laptop játsza le, aminek még kisebb az esélye, hogy változzon a sebessége
Na ezt miből gondolod?
Ez pusztán előítélet. Nem vagyok hardverben annyira jártas, hogy ezt állítsam, de azt gondoltam, egy modern hangkártya azért ugyanazt a wavot ugyanúgy játsza le 2 hónap elteltével is.
Igazából érdekelne, hogy mi ez a projekt ...
A github-on primoutils néven vannak fenn az alakulófélben lévő primo eszközeim. Ezek közt van a jelenleg vizsgált slideshow. Arra képes, hogy megadsz egy csomó gif fájlt, összefűzi egy wav fájlba, az elejére beteszi a loadert, majd a PRIMO-n a LOAD paranccsal tölthető. Betölti a loadert, az pedig a wav-ból érkező képernyőképeket nyomja ki a képernyőre 6másodperc/képernyő sebességgel. Ráadásul, hogy legyen idő megnézni a képet, minden képet kétszer teszek bele a wav fájlba, így a második betöltődése csak várakozásnak tűnik.
Azonban, ha akár csak egyetlen bit hiba is van, az azonnal meglátszik a képeken. A jelenlegi teszt slideshowm 17 perces, és hiba nélkül megy végig. De azért eléggé bosszantó, hogy két hónapja ugyanez a teszt slideshow két NOP nélkül ment végig hibamentesen.
Zenélős játékokban amúgy mit használnak frekvenciaalapnak?
Van egy Fishcer Price zenélő játék, amiben ha merül az elem kezd belassulni a lejátszás, mint egy merülő kazettás magnónál. Azt gondoltam, hogy digitális lejátszóknál ilyen nem lehetséges, de ezek szerint mégis, azt meg nem gondolnám, hogy egy magnó van benne :D
Lehet szimpla RC oszcillátor az olcsóság jegyében.
Ha a tápot egy (jobb) UPS-re kötöd, akkor is produkálja ezt?
Igen, próbáltam a tápcserét is. Most saját tápról megy, de PC tápról is teszteltem, az elég stabil szerintem, de ugyanaz volt a jelenség. Drótot is cseréltem, hátha a kábel zajos, az sem segített.