Fórum témák
» Több friss téma |
Ott nekem nem volt eredetileg semmi ( biztos van valami alapértelmezett, mert nem pampogott
 ! ), most meg az emlegetett 18f24k22_g.lkr-t raktam oda be, de nem változott!Ebben egyébként ez van: Idézet: „
A "_CRUNTIME"-t az MPLAB-C18 definiálná vagy nekem kellene ?! Adatlap szerint : Idézet: „The default linker scripts provided by MPLAB C18 link with either the c018i.o or c018i_e.o module depending on whether Non-extended mode or Extended mode is being utilized, respectively” A hozzászólás módosítva: Ápr 18, 2014
Az lkr -t neked kellene megítni illetve a meglevők közül kiválasztani és esetleg módosítani. A <telepítési könyvtár>/lkr tele van állományokkal. A e végyődés az Extended mode -ra utal. Válassz onnan egy a kontrolleredhez való i -t tartalmazót, módosítsd, tedd bele a projectbe.
Szia!
Írtam, hogy csak a 18f24k22_g.lkr van, ezt hogyan használjam ?! C18 v3.40 . Köszönöm, hogy próbálsz segíteni, mert itt nem látom a fényt az alagút végén ! szerk.: A "_CRUNTIME"-al mit kezdjek ?! A hozzászólás módosítva: Ápr 18, 2014
Idézet: „A e végyődés az Extended mode -ra utal. Válassz onnan egy a kontrolleredhez való i -t tartalmazót, módosítsd, tedd bele a projectbe.” Nincsen már külön _e és _i változat, helyette _g van, amelyikben feltételes linkelési direktívák választják ki a megfelelő változatot:
Igen, de ezt a "_CRUNTIME"-t a fordító hozza létre vagy nekem kell tenni valamit a cél érdekében
, illetve kell-e nekem és mikor szerkesztenem a c018x.c fájlokat ?! A hozzászólás módosítva: Ápr 19, 2014
Ez akkor megint egy saját magunkkal való inkompatibilitás a MicroChip -től a MpLabX környékéről. Elvárható lenne egy ekkora cégtől, hogy körültekintően jár el és gondol azokra is, akiknak temérdek már elkészült projectje van C18 (vagy egyéb fordítójukkal). Belőlük élnek / éltek eddig....
C18 V3.35 -ig úgy volt, ahogy leírtam... Ezek szerint a _CRUNTIME és az _EXTENDEDMODE az MpLab -ban nem állítodnak be rendesen... Idézet a "Release Notes for MPLINK™ Object Linker and Utilities v4.35" -ből Idézet: „Generic Linker Scripts: Using the conditional directives, now a single generic linker script, per device, replaces the various existing linker scripts, eliminating the need for an explicit selection of a linker-script inside the MPLAB projects. Through the /p and /u command-line flags, the IDE communicates the part number and different debug and part specific information to MPLINK. Accordingly, MPLINK selects the proper generic linker script and uses it to link the entire project. Any combination of the following build possibilities will automatically be handled without the user needing to worry about linker scripts:” A legjobb, amit ajánlani tudok: Másold át a general linker scriptet a projectedbe, töröld ki belőle a felesleget, tedd be a módosított scriptet a liker scripts alá. Az idézett bekezdés előtt azt írták, ez működni fog. A hozzászólás módosítva: Ápr 19, 2014
A kerdesre a megoldas: File >> Project properties >> Categories > General > Source folders > Add > valaszd az aktualis projeckthez valo konyvtarat. >> Apply (ennek hatasara a Source folders ablakban megjelenik egy pont) >> OK es voila eltuntek a hibauzenetek.
Köszönöm, majd próbálom ( jelenleg szétszedtem a kapcsolást, mert protoboard-on volt
 !) !
Üdvözletem minden fórumozónak!
Abban szeretném kérni a segítségeteket, hogy piklab-ban Hi-Tech fordítót szeretnék használni úgy, ahogy egy rendes fordító működik, nevezetesen több .c és .h állománnyal. Jelenleg csak úgy hajlandó nekem működni, hogy van egy .c állományom ami main, a többit pedig csak .h-nak fogadja el. Láttam a manualban hogy van valami driver amit be kellene állítani, mert több üzemmódban is képes működni, de őszintén szólva nem tudtam kiokoskodni hogyan kell konfigurálni a fordító és a linker parancssorát. Tudnátok adni valami ötletet?
Erra talát már valaki megoldást ?
sprintf COFF Error PICC 9.80-at használok és csak a az sprintf kellene a lebegő pontos számok kiírásához, de lassan a halálba kerget, hogy állandóan felhoz egy hibaüzenetet. Köszi...
Sziasztok!
MODBUS protokollt szeretnék megvalósítani RTU-t, 0x03 funkciókódra válasz csomagot egyenlőre. A MODBUS-t sikeresen megírtam, szépen működik, válaszolgat, de néha timeout-om van, és még ritkábban Invalid response is modscan-nel tesztelve. Körülbelül 150.000 üzenetből kevesebb, mint 1000, vagyis még 1 % sem, de annak sem kellene lennie. Még a timeout elképzelhető is, ugyanis emellett 1wire protokol is fut, mégpedig ds18b20 hőmérés 24 darab érzékelővel és ugye a 1wire kritikus részein tiltom a megszakítást, így elképzelhető, hogy pont akkor jön egy kérés, mikor tiltva van. Ám szeretném fejleszteni, ahogy tudom persze. Mi a javaslatotok? A struktúra pillanatnyilag a következő: A main függvényben kontrol flageket vizsgálok, amennyiben igaz, úgy végrehajtom, egyébként nem. A flageket a megszakításban engedélyezem bizonyos számú megszakítás esetén. Amennyiben jön egy karakter uarton, a megszakítás megvizsgálja, hogy az 1. bájt-e, vagyis egyezik-e a PIC címmel. Ha igen, bevár még további 7 bájtot, emellett párhuzamosan fut egy timer is, ha egy adott idő alatt nem érkezik be a 7 bájt, akkor kilökjük a buffer tartalmát. A további hét bájt: 1 funkciókód, 2 start address, 2 quantity, 2 crc. Ha megjöttek (megszakításban nem vizsgálok minőségre, csak mennyiségre, kivétel az első bájt, a cím), akkor modbus flag=1, amit a főprogram kiértékel. Ha minden adat stimmel, akkor válaszol, amúgy nem. A kiértékelés közben létrehozok egy másik buffert, amibe átmásolom a bejövő usart tartalmát, így a vizsgálat alatt nem lesz foglalt a bejövő bufferem, elvileg jöhet újabb üzenet is. Valamit ennek ellenére nem jól csinálhatok, mert van úgy, hogy Invalid response jön a modscan-en, ami nem jó üzenetet jelent. Hogyan szervezzem át a kódot? Talán szervezzem át úgy, hogyha bejött az első bájt, akkor utána ne csináljon semmit a program, hanem várja meg a többit is? Válaszokat előre is köszönöm!
Az mindenképpen problémás, ha 1 karakteridőnél hosszabb ideig tiltod a megszakítást.
Értem. Azt viszont nem akarom, hogy akkor addig meg ott álljak a megszakításban, míg be nem jön a további 7 bájt. Az sem jó, nem?
Nem kell ott állni, csak ne tiltsd le a megszakítást, amíg a csomag véget nem ér.
Akkor ha jól értem:
Fut a program.
A megszakítás:
Vagyis az a baj, hogy ha éppen le van tiltva a megszakítás, mert hőt mérek, akkor nem tudom fogadni a karaktert. Tehát ha jön egy karakter és éppen nincs letiltva a megszakítás, akkor mit csináljak a mérés flag-el, kijelző flag-el? A hozzászólás módosítva: Jún 4, 2014
Mikor tiltod le pontosan a megszakítást és engedélyezed újra a mérés folyamán?
A megszakítást csak nagyon indokolt esetben, nagyon rövid időre illik letiltani. Nem látok olyan okot, hogy a hőmérés miatt le kéne tiltani bármilyen megszakítást. Te milyen indokot látsz erre?
Idézet: A kijelző flag nem gond (feltételezem, ott nincs letiltva a megszakítás). A mérés flag viszont az üzenetcsomag első bájtjától a befejezésig ne billenjen be (majd csak a csomag beérkezte után). „Tehát ha jön egy karakter és éppen nincs letiltva a megszakítás, akkor mit csináljak a mérés flag-el, kijelző flag-el?” Egyébként bölcsebb lenne valamilyen hardveres megoldást találni a hőmérők beolvasására, hogy egyáltalán ne legyen letiltva a megszakítás.
DS18B20-nál egy bit átvitelének idejére általában le kell tiltani, mert az időzítés nem timerrel van megoldva, hanem néhány NOP-al (60us a bitidő). Én arra gondolok, hogy nem csinálta meg azt, hogy minden bit elején letiltja, és a végén engedélyezi, hanem a teljes mérési eredmény olvasása előtt tiltja le, és csak a legvégén engedélyezi. Vagy esetleg csak az egyes bájtok olvasása előtt tiltja le, és a bájt olvasása végén engedélyezi újra. Ha tényleg úgy van, ahogy gondolom, akkor ez legalább 5,3ms (gyakorlatban inkább >6ms), illetve ha bájtonként, akkor 480us (gyakorlatban >550us) időt jelent, amikor a megszakítások ki vannak kapcsolva. Most hogy a modbus milyen sebességgel megy, azt nem tudom, de a 6ms az 4800bps sebesség mellett is túlcsordulást okoz.
Nem használtam megszakítás tiltást DS18B20-hoz, jól működött. Sima várakozásokkal működik, amiket megszakít a megszakítás ha kell. Nyílván a megszakítás nem vehet el sok időt, de ez szervezés kérdése. Ettől eltekintve biztosan van olyan, amikor ez nem megfelelő, de elég extra eset lehet.
Tökéletes volt a kifejtésed. Úgy írtam meg a programot, ahogy leírtad.
Igen, ott nincs. Akkor kipróbálom, ahogy írtad.
Tehát minden bit előtt tiltod és utána engedélyezed a megszakítást? Akkor elvileg nem marad le a soros megszakításról. Esetleg a 1-wire Reset ideje alatt? Mekkora kommunikációs sebességet használsz?
Ajánlást azt végülis nem kötelező betartani...
Nem, bájtonként van tiltva.
Idézet: „Vagy esetleg csak az egyes bájtok olvasása előtt tiltja le, és a bájt olvasása végén engedélyezi újra.”
Ennek ellenére sokan nem tiltogatnak, csak CRC ellenőriznek és ha hiba van kidobják az értéket. pl. a FlowCode 1wire moduljában sincsenek megszakítás tiltások, igaz nem referencia, de működik...
|
Bejelentkezés
Hirdetés |
