Nem feltétlenül kell ahhoz nagy projekt, hogy kényelmessé váljon a linker használata. Akkor is nagyon jól jön, ha kifejlesztesz valami rutincsomagot, amit több projektben fel akarsz majd használni a későbbiekben - és most nem arról beszélek, hogy lib-et kellene gyártani!

Én pl. az első LCD kezelő modulomat inc-ként írtam meg, viszont van pár saját változója. Nomost, ezeket a változókat vagy definiálod a főprogiban a többivel, vagy az inc-ben egy fix helyen, és akkor a főprogiban azt ki kell hagynod. Esetleg csinálhatsz két inc-et, egyik, ami a változókat tartalmazza, és egy másikat, ami a kódot, majd ezeket a megfelelő helyen kell a főprogramba beinkludálni. Szerintem egyik megoldás sem igazán elegáns.

Ha linkeres megoldást választasz, akkor úgy néz ki a dolog, hogy a modulban is van egy udata szekció és a főprogramban is. Mindkettő egymástól teljesen függetlenül, majd a linker elhelyezi az adatokat. A főprogramba csak egy olyan inc-et kell beinkludálni, ami a modulban létrehozott globális címkéket (függvények vagy változók) extern-ként definiálja. Gyakorlatilag egy include beírásával és a modul asm-jének a projektbe beemelésével megoldható a máshol felhasználás.

Köszi a választ mindkettőtöknek, nem tudom, hogy a 10MHz+HSPLL-re miért nem gondoltam.

Ez jól hangzik, trudnai is erről írt ha jól értettem.
Nem tudnál egy olyan példát adni, ahol a kódtól meg van szabadítva a deklarálási lényeg? (Kitörölgetni egy meglévő projectedből a forrást és a változó deklarálásokat meghagyni. Azt hiszem Jobbagyag is ilyesmit kért)

Ime... egy keret... Az extern hivatkozasok az INC-ben vannak amit csak be kell inkludalni a main-be, es akkor az tudni fogja, hogy van neki modulja ami majd definialgatja a globalis valtozokat es fuggvenyeket...

A rohej, hogy eleg a module.asm-et leforditani egyszer, es aztan valthatsz akar MCU-t is akkor is elegendo a leforditott module.o -t betenni a projectbe.

(Na, kozben rajottem a portok meg ettol INC-ben vannak definialva, szoval nem tudom ez hogy allja meg a helyet A modulban is kell akkor az #include p16F877 es akkor megette a fene az egeszet - mi a megoldas vajon?)

Sziasztok

Segítségeteket kérném a következő problémában:

Egy PIC24FJ64GA002-et használok amivel egy egyszerű UART kommunikációt szeretnék megvalósítani többek között.
PC-vel összekötve Hyperterminállal teszteltem. A Pic csodálatosan küldi az adatokat a PC-nek. Az RX rész viszont sehogy sem akar müködni.
Pic és PC között van MAX3232, ez jól müködik,tesztek alapján a Pic környékén lehet a gond.
A soros adat amit a PC küld a Pic-nek az helyesen megérkezik a Pic lábára.
A rendszer a következő képpen néz ki:
8 MHz-es quartz-ról (PLL nélkül) megy Pic, 3.5V a tápfesz, RX láb RP13-ra kiosztva, TX láb RP14-re.
Beállítások a tesztprogramban.

Ötleteket, tapasztalatokat ezzel kapcsolatban szívesen fogadok.

Az a megoldás, hogy lehet ifdef-es feltételes ágakat csinálni a forrásban az MPLAB által definiált, a processzortípust meghatározó címke alapján. Pl. ha 16F877 az MPLAB-ban kiválasztott target device, akkor fordításkor deklarálódni fog egy __16F877 nevű címke (két aláhúzással kezdődik a neve). A feltételes ágakba lehet a CPU-tól függő include-okat és a config-okat is (sőt, időnként még a végleges és a fejlesztői boardon lévő hardvereltéréseket leíró definíciókat is):

Igen, de most nem erre gondoltam. Hanem pl egy LCD modul, vagy egy mit tudom en egy PWM modul ami MCU specifikus dolgokhoz nyulkal, olyan SFR-ekhez amik mas es mas helyen vannak a kulonbozo tipusokon. Es hogy egy .o -t be lehessen tenni anelkul, hogy az megzavarna a mukodest. Azt hiszem van otletem ra, hogy kellene egy modult csinalni ami ezeket ledeklaralja globalis valtozoknak, beleertve inicializalasi kodokat is, es akkor MCU-nkent ezek letrehozhatok es akkor mar az LCD modulba nem kell bele nyulni. Majd kiprobalom otthon, de valami ilyesmi:

module18F877.asm:


Na mindegy, valami ilyesmi, eleg csunya a vegeredmeny, de vegul a fo programban nem inkludaljuk az MCU specifikus INC-et, helyette a modult betesszuk a projectbe... Nem tudom menne-e ez igy?

Délután talán lesz időm kipróbálgatni a lehetőségeket, addig is olvasom az infókat.
Az már lejött, hogy a MC specifikus dolgokat nehezen lehet kikerülni, #ifdef-ekkel teletűzdelt progi meg undorító! Nem beszélve arról, hogy nem lehet minden PIC-et le #if-elni, mert programrészeket is le kéne, nem csak az *.inc-ket, mivel más más regisztereket kell eltérő módon beállítani.

De talán nem is ez a lényege ennek, bár elsőre jól hangzott . Úgy godnolom, hogy a több fős fejlesztő gárdának lett ez inkább kitalálva, előkészítendő a különböző nyelveken megírt rutinok összefésülését.

Mindenesetre talán csökken az ellenszenvem, ha jobban megismerem és foglalkozom ezzel a résszel is! Ezt külön köszönöm!

Folyó év szeptember 30. körül volt egy hasonló problámája ciw nevű topiktársunknak. Akkor



volt a megoldás. Kiderült az is, hogy a demókártyához adott mintaprogramban elírták a konfigurálandó regiszter nevét.

Sziasztok!
Milyen algoritmussal tudnék előállítani assemblyben 1.728ms késleltetést (szoftveresen)? (18f4520, 20Mhz)

Ez 1728us vagy 1728ms? Egyébként ennyire pontosat nagyon nehéz ha a 20MHz-hoz nem jön ki a lépés. Mennyi lehet az eltérés?
Nem hiába van, hogy ha órát akarnak csinálni ahhoz spec MHz-s quartzot használnak, mert pl a 20MHz-ssel mindíg késik vagy siet egy kicsit. Lehet hogy neked is ilyen kell.

20MHz-es kvarcból is elő lehet állítani pontos órát, csak a 20MHz-es kvarcok nem szoktak annyira pontosak lenni, mint az órakvarcok. Raktam már ide fel pontos órát létrehozó kódot valamikor régebben. Ismerni kell hozzá a hardvert is alaposan, hogy tudjuk, mi mikor és mire van kihatással, illetve ha nem asm-ben készül, akkor is tudni kell, hogy mit mire fordít a fordító.

20MHz-es kvarcnál egy utasítás 200ns. Ennek az egész számú többszörösét elő lehet simán állítani, csak használni kell hozzá a szimulátort is a pontos belövéshez.

Pl. addig varakozol ameddig pontosan annyi ido telik el... Vagy timert ugy programozod fel, hogy pontosna akkor adjon megszakitast...

Nem mondtad milyen nyelven akarod megvalositani, de pl magas szintu nyelveknel leteznek olyan varakozo rutinuk mar keszen, aminek csak megadod mennyi ideig varakozzon es addig egy helyben all a program, csak akkor megy tovabb mikor az idozites mar lejart.

ASM-nel kiszamolod mennyi ido egy utasitas vegrehajtasa 20MHz-en, utana, hogy egy ciklushoz mennyi utasitas ill utasitas ciklus szuikseges, es akkor azt kiszamolhatod hanyszor kell a ciklust megismetelni hogy a kello idozitas meglegyen...

1,728 milisec.
Nem órához kell, hanem infra jel beolvasáshoz. 2 bit között ennyit kell várni.
Vmi olyasmire gondoltam hogy egy változóba írnék vmekkora értéket és ebből vonogatnék ki, amíg nulla nem lesz. Csak nem tudom hogy milyen számértékekkel kéne dolgozni.
ASM-ben kívánom megoldani

Az 'ms' -t ertettuk, szerintem gulasoft-nak azzal volt baja, hogy vajon az a vesszo vagy pont az ezres elvalaszto vagy tizedes vesszo



Pontosan. Potyo mar leirta neked mennyi idobe kerul egy utasitas, egy ciklusban kell megoldanod nyilvan a varakozast. Meg annyi kiegesziteskent hogy ha megnezed a GOTO utasitast akkor annak 2 ciklusidore van szuksege, magyaran ha egy us-et akarsz egy ciklusban akkor 5 utasitas ciklusidonyit kell varnod de mivel a GOTO ebbol 2 akkor osszesen 4 utasitast tehetsz bele. Ebbol kell megoldanod, hogy 1728us ideig varakozz, magyaran 1728 -tol szamlalj lefele, es ezt ugye 16 bitesen tudod csak mehgoldani...

Bocsánat, pontot akartam írni pontosvessző helyett.
A 16 bites kivonás helyett mi lenne ha egymásba ágyazott ciklust csinálnék? pl. így nem lenne jó?

Delay
movlw D'34'
movwf TEMP2
movf TEMP,W
HUR1
movlw D'254'
movwf TEMP
HUR2
decfsz TEMP, F
goto HUR2
decfsz TEMP2
goto HUR1
movwf TEMP
return

Nekem is van olyan kódom, ami 20Mhz -es quartzal olyan órát csinál, aminek a pontossága csak a quartztól függ. C-ben van írva, és nem kell hozzá tudni hogy mire fordítja a fordító Gondolkozom is hogy kéne belőle egy cikket csinálni. Persze ez így önmagában elég kevés, de ezen az elven lehet bármilyen más frekvenciájú jeleket is előállítani. Pl zenei hangskála. Kérdés, hogy érdekel-e ez valakit rajtam kívül.

Amikor már egyszer megírtad, akkor már nem kell tudni. De amikor készíted a rutint, akkor kell tudni, hogy miből mi lesz.

Tedd már fel, ha publikus, kíváncsi lennék rá.

De, ez egy jó megoldás, csak a két konstanst kell úgy beállítanod, hogy a futási idő pont annyi legyen, amennyire szükséged van. MPLAB szimulátorában van stopper, le tudod vele mérni egész pontosan a futásidőt (be kell állítani a szimulátornak az órajelet).

A kódodban az a movf TEMP,w és a végén a movwf TEMP szerintem nem kellenek, én nem látom semmi értelmüket.

a szimulátorban a stoppert hol találom?

stopwatch?

mögvan

Sziasztok!
Szerintetek mi a hiba a csatolt progiba? Miért nem kerül semmilyen adat az ADRESH és az ADRESL-be? PICKit2Start proba panelt használok, melyre raktam egy MCP9700-as hőmérséklet szenzort. Ebből kéne adatotnyernem.

Lenne egy másik kérdésem: egy általam készített NYÁKra kivezettem a PIC16F690 lábait ugyan olyan módon mint a PICKit2Starter-ben van. Programozót rádugva, és elindítva a felprogramozását, pillanatok alatt tűz forró lesz a kontroller. Ez ugye nem normális?

Köszi

ja és még annyi,h. a kontroller RC0 lábára van kötve a szenzor..

Nah végre elkészült a végleges hardware, 12MHz-es kvarccal is 40MHz jön ki a PLL-ből.

Aztán azt meg hogyan csinálod? A PLL-nek 4xes szorzója van! Nem tesz túl jót ha túlhajtod a PIC-et, bizonytalan lehet...

köszönöm mindenkinek a segítséget, főleg szilvának.
A stopper megoldotta a problémát.

Már volt róla szó ebben a topikban, hogy ADCON0 írása után (ADC engedélyezése) nem szabad azonnal elindítani a konverziót, hanem várakozást kell beiktatni.

]Ajánlott olvasmányok:

Hat nem egeszen... Vpp hova van kotve? Nincs valahol rovid zar?

Oké, raktam egy 500ms-os késleltetést az ADCON0 után, mielött még elindítanám a konverziót. Ennyi késleltetésnek elvileg elég kéne lenni nem? De igy sem működik.

A Vpp pedig ellenálláson keresztűl a PICKit2Starter adatlap 29 odlalán lévő ábra szerint lett bekötve.