Fórum témák
» Több friss téma |
A boot loader nem nagyon tud "bekever"-ni semmit. Miután a főprogramod elindult, annak a részei többé nem kapnak behívást. Normál esetben.
A pic-el ami gubancod lehet, azt ki is tudod mérni. Tedd azokat a port kezeléseket célirányos függvényekbe, és a továbbiakban már csak azokon keresztül kezeld a portokat. Szerencsére a modulod külön drótozva van, így nagyon könnyű azt kimultiméterezni, hogy kiadsz valami jeleket a vezetékekre, és tényleg tudod-e mindegyik bitet vezérelni, vagy sem. Ha ott nem találsz olyan hibát, hogy valamit elkötöttél, valami ki/bemenet rosszul lett beállítva, mégis piszkáltad a jtagot és nem figyeltél rá, vagy bármi olyasmi, akkor a pic oldalán hiába keresed a bűnöst. Egy kapcsrajzot esetleg feldobhatnál, több szem többet lát.
Az a baj, hogy nincs kapcsolási rajz, én tervezem éppen most.
Műszerrel a kiadott adatokat végig mértem, és sajna mind a helyén van. Mind a címzés, mind az adat és az össze vezérlő láb a helyén van. Azért gyanakszom a PIC-re mert minden látszólag jó, de még sem működik. Kivétel az olvasás. Ha abból indulok ki, hogy az olvasás jó és működik, de a parancsokat nem tudom kiadni, akkor csak a PIC lehet a bűnös. Az USB lehet a gond, de egyelőre nem tudom miért. (legalább is remélem) Esetleg még azt tudom megnézni, hogy egyesével mind a 23bit és mind a 16bit adatportot bitenként állítom úgy, hogy közben egy LED-del vissza is ellenőrzöm. Ha ez megvan, akkor tutira kizárható a vezeték, vagy elkötés illetve hibás működés vagy program. Kicsit lassú folyamat lesz, de muszáj lesz valamit csinálnom mert durva milyen rég óta vacakolok már vele.. Idézet: „Ha abból indulok ki, hogy az olvasás jó és működik, de a parancsokat nem tudom kiadni, akkor csak a PIC lehet a bűnös.” A megállapítás szerintem tökéletesen illogikus. Te egy perifériát kezelsz, aminek a tervezet szerint működnie kellene valahogy, és két oldal közül az egyikről már megállapítottad, hogy tökéletesen úgy működik, ahogyan kell. A logikus következtetés, hogy a másik nem úgy működik, ahogyan kell. Szedd elő annak a nor flashnek az adatlapját, és nézd végig a parancs időzítéseket az időzítési diagramjaihoz. Nekem van egy gyanúm, hogy még mindig nincs a helyén egy késleltetés, vagy valami sokkal nagyobbat számoltál el - például tökéletes protokol tévesztés.
Folytassuk itt mert ez már a memória: Bővebben: Link
Ott találsz egy kód részletet is és az adatlapot is feltöltöttem.
Nem ártott volna olyan vezérlőt választanod, amin teljes portokat használhatsz. A 100 lábúakon pl. a teljes 16-bites B és D port használható, a maradék cím és vezérlőbitek pedig kioszthatók 1-1 kisebb portra. Ez a toldozás-foltozás nagyon össze tudja kutyulni a dolgokat.
Lehet hogy csak az okozza nálad a problémát, hogy nem megfelelően állítod minden bithez az adatirányt, vagy összekutyulod a biteket.
100lábú PIC-et használok.
Irányok és bitek a helyén. Más gond lesz, de még nem jöttem rá, hogy mi.
Én a helyedben megnézném egy logikai analizátorral, lehet hogy olyan dolog is kiderülne belőle, amire nem gondolsz. Ha nincs ilyened már 8dollár alatt kapsz egy 8 csatornásat. Igaz, hogy minden cím és adatvonalra ez nem elegendő, de a fontosabbakra rámérve ki lehet sakkozni a dolgokat.
Korábban 8-bites módot használtál, most meg 16-bitest, tehát változtatnod kellett a rutinokon.
A HW bekötésről van rajzod? A vezérlővonalakra tettél felhúzó ellenállásokat, hogy a PIC kimenetének nagyellenállású állapotában is határozott (magas = inaktív) szinten legyenek?
Ez már megtörtént, jó helyen vannak az adatok.
Van 8bit-es analizátorom. Zsora: Az nagyon korábban volt, már mint a 8bit-es mód. Mivel tudja a memória a WORD módot, így azt használom, mivel így több mint 2szer gyorsabb. Persze mindig megírom a Byte módot is, de azt a végén nem használom. Nem kellett a rutinokon változtatni, csak a PIN kiosztást kellett újra definiálnom, minden maradt max az időzítés változott. Nincs rajzom semmiről, a memória adatlapját és a PIC adatlapját használom. Nyáktervem van, de azt feleslegesen dobnám be mert két oldalú és durván kuszának hat. Jelenleg meg ügye összedugósban van megoldva. A memória topikban láthatsz egy kód részletet: Bővebben: Link A teljes PIC definícióról meg egy oldallal visszább van egy bejegyzésem. A vezérlő lábakra nem tettem felhúzód, az régebben sem volt gond, de most hamar teszek is fel, hátha amiatt nem jó valami. Idézet: Akkor a B és D port teljes egészében használható lenne. Az RB5 csak Host USB módban foglalt.„100lábú PIC-et használok.” Szándékosan nehezíted a saját dolgod, hogy nagyobb legyen a kihívás? Hajrá! Idézet: Akkor mi alapján kötögetted össze a dolgokat. Csak úgy fejből?„Nincs rajzom semmiről” Érdemes mindig először a rajzot elkészíteni, mert könnyebben eligazodsz a saját cuccodon, és segítségkéréshez is felhasználható. Nekem pl. látnom kell a pontos kapcsolást is, mert anélkül a program nem ér semmit. A hozzászólás módosítva: Júl 17, 2016
Kipróbáltam a felhúzó ellenállásokkal, de semmi változás.
RB5-el vacakoltam már nagyon sokat, nem tudtam felhasználni. USB-t CDC-ben használom, de így is foglalja RB5-öt. (kell az USB mert PC-ről küldöm az adatokat amit fel kell dolgozni) F5-re átkonfiguráltam és írtam hozzá egy ilyet:
Rajzom nincs, fejből csinálom, vagy is egy részét. Lényegében ezt nem is kell lerajzolni mert egyszerűen a memória adja magát, hogy kell bekötni és kész. PIC (port) bit szervezése rossz (32MX795) ezért egyszerűen 2oldali nyákon sem tudom megoldani normálisan a D port kihasználását. moderálva A hozzászólás módosítva: Júl 17, 2016
Van egy mikroC-s kódom, azzal nem tudok vele kommunikálni az a bajom. Igen , így kötöttem össze , ahogy leírtad.
Logikai analizátorod vagy USB-UART átalakítód van? Ezekkel látható, hogy az ESP milyen parancsokat kap. Könnyen lehet, hogy a programban van a hiba (viszonylag gyakori eset).
Nincs egyik sem. Valószínű hogy ott a hiba , csak épp azt nem tudom mi.
Nevezett eszközök nélkül nehezen fogsz a végére járni. Esetleg úgy, hogy az UART kommunikációt te magad használod, nem egy könyvtárra bízod.
Proteus szimulációval virtual terminállal se lehetne megnézni a kimenetet ?
Azzal valószínűleg igen, nem ismerem a programot.
Megnéztem és csak $ jeleket ír másodpercenként folyamatosan .
Sziasztok!
Egy modbusz rtu slave eszközt kellene készítenem. Utána jártam a modbus-nak. Van még egy-kettő kérdéses dolog. Kezdjük ott, hogy 16F-es szériához vagyok szokva. Ezen most még nem akarok változtatni. Úgy néztem elég lesz ehhez a feladathoz. Két funkcióra lenne szükségem. Holding regiszter írás/olvasás (03-as és 10-es kód talán). Ami először feltűnt a kevés ram. Mert ahogy néztem a legnagyobb üzenet mérete 256 bájt lehet. Megnéztem pár modbus-os eszköz adatlapját és ott feltűnt, hogy megadták az üzenetenként rendelkezésre álló bájtok száma. Ezek szerint én is megadhatom, hogy az én eszközöm hány bájtot tud fogadni. Így elég egy kisebb vételi buffer is (tehát elég lesz a kisebb ram is). Ezt jól gondolom? A másik kérdésem: A regisztereknek van meghatározott címük? Nekem szükségem volna 4-5 regiszterre. Akkor elhejezhetem őket 01-től 05-ig? Felette pedig már tartományon kívül esik. A modbus leprogramozásával is akadnak még gondok. Hogy volna a legegyszerűbb megoldani? Egyenlőre csak a vétel akarom megoldani. Timer megszakításban növelnék egy változót. Mikor jön egy vételi megszakítás, akkor nulláznám a számlálót. A főprogramban figyelném a számláló értékét, és ha az eléri a 3,5T-t akkor kiértékelném az addig vett adatokat. Ez járható út?
Sziasztok!
Csak egyetlen kérdésem lenne, amire nem találtam választ az adatlap felsorolásában. Jól emlékszem hogy egy PIC lábán max 10 mA áram folyik ki? Ennél nagyobbat már tranzisztorral kell kapcsoltatni? Csak azért kérdezem mert van egy szilárdtest relém, és ha jól olvastam 7 mA-rel már kapcsol.- Vagyis közvetlenül tehetem a PIC lábára. Jól gondolom?
30mA-erig nincs gond.
Szerintem oda tegyél tranyót, én is azzal vezérlem. Fő a biztonság..
A kontroller adatlapja tartalmazza, hogy adott lább forrásként és nyelőként mekkora áramot visel el. Ezek változó adatok, nem lehet rá egyértelműen válaszolni.
Egy korlátozó ellenállat azért nem árt. Pontosan melyik PIC?
Odáig rendben, hogy hány bájtot kér a mester, de ha megnézed ennek a frekiváltó adatlapjának a 8. oldalát, akkor láthatod, hogy megadták, hogy a mester hány bájtot olvashat ki. 4 bájt adatot olvashatunk ki. Ebből kiindulva, a leghosszabb ami nekem kell, az a holding regiszter írás. Ha jól számolom akkor (1 cím, 1 funkció, 2 kezdő cím, 2 adathossz, 2 adat1, 2 adat2, 2 crc) egyszerre 12 bejövő adatom lehet maximum. Így akkor elég lehet egy 24-es vételi buffer is.
Tudom, hogy válaszolni kell, de először a vételt akarom megírni. A válasz az egy másik nekifutás lesz.
Elbírhatja éppen, de ha nem akarsz egyszer csak egy tönkrement pic-es áramkör miatt sopánkodni, általános jelleggel a pic-et csak a logikai funkciók ellátására használd. Bármi, ami nem logikai áramkör vezérlés, az már "teljesítmény meghajtás", és arra külső jel erősítőt használj. Mint például egy külső kapcsoló tranzisztor. Akkor maximum egy tranzisztor megy csak tönkre.
A relék olyasmik, hogy van kapcsolási idejük, és az is kérdéses, hogy behúznak rendesen, vagy "lebegnek", mert nem kapnak igazán sok áramot, és saját utánhúzójuk sincsen. Ugyan nem tudom, melyik reléről van szó, de valószínűleg többet kell majd adni neki, ha biztonságosan akarod használni.
Ha csak rtu-ban kell tudnia működni, semmi baj. Hosszabb buffert azért szoktak hagyni, mert létezik modbus ascii is. Nézd át annak a protokollját is, és megérted. Aztán ha tényleg elég, ne rinyálj, mert akkor tényleg elég. De részemről nem sajnálnék egy nagyobb pic-et oda, és nincsen memória para. A modbus-os eszközöknél nem szokott követelmény lenni az extrém kicsi fogyasztás. Gondolom, nem napelemről akarod majd üzemeltetni, vagy hasonló szeszélyes természetű áramforrásról.
Egy 16F886 -ban is van legalább 368 byte RAM, de ha ez is kevés, a 16F1847-ben, 16F1938, 1939 -ben 1k van, ráadásul az Advanced Midrange kontroller lineáris indirekt címzési lehetőséggel is rendelkezik. A bankváltástól sem kell annyira félni, a vételi és az adási buffert úgyis indirekt címzéssel kell kezelni...
Egy pici segítségre lenne szükségem. Megcsináltuk a képen látható kapcsolást. Működik is szépen, a gond az, hogy a 18-as lábat arra használnám, hogy jelezzem a pic számára van-e tápfesz vagy elemről megy, de hiába veszem el a tápfeszt valamiért 2,5 volt körül marad a lábon és így a pic nem érzékeli a változást. Ha műszerrel rámérek akkor lemegy a feszültség és rendben működik, de magától nem esik le a feszültség. Mi lenne erre a megoldás?
Jelezném, hogy a kapcsolási rajz kivehetetlenül gyenge felbontású.
Az oldal nagyon lebutította, nem vettem észre. A legfontosabb részletét kittem pdf-be.
|
Bejelentkezés
Hirdetés |