Windows 7 32bitet használok. Nem látszik az eszközkezelőben.

Mindegy mit használsz. Ha semmilyen device-ként nem látszik, akkor a bootloader nem megy benne, szóval az első opció kilőve.

Aha értem. Köszi szépen a segítséget. Gondolom Microchip oldaláról leszedhető a firmware hozzá? Ha a firmware megvan, a programozás igényel valami különlegességet? MPLAB-ból kivitelezhető?

A firmware szerintem a MPLAB megfelelő könyvtárában is benne van, hiszen onnan tölti bele az MPLAB is. Azt hiszem, hogy a programozandó eszköz fajtája szerint több különböző firmware is van hozzá, és az MPLAB cserélgeti (nekem a 32MX és a 16F között cserélgette).

Megtaláltam egy Microchip-es fórumba a firmware-t. Csatoltam is hátha kell másnak is. Igen így van hogy minden eszközhöz tartozik 1 firmware nekem is akkor halt meg mikor ezt töltötte volna be.

Szia!
Érdemesebb letölteni a PICkit3_GUI_scripting_v03.00beta.zip -et, abban frissebb firmware van.

Oké köszi hogy szóltál.

Sziasztok!

Egy PIC32MX460F512L vezérlővel és egy VS1053 mp3 codec IC-vel szeretnék USB-s hangkártyát készíteni.

Valakinek nincs valami mintája arra, hogy hogyan lehetne az USB-n kapott adatokat MP3-ba konvertálni, hogy így tudjam az adatáramlást megvalósítani a gép és a codec IC között?

Előre is köszönöm a válaszokat!

Hello!

Nem inkább a PCM29xx-es családdal szeretnél ilyen ötletet kivitelezni? Esetleg a kimenetére illesztett DAC eszközzel tovább lehet javítani az amúgy sem olyan rossz minőségén. Én inkább ezt az utat favorizálnám a helyedben. Még topik is van ezzel kapcsolatban.

Szerintem értelmetlen dolog az, amit szeretnél. Ha már egyszer tiszta audio jeled van, akkor minek kódolnád azt el MP3-ba (ami minőségvesztéssel jár), ráadásul minek tennéd ezt pont egy meglehetősen gyenge PIC CPU-val, és minek használnál utána egy több ezer forintos MP3 dekóder IC-t, hogy rögtön vissza is alakíthasd? Ennek az égadta világon semmi értelme nincs.

Azért ezt az utat választottam, mert mind a két IC-vel rendelkezem itthon. Így gondoltam összeüthetnék a kettőből egy ilyen hangkártyát.
_vl_ válaszát nem egészen értem mert az USB kapcsolaton keresztül nem tudom milyen formátumba kapná a PIC az adatokat. Végülis nekem nem lényeges az MP3 formátum.
Csak az lenne a lényeg hogy a dekóder IC támogassa azt az adatformátumot amit kap.

Először ennek kellene utánanézni! A végén még kiderül, hogy neked kell hozzá driver programot írni a Windows alá.... Nem egyszerűbb, ha MP3 lejátszót csinálsz az IC-kből?

Igen, ez lenne az egyik lényeg. Ha a PIC-nek kellene konvertálgatnia, hogy az IC-nek jó legyen az adat, akkor megette a fene az egészet. Meg kell nézni, hogy mit tud fogadni az IC, és ebbe beleesik-e az, ami az USB hangkártyák szabványa szerint ott érkezhet (szerintem PCM jelet kell tudni fogadni) - MP3 pl. biztosan nem.

Egyébként kicsit "gombhoz a kabátot" jellegűnek érzem a megközelítésedet.
Még ha ismeri is a PCM-et a chip, akkor is felesleges pazarlás egy bonyolult formátumot dekódolni képes drága IC-t elhasználni egy olyan feladatra, amire egy 300 forintos DAC is pont megfelelő...

MP3 lejátszó már készült belőle
Ez egy mikromedia for PIC32 kész hardver. Tehát nekem nem pazarlás "felhasználni" az IC-ket mivel ígyis-úgyis univerzális marad az eszköz.
Csak gondoltam bővíteném a felhasználhatóságát a dolognak. Ezért jött az ötlet

Hát akkor utánanézek az USB hangkártyák szabványainak, hátha okosabb leszek.

Köszönöm az eddigi segítséget!

Vagy egyszerűbb lenne driver-t írni az op.rendszer alá, hogy a kapott hangokat mp3-ba vagy más támogatott formátumba konvertálva elküldje, és a PIC így csak az USB-SPI adatfolyamot valósítsa meg?

Sziasztok! A következő a problémám: TSOP1736-ot szeretnék kiolvastatni egy PIC-kel. (16F887) Odáig jutottam, hogy a különböző távkapcsolókat meg tudom különböztetni, de a gombokat nem. Mi a titka? Nem foglalkoztam még infrás dolgokkal sajnos.

ÖÖÖ...nem egeszen ertem.
A tavkapcsolo adofrekijenek meg kell felelnie a vevode. Ez rendben?
Ha ugyanazon taviranyito ugyanazon gombja mas-mas jelsorzatot ad, akkor nem stimmel valami ezzel.

A tavkapcsolo az elejen egy hosszabb impulzussal jelzi, hogy adni fog (nullara huzza a vonalat). Utana jon a kod valamilyen kodolassal: vagy idokodos rendszerben vagy PWM kodolasu rendszerben (az elso esetben a rovid impulzust fix ideju elengedes utan koveti az esetleges hosszu, a masodiknal frame-ek vannak es azon beluli impulzushossz hatarozza meg, hogy 1 vagy 0, tehat itt az elengedes ideje valtozik a jelek kozott.)
Valamilyen hosszusagu bitsorozatot ad, ezt te veszed. Altalaban 32-48 bit korul van. Alkalmaznak Manchester-kodolast.
En eddig nem talalkoztam olyannal, hogy az ado sajat magat is azonositana..., de termeszetesen elkepzelheto, tul sok taviranyitoval meg nem talalkoztam.
Tehat egy adott gomb megnyomasara MINDIG ugyanazt a jelsorozatot kell, hogy kapd.

Szia!

Nézd át az infra protokollokat! Majdnem minden gyártónak sajátja van: Philips (RC5, RC6 - Manchester kódolású - példa a Propeller óra topikban található), Sony, stb.
A TSOP negál, azaz ha van infra jel, akkor alacsony a kimenete. Ezenkívül a beépített AGC miatt van egy minimális és egy maximális üzenethossza.

Nem minden esetben:
Philips RC5: A biztos vétel érdekében megengedett, hogy az adó ismételjen, azaz egy lenyomásra többször küldje el a táviratot. Ha a vevő hibásan venne egyet, akkor az ismételtek közül valamelyiket veheti még jól. A többszörös vételt az un. toggle bit bevezetése küszöböli ki. A gomb lenyomásakor a toggle bit vált, az ismételet táviratokban azonos értékű. Váltani legközelebb akkor fog, ha a gomot felengedték és újból lenyomtak egyet.
Pl. Egy gombot lenyomva több távirat megy mondjuk 0 toggle bittel, aztán felengedve és újra lenyomva a gombot, megint mennek a táviatok, de a toggle bit 1 lesz bennük.

Segítséget szeretnék kérni megszakítás + programmemória lapváltás kérdésében.
Adott egy 16F887, ahol mind a négy programmemória szegmens használatban van. A szoftver a PAGESEL-ek segítségével szépen működik egészen addig, míg megszakítás nem következik be. Ilyenkor szépen a 0x0004 címre ugrik, lefut a megszakítás, visszatéréskor azonban hiába olvassa vissza a veremből a címet (cím+PCLATH) "elkószál" a program az egyes programmemória bankok között. Míg a programban szabályszerűen tudom alkalmazni a
PAGESEL - címke
CALL - címke
PAGESEL $ (aktuális bank)
kódrészletet, addig megszakítás esetén az utolsó "PAGESEL$" nem használható, így a program nem is téríthető vissza a helyes (kiindulási) programmemória-lapra.
Megoldási javaslat?

A megszakítás belépésekor miket mentesz el és hogyan? (kódrészletet, vagy fájlrészletet tegyél fel, hogy lássuk.)

Most munkahelyen vagyok - este tudok kódot feltenni - de a szokásos W és STATUS mentés van - és működnek is.

Az kevés, ebben az esetben a PCLATH-ot is mentened kell ( valószínűleg használsz ugrást a megszakításon belül is, amiért a PCLATH-ot át kellett állítanod!)!
Steve

Szia!
Olvastad?
A megszakítási rutinban menteni kell a PCLATH értékét, a megszakítási rutin lapjára kell állítani az első ugrás előtt. A visszatérésnél (az utolsó ugrás után, de a retfie előtt) a mentett értéket vissza kell állítani.

Ha a fentieket megcsinálod, akor jó helyre ugrik majd a megszakítási rutinban is és a visszatérés után is.

Köszönöm a válaszokat! Természetesen "tökén fogtam" a PCLATH-ot már, azonban az a rettenetesen érdekes, hogy ha a megszakításban csak annyit csinálok, hogy törlöm az IRQ-FLAG-et, majd zavarom is vissza RETFIE-vel - na ekkor is elkószál...

Szia!
A megszakítás elfogadása nem változtatja meg a PCLATH értékét, a retfie minden bitet visszatölt a PC -be. Nézegesd még egy kicsit: Ha nincs ugrás a kiszolgáló rutinban és nem változtatja meg a PCLATH értékét, a retfie pedig visszatölti a megszakítás előtt teljes PC -t, akkor a következő ugrás jó helyre megy. Esetleg az ott levő ugrás célja van más lapon?

Működik a program. Szépen, hibátlanul. Ugrál lapról lapra. Aztán beüt a megszakítás (TMR1). Ugrunk 0x0004-re. Itt ennyit teszek:

BCF IRQ_FLAG
RETFIE

Se goto se call, semmi ugrás
Innentől elmegy a program.
A 0x0004-re ugrás megy, mert betettem oda egy BSF LED-et (Egyik porton egy LED) és felkapcsolja. Csak vissza nem tér... És ettől vagyok már idegbeteg

Az általad leírt esetben nem lehet, mert return, retfie esetében a teljes címet visszatölti, nem használja a PCLATH biteket! Ha a megszakításban csak a jelzőbit törlése és a RETFIE van, akkor az nem okozhat problémát! Nem lehet, hogy a megszakításban pl. vizsgálod, hogy ki okozta a megszakítást és ennek megfelelően ugrasz ( pl. BTFSS, ez is egyfajta "GOTO" és ez már okozhat eltévelyedést!) ?
Próbáld szimulátorban keresni a hibát, ott szerintem látni fogod a hibádat ( a saját "hülyeségeket" a legnehezebb megtalálni, de ebben nagyon jó segítség a szimulátor!)!
Steve

Nézd meg szimulátorban!
Steve

Nem, nincsen IRQ FLAG vizsgálat, mert egyedül TMR1 megszakítás van. Minden más tiltva (beleértve DA, AD, MSSP, ...) Én is ezért vagyok abszolute tanácstalan, mert a visszatérő utasításoknak a teljes (helyes) címet vissza kéne adni. Biztos hogy az én hülyeségem van a dologban, meg tuti valami bagatel dolog, de rettentő bosszantó...

Szia!
Ha ilyen egyszerű a programod, tölts fel egy szöveges állományban. Így látatlanban csak azt tudom mondani, hogy állítsd be debugger -nek a MpLab Sim -et és lépésenként hajtsd végre a programot. Nézd meg a Hardware Stack -et is...