Egy kérésem lenne. A kapcsolási rajzot mondjuk pdf-ben vagy valamilyen képformátumban nem lehetne feltölteni ide? Már vagy 5 órát szenvedtem ezzel a progival, de sajnos csak win7-es gépek vannak a közelemben, azokon beüzemelni sem nagyon lehet. Előre is köszönöm!

A ZIP file-okba betettem a PDF-be konvertált rajzokat.
A Scope_proba_SCH.zip file-ba is megtalálhatóak PDF -ben a rajzok.
Remélem így már többre mész vele.

A Spartan3 rajzán az FPGA táp lábak és a rajta lévő hidegítő kondenzátorok nincsenek berajzolva.
Rohadt sok van belőle és lusta voltam lerajzolni, de ha letöltöd a kész panelről a képeket,
akkor azon jól láthatóak közvetlenül a chip alatt a forrasztási oldalon.
A képeken az is látszik, hogy nem egyforma mindegyik. Ahol lehetett 2-2db lett párhuzamosan kötve, 100nF és 1uF. A chip kivezetéséhez közelebb lévő a 100nF-os.

Köszönöm én is a rajokat. A Tango-val én sem jutottam semmire, hiába futott XP alatt.

Köszönöm szépen!

Nagyon szívesen.



Fura, mert XP-n nekem több gépen és laptopon is tökéletesen fut.
Win7 alatt nem próbáltam, mert azt nem használok.

Nagyon szívesen.

Tudna valaki segíteni? Jelanalizátort készítek (mondjuk hogy pc-szkóp ), és a megjelenítésével van bajom. Visual studio-ban készülget a programja c++ -ban, de a soros port kezelés számomra kicsit mágikus dolog.
Összefoglalva: Van 64K statikus ram, amit egy számlálólánc töltöget fel adatokkal. Miután ez megvolt, egy mega8 kiolvassa őket, és átküldi a pc-nek soros porton. Az áramkör kifogástalanul működik, terminállal teszteltem.
Namost karakterláncokat tudok küldeni fogadni (parancsok), de egyben 64K blokkot már nem. A soros port puffere 4096 byte-ot fogad, nekem meg kicsit azért több kellene. Igazából a tudatlanságommal kellene kezdeni valamit, ezért kérem, hogy akinek van valami forráskód részlete ami ezt a problémát orvosolja, az ossza meg velem!
A windóz programozásában nem kívánok nagyon mélyen elmerülni, csak amennyire feltétlenül szükséges. Ti hogyan oldjátok meg az adatok átvételét???
Üdv!

Én sajnos nem beszélni C++.

És VB? Úgy tudom azt beszéled! Én olvasni talán kicsit Bánja kánya, felteszem a környezetet hozzá ha abban lesz megoldás..

Délután átküldöm neked a VB6 forrásom. Ami nálam 9600baud átviteli sebesség mellett működött vele az sajnos 115200baud mellett már csak hibákkal megy. Nem mindig ér át minden adat. Májusban el kezdtem átírni VB.NET-re. A sorosport kezelésig már nem jutottam el. A DirectX9 programozásnál elakadtam június környékén. Azóta minden mással foglalkoztam csak a scope projectel nem.
Számomra teljesen új volt a Lazarus (freeware Object Pascal) fejlesztő környezet létezése. Van hozzá soros port kezelő komponens. Szerintem ígéretes lehetőség fejlesztésre.

Csendben megsúgom Nektek, hogy RTS/CTS-alapú (hardver) flow controlt kéne használnotok, és akkor nem volnának olyan gondok, hogy X sebesség/Y byte felett elvesznek az adatok... Ehhez persze kell két plusz vezeték a mikrokontroller oldalán, meg a szoftverét is úgy kell megírni.

MCP2200-on keresztül (UART-USB) átalakítón keresztül használom a soros átvitelt. Kösz a tippet körüljárom ezt a lehetőséget is.

Ti hogyan oldjátok meg azt, hogy a beérkező sok sok adatból csak egy ilyen "zoom-all" összképet mutasson?
A megjelenítőm vízszintes felbontása 800 pixel, az adatok száma 65536. Első blikkre azt gondoltam, hogy csak minden (65536/800= ) 82 adatot teszek ki, és akkor majd az nekem jó lesz. Hát nem lett az. Szépen eltorzult az egész, gondolom az aliasing jelenség miatt. A tárolós, vagy lcd szkópoknál hogyan oldják ezt meg? Ha csak pixelként jelenítem meg az adatot, az már korrektebb, de az meg értékelhetetlenül néz ki. Kinek milyen tapasztalata van ezügyben?

Ha nekem kéne ilyet csinálni: ha egy függőleges oszlopra jut 82 adat, akkor azokra minimumot és maximumot kéne számolni, és a minimum és a maximum érték közé egy függőleges csíkot rajzolni (hiszen abban az időintervallumban a jel megjárta azt az értéktartományt). Ezen felül az egymás után jövő oszlopok közé egyenes vonalat kéne rajzolni, hogy folytonos legyen a rajzolat. Az egyenes vonalak kezdőpontja az előző oszlophoz tartozó utolsó érték, a végpontja a következő oszlophoz tartozó első érték.

Képet kérhetnék. Csak holnap tudom megnézni. Mára befejeztem a netezést.

Pontatlan voltam, bocsi!
Ez egy logikai analizátor lesz, ezért a kijelzendő érték vagy 0, vagy 1. Időben egymás után megjelenítem, és ebből van nyolc darab a nyolc csatornára (ez most ugye nem fontos).
Ha pontosan ugyanannyi adatom lenne, mint ahány képpontos a képernyőm, akkor semmi gond, minden egyes pixel egy hasznos adatot jelent. Ha zoom-in, vagyis nagyítást alkalmazok, akkor két szomszédos érték között húzok egy összekötő vízszintes vonalat, és ha a mostani nem ugyanaz mint az előző, akkor egy függőlegest is. Itt nincs adatvesztés. Eddig jó. (Ez volt _vl_ megoldása is)
De ha másik irányban (zoom-out) kicsinyítek, akkor az értékek sűrűbben lesznek a mint a megjelenítő pixelek, tehát adatvesztés lép fel. Ha két pixel között megváltozik a jel (márpedig miért ne változna), akkor teljesen eltorzulhat az egész.

Van-e erre valami bevált módszer, vagy legalább valami irodalom, ahol utána nézhetnék?

Nem jó irányból közelítesz. Egy pixelhez nem egy érték tartozik (ami miatt a pixelek közötti "üres" részre is jutnának értékek), hanem minden értékhez tartozik pixel, legfeljebb egy pixelre több, egymást követő időpontbeli érték is jut.

Ez rendben is van!
Máshol van a gond. Analóg jelnél a jelváltozási sebesség ideje véges. Amikor nézed a jelet, akkor szép lankás. Ha ezt most elkezded távolítani (zoom-out), akkor ahogy nyomod össze a jelet vízszintesen kicsit torzul ugyan, de felismerhető marad. Ha a mintavett adatokat nézzük, akkor ezt úgy képzelem el, hogy csak minden második, minden ötödik adatot jeleníted meg, így olyan mintha összenyomnád. Analóg jelnél ez működik is.
Nekem viszont digitális jelem van, ahol a jelváltozás kvázi végtelen gyors. Ha elkezdem minden második, ötödik, stb adatot átlépni, akkor a jelváltások tetemes része elvész.
Csináltam két képet, hogy mire gondolok. Mindkettő kép ugyanazt ábrázolja (számlálás 0..65535-ig), csak az egyik 1:1-ben, a másik pedig teljes kép módban. Látható, hogy az elsőnél szépen felismerhető, a második pedig nem is hasonlít rá. Na erre kellene megoldás, hogy legalább egy kicsit hasonlítson a valódi jelsorozatra.

A Shannon-Nyquist tétel értelmén gondolkozzál el, aztán rájössz, hogy ez az egész miért értelmetlen. Jelen esetben a "minden x. adatot jeleníted meg" megoldás addig működik, amíg a "minden x. adat" teljesíti a Shannon-kritériumot, azaz az ábrázolandó jel legmagasabb frekvenciájú komponensénél legalább 2x sűrűbben veszed a mintákat (tehát minden ciklusból minimum 2 mintát kell venned). Ha ezt nem tudod teljesíteni, akkor esélyed sincs arra, hogy az ábrázolt "valami" hasonlítson az eredetire, ez elméletileg is kizárt. Már a Shannon-kritériumhoz közelítve is mindenféle nemkívánatos jelenségeid lesznek.
Az, hogy digitális a jeled, nem sokat változtat ezen.

A kérdés ott fogalmazódik meg, hogy mit csináljon az ember, ha alacsonyabbra kell venni a mintavételt, mivel a kezelő kizoomolt. Ebben az esetben lehet tudni, hogy az ábrázolás nem képes visszaadni az eredeti jelet, a kérdés viszont az, hogy hogyan ábrázoljuk, hogy mégse vezessük félre a nézőt. Erre mondtam azt, hogy ne az x. mintákat ábrázoljuk (mert ez hamis, az eredeti jelben nem létező frekvenciájú jeleket fog mutatni = aliasing jelenség), hanem helyette jelenítsük meg azt, hogy a jel sűrűbben változik, mint amit a képernyő meg tudna mutatni.

Másodikra már megértettem, hogy a megjelenítéskor szintén a Shannon féle megközelítés él. Igazad van.

Tekintsünk el a fizikai megvalósítástól, nézzük csak a pc oldalt! Tegyük fel, hogy van egy data_buffer[65536] nevű tömböm, ami fel van töltve 0..65535 értékekkel!
Ezt a 64K adatot kellene megjeleníteni 800 képponton úgy, hogy legalább kicsit hasonlítson a valódira.

Nem. Te azt szeretnéd, hogy az ábra, amit kirajzoltál (ami a műszaki adottságai miatt diszkrét-idejű, hiszen pixelek vannak a képernyőn), emberi szemmel nézve "hasonlítson" az eredeti jelre. Ez nem másnak a megfogalmazása, mint hogy a diszkrét-idejű jelből (a kirajzolt képpontokból) lehessen helyreállítani az eredeti jelet - a Shannon-Nyquist tétel pontosan erre fogalmaz meg egy szükséges feltételt: a kvantálási frekvenciának (a kirajzolt pontok sűrűségének) egy minimumot el kell érnie. Ha ezt a feltételt nem teljesíted, akkor lehetetlent kívánsz, amikor azt várod, hogy az ábra "hasonlítson" az eredeti jelre. Egész egyszerűen nem tud. Erre írtam, hogy ilyen esetben már csak kármentés tud lenni, azaz azon már túl vagyunk, hogy az eredeti jelre nem fog hasonlítani az ábra, már csak annyit volna érdemes elérni, hogy ne olyasmi legyen az ábrán, aminek még köze sincs az eredeti jelhez.

Ezt úgy érdemes megoldani, hogy a 65536/800 = ~82 egymás után olvasott adatból gyúrunk egy oszlopot.

Már beláttam az igazad, csak közben még szerkesztettem.
Arra gondoltam, hogy erre lehet egy áthidaló megoldás, ha a szomszédos adatokból egy átlagot képezek, és ez az átlag fog majd szerepelni pixelként. Egyenlőre még matekozok rajta, hogy miként számoljak, de az elgondolásom ez:
Az emberi szem felbontása is véges. Ha közelről nézek valamit, akkor az szép részletes, de ahogy távolodok tőle, úgy az egyes részletek kezdenek összemosódni. Mivel a szem felbontása nem lesz nagyobb, így nyilvánvalóan valamiféle átlagolás történik, elvégre attól, hogy a részletek elvesznek, még kb értékelhető marad a látvány. Na ezt fogom modellezni. Először számtani átlagolással, mozgó átlaggal, aztán logaritmikusan is kipróbálom.

Valószínűleg ezzel az átlagolós dologgal menni fog, most azzal kísérletezek, hogy mekkora legyen egy "ablak", amin átlagot számolok.
De most tényleg! A nagyok ezt hogy oldják meg? Vannak lcd-s analilzátorok, azok milyen eljárást használnak erre?

Pl Gauss szűréssel. Itt van egy SRTM_HUN nevű, nyílt forrású program, ami bár GPS koordinátákra szakosodott, de elég jó grafikonokat rajzol. Eredetileg azért íródott, hogy magassági szintprofilt rajzoljon GPS-el rögzített nyomvonal alapján, ha pedig nincs magassági adat, akkor egy nyilvános NASA adatbázisból veszi a magasságot. Ha írsz a fejlesztőnek, biztosan segít, hogy oldotta meg a grafikont. Sokat tárgyaltuk annak idején (évekkel ezelőtt) a fórumon a működését, de én már nem emlékszem rá. Érdemes elolvasni a mellékelt szuro_help.html fájlt is, mert elmagyarázza a lényegét. Remélem segítettem.

Ha jól látom, akkor ebből ennyi a lényeg ugye? Nekem a tömb elemei 0 és 1 egész számok, viszont az előfordulásuk gyakorisága rapszódikus. Ezt vajon kezelni tudja ez az eljárás?

Passzolom. Nem ismerem ilyen szinten a Gauss-t. Csak eszembe jutott a GAUSS kulcsszó, meg hogy ezzel alakítgatta jekaeff fórumtárs a grafikonját. Elég komolyan utánanézett, hogy a "nagyok hogyan csinálják". Emlékeim szerint inkább a sugár kitalálásában, és hasonlókban segédkeztem. Na meg mindenféle lehetetlen hihetetlen, de valós adatot tartalmazó nyomvonalat biztosítottam, és azon teszteltem, hogy mennyire torzítja el.

Akkor ez szerintem nem az én játékom lesz, mert nekem nem grafikonom van, csak egyeseim, meg nulláim. Azért köszi, nyomom tovább

A 0/1 értékű függvényedre a világ legegyszerűbb dolga grafikont rajzolni.

Felosztod 800 részre az adataidat, minden oszlophoz fog tartozni ugye 65536/800 db. Veszed az adott oszlophoz tartozó ~82 értéket, veszed az ezek előtt levő utolsót (ami még az előző oszlophoz tartozik), meg az ezek után következő elsőt (ami már a következő oszlophoz tartozik). Ha a ~84 db érték közül az összes 0, akkor alulra (a 0-ás értékhez) teszel egy pixelt abba az oszlopba, ha az összes 1, akkor felülre (az 1-es értékhez) teszel egy pixelt, bármilyen más esetben (ha mind 0, mind 1 szerepel vegyesen) pedig húzol egy függőleges vonalat a 0-ás értéktől az 1-es értékig.

Na, ez a világ legegyszerűbb dolga volt az, ami megfogta a burámat! Ez lesz a jó, köszönöm szépen!

Megcsináltam a fenti algoritmussal, és úgy tűnik teljesen jó lett! Mellékelem az eredményt. Azok a hézagok azért vannak a második ábrán, hogy valóban hasonlít-e a kapott kép a valódi adatokhoz (5000 adatonként ugrik egyet a kihagyás). Annyit kellett még korrigálni, hogy ha az aktuális pixelen nem ugyanaz az állapot (magas/alacsony) mint az előző, akkor is húzni kell egy vonalat. Ellenkező esetben előfordul, hogy megszakad a jel, és a másik állapotban folytatódik.
Köszönöm a segítséget!