Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Hello watt.
A varázslóval végigvittem a dolgot. Ha meg akarom nyitni a workspace-t nem látja a .mcp file-t Ha a windows intézővel megnézem akkor ott van, de ha rákattintok, hogy nyissa meg, akkor azt írja ki hogy "zárolás megsértése"
Üdv mindenkinek!
Tudom hogy ez a kérdés nem igazán kacsolódik a PIC-hez de progarmozáshoz annál inkáb. Szertnék építeni egy "egyszerű" robotot amin tudok kisérletezgetni ,játszogtani, kipróbálni pár újítás...stb. Az egészet úgy képzelem hogy egy viszonylag kis teljesítményű ( P3-mas) gépre motort , érzékelőket és kerekeket aggatok, erre írok egy programot és a kis gépe megcsinálj azt.Nagyából enni a tervem dóhéjban. Pascal nyelven írnám a prgramokat,az alapokat nagyából be is tanultam de mégsem tudom megvalósítani a tervem mivel nem tudom hogy hogyan tudok mondjuk LPT portot kezelni. Az LPT potra szertném rákötni a motrot,az érzékelőket és miegymást. Egyszóval a kérdésem: Hogyan tudok LPT prtot vezérlni/kezelni? (vagy akármilyen más sorosportot pascal nyelven)  Kérlek segítsetek! Előre is köszönöm.
Ha tudod, hogy teljesen off a kérdésed, akkor miért írod ide?
 Keress egy megfelelő topicot, kérlek! Arra is nagyon morcos leszek, aki válaszol!  Kedves modi sorstársak, nem lehetne ezt törölni(természetesen az enyémmel együtt..?
Ha megvan az asm, akkor csak azt próbáld az új project-be beilleszteni, mint forrás. Ne próbálj már kész .mcp-t máshonnan megnyitni.
A MPLAB-ot úgy telepítsd, hogy rögtön a gyökérbe kerüljön, és nevezd át, hogy azzal is spórolj az elérési út karakterhosszával(64 max). Nekem pl. MPL a neve a könyvtárnak. Az elérési út beállításokat a Project/Build Options/Project fülnél tedd meg.
Sendi,
Most neked tulajdonkepp 8.00 vagy 8.02-d van? Eloszor is 8-as sorozatban en eleg sok hibat latok, a legutolso tokeletesen mukodo (vagy legkevesebb problemaval rendelkezo) MPLAB nalam meg mindig a 7.41. Sajnos az a PicKit2-t csak eleg gyengen tamogatja, es ezert az uj laptopomon a 8.02 van fent, ilyen hibaval meg nem talalkoztam amivel szenvedsz de nem is lepodnek meg. Eloszor probald meg ujra telepiteni, szerintem szedd is le a legutolso valtozatot es ugy. Ha nem segit, akkor 7.6x vagy 7.40-et tedd fel, ezek az archive-bol leszedhetok a Microchip oldalarol.
Nem olvastam, valahogy átsiklottam felette, ne haragudj. Viszont megint kezdek összekeveredni.
 Az adatlap szerint a 12F675 nél így néz ki a mentés és a visszaírás:MOVWF W_TEMP SWAPF STATUS,W BCF STATUS,RP0 MOVWF STATUS_TEMP : : (ISR) : SWAPF STATUS_TEMP,W MOVWF STATUS SWAPF W_TEMP,F SWAPF W_TEMP,W RETFIE Itt nem is szerepel a MOVF utasítás ami ha jól néztem utána az "F" kiolvasása A "W" be, vagy csak tesztelésre. Sőt előbányásztam egy régebbi ASM et ami 16F90 re íródott és megszakítást használ. Abban sincs MOVF utasítás. Hogyan jön ez a képbe?
A W vissza allitasa az utolso muvelet a retfie elott. Ha ez MOVF-el tortenne meg akkor az allitgatna a Z flaget ami nem biztos szerencses dolog, jol osszekavarhatja a firmwared...
SWAPF ha megnezed nem allitgat flageket, emiatt ezt hasznaljak mentesre. Ennyi az egesz, semmi mas boszorkanysag nincs ebben,
Hello trudnai.
Köszi az ötleteket, ezen már túl vagyok. Semmi nem változott. Azonban megtaláltuk a hibát.(egyik barátommal) Mint írtam, új virusírtot telepítettem.Ez még nem gond, de ellenőrzés közben nem tudni mi okból zárolta az egyik mappát. Így megnyitni sem engedte a az oda elhelyezett filet, sem oda menteni sem. (irta is, hogy a zárolás megsértése). Nyitottam egy új mappát, oda másoltam a megnyitni valókat, és simán megnyitotta az MPLAB, és mentett is oda. Ennyi volt, hátha tanul más is belöle. Köszönöm a segítségeteket. Idézet: „Hogyan jön ez a képbe?” Pont ellenkező előjellel. Ha újra elolvasod amit írtam, rájössz, hogy pont azt írtam, hogy a MOVF utasítást kell valahogy kihagyni, mert az állítja a STATUS biteket.
Lenne még egy kérdésem. Ha a komparátort beállítom akkor a hozzá tartozó lábakat külön be kell állítani a TRISIO val vagy ez megtörténik azzal hogy a komparátort engedélyezem?
A komparátoros kérdést megoldottam egy próbával, tehát megoldódott.
Sziasztok!
Nincs valakinek olyan progija amelyik több analóg csatornát mér és a soros porton küldi azt el?Főképpen a soros adatok (több adat kezelése) küldésének megoldása érdekelne. 
Programom nincs, de ötlet van, ha jó
 Alapból ugye 10 bites a konverzió, jobbra igazítva ADRESL "tele" lesz, ADRESH-ban pedig csak az alsó két bit tartalmaz eredményt. Mintavétel után így a maradék 6 biten tetszőleges azonosítót lehet lekódolni, ami alapján a PC-s program már meg tudja különböztetni a csatornákat. Küldéskor meg csak arra kell figyelni, hogy mindkét byte átmenjen.Több csatornán dolgozva figyelj az időzítések betartására, és csak befejezett konverzió után válts közöttük.
A másik megoldás, hogy megméred mindegyik csatornát és letárolod, majd ha mind megvan, akkor azonnal, vagy bizonyos ütemmel elküldöd. Az ekkor megérkező adatok sorrendje azonosítja a csatornákat.
Amúgy a kérdésedből nem derült ki, hogy milyen mélységben kéne ezt a dolgot kifejteni, lehet, hogy ezek az elmélkedések nem sokat modanak neked... Nemrég betettem ide egy soros vonal kezelő progit(keresd vissza), lehet, hogy az segít ebben a részben. Az AD kezelése pedig elég részletesen benne van az adatlapban is, de a microchip oldalán lehet találni komplett példákat.
Felallitasz egy adatatviteli protokollt. Pl minden meres egy szam paros, 1. szam a csatorna szama a masodik a mert ertek - kb ezt irta le Kobold ha jol ertettem. Vagy mondjuk minden esetben az osszes csatorna adatait elkuldod, es akkor egy csomagot allitasz elo, elso byte megmondja hany csatorna van a csomagban, utana egymas utan novekvo sorrendben elkuldod a csatornakon mert erteket. De akarmi mas megoldas jo lehet, ezek mind attol fuggenek mire kell, mennyire kell a protokollnak gyorsnak lennie (pl a CSAT+ERTEK lehet lasabb mint az utobbi megoldas ha mindig az osszes csatornat at kell vinni). De lehet az atvitel sikeressege a fobb szempont, akkor mar jol el is lehet bonyolitani, hogy milyen hibak lephetnek fel a kommunikacio soran es azokat hogy lehet kiuszubolni vagy legalabbis minimalizalni...
Igazából mindegy, hogy a fogadó egy PC vagy PIC. Mivel a protokollt te döntöd el, úgy azonosítod a csatornákat, ahogy szeretnéd. Ahogy előttem is mondták: ha az adatsebesség engedi, akár több byte-ot is átvihetsz, teljesen tetszőleges címzési módot választva.
Ha gyors adatcsere szükséges, akkor watt, illetve trudnai megoldásai jöhetnek szóba, de a végső alak nagyban függ attól, mennyi csatornával dolgozol, egységes-e a mintavétel sorrendje stb. Pl. ha van 6 csatornád, amiket folyamatosan ugyanabban a sorrendben kérdezel le, akkor csak a legelső adatai előtt (vagy abba integráltan) kell egy jelzést küldened a fogadó oldalnak, amiből az tudja, hogy kezdődik a 12 byte küldése; ezután már csak számolnia kell a beérkező byte-okat, és kettesével szétosztva megvannak a mért értékek. Esetleg a legutolsó után mehet egy egyszerű checksum az átvitel ellenőrzésére, és a fogadó PIC csak akkor jelzi ki, vagy dolgozza fel az adatokat, amikor az ellenőrzést (a vett byte-ok alapján) szintén végre nem hajtja, és egyező eredményre jut.
Köszönöm szépen a válaszokat!
Kicsit még pontosítok: Jelenleg már műkszik a progi olyan szinten ,hogy az első PIC egy AD csatornát mér, majd 9600-al átküldi a második PIC-nek ami kijelzi egy LCD-n!Próbáltam keresni a neten, de nem találtam rá példát, hogy ez miképpen szokás csinálni több adat esetén.Olvastam arról a megoldásról is,hogy a 9bites átvitel használatos ahol a kilencedik bit jelzi,hogy adat vagy érték az átvitt információ.Majd 6 AD csatornát szeretnék mérni + 32 bemenetet figyelni.( a 32 bemenet időmultiplexelve van,4x8).Mivel több minden történik,nincs folyamatos átvitel, ezért kell valami biztos megoldás erre.
Az adat, meg az érték között szerinted mi a különbség?
A 9. bit a címbit egyébként. De való igaz, hogy sokminden mást is jelenthet, ha van valami értelme. Itt nincs.
Semmi ,csak a szóismétlést kerültem!
ok! Benéztem!Tehát : adat vagy cím helyesen!!!!
Egy bit úgyis kevés lesz 32 csatorna azonosításához. Vagy elmented a mérő PIC-ben az értékeiket, és egy start-jelzéssel egyszerre átviszel mindent, vagy kisebb csoportokra bontva, esetleg egyesével címzel és küldesz. Több lehetőség nem nagyon van.
Igen,én is valahogy így gondoltam:1 cím+1 adat 2bájtosával küldve!
Ha a 9.bit,címbit 1 ,akkor ez lesz a mért csatorna száma,ha 0, akkor ez lesz a mért adat!
Ez így már jó lesz. Esetleg még lehet finomítani, hogy ha az AD konverzió mind a tíz bitjét át kell, vinni, akkor pl. az alsó két bitet el lehet helyezni a címet tartalmazó bájtban. Így a 32 csatorna azonosítója plusz a két alsó bit épp elfér a 8 biten, csak be kell hozzá billenteni a 9. bitet, hogy a vevő tudja, hogy ebből ki kell hámoznia a sorszámot.
Szerintem kár ezzel a 9. bittel elbonyolítani a dolgot. Érdemes olyanra megcsinálni, hogy adott esetben egy PC-n, hyperterm-mel, vagy akármilyen soros terminálprogival debugolható legyen. A 9 bites megoldás nem egészen ilyen.
Azt kell először eldönteni, hogy a küldő oldalon mikor kell adatot küldeni. Ez lehet pl. a bemenetek állapotának megváltozásakor, vagy rendszeres időközönként, vagy esetleg a vevő oldalról beeső kérésre. Ha ez megvan, akkor el kell dönteni, hogy egy csomagban mit akarsz átküldeni: az összes létező adatot, vagy csak azt, ami megváltozott, vagy csak azt, amit kért a lekérdező. Ezután meg kell tervezni a válaszcsomagok tartalmát, lehetőleg a csomagok elejét és végét jól azonosíthatóvá tenni. A vevő oldalon a csomag egyértelműen dekódolható kell, hogy legyen. Ha csak egy részadatot küldesz (pl. annak a portnak a bitjeit, ahol változás történt), akkor valamilyen címet bele kell építeni a "csomagba", ami alapján értelmezed az adatot. Ha mindig mindent küldesz, akkor pedig nem kell címekkel bajlódni, olyan struktúrát kell összeállítani, amiben mindig ugyanazon a helyen van ugyanaz az adat. Szokás az ilyen adatcsomagokat STX (start text) karakterrel kezdeni és ETX (end text) karakterrel befejezni, ekkor a fogadó ezeket is ellenőrzésként megköveteli. Ha jól emlékszem, ezek 3 és 4 ASCII kódú karakterek. De amúgy ahogy mondták többen is, lehet beépíteni valamilyen CRC-t is ellenőrzésképp. A dolog Rajtad múlik, hogy hogy érzed célszerűnek, erre "szabvány" nincs.
Na en mar teljesen megzavarodtam. Szoval az egyik PIC egy adat gyujto, ami 6 analog es 32 digitalis jelet gyujt es ezeket kell egyik helyrol atvinni a masikra?
Kerdesek, amire leginkabb sajat magad szamara kellene megtalalni a valaszokat, ill ha "hangosan" gondolkodsz ezeken akkor mi is tudunk segiteni: 1. A PIC amelyik szamara a mert adatokat el kell kuldeni az kerdezoskodik, vagy az adat gyujto PIC automatan megadott idokozonkent kuldi az adatokat? 2. Minden alkalommal az osszes csatornat el kell kuldeni vagy aszinkron modon "ahogy esik ugy puffan" elven ami bejon adat az megy is at rogton? 3. Minek kell tortennie ha ket meres kozott nincs elteres? Akkor is el kell kuldeni vagy csak ha valtozik az meres eredmenye? 4. Milyen sebesseget kell elerni az egyes csatornakon? Hany sps (samples per second)? 5. Mindehhez mekkora sebesseg kell a soros porton? (bps - bit per second) - beleszamitva esetleges szinkronizacios vagy adat helyesseg ellenorzo lepeseket is... 6. Mi fog tortenni ha az atvitt adat megserul? Most hirtelen mas nem jut eszembe, biztosan lehet meg ehhez hasonlo kerdeseket feltenni egy ilyen project eseteben.
Igen,az első PIC:6 AD csat.+32 digitális bem.Második PIC adat fogadás+ LCD-n a mért értékek kijelzése.
Az AD csatornákat folyamatosan küldeni kellene minden mérés után (ha nem változik akkor is), ugyanis ez változhat folyamatosan is akár 0 és max. között.Nagy mintavételezési sebesség nem szükséges (kb.0,2 sec is elég lenne). A 32 bemenetek(4x8) közül csak azt a 8-at, esetleg ha kell másikat is amelyik közül aktív bármelyik is.Ha nincs egy aktív bemenet sem,akkor ezt nem kell küldeni!Szerintem ezt viszonylag kis átviteli sebességgel is meg lehetne oldani,ahol kisebb a bittévesztés esélye....Adatsérülés-a következő adatküldéskor korrigálódik.Nincs igazán komoly jelentőssége! Na alszom rá még holnapig! Köszönöm a sok választ!
Baromira elbonyolítod. Nem kell itt címezni! A címzés akkor jó, ha több vevőd lenne, de nincs!
Letárolod a mért adataidat egy tömbbe, majd ezt a tömböt elküldöd. Az érkezés után szintén egy tömbbe tárolod. A letárolt tömbben minden adat ugyanott lesz, mint a forrás PIC-ben. Ebből talán már tudnod kéne, melyik bájt mit jelent! Ha nem akarsz CRC-vel bíbelődni, akkor kétszer elküldöd a tömbböt, és ha mindkét adatcsomag egyforma, akkor elfogadod jónak. A 0,2sec-be simán belefér a kb. 50bájt átviteled 9600-baud-on! Részemről lezártnak tekintem a témát, mert már szédülök a sok hozzászólástól, ahogy szétbonyolítanak egy ilyen halál egyszerű dolgot! (tisztelet a kivételnek!)
Van valakinek ötlete, hogy hogyan lehetne megismételhető kommunikációs hibát gerjeszteni egy RS485-ös hálózatban, célzottan, időzítve?
|
Bejelentkezés
Hirdetés |
