Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Most probalgatom az MPLAB X betat Linux alatt.
Kis ossze foglalo: - Java alapu cucc, Netbean-en alapszik - Windows, Linux es MacOSX is tamogatott - PK2-t NEM tamogatja! - Itt a Linux alatt a szimulator ugy tunik nem el, legalabbis a betaban nem - Ugy tunik mintha ez egy modern fejlesztoi rendszer lenne, pl kiemeli a fuggveny neveket, valtozokat stb es igy klikkelesre lehet a forrasban a definiciora ugrani stb - Tulajdonkepp nagyon szep es jo, kicsit talan lehetne gyorsabb is - gondolom ez a Java alap miatt van, hogy nem ugyanaz a feeling mint egy nativ kodu alkalmazassal...
Azért szerintem kicsit meredek lenne olyan hardvert építeni, aminek a másik vége akár a 12Mbps, 3.3V-os logikai jelszintű USB-be, akár a maximum +/-25V-os jelszintű RS232-be is bedugható legyen, és mindkét esetben az elektromosan korrekt illesztés (lezárás) jöjjön létre.
Mivel az általad felsorolt kommunikációs felületeknek mindnek mások az elektromos követelményei (és ez nem csak a feszültségszintekre áll), ezért én nem tartom túl jó ötletnek, hogy ugyanazokon a csatlakozási pontokon akard ezeket fogadni. Már az RS485 és az RS232 között is óriási a különbség, de az USB végképp kilóg a sorból. Jobbnak tartanám azt, ha mindhárom interface hardveres kezelését megépítenéd előírásszerűen, úgy, hogy a PIC felé mutatott oldaluk már egységes legyen, pl. egy TTL szintű, külön RX és külön TX vonalakkal kommunikáló, aszinkron soros átvitel. RS232 és RS485 esetén ez a megfelelő szintillesztőket, buffereket jelenti, USB esetén egy USB/soros átalakítót, ami lehet pl. FT232 is, de akár egy PIC is megfelelő firmware-rel. Az interface-eket kezelő PIC programjába aztán lehet automatizmusokat beépíteni, amiknek segítségével felismerheti, hogy melyik vonallal kell kommunikálnia. A vonalak közötti választás is lehet tisztán szoftveres (mindhárom interface TTL jelei bemennek a PIC-be), vagy hardverrel támogatott (külső kapukkal, multiplexerekkel egy, a PIC felé néző RX/TX jelpár előállítása).
Én eddig úgy tudtam, hogy az interfészek adottak, csak azt kellene eldönteni, hogy melyik kimenete legyen aktív és melyik protokol legyen kiválasztva. Bár ha különböző csatlakozóval oldjuk meg a "kiválasztást", akkor a kimeneteket sem kell vezérelni...
Igazad lehet, engem ez a hozzászólás kavart meg egy kicsit:
Idézet: „Elindultam azon az úton hogy a jelszintet figyelném.” Viszont ha az illesztők megvannak, akkor csak az adatforgalom vagy a csatlakozó mechanikai csatlakoztatásának észlelése marad. Az USB kommunikáció azért kicsit eltér a másik kettőtől, mert ott akkor is kell "dolgoznia" a firmwarenek, amikor éppen adatcsere nem történik. Ha az adatkommunikáció elviseli a soros porti kommunikáció lassúságát, akkor én valószínűleg az USB-s interface-t is egy USB/soros átalakítóval ilyenre hoznám, a PIC-ben futó programnak így csak egyféle típusú kommunikációt kell ismernie, maximum az interface-ek között választ.
Igen, én is pl. egy FTDIxxx-re gondoltam volna.
Viszont nem csak fizikai protokol jelenthet gondot, sokkal inkább a magasabb szintű. Aza baj, hogy igazából azt se tudjuk milyen eszközöket akar rádugni, mert nagyon nem mindegy, hogy gyári cuccokat, vagy saját gyártmányú eszközöket, amiknek a protokolját is maga írja, azaz esetleg be tudnak jelentkezni. Kevés az infó...
Ez mindenképpen érdekes hír, van itt egy előadás is róla.
Ami számomra a legmeglepőbb, hogy van LINUX-os (parancssori) változata az MCC18-nak is. Kicsit hülye helyre települ, de az elérési út megadása után (export PATH=$PATH:/opt/microchip/mplabc18/v3.36/bin) ez már nem különösebben érdekes. Az example1 (leds.c) mintaprogram lefordítása pl. így ment: mcc18 -p 18f452 -I /opt/microchip/mplabc18/v3.36/h leds.c A linkelés már egy kicsit cifrább: mplink -oleds.cof -l/opt/microchip/mplabc18/v3.36/lib -k/opt/microchip/mplabc18/v3.36/bin/lkr 18f452_g.lkr leds.o p18f452.lib clib.lib De végül előállt a leds.hex állomány (nem próbáltam ki!)
Hmm, nem rossz! A vegen lesz egy elfogadhato fejlesztoi eszkoz keszletuk
Sziasztok,
köszi watt és szilva a gondolatokat. A szituáció akkor megint pontosítva az hogy egy csatlakozó felületem lesz adott a panelen, ezen keresztül kommunikál az eszköz, de különböző területeken(akár más országokban) más más interface-t használnak , ezért egy univerzális eszköz létrehozása a cél(1.fázis kész) Namost addig problémamentes a dolog hogy a felhasználóra bízom az utolsó lépést miszerint Ő állítja be a panelen lévő jumperek segítségével hogy a csatlakozóról a jel melyik illesztőre menjen( és persze hogy a PIC is tudja mit használ az is külön jumper). Jött az ötlet milenne ha a felhasználót kizárnám és intelligensen megtudnám vizsgálni a jelet és a PIC maga eldönti mit és hogyan használjon. Namost a kommentekből is meg pár napos agytörés után is odáig jutottam hogy naturba nem fog menni. Szóval mostmár a soksok jumpertől eljutottam egy DIN kapcsolóig ami a kommunikáció tipusát választja meg , a PIC ezután tudja hogy multiplexeren, switchereken keresztül melyik illesztővel kell kommunikálnia. Határidő sürget, szóval ennél egyszerűbbet "felhasználó barátibbat" már nem fogok találni. (ez már tényleg nem ebbe a forumba tartozik) Azért köszönöm a kommenteket! Szép napokat
Bevallom még mindig nem értem. Hogyan fogsz tudni egy féle csatlakozóval többféléhez kapcsolódni? Az interface-ek azonos csatlakozóval vannak ellátva? Mik ezek az interface-ek, titok?
Léteznek csatlakozók , lehetnek bármilyen alakúak, lpt-től kezdve usb-ig, speciel nekem 8pólusú telefon alj a kérés, és abba dugnak bele olyan kábeleket aminek egyik vége telefoncsati, a másik vége meg épp amit használnak és természetesen a 8 vezeték bekötése adott ( táp, föld, jelvezetékek stb... ), és igen többféle kábel van, de az egyik vége mindnek telefoncsati, a másik lehet tényleg bármi csak jól legyen bekötve és ugye azt használják amit akarnak.Jó példa az ilyen kábelra a telefonok adatkábele.. mindegyik márkának más csatlakozása van a telefonon, és usb-ben végződik. Amúgy ha valaki most húzza a szemöldökét az "ostoba" problémámra , igen én is húztam mikor ilyennel előállt valaki..
Ezen a listán is ugyan azokat írja támogatottnak, de attól még továbbra sem jól, sajnos...
 Idézet: „Tehat ha a program memoriaba toltene el a programozoi adatokat, akkor igen, 10ezer chip valtas utan lehet pk3-at kidobni.” Ezek szerint akkor nem gond,ha én csak max 4-5 félét szeretnék programozni, akkor sosem érné el a 10000-et. Jól gondolom? Köszi a segítségeteket továbbra is. ui: Nem kell valakinek PICkit 2?  
Az önsanyargatás az lett volna, ha felrakom a böhönc IDE-t is. Azt most megspóroltam...
 Ja, és mindez egy 800 MHz-es Pentium III gépen történt. Idézet: „Ja, és mindez egy 800 MHz-es Pentium III gépen történt.” Hat Te tenyleg onsanyargato vagy Idézet: „Ezek szerint akkor nem gond,ha én csak max 4-5 félét szeretnék programozni, akkor sosem érné el a 10000-et. Jól gondolom?” Nem ez a lenyeg, hanem, hogy hanyszor valtasz celeszkozt. Tehat ha van 2 fajta PIC-ed, ez 5ezerszer valtasz a ketto kozott, akkor ugye az 10ezer feluliras a PICkit3 chip-jeben... Amit Hp41C javallott, hogy akkor lehet jobb ha ketto db PICkit3-t veszel, vagy ha 4-5 fajta PIC-ed van akkor inkabb 4-5 db-ot, es akkor nem valtogatsz FW-t a programozoban. Majd megkerdezem vagy rakeresek a Microchip oldalan, hogy hova tarolja a PICkit3 ezeket az infokat, hogy valoban a program memoriaban vagy esetleg az adat eeprom-ban -- mert ez utobbi 1 milla irast is kibir, tehat ott nem jelenthet igazan gondot.
Bocs, még kezdő vagyok. Hol lehet kapni 16f877p típusú picet?
Kösz
Vagy a chipcad nél még olcsóbb. De az utódja mégolcsóbb, a 887-es.
http://www2.chipcad.hu/www/arak.aspx?group=010103
Erre azért tényleg kíváncsi leszek, hogy a különböző feszültségszintű kommunikációs vonalakat hogy tudod két vonalra(Rx/Tx) összehozni!
Vagy az átmeneti kábelben lesz az interface? Ha igen(én mást el sem tudnék képzelni), akkor van elég vezetéked a 8-ból, hogy a kábelen keresztül jelezd(annak különböző bekötéseivel), hogy melyik protokolt kell elővenni! Ha csak 4 vezetéket binárisan értelmezel, 16 féle protokol kiválasztását is meg tudod oldani. 2 vezeték a táp, két vezeték a kommunikáció, 4 vezeték a kód.
Teljesen most kezdem el a picezést. A honlapon találtam egy cikket a nulláról a robotokig és abban az első tesztáramkörben egy pic16f877p típust használ. Ezt ki lehet váltani a 887-essel?
Igen, ajánlott is. Azért némileg eltér, de ez nem akkora probléma, az adatlapból könnyen ki lehet mazsolázni az eltéréseket.
Szia!
Ha a PIC -ben van A/D, akkor egy vonal is elég, az illesztőkben egy-egy ellenállásokkal beállított feszültség osztó leágazását kellene egy éren eljuttani a PIC analóg bemenetére. Ha az illesztő a vezetékben van, már egész egyszerű a feladat: USB esetén USB -> UART konverter, RS232 esetén MAX232, RS422 és RS485 esetén terminálás és 75175, stb. Ekkor az adatforgalom már tényleg az uart TX és RX vezetékén menne....
Szia, csak mielőtt vásárolnál, nézd meg,hogy hogyan ér véget a sorozat.
Idézet: „Ha az illesztő a vezetékben van, már egész egyszerű a feladat:” Igen, ezt írtam én is. Az A/D-s megoldás jó ötlet. Én gombok kezelésére használtam egyszer.
Üdv !
Akit érdekel: Van már PicKit 3 -hoz különálló kezelő progi (még beta!) : http://www.microchip.com/forums/m525698.aspx Így már nem csak mplab alól lehet használni.
Nem sok tapasztalatom van még PIC téren. Volna 1 érdekes kérdésem. Nem tudom, hogy mit szúrtam el.
PIC16f690-es -el csináltam egy panelt, A C portjait használnám, de valamiért a C0-C2-t nem tudom magasra állítani- a multiméter szerint. A C6 működik. A majdnem kész kódot megheréltem mire erre jutottam. A lábakon semmi terhelés sincsen, se földzárlat. Mi lehet a hiba? A kód: [code=c] LIST P=16F690 INCLUDE "P16F690.INC" TIMER1 EQU 0x20 TIMER2 EQU 0x21 ERTEK_H EQU 0x22 ERTEK_L EQU 0x23 SOR_H EQU 0x24 SOR_L EQU 0x25 OSZL_H EQU 0x26 OSZL_L EQU 0x27 TEMP1 EQU 0x28 TEMP2 EQU 0x29 ADL EQU 0x30 ADH EQU 0x31 ORG 0X04 START BANKSEL TRISC ;BANK1 MOVLW b'00000001' MOVWF TRISC BANKSEL PORTC MOVLW 0xff MOVWF PORTC MAIN CALL WAIT BSF PORTC,1 ;Kijelző OSZLOP BSF PORTC,2 ;Kijelző SOR BSF PORTC,6 CALL WAIT CALL WAIT BTFSS PORTC,0 ;Kijelző érzéklés GOTO MAIN BCF PORTC,6 BCF PORTC,2 call GO_AD call GO_CONV call GO_SERIAL BSF PORTC,2 BCF PORTC,1 call GO_AD call GO_CONV call GO_SERIAL GOTO MAIN GO_AD;PORTA.2 digitalizálása RETURN GO_CONV;Kuldeshez elökészítés RETURN GO_SERIAL;3bájt sorosportra küldése RETURN WAIT MOVLW 0x00 MOVWF TIMER2 CLRF TIMER1 DECFSZ TIMER1,1 GOTO $-1 DECFSZ TIMER2,1 GOTO $-4 RETURN END
Szia!
Az analóg egységet is tartlamazó kontrollereknél azokat ki kell kapcsolni, hogy a digitális be- vagy kimenetet lehessen használni... A 16F690 -nél az ANSEL és ANSELH regiszterekkel történik...
Ha most kezded el, akkor szánj még egy kis időt az olvasgatásra, nézd meg, mit veszítesz, ha pl. PIC18 vagy PIC24 helyett PIC16-tal foglalkozol, amelynek nyűgösebb a progamozása.
Tananyagot PIC18-hoz a honlapomon itt és itt találsz, PIC24-hez pedig emitt. Ezeket azért érdemes legalább futólag megnézni, mert kiderülnek belőle a fejlettebb mikrovezérlők jellemzői. Az első 5 fejezetet az MPLAB szimulátorának segítségével lehet tanulmányozni, tehát mielőtt pénzt költenél,már el tudod dönteni, hogy melyik mikovezérlő tetszik, mire van szükséged.
Az a kérdésem lenne még, hogy pár kérdéssel előrébb megemlített cikkben levő pic 16f877-es. Ez megegyezik a 16f877A-I/P típussal?
Laci Idézet: Nem tudom, hogy neked feltűnt-e, de RC0-át bemenetnek állítottad be:„valamiért a C0-C2-t nem tudom magasra állítani”
|
Bejelentkezés
Hirdetés |
