Fórum témák
» Több friss téma |
Szia!
Végülis mindegy hogyan kötöd rá a bemenetre: a gomb megnyomásakor magas vagy alacson szint lesz a bemeneten... - A pergésmentsesítést meg kell oldani programból vagy kapcsolással (debounce). Ha nagyon óvatos vagy, a nyomógomb és a pic lába közé tegyél 1k ellenállást - ekkor a véletlenül kimenetre állított lábat sem tudod tönkretenni a nyomógomb lenyomásával. - Az LCD lassú, csak akkor töröld és írd ki az új szöveget, ha a kiválasztás változott. Ha túl gyakran írod, a kijelző hunyorodni fog, esetleg semmi sem fog látszani.
Inkább leírom mi a konkrét feladat és lehet, hogy van jobb megoldás is..
Van egy 2x16-os lcd és egy pic16f876/73 mikrovezérlő. A mikrovezérlőben egy tömben van tárolva x számú string, amiket egymás után kéne megjeleníteni gombnyomásra. Ha a végére ért akkor kezdheti újra. És alapból a tömb első string-jei jelenjen meg.
PIC-es technológiák hol tartanak most a hangdigitalizálásban?
Emberi beszéd lenne, és cél a lehető legkisebb bit/sec ráta. Semmiféle jó minőség nem kell, torzulhat is a jel, éppen csak az érthetőség szintjét kellene megtartani. Hangcsomagokat digitalizálnék és soros porton küldeném számítógépre. Van erre support pic-hez, vagy valami spec külső áramkör, vagy hogyan célszerű?
8kHz mintavételezés az érthetőséghez elég, annyit meg lazán tud bármelyik pic AD-je, nem kell ehhez semmi hókuszpókusz. A lényeg, hogy a jelszintet hozzá kell illeszteni a pichez pl. műveleti erősítővel, megírni a firmware-t és mehet a dolog.
Jó hát ennyit meg tudok tenni végülis. Egy tapasztalat arról érdekelne esetleg, hány biten érdemes mintavételeznem a jelet.
8 biten 8 khz az 64 kbit/sec. Ofc, ennek a tizedére is húzom a számat  Van esetleg valami mégiscsak hókuszpókusz gsm tömörítő vagy ilyesmi ?
A GSM valtozo bitrataval dolgozik eleve es egy viszonylag bonyolult tomoritesi algoritmust hasznal -- ezt en nem javasolnam PIC-re. Tegyel ra egy sima RLE tomoritest, es kezdj el jatszadozni a mintavet frekivel is, akkor ki fog derulni szamodra mi az elfogadhato hang minoseg. Amugy meg 64kbps egyaltalan nem sok, a standard RS232 115kbps-ig birja, ill ISDN 64kbps-ig -- nem veletlen hisz ez az un. 'telefon minoseg', legtobb voip alkalmazas is ezt hasznalja. Ennel en szerintem lejjebb is mehetsz, de 1kHz hangot le kell tudnod digitalizalni. Extrem esetben kiprobalhatod hogyan viselkedik egy interpolacios algoritmus, de annak kitalalasa sok ido es energia (ez mar surolja a GSM-ben is alkalmazott modszereket).
Thx, ** jó tippnek tűnik. Erre nem is kell lib. Egy ilyet magam is összerakok.
** Kérlek mellőzd az angol - magyar keveredést .
Nekem úgy rémlik, hogy az érthetőséghez legalább a 2,4kHz-ig terjedő hangokat kell tudni digitalizálni, de ekkor a telefon másik végéről a beszélőpartner felismerése igencsak kétséges, anya-lánya, apa-fia, egynemű testvérek, stb. rokonságban levőket nagy eséllyel nem lehet megkülönböztetni. A 3,4kHz-ig kell menni legalább, hogy a felismerés is biztosítható legyen. Ezt lehet elméletileg 6,8kHz mintavételezéssel biztosítani, gyakorlatban valóban a 8kHz a reális és mint említette, a 8 bites felbontás.
Igen, valoszinuleg a felharmonikusok azok amitol a szemely felismerhetove valik, es e szerint a cikk szerint az alap frekvenciak 85-255Hz tartomanyba esnek -- gondolom a felismerhetoseghez elegendo az. De majd egyszer lemerem szkoppal, mert enem is erdekel ez a tema, csak most sajnos nem tudom megtenni.
Üdv!
PIC18F4550 m.vezérlővel ismerkedem, Mikro C illetve MPLAB környezetben. Segítséget kérek: 1. hogyan lehet pl. az RA5-re adatot (byte) kiírni és beolvasni. 2. C-ben az OW_reset,OW_write és az OW_read működik és fordítható, ha MPLAB projekbe becsatolom a fordító hibát jelez. 
Szia!
Idézet: „hogyan lehet pl. az RA5-re adatot (byte) kiírni és beolvasni.” RA5 az bit, most mit akarsz csinálni, byte-ot vagy bitet írni? byte --> PORTA=0B10100011; bit --> PORTAbits.RA5=1; A PIC18F4550-nél RA5 induláskor analóg ( át kell kapcsolni digitálissá!)! Nem azzal van bajod?! Idézet: „C-ben az OW_reset,OW_write és az OW_read működik és fordítható, ha MPLAB projekbe becsatolom a fordító hibát jelez.” Ez a C valószínűleg a Mikroc, amit írtam Neked korábban... Az MPLAB nem ismeri azokat az include és header fájlokat, le kell neki írni, ha használni akarod --> hibajelzés!! + a sebességet ( késleltetést ! ) is megfelelően állítanod! Steve
Üdvözlök mindenkit!
PIC kérdésben abszolút kezdő vagyok ezért gondoltam, hogy már kész dolgokkal próbálkozom először. Terepasztalomat szeretném digitalizálni és egy a neten található kapcsolást építettem meg és a hozzátartozó programot (kész HEX) próbáltam a PIC-be tölteni, de nem működött. Több problémára is gyanakszom, de mind ez csak gyanú. Ezért fordulok hozzátok hátha valaki tud segíteni. Az első gyanú: az MPLAB az asm fájl kapcsán több hibát is jelzett, de lehet, hogy csak én bandzsítottam el valamit a programba. A második gyanúm, hogy a kapcsolásba 8MHz-es kristály oszcillátort kellett beépíteni, de a PIC típusa amit használok PIC16F84A-04, ami az utánajárásom szerint csak 4MHz-ig működik. Kérdés, hogy ha 4MHz-es re cserélem az oszcillátort, akkor működhet-e a dolog. Hozzászólásaitokat előre is köszönöm. Üdv: ipijani
Szia.
A PIC16F84A 20MHz-ig működik a specifikáció szerint. Először talán a fordítási hibákat kéne megszüntetni.
Hali!
Nem tetszik az MPLAB-nak a "config" nevű változó, lecseréltem "konfig"-ra. Továbbá a "movwf" parancs nem a BANK0-ban van, de szerintem azt kijavítja (azt nem írtam át). Csatoltam a javított verziót, próbáld meg ezt lefordítani. Szerk.: nyugodtan berakhatod a 8MHz-es kvarcot.
Üdv.
Igen most már tudom hogy az MPLAB/C18 nem ismeri a MikroC-t. Azt is tudom hogy a portot digitálisra kell beállítáni, bit és byte fogalmát is. Az A port 5. bit-jét akarom használni jelsorozatok beolvasára, konkrétan DS 18B20 hőszenzor. Adatlapja és az 1wire protokol meg van. Reset 'kimegy', jelenlét jel meg van. Ezek ugye 1 bites adatok. Be kellene olvasnom az azonosítót 64 bit (8+48+8), Ehhez először ki kellene küldeni (5.bit kimenetre állítás után) 55h-t és (bemenetre állítás után) beolvasni. Szóval nem tudom hogy kell kiküldeni a kimenetre állított RA5-ön az 55h-t és bementre állítás után beolvasni a 64 bites adatot.
Köszönöm!
Sajnos még mindig nem működik. Még futok egy kört a „Digitális vasútmodell” topic-ban, hátha rosszul üzemelembe. Üdv: Ipijani
Ha megnézed a DS adatlapját, akkor látod, hogy időszeletek vannak... Az adás kezdete után adott időnként egymás után kell kiküldeni a biteket, azaz kiadok egy bitet, várok x időt és adom a következő bitet az RA5-n és így tovább, egészen az utolsó bitig!
Adatlap kötelező a megértéshez :yes: ! Steve
Üdv.
Ez a következőt jelenti? mivel 55h az 1010101: 1. kiküld 1 2. várakozás 3. kiküld 0 4. várakozás .... és hogy történik a beolvasás, ennek fordítottja? Az adatlap megvan az 1wire-t ismerem, a konkrét megvalósítás a gondom.
1. beolvasas elso bit
2. várakozás 3. beolvasas kov. bit 4. várakozás ....
Ezt olvasd el: AN1199 1-Wire Communication with PIC Microcontroller
Üdv.
Köszönöm a válaszokat, igazán sokat segítettetek. Kezdem érteni, próbálkozom a megoldással.
Létezik pic-hez olyan szoftver támogatás, amivel afféle mini programokat lehet gyártani? Olyasmire gondolok, mint pld pic 32-esnek leküldeni soros porton egy programot valamilyen nyers formában, amit futtatni tud (tud memóriából végrehajtani). Van erre bármi kitalált módszer?
Most biztos nem fogod szeretni ezt a dolgot, de így a legelején, amíg legalább az első példát igazán megérted, végig kellene szenvedned az egészet saját lábon bitről bitre.
Az igazán profi megoldás az lenne, hogy kvarc pontos oszcillátor mellett egy timert megszakításra raksz, az adatokból shift regisztereket modellezel, és leprogramozol magadnak adat átviteli buffereket kimenetre / bemenetre. Aztán bitenként shiftelgetsz a megszakítás vektor esemény kezelőjében (fázisregiszterbe elrakhatod magadnak, hogy éppen milyen esemény is zajlik). Ha már egyedül is frankón egybe tudod barkácsolni, a kész kód legózgatással utána is ráérsz. Különben igazán nem nagy munka saját lábon végig tolni. A struktúrált gondolkodásra persze szükség lesz hozzá. Idézet: Bootloader van. Egy 100 000-szer újraprogramozható mikrovezérlőnél ez teljesen kielégítő megoldás. „Van erre bármi kitalált módszer?”
Vannak interpreterek, de nem javasolt. Pl Parallax BasicStamp-je is ilyesmi, meg van Forth nyelv is, de ahogy mar emlitettek elottem szimulatorral (szoftveres debug), vagy emulatorral (hardveres debug) jobban jarnal es akkor nem kell megalkudnod sem.
Nem debug-ot akarok. Az más.
A scriptelés már közelítene, de technikailag nem stimmel. A scriptelésnek az a lényege, hogy van egy lib, aminek a funkcióit hívogatod, és amikor ráhívsz, addigra már a teljes lib ott van a pic-en, és csak a felső szintet írogatod át. Egy hálózatra felgyártott kicsi elektronikánál ez egyáltalán nem biztos. Nem lesz ott a lib. Maga a lib is kell, hogy tudjon bővülni, és időnként csak átmeneti funciókkal. Olyasmi, mint pc-n a dll-ek, vagy temp pluginok, vagy mifenének lehet még őket nevezni. Ennek a bootloader technikának még utána lesek, de előre gyanítom, ott is fixen rögzített kódról van szó, és nincsen kitalálva dinamikusan részletenkénti kód bővítésre - vagy igen? Interpreterek megint csak a scriptes dolgok. Azokat hagyjuk. Szerintem nem pic-re való a scriptelés meg ilyesmik. Asm / C, ezekkel ki vagyok békülve, de pic-re már a C++-ra is nagyon furcsa szemmel nézek, nem hogy basic ???
Sziasztok!
Ma kigondoltam egy belső eeprom-ból való LCD cg-ram adattal való feltöltését. Ez az első próbálkozásom. Az lenne a kérésem, hogy valaki rá tudna-e nézni, hogy a 1. movlw 0 2. movwf EE_cime ; kezdőcím beállítása 3.olvas movf EE_cime,w ; a cím a w-be 4. call RD_EE ; olvasás rutin 5. call LCD_Txt ; lcdbe töltés 6. incf EE_cime,1 ; adatcim növelése 7. swapf EE_cime,w ; nybble csere -->w-be 8. xorlw b'10000111' ; kizáróvagyolás  9. btfss STATUS,Z ; 0? szóval elérte a végét? 10. goto olvas ; nem, még nem 11. tovább ; igen elérte, további feladatok.. rész mennyire jó? Előre is köszi! |
Bejelentkezés
Hirdetés |
