Szia,

póbáld meg rövidebb címkékkel. Lehet hogy a 20 karakter már sok a fordítónak.


Szia.

Tudtommal a PIC16F690-ben nincs LATx.

Közben megnéztem, hogy a C18-as a main függvényből kilépve nem resetelődik, hanem a startup-ba lép vissza, ami végtelen ciklusban hívogatja az __init() és a main() függvényeket. Mondjuk ennek Rumcájsz problémájához semmi köze csak így pontos a dolog.

Megprobalom a rovidebb cimkeket, bar nemelyik forrasfile-ban van ennel hosszabb is (ugy tapasztaltam 32 karakter utan szokott tiltakozni a fordito). Amit viszont tenyleg kiprobalok az az eeprom mento szubrutin a hosszu forrasfile-om helyett. Hatha ott zavar be valami. Valami ilyesmire gondoltal (lsd melleklet), vagy van egyszerubb is? Ezt most csak ugy nagyjabol irtam meg, még nem futtattam, hianyzik par banksel de igy jobban attekintheto. Ha elvileg ok, kiegészitem kiprobalas elott.
Udv

Ez az apróság elkerülte a figyelmem. De akkor hogy került egyáltalán szóba a LAT?

Nagyon szépen megköszönöm az információkat, sikerült megirnom az első gyerekjáték programot a PIC-re. Próbálok továbblépni a nyomógomb kezelésre. Keresgélek a neten (és a CD-n) de szinte csak assembler forrást találok. Talán annyi kérésem volna még, ha valakinek volna apró kis próbaprogramjai -jól kommentezve- azt szívesen venném és megköszönném! Akár PÜ is lehet.

A mikroC -ben rengeteg examples van, megtalálhatod a könyvtárjában, persze ezek csak alapdolgok, de kezdésnek nem rossz. Illetve van itt két link, amiben sok-sok project van: link1 , link2

ui.: watt úgy, hogy ő a programjában először LATC -t írt.

Szia....

Nem egészen, de valami hasonlóra....

Szia

Miért is nem a Hi-Tech C fordítójával próbálkozol? Mostmár az a "hivatalos" Microchip C fordító PIC16F-hez. :yes:

Ez nekem jobban teccccik

Map file-t nezd mar meg mit hova pakolt. Egy ekkora programnal siman elofordulhat, hogy a linker mar masik lapra pakolaszott es ha csak nem hasznalsz pagesel makrot vagy mas modon nem bogaraszod a PCLATH-ot akkor siman lehet meghiv egy rutint aminek 0 az offsetje de a page nyilvan nem nulla - magyaran az a call 0 akar lehet jo is...

Ellenben kevesen használják! De nyugodtan ragaszkodj hozzá, és a C-hez is a kezdéshez! Nekünk mindegy...

Még ezt is értem, de a miértet nem. mindegy...

A tetszésindexen kívül vannak egyéb szempontok is, amelyek józan megfontolásra késztetik az embert: pl. merre halad a mainstream, hol várhatok több segítséget, tanácsot? Linuxnál is azt szokták javasolni: telepítsd azt a verziót, amit a környezetedben használnak!

Természetesen, a külön utaknak is meg van a létjogosultsága, semmi akadálya annak, hogy a MikroC-t használd. De ahogy Watt is célzott már rá, így kevesebb segítőre számíthatsz, nagyobb önállóságra lesz szükséged.

Szerintem ezt a konyvet nezhette meg Rumcajsz vagy ehhez hasonlo hivatkozast:

MikroC dsp konyv

A konyv amugy nem artalmas, ha elolvassa az ember, csak tudni kell a dsp nem a 14 bites PIC architektura...

Amikor valamilyen lap hivatkozását szúrod be a hozzászólásodba ajánlott a "LINK" feliratú gombot használni!

Mi a típusa az áramkörödnek? Mit akartál beállítani az IC-Progban? (Megnéztem a hivatkozást, tehét direktbe dudzsinak szól a kérdés...) Ha tudod a típusát, ebben a topikban rákerestél-e?

No! Közben dudzsi a kérdését törölte!

szia
Közbe megoldodott. Amugy 12F683 volt ami nincs az Icprogba, de közbe megtaláltam a winpicbe. Most már mükszik rendesen. De köszi a segitséget

watt lehet hogy kevesen használják, de nekem az egy emberibb nyelv mint az assembly.
Valamikor több mint 20 évvel ezelőtt tanultam a Z 80-as világban basic-et abból nagyon sok megmaradt bennem és a C igen közel áll hozzá. Már akkor is megpróbáltam az assembly-t de lehet hogy az nekem akkor magas volt.
Szóval ezért választottam a C-t.
Nem akarok (még) csúcsszuper programokat irkálni, csak ismerkedek a technikával.
Amint látom nagyon klassz kis eszköz, nagyon sokmindenre használható. Lépésről lépésre haladok előre, egyre jobban izgat.

Nem az általad említett könyvet olvastam (az előzőben leírtam) de lehet hogy meg fogom szerezni és áttanulmányozom. Az angolt nem nagyon vágom, nekem még oroszt tanítottak és az egy kicsit más nyelv. Jó, a koszon kívül egy kis angol azért ragadt rám.

Én nem azt írtam, mint amire válaszoltál. Kérlek olvasd el az oldalamon a kezdőknek szánt iránymutatást, abban benne van minden, amit én erről gondolok!

Nem is a C-vel van a baj, hanem, hogy a mikroC-t forditot nem ismerik itt sokan igy tul sok segitseget sem szabad varni a forumozoktol. En olvasok mas angol nyelvu forumot is (pl. a Microchip sajatjat is aminek nemzetkozi szinten oriasi a tabora) es az MIT piclist levelezesi listajat is, de az a tapasztalatom, hogy mikroC-t viszonylag kevesen hasnalnak mivel eleg ritkan emlegetik. Nyilvan ha megis ragaszkodsz ahhoz a forditohoz akkor a Mikroelektronika foruman talalsz majd megfelelo kozosseget a keredeseid megvalaszolasara.

Amugy ami konyvet "mutogattam" az ingyenesen olvashato online tehat megvenned sem kell - csak tartsd figyelembe, hogy a 16 bites dsp PIC-ek meroben elternek a 8 bites mid-range architekturatol. Es a mikrokontrollereknel nem eleg programozonak lenned, elektro mernoknek is kell egy kicsit ahhoz, hogy dolgozni tudj, hiszen nem egy adott elektronikai keszulekre irsz alkalmazast (mint amilyen a PC) hanem egy aramkori elemre amihez egy komplett elektronikat kell ra tervezned - vagy ha nem is te tervezed meg kell ertened az aramkor mukodeset mert lehet a problema amivel szembe fogsz kerulni nem is szoftveres hanem hardveres...

Valoszinu olyasmi lehet a problema amit irsz a masik lapra pakolasrol. Az eredeti eeprom mento forrasfile-t átirtam egy tizede olyan hosszu rutinra (Hp41C bolcs javaslatara) es megszunt a hiba. Aztan mivel az EEPROM mentest mindig par szazszor hajotta vegre egyetlen rovid kapcsolomegnyomasra is, betettem az eeprom rutinba egy pici kesleltetest meg egy RB0-on a megszakito jel meszunesere varakozast. Ettol megint megbolondult teljesen minden. Pedig arra a bizonyos eeprom mento forrasfile-ra el sem ugrik, megneztem. Programozas utan (RB0 megszakito jel nelkul) fut a program de valami miatt az INTCON,GIE jelet valami törli. Egyesevel lepkedve semmi nem torli, de mihelyst a run-ra kattintok törlődik, így nincs timer interrupt és nem megy semmi. Mindez egy ártalmatlan pár sor beszúrása utan az eeprom forrasfile-ba. Miért pont erre allergias a fordito? Ezt a file-t adtam utoljára a projekthez (addig 17 file minden gond nélkül működött együtt).
Szóval ha tudnál valami irodalmat erről vagy csak egyszerűen be kell szúrni bizonyos helyekre a pagesel-t?
Amúgy roppant egyszerű dologgal szenvedek már 1 hete: azt szeretném ha tápfesz esésre elmentene pár byte-ot a program az EEPROM-ba, hogy ne legyen adatvesztés egy áram kimaradás esetén. Csináltam egy feszültséget figyelő áramkört ami RB0 lábon megszakíást okoz, ami után mentenék (PIC(16F877A) nagy kondiról még pár sec-ig tud működni). De nem erről megy még, szóval nem hardveres a probléma.

Szóval teljesen érthetetlenül(szamomra) mukodik, sosem azzal van a hiba amit épp módosítottam, ugyhogy valami ilyen pagesel baj lehet.

Mellékelem a map file-t ami rendkivul impozáns, de nekem sajnos még nem sokat mond.
Barmi ötletet szivesen vennék.
Kösz elpre is.

Ha megnézed az adatlapot, a program memória résznél, láthatod, hogy a 0-ás lap a 7FF-ig tart, ezután jön az 1-es lap. Nos, a map fájlod szerint átlóg a main.asm és a PORTA1_PORTA2_hossz_megnyomas.asm az 1-es lapra. Úgy kell szervezni a programot(org), hogy ne szeljen ketté egy laphatár egy rutint, valamint az átkerülő rutinokból ne hívogassunk más lapokon lévő rutinokat, azaz azok is kerüljenek mellé, különben nem győzől lapokat váltogatni.
Én azért hagytam el a 16F-eket, mert a végén majdnem ugyanannyi utasítás váltogatta a lapokat, mint ami dolgozott(kis túlzással persze).
Javaslom a 18F-eket! (pl. 4321 talán még lábkompatibilis is!)

Amellett, hogy teljesen igazad van, a jelen esetben lehet, hogy gyorsabb, célravezetőbb lenne a progiban lévő összes JMP-t LJMP-re, valamint CALL-t LCALL-ra változtatni. Ezek az MPASM-ben definiált makrók, amik minden esetben állítják a page biteket is az ugrás vagy szubrutinhívás előtt.

Persze, nem elegáns, de egy ekkora, ilyen sok részből összeálló programnál ez talán most a leggyorsabb módja a problémán történő túljutásnak.

Szia!

A mentő rutinban az írási kulcs bevitele (0x55, 0x AA az EECON2 regiszterbe) tiltja a megszakítást (GIE -be 0 ír).

a WR bit 1-be írása után nem maradt ki véletlenül a
BSF INTCON, GIE ?

Bemásolom az adatlapból az ajánlott rutint:

BSF STATUS, RP1
BSF STATUS, RP0 ;Bank 3
BTFSC EECON1, WR ;Wait for
GOTO $-1 ;write to finish
BCF STATUS, RP0 ;Bank 2
MOVF ADDR, W ;Address to
MOVWF EEADR ;write to
MOVF VALUE, W ;Data to
MOVWF EEDATA ;write
BSF STATUS, RP0 ;Bank 3
BCF EECON1, EEPGD ;Point to Data memory
BSF EECON1, WREN ;Enable writes
;Only disable interrupts
BCF INTCON, GIE ;if already enabled,
;otherwise discard
MOVLW 0x55 ;Write 55h to
MOVWF EECON2 ;EECON2
MOVLW 0xAA ;Write AAh to
MOVWF EECON2 ;EECON2
BSF EECON1, WR ;Start write operation
;Only enable interrupts
BSF INTCON, GIE ;if using interrupts,
;otherwise discard
BCF EECON1, WREN ;Disable writes

Még egy megjegyzés: Az interrupt rutinból hívódik meg a mentés ?

Ha nem, akkor a fenti rutinnak működnie kell.

Ha a megszakítási rutinból hívódik meg, akkor a GIE bit állítása NEM kell, hiszen a processzor azt hardverrel tiltja.

Szia.

Amellett, hogy igazad van, van ennek egy hátulütője. Gondolj arra, hogy mi lesz, ha egy BTFSS után egy CALL állt!

Ajjaj, teljesen igaz! Akkor mindenképpen figyelmesen kell csinálni a cseréket. Viszont nemigen spórolhatók meg ezek a hosszú ugrások, ha a projekt linkerrel készül, ki tudja, linkelésnél mi melyik lapra kerül. Esetleg lehet kicsit erőszakoskodni, hogy pár modult bekényszerítünk az 1-es lapba, és azokat mindig hosszú ugrásos makrókkal használjuk, az általánosan használható (ha nem határozunk meg kézzel lapot) területet meg leszűkítjük a 0. lapra, de ehhez már a linker script-be is bele kell mászni.

Igen, sajna abba is bele kell mászni.
Én ezért nem használtam még a linkert ASM esetében. Jobb azt kézzel szépen oda, ahova én akarom!

Sziasztok!

Ha a programban van néhány táblázat vagy szöveg, akkor azt, azokat célszerű egy magasabb című lapra tenni.

A táblázat kezelését viszonylag egyszerű átírni - csak néhány helyről hívjuk meg, ott kell csak a lapozással foglalkozni.

A propeller órában nekem bevált.


A programot át kéne nézni, a megadott részlet alapján a hosszát jócskán lehetne rövidíteni.

Az óra optimalizálása során annyi felesleget szedtem ki, hogy a javítások, az RTC és az I2C szoftver kezelése is befért az eredeti 628-ba.

A 16F886/887 verzió a bővitésekkel is csak 1.5K (0..5E1), itt a karakter generátor a 2. 2k-s lap tetején van.

Sziaszok.

Röviden úgy gondolod, hogy meg kéne írni a programot újra rendesen?

Egyelőre azt ajánljuk neki szerintem, hogy próbálja ezt a lapozós dolgot némi átszervezéssel kiküszöbölni. Bár ez hosszú távon úgy is kavarodást fog okozni, de átmenetileg megoldhatja a problémát.