Ez nem a Play Station2 vezérlőpanel?

Fogalmam sincs. Csak láttam, hogy van rajta analóg kezelőszerv is, hogy PIC, és van leírás.

csak mert olyanom van s elgondolkoztam, ha azt lehet használni erre, akkor már meg is van oldva...

Üdv!

Az lenne a kérdés, hogy megoldható-e valahogyan, hogy a PIC átírja a saját szoftverét bootloaderes módban. Azt szeretném elérni, hogy pl egy pendriveon található hex-et beégessen magába bootloaderrel, és ne kelljen hozzá a microchip feltöltő fájl-ja.

Megoldható.

Nagyszerű, és tudsz is valami irányt mutatni miképpen kellene ezt elkövetni?
Át kellene írni a bootloadert esetleg?

Nem csináltam még ilyet, de mintha láttam volna a microchip demó programok között olyat, ami pendrive-ot kezel, akkor az a rész abból kiindulva vélhetően minimális módosítással megvan.

Valamit biztosan át kell írni, hogy mit és mennyire, az attól függ, hogy pontosan mit is akarsz csinálni. Lehet pl. úgy, hogy a bootloader megnézi induláskor, hogy van-e pendrive, azon adott nevű fájl, és ha van, meg stimmel mondjuk a CRC-je is, akkor azt felírja a kódterületre.

Természetesen. Itt van egy példa: Bővebben: Link
Itt pedig egy hivatalosabb: AN1388 PIC32 bootloader

Köszönöm. Átolvasgatom őket.

Jó Napot!

Van egy 28pin-s Low Power Demo Board-om, PICKIT3 programozóval, és vettem hozzá egy PIC18F24K50 microchipet is. ennek van USB áramköre, és szeretném összekötni a PC-vel.
Sajnos ezen a demo board-on nincs USB csatlakozó, ezért ezzel kapcsolatban kérdezném, hogy hogyan kell bekötni az USB-t? ha jól értelmezem a doksit a 14-lábra kell 3.3v, és USB-nek meg kell 5 v.
Erre a problémára tudnátok küldeni kapcsolást?

Nekem tied kisöccse van (PIC18F14K50), erről a honlapomon és ebben a cikkemben is olvashatsz.

Az 5V-ot a számítógép adja. A 3,3 V-ot (gondolom) a PIC beépített LDO-ja adja, csak egy 470 nF-os kondi kell a VUSB kivezetésre. PIC18F14K50-nél azt tapasztaltam, hogy a 3,3 V-ot akkor is produkálta a VUSB kimeneten, amikor 3,3 V volt a bejövő VDD feszültség.

Szia!
Köszönöm a gyors válaszodat, de csak most volt lehetőségem kicsit komolyabban átolvasni a cikkedet. Őszintén szólva megtaláltam már google-val, de talán így kicsit személyesebb, hogy van kontakt..
Tehát, ha jól értem. az 5 V jön a PC-től, de sztem nekem ez még nem kell, mert bőven örülök, ha PICKIT3-al menni fog a dolog.
D+, D- rákötöm a megfelelő lábakra, földet is a demo board földjére.
nem kell extra 3.3v (a Full Speedhez), mert a belső felhúzást a megfelelő regiszterrel tudom konfigurálni.
Vusb3v3-ra rakok egy 470nF-os kondenzátort.
A következő problémám a sebesség. Szerintem ehhez a chiphez nem kell külön oszcillátor, mert van benne egy 16Mhz oszcillátor és ezt lehet szorozni 3-al.
hálás lennék, ha ezekben a kérdésekben segítenél, útba igazítanál, ha vmit nem jól gondolok.

Az nem elég, hogy a 48 MHz-et elő lehet állítani, annak kellően pontosnak is kell lenni, mert az USB buszon kritikus időzítések vannak. Kvarc nélkül csak azok az eszközök alkalmasak Full-speed USB-re, amelyek képesek hozzáhangolni az oszcillátor frekvenciát az USB buszhoz. Ha az adatlap ezt nem írja, akkor ilyen képessége nincs a mikrovezérlődnek. A 14k50-nél kifejezett írja, hogy kell a kvarc.

Utóirat: most látom, hogy ennél írják: "Internal 48MHz Oscillator with USB Accuracy -Via Active Clock Tuning from USB Host". Akkor tényleg mehet kvarc nélkül is!

köszönöm a segítségedet!

Sziasztok!

PIC24E -n próbálom (pic24ep512gu810) az USB kapcsolatos feléleszteni.
Ehhez letöltöttem a Microchip Bootloaderét ami kisebb módosítások után felprogramoztam.
Módosítások: (a hardware-en secondary osc-re van kötve 4mhz kvar)


Reményeim szerint így elő áll a 48MHZ
((4mhz / 1)*24)/2 = 48
Kérdésem, hogy a fenti beállítások szerint ha a forrást az AUX-ra állítottam akkor (a rajzok szerint is) a secondary osc-re kötött 4mhz jó kell, hogy legyen, igaz?

Utána még amit változtattam az a LED lába volt így most már villog is, ami elvileg azt jelenti, hogy a bootloader jó. Sajnos ennek ellenére semmiféle usb kommunikációra nem tudtam rávenni. Elindítottam a Microchip -es bootloader PC-s felét, beírtam a VID és PID azonosítókat amiket a forrásban találtam és azt mondja, hogy nem találja!
Egészen pontosan ebből próbáltam kiindulni: "PIC24E_USB_HID_Bootloader_StarterKit.mcp"

Továbbá a HardwareProfile.h-ban találtam 2 dolgot ami nem tudom mire való, kell-e nekem


Nem tudom merre fele mehetnék tovább.

Az USB vezérlő lehet saját táplálású (self powered) ill. USB-n keresztüli táplálású (bus powered). Viszont az áramkör többi része működhet ettől eltérő tápforrásról. Emiatt szükséges lehet hogy az USB vezérlő érzékelje hogy a többi táp is megvan a normális működéshez, ill. az USB kábel egyáltalán csatlakoztatva lett-e. Ehhez kell a Bus Sense (USB 5V megvan, tehát csatlakoztatva van a kiszolgálóhoz), ill. Self power (saját táp megvan) bemenet.

Köszönöm!
Az előbbi hsz-ben megírt konfigurációt még ennyivel bővítettem:


illetve kitettem az USBDeviceState -et ledekre, így most a következő látszik:
POWERED és DETACHED a státusz (sajnos akkor is ha bedugom a kábelt)

Egy szemléleti tanácsot szeretnék kérni.

Adatcserét valósítanék meg usb-vel periféria és számítógép között, és döntenem kellene róla, milyen típusú legyen az usb-s periféria. Természetesen meg szeretném úszni a driver fejlesztést, és a meglévők közül is valami olyat kellene választani, ami általánosan elérhető minden platformon.

Információ szempontjából két irányban 580 byte-os csomagokat küldözgetnék, de tudom úgy formázni az adatot, hogy mehet akár nyers soros adatfolyamként az egész, és elég nekem 1 bulk in + 1 bulk out endpoint (kell a hibamentes adatfolyam). Most windows-on tesztelném az eszközt, de később nem lenne rossz android mobil eszközökhöz is hozzácsatolni, és arra bizony semmiféle drivert nem tudok majd fejleszteni, maximum használni, ami biztosan van, és csak java level alkalmazás logikát írni.

Nézegettem hid meg common device classokat, és kissé meglepődtem, hogy nyers adatfolyamot is mennyire megbonyolítanak a szabványok. Becsomagolhatom ugyan bármilyen formába az adatot, de csak nyűg nekem.

Van róla valami kiforrott tapasztalat, milyen formába érdemes csiszolnom az eszközt driver szempontjából?

Mekkora átviteli sebességre lenne szükség? HID a legegyszerűbb szerintem driver szempontjából. Csomagodat felosztod 58 bájtos darabokra, adsz hozzá sorszámot, és a túloldalon meg a sorszám alapján összerakod.

Nincs különösebben sebesség probléma. Akár 1 mbps-re sem lesz szükségem átlagos sebességben. Inkább a "ping" az, amit leszorítanék. A hid controllinggal dolgozik. Kimegy a kérdés a hid-nak, hogy "na, történt-e valamit?", és ha visszament a "jaja, akarok róla beszélni" válasz, akkor a host végig kérdezősködik az endpointokon. Mindez nyers bulk eszköz esetében csak egyirányban végigzuhan külön kérdés nélkül.

Tényleg nem létezik olyan driveres support, ami nyers bulk endpointokat kezelni tudna, és megvan minden platformon? A hid az egyetlen, amiben meg lehet bízni?

A Microchip Applications Libraries USB szekcióban a LibUSB demót nézd meg!

Köszönöm a tippet. Nem is értem, azt a könyvtárat miért ugrottam át. Alap libnek hittem, és csak a többibe lestem bele

Apropó az a példa nagyon szereti a 4550-est, de az a 40 lábú izé egy böhöm nagy valami. Próbálta már valaki azt a demót 2550-esre felgyömöszölni?

Az a demó tudtommal nem sok lábat használ, tehát elvileg mindegy neki, hogy 4550 vagy 2550 . A gond csak az, hogy 2550-es demó kártyát nem készített a Microchip ezért a demóprogramok csak mérsékelten támogatják ezt a típust. Több-kevesebb matatással bizonyára megoldható az adaptálás.

Első lépésként egy hardverprofilt kell készíteni a kártyádhoz, s a HardwareProfile.h állomány feltételeinek bővítésével gondoskodni kell a becsatolásáról:



Ha a fenti sorok után betoldod az alábbiakat, akkor a siker már félig garantált:


Az önkényesen HardwareProfile - myboard_2550.h névvel ellátott harverprofilt például a HardwareProfile - PICDEM FSUSB.h mintájára (átszerkesztésével) lehet létrehozni.

A forrásállományokban (pl. main.c) gondoskodni kell róla, hogy:
- ahol a feltételes fordítási direktívákban 4550 szerepel, ott a 2550 is szerepljen vagylagosan.
- Ahol a PICDEM_FS_USB szimbólum szerepel, ott a MYBOARD_2550 szimbólumhoz is tartozzon egy hasonló feltételes rész.

A MYBOARD_2550 szimbólumot természetesen a harver profil definiálja az alábbi mintájára:


Nagyjából ez a lényeg, de 2550 még nem volt a kezemben, úgyhogy csak elvi szempontokat soroltam egy 4550-es, de a PICDEM FSUSB kártyával nem kompatibilis hardver adaptálásának tapasztalatai alapján (én a HID Custom demos mintapéldát használtam, de az adaptálás szempontjából ez most mindegy).

Köszi a tippeket. Az igazi problémám az volt, van-e valamilyen ismert hw gyengesége a 2550-nek, ami esetleg tuti problémát okoz. Valahogy nem találom ezekhez a pic-ekhez az ismert hibajelenségek listáját, pedig biztos van belőlük. Jó, tudom, ott az errata, de azt mindig csak utólag adják ki.

Nyilvánvalóan minden hibalistát csak utólag lehet kiadni, amikor a hiba kiderül. Nézd az Erratát, s nézd meg azt is, hogy milyen verziószámú a mikrovezérlőd (a hibák egy részét az újabb kiadásokban már kijavították, más részét újonnan vezették be...)

Találtam az usb libek között "mchpusb" példát, és azon filozom, vajon mennyi esélyem van arra, hogy az mc gyártói oldalról supportot ad ehhez? Gondolok itt arra, hogy pld valamennyi pic18lf2550, amit csak meg tudok venni, mind előreprogramozottan kerül kereskedelmi forgalomba. Vagy legalább lehet úgy is rendelni eszetlen felár megfizetése nélkül. Például ha valami miniszériát terveznék, a gyártásnál tud az előnyös is lenni, ha létezik ilyen support. Nem az életem múlik rajta, épp csak kíváncsi vagyok. Erre vonatkozó feljegyzéseket kerestem, de amit találtam, az egy sem a "hivatalos" forrás nyilatkozata volt. Aki már megfutotta ezt a kört, segítsen egy kicsit, mi lett a vége? Köszönöm.

Alapértelmezetten egyik Microchip mikrovezérlő sem előreprogramozott. Ha miniszériát tervezel, akkor vagy a MirochipDirectnél próbálkozhatsz (elvileg van újabban ilyen szolgáltatásuk, de én nem próbáltam), vagy beleírod magad.

Megjegyzés: Az "mchpusb" is csak ugyanolyan program, mint a HID, libusb, winusb és a többi mintapélda.

Van egy olyan szervezet (afféle irodai cég), hogy T10 Technical Committee. Elvileg az a szervezet tartja karban a mass storage protocolt, amit az usb is használ. Sajnos csak regisztráció után lehet tőlük érdemi dokumentációt letölteni. Nincs véletlenül valakinek olyan cégnél ismerőse, ahol ahhoz hozzáférhet? Vagy bármi egyéb ötlet, hogyan lehetne olyan doksinak viszonylag aktuális állapotához hozzájutni?

Megpróbáltam visszakutakodni az usb layer 2 fölötti scsi filtert az MC libből, de nem egyszerű dolog forráskódból ilyet csinálni.

Amit az usb.org-on találsz az nem elég neked? Vagy mit is keresel?

Approved Class Specification Documents

Ott megtalálod ledokumentálva a layer 1 és 2-t, de semmit többet. Ott van részletesen az összes elektronikai elvárás, a bitek dekódolása, és le van írva a frame képzés, a frame képzés protokolljai, a frame-ek típusa. De az még mindig csak maga az üzenet keret. Hogy az üzenet keretbe hogyan vannak beillesztve a scsi parancsok, hogyan küldenek és várnak vissza adatot, milyen parancs kódok vannak, az egész adatátvitelnek milyen időzítési korlátokhoz kell alkalmazkodnia, arról nem találsz majd ott egyetlen szót sem. Van egy könyv valami usb complete reference vagy ilyesmi. Ott van egy kicsit több is. A felső keretből valamit leír, ami azonos cd, dvd, floppy, meg ilyesmiknél. A többiről pedig:



Nos, azt keresem. Nem lenne rossz valahol rátalálni egy nem túl régi verziójára (mondjuk 2012 és későbbire), mert amúgy állandóan fejlesztik.