Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „a multiplex hibaja eppen a fenyero oszlasa az idoszelet miatt...” Ezekkel az ujabb LED-ekkel egeszen jok a tapasztalataim, mar az eloirtnal joval kevesebb arammal is nagy fenyerot produkalnak. Az egyetlen problema az szokott lenni, hogy nemelyiknek kisebb a latoszoge, tehat kisse oldalrol nezve mar nem latszik annyira fenyesnek, de talan ez nem problema egy modell vasut eseteben.
Igen, tökéletesen érted! (fél duplex) (Végre! Hidd el örülök, hogy végre valaki megérti amit írunk! Ez mostanában nem divat!
 )
Csak úgy szólok neked, hogy ez NEM a vasutamhoz készül, mert ezt kiállítási tárgynak tervezem.
Valamint, mivel a pic memóriája nem végtelen, ezért a felrakott kis program elődjében van egy olyan rész amit úgy jelöltem: //ism [itt egy szám]x Valamint úgy, hogy: //ism vége ezt a részt kéne ismételtetni annyiszor, ahányszor oda van írva.
Látom közben szilva elmagyarázta a lényeget, én csak annyit tennék hozzá, hogy a karaktereknek címeik vannak, amit be kell állítani a programban, mielőtt kiviszed a szöveget. Ha a kijelzőnél máshová esnek a címek az áramköri kialakítás miatt, akkor történik ez a felfordulás. Ezért írtam, hogy kell az adatlap(vagy ki kell molyolni próbálkozásokkal a címeket, de ez nagyon macerás tud lenn, még akkor is, hanem túl sok cím van.).
Nagyvonalúan elsiklottál az itteni hozzászólásom fölött, pedig abban már megírtam, hogy ciklusszervező utasításokkal lehet programrészeket ismételni (és C jegyzetet is adtam hozzá).
Arra is megkértelek már, hogy nevezd meg a választott fejlesztői környezetet, és a fordítót, hogy ÉRDEMBEN segíteni tudjunk. AVR-re írt programok pedig nem fognak a PIC-en futni (sőt, lefordulni sem...)! A konkrét kérdésre: Adott számú ciklus szervezéséhez kell egy változó számlálónak. Például:
Ez a fél duplex dolog nem tetszik benne, hogy mindig kapcsolgatni kell a vétel és adás között. Találtam viszont egy ilyet: Bővebben: Link
Ez nekem úgy tűnik mintha valami automata irány kapcsoló lenne. Szimulátorban próbálom épp. Nem azt csinálja amire számítottam: azaz adás kezdetekor átkapcsolja ugyan adásra, de amint végetér 1 bit, már le is kapcsolja az adót. Én meg azt hittem hogy adáson tartja legalább 1 byte ideig. Idézet: „Én meg azt hittem hogy adáson tartja legalább 1 byte ideig.” Az időzítést meg az adatsebességet össze kell hangolni. De szvsz az irányváltást jobb a PIC-re hagyni, ő jobban tudja, hogy mikor kérdez, mikor várja a választ. Mellesleg a kétirányú forgalommal elég messzire kanyarodtál az eredeti felvetéstől, melyszerint csak egy TTL jelet karsz elvinni. (A végén fogpiszkáló lesz belőle, ha azt is el nem... koncepcionálod!  ) Nem is tudom, hogy RS-485 és a 9 bites üzemmód (cím/adat) nélkül hogyan gondoltad az eszközök címzését és az oda-vissza kommunikálás szervezését?
Bár nem néztem meg az adatlapját, de két vezetékkel nem lehet automata(pontosabban nem úgy automata, hogy irányt vált, hanem bármikor beszélhet bármelyik, de ez egyébként is így van, csak abból hangzavar lesz, akkor meg minek). A fullduplex komunikációhoz két ilyen IC kell és meg is van oldva. Úgy is UTP kábellel kell szerelni, abban meg van vezeték bőven.
De én nem látok semmi bajt a félduplexben. Egy master-slave kapcsolatnál a kommunikációt a master indítja, a slavek csak akkor dumálhatnak a vonalra, ha őt szólították meg. Semmi értelme aközben a masterhez szólni, miközben más slavet szolgál ki, vagy szólít meg éppen. Ha megszakításra van szükség, azt egy szál dróton meg lehet oldani, de nem sok olyan slve szokott lenni egy láncban, ami olyan fontos lenne, hogy ne lenne elég az UTP kábel fennmaradó 6 vezetéke erre. Nálam egyébként 2szálon meg a kommunikáció, 2x2szálon a táp, és a maradék két szálon jön az interrupt a tasztatúra-TFT egységtől és a PC-USB-MMC egységtől. A többi egység nem csinál olyan dolgot, ami halaszthatatlan(szobák, kijelzők és egyéb kiszolgálók). Igaz nem tudom mit akarsz megoldani, de szerintem kevés olyan van, amihez ne lenne elég a sima félduplex. Programozásuk is könnyű, mert a PIC (E)USART támogatja a 9. biten történő cím adat jelzését. Így a slavek is tehermentesülnek egy másik slave-vel folytatott adatforgalom közben a hálózat vizsgálgatása alól és csak akkor nézik meg az adatot, ha 9bites címadat kerül a hálózatra. Természetesen címzést csak a master kezdeményezhet.
Úgy gondoltam, hogy amit master küld, azt mindegyik slave megkapja. És az üzenetből eldönti, hogy rá tartozik-e, vagy sem.
Azután gondoltam olyanra is, hogy figyelik a slave-ek a master felé menő vonalat, és csak akkor adnak, ha szabad a vonal már egy ideje. Vagy lehetne úgy is hogy csak akkor adnak a slave-ek, ha a master utasítja őket. Jah, az 555 -ös adókapcsoló működik végül, tényleg csak meg kellett növelni a RC tag időállandóját. (1200 baud hoz 39k, és 100n) Idézet: „Azután gondoltam olyanra is, hogy figyelik a slave-ek a master felé menő vonalat, és csak akkor adnak, ha szabad a vonal már egy ideje.” Ennél meg kell oldani a Slave-ek közötti ütközés feloldását. Idézet: „lehetne úgy is hogy csak akkor adnak a slave-ek, ha a master utasítja őket.” Ez mentesít az előző problémától.
Sziasztok!
Játszottam egy kicsit a banksel makroval, de minden esetben 2 utasítást fordít a kódba!  Sok esetben elég lenne egy utasítás is a bank válásához. Írtam két másik makrót: A program elején InitBank PORTA, beállítja a kezdő bank-ot. Ha bankváltás kell, a SelectBank csak annyi utasítást fordít, amennyi kell. InitBank macro reg sel_bank set reg endm SelectBank macro reg if (sel_bank ^ reg) & 0x100 if reg & 0x100 bsf STATUS,RP1 else bcf STATUS,RP1 endif endif if (sel_bank ^ reg) & 0x80 if reg & 0x80 bsf STATUS,RP0 else bcf STATUS,RP0 endif endif sel_bank set reg endm InitBank PORTA SelectBank TRISA SelectBank EEADR SelectBank PORTB SelectBank EECON2
Nem rossz! Tetszik, ahogy kinyered a regiszter bank értékét a címéből! Gratulálok!
Valóban felmerül a jogos kérdés, hogy ezt a fordító mi a fenéért nem tudja gyári kivitelben lekezelni!? Esetleg küld el nekik, hátha beépítik az előfordítóba! (Lehet jobban olvasható lett volna, ha használod a code=asm formázó parancsot. Vagy más miatt nem használtad?)
Ja most látom, hogy 94 hozzászólás! De csak a fórumozásban vagy kezdő, ahogy látom!
Szóval a Kód gomb, és a kis szerkesztés amit írtam és szép lesz a kód megjelenése. Ezt az offot pedig kijelölöm és rákattintok az OFF gombra és ettől lesz ilyen szép szürke! A többi gomb is hasznos...
Ez a 9. bittel jelölt cím is érdekes lehet. Olvasom az adatlapot, de nem tiszta teljesen.
Adó oldalon kell kiküldenem először egy bytenyi címet (megjelölve a 9. bittel), majd utána egy adatbye-ot. A vevő, pedig ha jól van beállítva minden, akkor csak akkor generál megszakítást ha a címe egyezik az épp vett cím byte-al? De ilyenkor minden atatbyte előtt címbyteot is kell küldenem ? És feldolgozáskor mikor kiolvasom a RCREG-et, már csak az adatbyteokat kapom meg ? (tehát a címet lenyeli?)
Ó, most sikerült találnom bővebb infót erről, de nem sok mindenre jó ez a 9. bit jelölte cím. Az egész csak annyit tud, hogy ha így van beállítva akkor a nem megjelölt byteok nem kerülnek be a vevő pufferbe. Így szoftverből kell ellenőrizni a címet, és ha stimmel, akkor engedni kell a többi byteot is. De akkor már nem módosítom a jól működő soros port programomat, megoldom enélkül a 9. bites bohóckodás nélkül is.
Bővebben: Link
Hát ez elég érdekes hozzáállás, mert szerintem sokkal egyszerűbb és hatékonyabb.
Nem beszélve arról, hogy azt hogy oldod meg, hogy miközben az adatok mennek, és az egyik adat pont az egyik slave címe, hogy az ne induljon be arra? Honnan fogja tudni, hogy cím, vagy nem? Számlálja a csomagban lévő bájtokat? És akkor csak egyforma csomagokat lehet küldeni? Elég kényelmetlen, és erőforrás pazarló dolog azt számolgatni, hogy beért e a megfelelő számú adat, és a következő lesz az új cím. Aztán mi van, ha az egyik slave szinkronja elcsúszik egy hibás vételtől? Borul a mutatvány!
Komplett packeteket küldenék, és csak hibátlan packet -et dolgoznék fel.
Pl ezt küldi a master: Cim:05:abcdefg......# A # lenne az adatcsomag vége jelző. Mindkét esetben ki kell dolgozni valami protokollt. Számomra egyszerűbb szoftvert írni, mint módosítani a soros rutint. Még ha lenne hardveres cím dekódolás akkor meggondolnám, de így nincs értelme, kb mindent szoftverből kell csinálni.
A 9 bites hókuszpókusznak két előnye van:
- Jelent némi biztosítékot arra, hogy az adatot nem nézi a slave címnek. - Ha nem stimmelt a cím, akkor a következő 9 bites karakterig a slave nem foglakozik a vonalon menő adatokkal (ez különösen a sok részvevős hálózatokon fontos), tehát több ideje marad a saját feladatainak elvégézésére. Az előző kérdésedre reagálva: az az általad kialakított protokol-tól függ, hogy milyen gyakorisággal kell a címet küldeni. Ha olyan a protokol akkor küldhetsz akár 10 kilobájtot is, mert a slave csak akkor kapcsol vissza címfigyelő módba, amikor - a protokol szerint - megkapta a maga adagját. Idézet: „Számomra egyszerűbb szoftvert írni, mint módosítani a soros rutint.” Én eddig azt hittem, hogy a soros rutin is szoftver. Idézet: „Honnan fogja tudni, hogy cím, vagy nem?” Gondolom, lesznek fenntartott karakterek, amelyek adatként nem mehetnek. Tehát nem küld bináris adatot, hanem csak kódoltat. Például egy kettőspont jelzi az üzenetcsomag elejét, s utána mindig cím következik...
Nem rossz! Ehhez hasonlo makrok amugy leteznek, az egyetlen hatranyuk, hogy a cimkek utan minenkeppen kell egy reset bank (vagy init bank teljesen mindegy honnan kozelited meg).
A masik, mi van akkor, ha a bank 1 van mar kivalasztva, es a bank 1-re nyulsz? Ilyenkor ha jol ertelmezem a mokrod, akkor eszreveszi, hogy a 0x80 bit magas, majd megnezi a regisztert, annal is magas, tehat allitja a bankot... ahelyett kihagyna a bank szelekciot.
Elakadtam HELP!
Terveztem egy PIC-es vezérlést, ahol PIC24FJ256GB110 a főnök. Próbálom az első programot benne futtatni, DE nem megy, nagyon érdekes a helyzet. Minimál terv az volt, hogy az RA4 porton lévő LED villogjon. Mert ekkor tudni fogom hogy a táp, reset, oszcillátor, ICSP funkció működik. Írtam félcenti programot, lsd. lent "24f_3a.c" MPLAB 8.20a -t használok, C30 3.11-et, és PICkit2. Elsőre lefordult a "bonyolult" program, égető felismerte a PICet, beégette a programot és mindent rendben talált, hawaii! Lépésenkénti végrehajtás PICkit2 debuggal megy, animált futtatás megy és RUN-ba is megy, szkóppal lemértem RA4-t. Viszont  ha PICkit2-t eltávolítom az ICSP csatiról és a NYÁKot a saját tápjával kapcsolom be akkor nem fut a program, semmi életjel nincs az RA4 lábon. Eddig 4x5 órám ment rá erre a problémára, nagyon megnéztem a tápot, reset környékét, oszcillátort is a belső FRC-re állítottam, nehogy a külsővel legyen problémája, bár az is jónak tűnik szkóppal mérve. Ez a PIC-et közvetlenül érintő kapcsi rajz, amin a tesztet érintő elemek kiemelve. Ha valakinek aki PIC24F-el már találkozott van valami ötlete azt nagyon megköszönném!!! Addig is átolvasom a teljes PIC doksit még egyszer, 328 oldal
Szia!
Az InitBank -nak nincs kód vonzata - a fordító eltárolja, hogy mi volt az utoljára használt. Ha két SelectBank -ot adunk ki egymás után ugyanarra a bankra a külső if -ek miatt nem fordul be semmi sem. A cimkék után csak akkor kell, ha a megelőző kódokban különboző Bank-volt aktív. Minden lehetőségre nem készült fel, azért adtam más nevet neki, hogy a bankselt is lehessen használni. Egy banksel után valóban kell egy InitBank is. Ki-ki kedve szerint használja. Az indító ok Jobbagyag problémája volt - néhány utasítás átlógott a 2k-s laphatáron
Nekem IDC2-m van, de nekem csak akkor fut a program az ICD nélkül ha az MPLAB-ban a programmer részben az ICD-t kiválasztva programozom fel a PIC-et. Debugger-ből felprogramozva belekerül az ICD-vel kommunikáló program is, ami nem indítja el a program futását ICD nélkül. Gyanúm szerint a Pickit2 is így működhet.
Ugye, a PICkit2 lehúzása előtt fordítottál egy Release változatot, és be is égetted?
Mellesleg a bit kapcsolagatások között kellene egy kis szünetet tartani. Igaz, hogy a mellékelt program PIC24HJ128GP502-re készült, ráadásul RB15-ön van a LED, de talán adhat ötletet. Az ODCB (open drain kimenet) beállítását hagyd ki. Nekem bizonyos okok miatt úgy kellett...
Ez egy full lineáris szervezésű programnál hasznos is lehet, ám ahol elágazások vannak, ott nagyon figyelni kell, hogy milyen ágról érkezik a progi!
Esetleg kellene még egy makró, ami "meghatározhatatlan"-ra állítja a belső lapmutatót, ezáltal azt kiváltva, hogy a legelső bankváltó makró mindenképpen az összes bankváltó bitet használja. Ezt a meghatározhatatlanra állító makrót kellene olyan címkék után használni, ahová a program futása során több helyről kerülhet a vezérlés, valamint szubrutinok elején, illetve szubrutinhívások után is. De lehet, hogy valamit még így is kihagytam Idézet: „Az InitBank -nak nincs kód vonzata - a fordító eltárolja, hogy mi volt az utoljára használt.” Ez nyilvan valo es ez igy jo, ambar nem szerencses lkeverni a BANKSEL makrot es egy ehhez hasonlo bank szelekcios makro gyujtemenyt mert az eredmeny akar hibas kod is lehet. Szoval tekintsuk az alabbi egyszeru 'nyomkovetest':
Ezert kell a cimkek utan feltetlen egy resetBank ami kikenyszeriti, hogy a legkozelebbi SelectBank-nal mindenkeppen tortenjen bank szelekcio - sot olyankor sokkal jobb ha BANKSEL makrot hasznaljak (a makrobol, nem kivulrol!) mivel a bank allapota nem nyilvanvalo es tobb, mint ket bank eseteben jobb az ovatossag... |
Bejelentkezés
Hirdetés |
