Helló!
Tenálad ez más, mert nekem 1Mhz-es a szkópom. Alapból 20-szor kisebb memória elég hozzá mint a tiédhez. Lehet hogy megcsinálom, hogy szoftverből lehessen állítani hogy hány Kbájt mintát vegyen.

Most ott állok hogy elvileg működik a konvertált adatok kiküldése a gépre. A konverter precizitásán valahogy még javítani kellene, mert nem vagyok róla meggyőződve hogy olyan nagyon pontos lenne. A bemenő jelet a HE gyűjteményben lévő jelgenerátor programmal állítottam elő hangkártyán keresztül Sokszor váltakozik a jel +-2 bitet. Nem tudom hogy ez a konverter pontatlansága, vagy a tápffesz ingadozik (cerka akksiről megy) vagy a program nem generálja rendesen a jelet.

A PC-s szoftverem az ott tart hogy egy tömbben tárolt értékeket kirajzolja. Igazából a scrollozást nemtudom még hogy fogom megoldani. Lehet hogy a kirajzoló metódusomat valami profibbra kéne cserélni. A sorosport kezelést holnap próbálom megírni hozzá.

A triggerelést még nem oldottam meg. Úgy gondoltam, az AVR komparátorára menne triggerlevel, a másikra meg a bemenő jel. És így interrputot hányna triggerkor amit aztán le tudok kezelni. Az volna igazából a legtutibb, ha a konvertálás után beolvasott adatot az AVR-ben tudnám a beállítot triggerszinttel összehasonlítani, csak erre nincs elég idő ha 1Mhz-el mintavételezek. A mintavételezési frekit 1Mhz-nél szoftverből csinálom, a többinél timer interruptal, azoknál a digitális triggerelés is beférne az interrupt rutinba. Csak sajnos a 1Mhz-nél 16 utasításom van mindent elvégezni, és az kevés. A triggerszintet a PC-ről küldöm a szkópnak sorosporton majd, és ha nem igitális trigger lesz akkor egy D/A átalakító fogja előállítani.

Nah, megoldottam a triggert is. Felfutó lefutó, külső trigger lehetőség. Egy LM358N műveletiből csináltam komparátort, mert az volt itthon. A sávszélességét még nem néztem, de ha kicsi akkor kicserélem egy 10 megás MCP6022-esre. Közben rájöttem hogy 1Mhz-es mintavételhez a 16Mhz-es kristállyal nem 16 utasításom van. Mert van egy csomó ugró meg vizsgáló utasítás ami 2 órajelciklusig tart. Tehát kb 10 utasítás van rá. De szerintem meg van oldva most korrektül. Még csak debuggerrel vizsgálgattam, de majd kitesztelem.

Biztos eszedbe jutott már, de hátha nem. Használhatnál két mikróvezérlőt az egyik csak a memória címzést végezné a másik pedig a trigger fogadást meg minden más funkciót. Két hónapja feltettem ide a fórumba egy egyszerű szkópot. A címzést (16bites) assembly-be írtam meg hozzá. Elég gyors a kód. Nem ismerem az AVR-ket, de gondolom nemsokat kellene módosítanod rajta és tudnád használni.

Köszi, de már megoldottam és szrintem így jó lesz. A címzést számlálóval csinálom, és csak egy órajelimpulzust gell generálnom két utasításból, amivel megvan a címzés. Igazából én is gondolkoztam a két processzoros megoldáson, de akkor azokat nagyon szinkronizálni kéne egymáshoz, hogy a megfelelő pillanatban történjem minden, és mindezt ughye kb 10 utasításban. Most a 10 utasításom úgy néz ki, hogy fel és lefutó órajel a számlálónak, aztán a konverter indítása, trigger vizsgálata, ha trigger volt, akkor 16K mintát kell még venni így 50-50% az elő és utót trigger, ehhez 16 bites számlálás, majd ezután konverter leállítása, és memóriába írás. Ezzel el életileg 1 Mhz a mintavételezés. A trigger meg a komparátorról megy az egyik interrupt bemenetre, tehát fel és lefutó élre is lehet triggerelni. Csak már annyi kábel van hogy mindig valamit szerelni kell rajta mert valami mindig elromlik.

Helló!

Hogy álltok? Én a szkóp digitális részét összeállítottam már a végleges kapcsolásban. A szoftvert kell bele még finomítgatni. A PC-s szoftverem már képes a szkópról jövő adatokat fogadni, és megjeleníteni is. A szkrollozás még nincs kész, meg semmiféle normális kommunikáció nem működik még a gép és a műszer között. Első verzióban meghagyom soros porttal, azán később rakok rá egy FTDI 232-es usb chipet. Csak két madzagot kell átforrasztani majd kb. Ahogy számoltam ez az 1.0 verzió extra alacson költségű lesz. Ha mindent mintaként rendelek amit lehet a maximtól, akkor kb 2000Ft-ból kijön az egész, nyákkal vezetékkel mindennel

Én rosszul. Képtelen vagyok gondolkodni ebben a hőségben. Két hétig nyomozgattam a NET-en hátha találok valami USB komponenst VisualBasic-hez. Találtam is 1XX$-ért. Közben én is rendeltem 1db. FT232BM és 2db. FT245BM-et. Meg is jött. Valószínűleg használni fogom valamire, ha rájövök hogyan tudok hozzáférni a driveréhez basic-ből. Meg PIC18F4550-ből is rendeltem 3db.-ot a szkóphoz. USB kezelés úgyanaz a sztori. Szóval az USB-vel foglakoztam az elmúlt néhány hétben , már amennyire a melegtől tudtam. De ott tartok ahonnan elindultam.

Akkor én könnyítek a gondodon valamennyit, de jól becsüld meg mert ezekért az infókért hónapokig nyálaztam a netet, meg szenvedtem a PIC-el

Az FT232-es az soros port emulációval kezeli az usb-t. Tehát első bedugásnál feltelepítessz egy gyári drivert, és onnantól megjelenik egy új COM port a gépeden, amit utána ugyanúgy tudsz kezelni visual basicből mint egy egyszerű soros portot.
EHUN van leírás róle, meg később is linkelek majd egyet.

FT245-nél kétféle mód van. Én is átnéztem ezt csak már nem emlékszem teljesen. Az egyik az ugyanúgy a jó öreg VCP driver, azaz a virtuális soros port. Ugyanaz a módszer mint a 232-nél. A másik egy úgynevzett D2XX dirver, amivel szabadabb kezet és nagyobb átviteli sebességet tudsz elérni (persze ha a szoftvered bírja a tempót meg a géped). Ez tulajdonképpen egy DLL, amiben deklarálva van egy halom függvény. Ezeket kell hívogatnod a programodból. Az FTDI honlapján van egy programming guide nevő doksi, amiben ezek a függvények le vannak írva, meg azt hiszem pont VB alkalmazási példák vannak. ezen felül a honlapon vannak még példaalkalmazások több nyelvre is komplett forráskód formájában. A hardver maga az meg úgy működik, hogy egy órajelet kell adni neki azt hiszem a küldéshez. ITT van egy jó leírás róla, ami alapján megérted.

A PIC18F4550 ügyében még írom a cikksorozatot. Jelenleg két résszel vagyok meg. Ott az a lényeg hogy ugyanúgy mint az FTDI232-nél egy soros port emulációra van lehetőség. Amit a PIC-ben elég egyszerűen a soros port kezeléshez hasonlóan van C-ben gyárilag megírva. Neked kb két függvényt kell meghívnod és odaadni illetve elvenni tőlük az adatokat. Aztán van az FTDI245-höz hasonlóan egy gyári DLL, amivel gyorsabb sebességet, blokkos adatátvitelt (max 64kb egyszerre) lehet elérni, viszont kicsit más jellegű a felépítése mint a soros port kezelésnek. Vannak mintaprogramok és jó leírások erre, ha odáig jutsz küldök. Vagy esetleg megírom a cikknek ezt a részét is. Kicsit macerás, akadtak gondjaim vele, csak már két hónapja nem vacakoltam ezzel és elfelejtettem mik. A lényeg hogy küldessz egy parancsot a PIC-nek (max 64 bájtos adattömb), amire az egy max 64bájt blokkal is válaszolhat. Harmadik lehetőségnek van egy olyan hogy USB háttértárként látszik a szkópod, ugyanúgy mint egy pendrive. Igazából ezzel még nem foglalkoztam. Itt valamilyen fájl formájában kell az adatot egy memóriában tárolni. Gondolom FAT32 vagy NTSC, ezt nem néztem még át.

Remélem tudtam segíteni. Amúgy honnét rendelted az FTDI chipeket és mennyiért?

Ja a konlúziót majdnem lehagytam.
Tehát ha nem ragaszkodsz az 1Mbájt/sec átviteli sebességhez, akkor a soros port emulációt választod, ami FT232 esetében annyi hogy a mikrokontrollereden a TX és RX lábat nem egy max232-re kötöd, hanem egy FT232-re. VB-hez nem kell komponenes csak simán sorosportot kezelsz.PIC18F4550 esetén annyi, hogy bekötöd a kapcsolás alapján amit elküldtem,az usb-t, majd a gyári C kódba a te rutinjaidat beleírogatod a megfelelő helyre. VB-ben szintés sima soros port kezelés.
FT245 esetén is azt hiszem sima soros port kezelés, csak ott az adat mehet párhuzamosan 8 biten egyből a chip-re. Tehát mondjuk az adatbuszra rákötöd és a memóriából a bájtot egy órajelel útnakindítod.

A többi esetben amikor DLL-t kell használni akkor se kell semmi sb komponens. Csak megnézed egy könyvben hogy kell külső DLL függvényeket használni, vagy a mintapéldákból kilesed.
Egyszóval ne keress usb komponens után mert nincs rá szükség. Ja ez nem egy szó .

Béke

Üdv néktek!
Nekem most sajnos a egyéb elfoglaltságom van, csak keveset tudok vele foglalkozni... (Meszelünk ...)
De jövő héten folytatom, komolyabban tudok vele foglalkozni.
Most egy RS-tárolót akarok úgy átalakítani, hogy ne H->L-re hanem fordítva menjen, és ha mind a kettő bemenet L akkor meg ne kezdjen szórakozni. Meg a kimenetet is ki lehessen kapcsolni kívánságra... Ez lenne a trigger része a szkópnak. Miután majd kész lesz a nyák, akkor meg én is veszek FT232-t és nekiállok delphiben fejleszteni a szoftvert hozzá.

Még a nyáriszünetben be akarom fejezni, mert utána tanulni kell az érettségire

Találtam egy egyszerű hangártyás szkóp programot Delphiben, forráskóddal együtt. Egész jó a kirajzolás megoldása, jóval egyszerűbb mint az enyém és valószinűleg gyorsabb is. Szerintem majd felhasználom. Igaz nincsen benne scrollozás meg ilyenek, csak egy sima sugár kirajzolás, de valmaire jó lesz.

Köszönöm a segítséged. Megnyugtató hogy nem kell komponens az USB-hez. Rengeteg leírást találtam, de eddig elvesztem a részletekben. Sokat segített hogy összefoglaltad a variációkat. Köszi!
Az FT232BM (brutto 1669Ft) és FT245BM (brutto 1763Ft) chippeket a HQVideo-tól vettem. FT8U232BM és FT8U245BM chipeket rendeltem, mert azt írták az van nekik készleten. A számlán is ez szerepel. A chippek meg valójában FT232BM és FT245BM.
Na csá. Megyek, küzdök a VisualBasic könyvvel.

Nem akarlak elkeseríteni, de ITT ezért a pénzért pontosan kétszer ennyi chipet kaptál volna. Méghozzá az újabb RL jelűt. Miért ragaszkodsz a visual basichez? aAgy ahhoz értessz valamennyire? Én Delphi 7-ben írom a programot (kb "Visual Pascal"). Abban tudok segíteni, VB-vel nem volt dolgom. Szerintem amúgy az FT8U meg a sima FT az egykutya.

Nemcsak ezeket rendeltem a HQVideotól.
Delphiben már írtam néhány programot. Főleg adatbázis alkalmazásokat. A VisualBasic nekem még új és éppen ezért álltam neki ebben, mert ezen keresztül szeretnék ismerkedni vele.

Oshon is beújított. A PIC 18 Simulator IDE-ben megjelent az USB kezelés. Példa is található rá. Felteszem a linket is hátha valaki még nem ismeri. itt

Mellékelte a Terminal program basic forrását is. Elkezdtem egy új projectet nyitva felépíteni a programot. A vezérlőket+eseményeket már sikerült kihámoznom de az eljárásokkal nem sikerült dülőre jutnom. HID_Detected szerinted Gory boolean vagy nem. A VisualBasic fodítónak nem tetszik. De miért nem? Mi a fene ez a HID_Detected ? Illetve ha eljárás akkor meg is kell lennie írva valahol.

Az USB eszközök osztályokba vannak sorolva, amikor bedugod valami enumerációval a driver meg a cucc megbeszélik az usb descriptorok segítségével amit kell. (Ezek a descriptorok a PIC usb kódban megtalálhatók, ilyeneket tartalmaznak hogy VendorID, product ID , usb osztály meg hasonlók, a driver ezek alapján tudja hogy te melyik cuccot dugtad be)
Na és ilyen osztály a HID is, ami annyit tesz hogy Human Interface Device. Ez például az ez usb egér vagy billentyűzet. Ezt nem véletlen nem soroltam fel a múltkor a hozzászólásomban, ugyanis szerintem ez nem annyira felel meg a szkóphoz, de rá lehet húzni ha éppen akarja az ember. Leginkább ez a HID kezelés arra hasonlít amikor fentebb említettem a DLL-es dolgot. Itt nem soros porthoz hasonlóan kezeled a bedugott eszközt, hanem úgy hogy küldesssz neki egy max64 bájtos parancsot, amire aztán az max 64 bájtot küld vissza. Annyi a különbség a DLL-el szemben, hogy a windows alapból tartalmazza azt hiszem az ehhez szükséges dolgokat. Sajnos nem emlékszem már pontosan, pedig a PIC témában átnéztem a HID Deivce Class-t is. A PC-nek kell küldenie minden esetben az adatok kérésére egy parancsot ha jól emlékszem a HID -nél is, tehát kvázi master-slave viszony van. (Soros portnál meg a PIC is tud kezdeményezni, és a PC oldalon interrupt szerűen tudod lekezelni, nekem azért tetszik ez a fajta megoldás, mert nem kell pollinggal lekérdezgetni a vezérlőt van-e mondanivalója, hanem küldi amikor van)

A soros port emulációval működő eszközök a CDC osztályba tartoznak, nem a HID-be. Communication Device Class. Szerintem a HID detected dolog az arra utal, hogy amikor bedugod a kütyüt, akkor abban HID descriptornak meg a HID szerinti működésnek kell lennie. Ezt lecsekkolja és ha detektálja akkor true, amúgy meg false. Valószinűnek tartom, hogy a PIC IDE usb-s része csak ezt a HID osztályt tartalmazza, más még nincs kifejlesztve benne.

Ha gondolod küldök egy C-s forrást a pic-be meg soros emulációról szóló cikkemet USB-hez. A forrásba meg bejelölm neked hogy hova írhatod a saját kódrészletet, meg hol a küldés fogadás, meg egy ksi leírást róla, hogy nagyjából eligazodj a kódban. Kell hozzá MPLAB meg C fordító.

Köszi az eddigi segítségedet. És kérlek küldj el mindent az Emailemre amit úgy gondolsz segíthet. Igen a Pic18 Simulator IDE-ben valóban csak a HID van. Az Osho valami HidTerm ActiveX control-t emleget a leírásában. Visszafejtettem egy light verziós programmal a Terminal programját és a Setupapi.dll és HID.dll -re van hivatkozás benne. Még keresgélem a VBfejlesztő környezetbe ezt a HidTerm ActiveX control-t.
Melyik C fordító alatt tudom a forrásodat majd befordítani? Vagy tökmindegy?

Küldtem mindent amim kell. Az egyik üzenetben a soros port emulációt találod, a Másikban a DLL-es témát. Majd kivaálasztod melyiket alkalmazod. Mindkettőnél próbáltam úgy válogatni hogy ha elolvasod meg a forráskódokat megnézed, akkor tisztában leszel mindennel. Ugyanakkor mégse tartson max 1-2 órát átnyálazni. Te vagy a tesztpéldány, majd szólj hogy meg lehet-e érteni ennyiből

Nem értem. Nem kaptam meg amit küldtél.

A vipmail-es címedre küldtem. Ide is felrakom, a modik csak nem veszik a fejemet. Ezeket az infókat tényleg baromi sokáig tartott így összeszednem, szóval másnak is hasznára lehet még.

Kész a szkópom kirajzoló rutinja. Nagyon elégedett vagyok. Tudja a scrollozást is már, a horizontális kicsinyítést, lehet kis lépésben scrollozni, meg képernyőnként is. Lepróbálom egy lasabb gépen is hogy működik-e jól a rajzolás, mert a 3000+-os AMD-n elég szépen elmegy. eleraktam egy olyan "fícsört is", hogy magnetic cursor. Ilyenkor ha ráviszed a kurzort a szkóp képrnyőjére, akkor a jelformán fut végig az egér, így könnyebb a jelszinteket meg az időket mérni, nem kell pozicionálni meg pixeleket vadászni.

Ez tetszik!
Ez tök jó ötlet, majd kipróbálom. Delphiben írod a programod? Mert csak azt kédzeném, hogy hogy nézed meg egy bmp-n (gondolom arra rajzolod) hogy egy pixelen van e valami?

Nem küldesz egy "szkrínshotot" a programról működés közben?
Nagyon kíváncsi vagyok! Még a PC-s szoftverrel sehol sem tartok, csak ötleteket gyűjtök. Az előbbi USB-s mellékletek szerintem nekem is sokat fognak segíteni

Nah itt egy sceenshot.Delphi 7-ben írom. Az egérkurzor nem látszik de kb a második alsó csúcsnál van. A szinuszhullám nem a szkópom jele nem kell megijedni , hanem egy függvénnyel rajzoltam ki tesztelésnek, azért ilyen tökéletes.
A zoomolásnak még nincsenek meg a gombjai, de 2-4-8-16-32-64 -szeresen lehet a maximális nagyításon majd kicsinyíteni horizontálisan. Vertikális nagyításnak szerintem nincs értelme, az nem lesz.

A rajzolás TImage komponens, Canvas-ra megy. amúgy a Pixel[x,y] mondja meg a pixel szinét de én nem használom.

Tetszik. Nagyon dizájn!

A vipmailemre nem érkezett semmi, de jobb is így, mert többen hozzáférnek. Köszi!

Tetszik!
Szép!
Ez már gondolom egy olyan ábra amit a szkóp küldött

Hoppsz!
Mégse!
:lookaround:
Lehet hogy még álmos vagyok? Nemtom hova figyelek....

Haladtam a szoftverrel. Megírtam a szkóp és gép közti kommunikációt. Kész a zoomolás, meg már kiírja az időtengelyre az időpontokat automatikusan mértékegységet váltva. Lehet horizontális és vertikális osztást váltani. Meg egy csík jelzi az adatáttöltés közben hogy hány százaléknál tart.

Eljött az ideje hogy elkezdjem tesztelni a szkópot. Az analóg rész mág nincs meg, de azért már kísérleteztem vele. Sajnos nincsen semmi normális függvény generátorom, így nem tudom normálisan leellenőrizni a jelalakokat. Attól tartok van még hiba benne, mert furcsa alakzatokat kaptam, remélem a jelforrás a hibás.

Annyit mindenesetre már látok, hogy a 32Kb átvitele nem fog 100%-osan hibátlanul menni. Most 115200 baud rate-re van állítva, de a kristály 16Mhz-es így nem pontos hanem 2,1% hiba van benne. Nemtudom hogy ennek köszönhető-e de a 32Kbájt memória 97-99%-a jut át a PC-re. Az adatküldést timerrel csinálom, és 250bájt/másodperc sebességgel. Lehet hogy ha pontosabb baudrate értéket meg lassabb sebességet állítok akkor kevesebb hiba lesz. Hibajavító kódot meg ilyen handshaking jellegű adatellenőrzést nem akarok belerakni, így is kb 2 perc mire átér minden.

Szerintem rakj bele valamilyen olyan értékű kvarcot, amivel 0%-os lesz a hiba.
AZ avr.tavir.hu-n van olyan progi, amivel ki lehet kísérletezni a kvarc értékét az átviteli sebességhez.
Pontosan ITT

Az AVRCALC menüpont alatt keresd