1. Próbáld meg kitalálni, hogy miért kellett a 25 ms késleltetés.
2. Olvasgast tovább a honlapomon leírtakat a státuszgépek logikájának megértéséhez.

A késleltetésre az első gondolatom a prell volt, aztán az oldalad olvasgatva ott is ezt láttam. Ez az állapotgépes dolgot viszont nem igazán értem, kutakodtam is egy kicsit, de nem igazán lettem okosabb. Viszont van mivel foglalkoznom Köszi!

Igen, azért kell, hogy csak bizonyos időnként nézzünk rá a kapcsolóra.

Az állapotgép programozástechnikailag annyi, hogy van egy változónk (pl. status), ami az aktuális állapotot jelzi, s a végtelen ciklusban rendszeresen lefuttatott programrészben egy switch(status) utasítás mindig azt az ágat futtatja, ami az aktuális állapothoz tartozik. Bizonyos feltételek esetén megváltoztatjuk a status változó értékét, s következő ciklusban már egy másik ág fog végrehajtódni.

Az I/O portok c. fejezetben van néhány mintapélda ilyenekre.

És már megint csak azt kell írnom, hogy köszi szépen, ez így már világos, és lényegesen egyszerűbb az egész mint eddig elképzeltem Azt hiszem szeretni fogom
Köszi még egyszer!

Sokáig nem tudtam én sem, mi az az állapotgép, és csak később jöttem rá, hogy az első programom így működik. Ezek a fogalmak, csak a profik között ismertek, én meg még ma is csak amatőr vagyok!

Á, ez inkább csupán szerencse kérdése, hogy találkozik-e éppen ezzel a kifejezéssel az ember valahol vagy sem.

Én pl. már ismerem a kifejezést néhány éve, mégis csak kezdő szinten vagyok PIC-ben.

Szóval ezért gondolom én inkább szerencsének.

Sziasztok! Újra bajom van, az alapokkal. Megpróbáltam egy új projektet létre hozni, ám nem fordul egy sima üres ciklussal próbálom egyenlőre. A mellékelt képen a hibaüzenet. Pedig ott a fájl. Köszönöm előre is!

Jól látom, hogy az egy felkiáltójel az elérési útban? Ha jól látom, az baj.

Jól látod, így teszem előre, lustaság, ööö praktikusság Kivettem, semmi változás.

Be kell állítani a projektben az elérési útvonalakat!
Az Include fájlokhoz a PICCOLO projekt include, Microchip/include és Microchip/include/USB mappájainak, valamint az MCC18 fordító h mappájának az elérési útvonalát kell felsorolni.

Az kapásból látszik, hogy rossz könyvtárszerkezettel indultál. A PICCOLO projekt mappájában nyiss egy új projektkönyvtárat, s akkor használhatod a példaprogramok mntájára a ../include, ../Microchip/include stb. relatív elérési útvonalakat. ( "/" helyett természetesen backslash kell, csak azt a fórummotor nem szereti...)

Én egyébként így hozok létre új projekteket (lustaság = félegészség!):

Utána Notepad editorral a regi.c nevet új.c-re változtatom az uj.mcp állományban. Nehéz volna ennél egyszerűbb módszert találni.

Köszönöm, este kipróbálgatom, most dolgozni kell.

A Microchip Application Library-ban közzétett USB Device - Serial Emulator példaprogramban nincs kidolgozva a valódi hardveres adatfolyam-vezérlés. Ha az usb_config.h állományban aktiváljuk (azaz kivesszük a kommentből) az alábbi sorokat

akkor csak az RTS és a DTR vonalak programmal történő beállítására van lehetőség a Set_Control_Line_State függvényen (usb_function_cdc.c) keresztül.

A gyári demóban azonban ez sem működik, mivel az RTS és DTR vonalak TRIS bitjeit csak definiálták, de sehol sem állítják be! Ezért a main.c InitializeUSART(void) nevű függvényében a C18-ra vonatkozó ágba be kell iktatni az alábbi sorokat:



Így már működni fog!

Egy lehetséges alkalmazás: az általam használt PIC24 gyakorlópanelon egy PIC18F14K50 USB-UART konverter biztosítja a kommunikációt, és a programok letöltését (a PIC24-ben bootloader van, ami RESET után 1-2 másodpercig aktív). A PIC18 RTS vonalával összekötve a PIC24 MCLR lábát, a resetelés és a bootloader aktiválása automatizálható, ahhoz hasonlóan, ahogy az Arduino kártyáknál csinálják.

Most azon dolgozom, hogy az RTS kimenet vezérlése aktív lehúzás és tri-state állapotok között váltogasson (aktív felhúzásra nincs szükség, s az a RESET gombbal párhozamosan roppant egészségtelen is volna...).

Hali!
Segítsen ki valaki.
VB6-ban hogyan kell Hex-t -> Dec-re átalakítani?
(PIC18F4550 beolvasott analog port adatot akarom VB-ben használni)
Köszi.Üdv.

Mitől lenne a beolvasott adat Hex? Átalakítod elküldés előtt karakterkóddá a mért értékeket(ha igen, akkor ez felesleges)? USB-n küldöd át az adatokat a PC-nek? Melyik protokolt használod (CDC, HID) ?

Gondolom, ugyanúgy, ahogy más nyelven is. Meg kell szorozni a referencia feszültséggel (alapesetben eza tápfeszültség),majd el kell osztani 1023-mal (mert a 0x3FF érték képviseli a referenciával azonos bemenőfeszültséget).

V = adc * Vref / 1023

Ha Vref V-ban van megadva, akkor az eredmény is abban lesz. Ha mV-ban adod meg, akkor az eredmény is mV-ban értendő. Ez utóbbi esetben a mV-ra átszámolt érték egészként is ábrázolható. Ha V-ban van, akkor lebegőpontos mennyiségként célszerű dolgozni vele.

Lehet, hogy én értettem félre a kérdést, de nekem úgy tűnik az a probléma, hogy a PIC-ből átküldi a mért értékeket a PC-re és ott akarja feldolgozni. Namost ha átküld egy értéket, az ugye nem hex, vagy dec, vagy egyéb, hanem egy érték. Ha a PIC-ben nem alakítja szándékosan HEX karakterekké, hogy pl. EF -et kül el két karakterkóddal az egy 239 érték helyett, akkor az nem hex szám.
Ezért kérdeztem, hogy mitől lett az hex a PC-n?

Talán az a valószínűbb, hogy te értetted jól, és én értettem félre. Mindenestre a kérdező mejd elmondja, hogy mi a gondja.

USB CDC esetén (bár egyelőre nem tudjuk, hogy erről van-e szó!) az indokolhatja a szöveges formában való küldést, hogy a bináris adattól esetleg megvadul a kapcsolat. Az ún. kontroll karaktereknek vezérlő funkciója lehet, a 127 fölötti kódok átvitele meg nyűgös dolog: a Windows vagy leharapja a legfelső bitet, vagy kódkonverziót végez.

Ha a firmware módosítható, akkor decimálisan lehetne küldeni az adatot. Természetesen a hexadecimális szám is átszámolható, csak 256-tal és 16-tal meg kell szorozni a "százas" és a "tízes" jegyét.

A CDC nem ágál a 0..255 ig terjedő értékek ellen, a VB6-ban pedig az MSComm szintén nem, csak akkor, ha meg akarod jeleníteni egy List ablakban karakterként. A lényeg tehát az, hogy megjelenítés nélkül bármilyen érték átvihető, kezelhető.

A CDC-ről annyit, hogy most gyúrom át a házvezérlőm PC kapcsolatát HID-re, mert tele van a púpom a CDC bizonytalanságaival. (Van egy diagnosztikai áramköröm(1ksps lassú szkóp), és a tapasztalat, hogy HID-el tökéletesen működik hosszabb távon is.)
Ezt azért gondoltam megjegyezni, mert javasolt a kérdezőnek is a HID használata, ha nem akar bajlódni sokat. Az egyedüli korlát a 64kB/sec, bár a CDC-vel sem sikerült 46kB/sec fölé tornásznom a sebességet, de ennek nem csak a CDC volt az oka...

Nem tudom, próbáltad-e már az USB-nek lefoglalt RAM területeket másra is használni? Én most kísérletezem, hogy a 0x500..0x5FF-as területen saját puffernek foglalok helyet. HID alatt ez eddig nekem nem okozott keveredést. A szimuláció szerint érintetlen maradt ez a terület, inkább a 0x400..0x4FF tartományban találhatóak változó értékek.

Tudsz erről a területről valamit bővebben?

Elmeletileg lehet, hogy a SIE nem hasznalja azt a teruletet, de az adatlap ova int annak felhasznalasarol mert megzavarhatja az USB mukodeset. Az adatlapban a "Buffer Ownership" reszt erdemes ezzel kapcsolatban atolvasni.

Tul ezen persze meg az is lehet zavar mentesen fog neked mukodni otthon, es akkor "kit zavar?" avagy "mi baj lehet?"

Már nem emlékszem, hogy próbáltam-e, mindenesetre most megnéztem, s a linker scriptemben minden USB által is használható memória PROTECTED jelzésű, tehát mostanában biztosan nem használom másra.

trudnai, icserny jogos a gondolat, én is láttam, hogy PROTECTED, viszont az is tény, hogy 64bájtnyi helyet lefoglaltam az 500-tól és az elküldött 64bájt adat elért a PC-re és viszont. Tehát nem tudom minek neki az a hely, de nagyon úgy tűnik, hogy nem használja, vagy pont olyan ütemben, ahogy én is, azaz pont oda veszi az adatokat, ahová én utána áttöltetem vele, illetve pont oda tölti fel a pufferjét, ahová én már eleve feltöltöttem, feltételezve, hogy pont ugyanazokat a címeket használja belső pufferként, amiket én külsőként. Remélem értettetek valamit a zagyvából!
Keresem azt a deklarációt, ahol látszana, hogy foglal-e helyet ott valaminek, de egyelőre nem találtam.

A .map fájlban (egy konkrét programnál) szerintem ezek a bejegyzések jelzik a tényleges foglalást:
A többi hely tudtommal szabad.

Az USB_BDT szekció címét az usb_device.c állományban, az USB_VARIABLES kezdőcímét pedig az usb_function_device.c állományban állítják be.

Köszönöm, délután megnézem!

Üdv!
Érdekelne hogy hogyan lehet (PIC24) mikrovezérlőhöz USB-s egeret ill. játékvezérlőt kötni és használni, ill. mikrovezérlővel ilyen HID eszközöket megvalósítani, amiket pl. a Windows alapból tud kezelni mindenféle driver nélkül. (Hardware-közeli, assembly nyelvű megvalósítást szeretnék.)
Míg az adatlapokon az I2C ill. SPI buszok működése és használata elég jól le van írva, addig az USB Microcip-féle dokumentációja egy nagy nulla.
Hol találok jó információkat erről a témáról?
Esetleg valaki csinált már ilyet?

Hali
Itt talalsz egy eleg jo USB konyvet.

Vannak példák, én talákoztam velük, de C-ben.
Egeret még nem próbáltam, de van egy cikkem a HID kapcsolatról. Csak az azonosítót kell elvileg megadni, hogy a Win pl. egérnek ismerje fel. Pillanatnyilag nem vagyok benne a témában, konkrétumok után nekem is keresgélnem kéne...

Szia!
Konkrétan melyik foglalkozik USB-vel?
(Engem nem a C-nyelvű és Framework-ös alkalmazások érdekelnének...)

Próbáltam szerkeszteni az előzőt, de nem ment...

Szóval közben rájöttem, hogy te a PIC-re akarod kötni az egeret, ahhoz host-os PIC kéne. Azt hiszem van ilyen is, de még nem találkoztam ilyennel, és példával sem. Nem lesz könnyű dolgod.