Sok mindent leírtál, szerintem nem hangsúlyoztad eléggé. Egyből high speed FTDI, linuxos ARM etc. Úgy éreztem, hogy nem árt kihangsúlyozni.
Az MPLAB-X problémádnál meg az elérési útvonalak hiányoznak.

Sziasztok, lenne egy valószínű nagyon alap kérdésem, de nem találtam meg hol van leírva.
PIC ek után vannak ilyen adatok hogy I/P E/P I/SN
Azt kikövetkeztettem hogy a / utáni karakter/karakterek a PIC lábaira utal, de az I E micsoda? Valahol le van ez írva? Előre is köszönöm.

Szia,

I - industrial, E - extended, C commercial

módosítás/pontosítás: a hőmérséklettartomány szempontjából különböznek ezek a processzorok. Itt a negyedik oldalon látható, mi micsoda.

István

A problémád két külön eset - illetve 3.

Az egyik, a sebesség. Mint fentebb El_Pinyo is rávilágított, nem pont úgy használod felső szintről az usb-t, ahogyan azt kellene. A mai számítógépek mindegyikén több giga rammal már rég nem a commodore 16-osok világát éljük. Nem 1 byteonként kellene vacakolni az adattal. Ha valahol szét is kapod byteokra, kötegelve - minimum 16k darabokban - kellene feldolgozni. Az alá bemenni már nagyon nem jó ötlet. És a file kimeneti bufferjét is állítsd legalább 100 mega byteosra. A bulk transfer az teljesen jó erre a célra, de bulknak kellene használni azt a bulkot, és nem controlnak. Nagy méretű, zsírosan megtömött fifo bufferek kellenek. Gondolj rá úgy, mint egy CD / DVD írásra. Megy a folyamat fél óráig, és ha egyszer is el tud fogyni a buffered közben, kukába dobhatod a cuccot, mert csak szemetet gyártottál. Nem fogyhat el a buffered a folyamat alatt.

A másik sebesség problémád usb kliens oldalon fog jelentkezni. Te 6 külön csatornába szét akarod dobni az adatot, mégpedig elég nagy össz sebességgel (4 megabit / sec) egy 8 bites pichez képest úgy, hogy mellette fut az usb stacked is. Milyen dac-okat terveztél a 4550 mellé? Bírhatja ugyan, de adatbufferelés fog neked kelleni mindegyik dac oldalán is egy jó 128 byte. Ha aszinkronban jó a 6 csatorna, inkább 6 külön készülék és usb hub a számítógépen, ha meg szinkronban kell, rá kellene kötnöd másik 6 pic-et arra a központira spi slave-ként, és mondjuk ellenállás létrázni. A memóriabufferes dac-ok sem lesznek olcsóbbak.

Az usb-ről külön oktatás valószínűleg nem fog kelleni, ha az mc stacket fel tudod használni. A számítógép oldalán végpontod van, a pic oldalán szintén végpontod lesz, nem sokat kell tudnod a kettő közötti dolgokról. Én végig nyaltam kettő jan axelson könyvet, plussz egy átfogó web doksit is, és nem vagyok előrébb vele. Egyébként angolul van minden. Én magyar usb doksit még nem láttam. Olyan tempóban változnak dolgok, hogy ha a mai világban le is fordítanak bármit, az addigra elavult.

Egyesével kikeresgéltem browserrel az összes .c meg .h file-t (jobb klikk add existing item..), eredmény semmi. Kiböki a szemét, de akkor sem találja meg. Furcsán nézek én erre az mplabx-re.

File menü/Project Properties A felugró dialógusablakban bal oldalon ráböksz pl. az xc32-gcc nevű elemre (attól függ milyen C fordítót használsz), majd a jobb oldalon megjelenő legördítő listát legalulra gördíted (a felül levő combobox legyen General-ra állítva), ahol az áll, hogy Include directories, majd ráböksz a ... felíratú gombra, és betallózod az összes .h állományod könyvtárát. A .c fájlokat mindenképpen hozzá kell adni a projekthez. Ha esetleg így sem működik, akkor passz.

Max 506A-t ismerem, s használtam erre a célra, csak nyomtató porton keresztül. Mivel a mai gépekben nincs már ilyen port, ezért lenne jó az USB. De az csak 4 csatornás. Nem találtam még ki, mit kellene alkalmazni, de mindenképp tárolósnak kell lennie. Asszinkronban jó.
A gép real time-ban játsza a lézershow-t, ha nagy puffereket rakok be, akkor csúszni fog az adat, az nem jó. Főleg hogyha zenével összhangban kell lennie.

Az usb nem csak emiatt érdekel, hanem amúgy is, nem ez az egyetlen eszköz, amit usb-re terveznék. Csak szeretem tudni mi folyik a háttérben pontosabban, nem érzem eléggé az enyémnek azt az alkotást, amiben felhasználok egy microchip által megírt kódot. Legalább lássam át rendesen, s ha kell tudjak belenyúlni, annyira jó volna megismerni. PC oldalon is tanulok programozni, arról az oldalról is érdekel. Jó volna, ha tudnék saját usb-s eszközt készíteni, saját driverral. Tudom, hogy nem egyszerű dolog, de hasznosnak gondolom.

Oké, a magas szintű libeket így már végig megtalálja. Viszont a teljes alacsonyabb szintű header support teljesen vak. Ilyen dolgokat nem talál meg, mint "TRISB" és társai. Komolyan végig kell vele vakarnom a gcc teljes include állományát? A windows explorer szerint 104 mappa. Egy friss projectnél ezt mind egyesével.. ?

A max506 tartalmilag egy latch regiszter + ellenállás létra. Nem vagy vele előrébb, mint a semmivel. Kell majd neked egy külön pic mindegyik csatornához. Lehetnek azok is 4550-esek, és úgy csak egy féle picet kell használnod.

Azt a lasershowt hogyan nyomatja a gép, milyen periférián keresztül? Ha az nem tud hangot úgy adni, hogy már analóg jelet, vagy az adjon ki közvetlenül digitális jelet beszinkronizálva, akkor nem fogod tudni megoldani a profi szinkront. Windows alól ügyeskedni ilyesmit mondjuk tized másodperces pontossággal fogsz tudni.

Az usb alsóbb rétegei valameddig free-k, utána már vannak fizetős doksik is. Én például beleszaladtam a mass storage classba, az 2000 usd. Vagy ott van a microchip lib megírva. Ha gondolod, kezd el böngészni a kódot, mert egyebet nem fogsz találni. Angolul van minden, magyarul ilyesmi elég rendesen esélytelen. Vannak az Axelson USB könyvek (keress rá neten), az is angol mindegyik.

Nem rémlik, hogy nálam bármikor lett volna ilyen probléma. Egyébként a project properties ablak bal oldali listájában a Conf-ra kattintás után a megfelelő eszköz van kiválasztva a Device combo-ban? Illetve be van include-olva minden forrásfájlodban a megfelelő mikrokontroller .h állomány is (Esetleg az általános .h, mint pl.: p24Hxxxx.h)?

A "TRISB és társai" az olyan header-ekben vannak, mint pl. a pic18f4680.h. Ennek a könyvtárát (és a header-t is) alapesetben saját magától is használja a fordító. Elképzelhető, hogy valami miatt mégis meg kell adni, de ezt elég egyszer, továbbra is a properties/include directories-ban. Nálam pl. itt van a fájl: c:\Program Files\Microchip\xc8\v1.12\include\

Miért ne lenne jó a max506? A picnek csak ki kell rakni a 8 bitet rá, engedélyezni a megfelelő csatornát, és kész. Ugyanis a program úgy rajzol, hogy küldi az x tengely koordinátáját, x tengelyt odaállítod, utána y tengely, majd jön a lézer bekapcsolása, ezután pár pontig nem mozdul el a scanner, majd lézer kiolt, és jön a következő pont. Szóval nem az van, hogy egyszerre kell mind a 6 csatornát vezérelni.
A program a hangot hangkarin keresztül küldi.
A lézershow scannereit 0-5V-ig terjedő feszültséggel lehet beállítani. Tulajdonképpen úgy működik, mint egy osscilloszkóp, ha a szkópot x-y üzemmódba állítjuk, ugyan úgy lehet rajzolni a DAC-al rá, mint a lasershow-al.

Hát akkor sokkal keményebb dió az USB, mint gondoltam. Én ezt a tanulmányt ismerem, elég érthető számomra:USB_Complete_3rdEdition

El_Pinyo: a conf [default]-on van, de a jobb oldali ablakban ott van kiválasztva a pic32mx795f512l. Részemről a mappa szerkezetben egy "C:\Program Files (x86)\Microchip\mplabc32\v2.02\pic32mx\include" könyvtárat találtam, amiben van egy "p32xxxx.h" file. Ezt a "C:\microchip_solutions_v2013-02-15\Microchip\Include\Compiler.h" includeolja be egy ilyen részben:


Az a __32MX__ a C32 fordító compilere esetén úgy kerül a symbolok közé, hogy kiválasztom a cpu-t, és annak alapján beteszi nekem. Ha mplabx alatt fordítok, elvárhatok tőle ilyesmit automatán, vagy jobb lenne utána néznem, csakugyan a fordítási paraméterek között van-e? A "Makefile"-ban nem találtam erre vonatkozó bejegyzést, és a make paraméterezésében sem, amit a build visszaírt nekem az mplabx-ben. Lehet ilyesmit fixen definiálni neki valahol?

A Microchip solutions include könyvtára biztosan nem alapértelmezett keresési útvonal az MPLAB-X-ben, ezért azt fel kell venni az include directories könyvtárai közé. Más esetben, mondjuk a saját main.c-ben, ha include-olod a p32xxxx.h fájlt, akkor látja az abban szereplő definíciókat, illetve struktúrákat? Mert azt viszont már látnia kéne!

Én is kissé rácsodálkoztam, mekkora szemétséged vannak usb alatt, de hát..

Szóval nem hangot küldesz le usb-n, hanem lézert vezérelni kellenek a dac-ok. Meg tudod-e oldani azt, hogy a zene anyag is ugyan úgy lemenjen? Programból kell neked egy pcm kódolás, az már a mintavételezett hang. Azt is belenyomni usb fileba valami saját protokollal, ami jelzi, melyik lézer és audio dac minták tartoznak azonos idő frame-be. Máris nem lenne szinkronizációs gondod.

Az 506-al az a fő baj, hogy külön cpu kell mellé megfelelő sebességgel adni rá a 8 bites jeleket. Az nem csinál semmi egyebet, mint egy pic lábakra kötött ellenállás létra is csinálna. Kell valami, ami időzíti, mikor kerüljenek oda az új minták. Amíg valami realtime folyamat figyelni tud rá, nincs is semmi baj, de amikor a pic éppen az usb stack task() hívásával van elfoglalva, olyankor nem tud rá figyelni, márpedig az alkalmazott sebesség nem teszi lehetővé, hogy kiakadjon a vezérlés X ideig - ami meg fog történni. Erre az esetre DMA kellene neked, ami viszont nincs a 4550-esben - pic32 jobb lenne rá.

Egy tényleg ennyire robosztussá kerekedő dolgot én már nem raknék 4550-esre. Ftdi breakout modult, és pic32 modult használnék rá halom külső spi-s dac-al. A pic32-esek némelyikének 4 spi modulja van, jutna belőle párhuzamos üzemben mindenre.

A program egyszerre játsza a show-t a zenével, a zene jön a hangkártyán, a lézershow meg USB-n. A program szinkronban küldi ki az adatot a zenével.

Azt gondoltam, hogy valamelyik timer modul megszakítással kezelné le a DA-kat. Végülis csak ki kell rakni a portra 8 bitet, az nem sok idő, megzavarná, ha közben pont adat folyna az USB-n?

Az SPI-s dacot nézegettem, csak azt gondoltam, több idő még lekezelni azt a kommunikációt is, mint csak kirakni valamelyik portra a biteket. Mondjuk ha FTDI csippet használok USB-re, akkor marad idő.
Nem feltétlen 4550-re akartam csinálni, csak eddig ezen gyakorltam USB-s dolgokat.
32-es családot még nem ismerem, bár erősen gondolkodom rajta, hogy el kellene kezdeni, mert árban ugyan ott van, tudásban viszont jobb Kár hogy nincs high speed USB-s PIC.

A main.c-ben includeolt dolgokat egy sima c32-es fordítás látja, de az mplabx-el valami nem tudom én mi van. Olyan, mintha egyszerűen csak nem tudna mit kezdeni az elérési útvonalakkal. A p32xxxx.h egyébként nem az mc solutionsban van, ha visszanézed kicsit pontosabban: az mplab-al együtt települt c32 toolchain könyvtárában van.

Amikor saját scripttel fordítok, abban van egy ilyen rész:
meg egy ilyen:
A pic32-gcc.exe a c32 fordító településekor automatikusan bekerül a path-ba, sima windows batch megtalálja. Amikor megkapja a c32 a processor paramétert, annak alapján ő maga automatikusan beilleszti a __32MX__ symbolt (is). Ez a p32xxxx.h nálam simán be is kerül.

Az mplabx-nek beállítottam a gcc toolchain include könyvtárát is (benne a p32xxxx.h-val), de így sem fordul le. Van ebben a headerben egy ilyen rész: Abban vannak az ilyen tris meg nemtudommik, megnéztem. Betettem a proc könyvtárat is az include-ok közé. Eredmény semmi. Még mindig nem fordul.

Ftdi breakoutban van high speed. A szinkront illetően viszont úgy néz ki, nem ugyan azt értjük szinkron alatt. Azt persze neked kell tudnod, milyen pontosságú szinkronra tartasz igényt.

A windows os 1/64 sec időszeletel. Nem biztos, hogy mindegyik szeletből jutni fog a threaednek. simán lehet, hogy 4-5 szeletből is kicsusszansz. Vagyis nem lehetsz benne biztos, hogy tized másodperc alatti reflex időd lesz. Az usb 1 milli sec framekkel dolgozik, meg azon belül is full speeden van 19 tranzaction, mindegyikben 64 byte adattal. Ezeket az usb perifériára a kernel megszakításokkal - kvázi timerekkel - nyomja ki, így ott az adat folyamatosan folyik. A hangkártya adat folyama is ugyan úgy kapja az anyagot. Viszont ha te arra számítasz, hogy az alkalmazásodnak is lesz olyan realtime jellege, mint a kernelnek, vagy hogy tudni fogod kezelni a szinkront sok10 milli sec időelcsúszás nélkül, csalódhatsz egy nagyot. Az usb stack a pic-eken az mc doksi szerint alig 100 utasítás, de az csak a sie regiszter kezelése. Valójában sokkal több megy ott, mert a sie után még ott a protokol filter is. Bőven 100 usec időt is elvihet egy 40 mhz-re állított 4550-esen. Ha 35 khz-en kell kifele pakolnod a 8 bites mintákat, az 30 usec-es rendelkezésre állást feltételez folyamatosan, és abba már a döntési folyamatnak is bele kell férnie, hogy melyik minta adatot rakod ki, és hova.

Összeadod, kivonod, így vagy úgy, de lesznek szétcsúszások.

Azt tudom, én a Compiler.h-ra akartam utalni, hogy azt biztosan alapból nem fogja látni.
Van egy olyan sanda gyanúm, hogy a 64 bites OS-ed kavar be az x86-os Program Files könyvtárral, de lehet, hogy ebben tévedek. Ha máshogy nem megy, akkor azokat az include file elérési utakat, amikre panaszkodik, add hozzá az include directories-hoz.

Rendben, köszönöm a segítséget! Majd még agyalok, próbálkozok, s kiderül mi lesz belőle!

Ha a PIC forráskódját átírom bulk transferről másra, pl iso-ra, akkor a drivert is újra kell írnom?

Pic oldalon ami változik is (a descriptorokat természetesen módosítanod kell), azt a lib szerintem teljesen automatán fogja lekezelni. Host oldalon szintén. A hid class-nak létezik alapból iso endpointja is. Az egyik descriptort be kell állítanod mondjuk audio eszköznek, és arra automatán az isosynchronous átvitel lesz használva, mert host oldalon a support már eleve megvan hozzá előre definiált kommunikációs eszközként (és persze az ahhoz tartozó eszközökkel kell majd kezelned). Hogy pic oldalon hogyan kötöd rá át az adatfolyamodat, az persze a te dolgod lesz. Az iso-ról jó, ha tudod, hogy nem foglalkozik a hibásnak detektált csomagok megismétlésével. Ha hosszabb kábeled van zavart környezetben, lehetnek frame hibáid, ami meglátszódhat mind a lasershowdban, mind a zenédben. Rövid full speedes kábel esetén ettől még nem félnék. A hosszabb high speedes kábel már más eset. Persze ott sem a kábel a gáz (ha csak nem sérült), hanem a csatlakozók szerelése, de az a végeredmény szempontjából ugyan az: elindul valami, ami máshogy érkezik meg, mint ahogyan elindult. A lasered lehetőleg úgy legyen beállítva, hogy szélsőséges esetben se történhessen meg az, ami az oroszoknál például megtörtént: a laser több tucat ember szemébe siklott bele, és megvakította őket. A szélsőséges esetek is legyenek adott irányba fókuszálva.

Rendben, köszönöm a segítségeket! Egyelőre még olvasgatok, aztán majd nekiállok

Elolvastam a descriptorokat, viszont az interface-kkel bajban vagyok, nem áll össze a kép. Jól értelmezem, hogy ha több interfacem van, akkor végülis olyan, mint ha több eszközt tudnék használni egy USB eszközön belül? Pl webcamnál egy kép interface, meg egy hang interface. Javítsatok ki, ha nem jól értelmeztem.
Valamint a végpontok száma amit még nem értek. Full speed USB-nél 64byteos lehet a max adat egyszerre egy végponton, ha több végpontom van, akkor nagyobb sebességet tudok elérni?
És még egy dolgot nem értek, ha a számítógép kiolvas minden infót az USB eszközről(sebesség, interfacek, végpontok száma stb), akkor miért kell még is driver? Mi az amit ezeken kívűl tudni kell még az oprendszernek?
Remélem nem írtam túl nagy hülyeségeket

Nem akarok hülyeséget mondani, de tudtommal csak akkor kell driver, ha a szokványostól eltérő, vagy hatékonyabb kezelés kell az átvitelhez. A HID-hez pl. nem kell driver. A Microchip CDC-hez sem kell driver (Windows alatt az usbser.sys-t használja, azért is olyan, amilyen...), csak információs fájl. A Microchip Mass stoge class-t is próbáltam már, ahhoz sem kellett driver.

Igen, ebben igazad van!

Ha azt a Jan Axelson könyvet nem csak "hozzáféred", hanem el is olvasod, ezekre a kérdésekre választ kapsz.

Az usb implementers forum (usb-if) szabványosított pár dolgot, így lehettek mostanra usb hid, audio, video, printer/scanner, kommunikációs eszközök mittudoménmégmiminden periféria (van róla egy lista a könyvben), amiknek a drivereit is szabványosították, és azt építik be windowsba meg akárhova. Driver hozzá azért nem kell (értsd: külön driver), mert teljesen szabványosított a kommunikáció mind a két végponton, és akkor jó az a driver, ami meg van írva. Ha elmozdulsz a szabványok adta támasztékokról, nyakadba szakad az usb összes démona. És akkor bizony az Úr legyen irgalmas hozzád, mert az USB-IF biztosan nem lesz - tapasztalat.

Az usb úgy épül fel, hogy van maga az eszköz, annak van egy descriptora, és a device descriptornak vannak alárendelt descriptorai. A továbbiakban legyen inkább leíró. Az eszköznek vannak különféle konfigurációi. Például egy video kamera usb tápellátásról nem supportolja a környezeti megvilágítást is, csak külső áramforrásról. Amikor a host leltárba vesz egy usb perifériát, dönteni kell az elfogadható konfigurációról. Miután az eldőlt, akkor mászik be a konfigurációs leíró alárendelt leíróiba, és az alatt találni fog interface-eket (felhasználható eszközöket). Abban a konfigurációban csak azok az eszközök működnek, akár van még rajtuk kívül másik kettő tucat is, akár nincs. Az eszközök mindegyikének vannak saját adat végpontjai. Például a nullás végpont in és out transferrel is üzemképes kell legyen control transferre - ettől kérdezgeti le a host, hogy mi az az eszköz (előre definiált device class, vagy user defined), az eszköz többi végpontja milyen típusú átvitelt használ, stb. Minden végpont a nulláson kívül vagy csak in, vagy csak out, és csak egy féle típusú átvitelt supportolhat (interrupt, isosynchronous, bulk, control). A full speed usb összes sebessége 12 mbit / sec elvi határon. Ha teljes egészében csak bulkra lenne beállítva, van egy másodpercben ezer frame, minden frameben 19 transaction, minden transaction 64 byte csomagot át tud köhögni egyik irányban. Elvileg 1000 * 19 * 64 = 1.216.000 byte - de ez csak elvileg. Például ha a végpont elkezdett adatokat fogadni a hosttól a frame-en belül, és az egyiket le-NAK-olta, akkor abban a frame-ben a host már nem zaklatja többet. Ha a frame első transactionját máris lenakolta, mert még nem készült el az addigival, akkor az a teljes frame már kiesett. A teljes sávszélesség nem csak egyetlen végpontra kell, hanem az összeset kell vele karbantartani, ezért nem érsz el vele semmit, ha több végpontot képezel ki. Arról gondoskodj inkább, hogy brutál teljesítménnyel tudj feldolgozni, és ahhoz főleg temérdek sok munka memória kell fifo-nak. Akkor még valami esélyed is van az elvi korlát jó érzékű közelítésére. Akkor már csak a szükséges control tennivalók fognak megenni valamennyit (például a host rendszeresen rákukkant, hogy azon az usb hubon jelenik-e meg másik periféria), de az nem sok. 18f4550-essel például azért nem lesz meg a max, mert amikor dobja neked a filter az adatokat, és te azokat dolgozod fel, addig sem fut az usbtask(), és a SIE csak addig gyűjti a host felől érkező adatokat, amíg meg nem telik egy 512 byteos buffer. Akkor pedig a többit NAK-olja automatán. Még pic32-vel sincsen túl sok esélyed tényleg annyit feldolgozni, mint amennyi akár csak full speeden le tud menni. Használhatsz külső ftdi-t, az az usbtask() futási idejét spórolja meg a proci számára (némely esetben 30% proci idő is tud az lenni). De ha nem használsz külső modult, akkor is tudsz akkora sebességet elérni, amennyi neked már elég tud lenni. Például fürtbe kapcsolsz néhány pic-et, és szétosztod a tennivalókat.

És tessék olvasgatni azt az Axelson könyvet!

Sziasztok!
Egy kis segítséget szeretnék kérni ADC-ben.
Az overflow (túlcsordulás) problémát, hogy megoldani, hogy ne 0->256-ig hanem 0->255-ig számoljon vagy ha kell még kevesebbig itt a program:

Köszönöm!

Szia!
NE használj $+2 alakú ugrási címeket. Hagyd a fordítóra.

Nagyon köszönöm a hasznos és kielégítő választ! Olvasom a könyvet, ma is átrágtam magam egy részén, csak sajnos az angol tudásom nem a legprofibb, így sokszor nem értem meg könnyen az amúgy sem egyszerű szöveget Még azt is elolvasom párszor, amit írtál!
Még biztos lesz kérdésem, de mégegyszer köszi a segítséget!

köszi de ezzel még mindig nem oldódott meg a probléma valami más lehetőség ?