Köszönöm a válaszokat. Nem mondom hogy értem csak kapisgálom. Párszor még meg kell rágnom de valami fény dereng már az alagút végén.

Trudnai:

Tehát ha a megszakításból egy rutinnal a megfelelő programrészhez küldöm, (a regisztermentések visszaállítása előtt) akkor a RETURN után visszalép a megszakításba. A RETFIE után pedig már arra a címre lép vissza ahová a rutinnal küldtem?

ÉÉÉS MŰKÖDIK!

Köszönöm mindkettőtöknek.

Hat ezt nehez szoban leirni, rajzolni kellene, de most romokban a gepem igy nem probalkoznek rajzolassal.

Szoval gondolj bele, hogy fut a program. Egyszer csak jon egy megszakitas, ami gyakorlatilag barhol ekovetkezhet a program futasa soran. Ezen a ponton a program futasa felbe szakad, es elugrik a megszakitas kezelo rutin elejere. Itt armit csinalsz addig nem ter vissza az eredeti programba ameddig ki nem adod a RETFIE-t.

Namost, ha pl elugrasz egy szubrutinra CALL -lal valahol a mesgszakitas kezelon belul, akkor ettol meg a megszakitas lekezelesebol nem leptel ki. Ha ujabb megszakitas jonne az nem okoz ujabb felbeszakitast - egeszen addig ameddig a RETFIE-t ki nem adod. Tehat benne vagy a rutinkadban, az elvegzi amit el kell, RETURN-nel vissza ter a CALL utani utasitasra... Barmit csinalsz kozben, a szubrutinbol is hivhatsz masik szubrutinokat stb, de meg logikailag mindig a megszakitas lekezeleseben vagy. Ezekutan hogy vissza tertel a CALL utan szepen kiadod a RETFIE-t es keszen is vagy.

Ezt ugy is lehetett volna, hogy GOTO-val ugralsz el, es minden szubrutin vegen RETFIE van, de nem illik egyreszt, masreszt a kontextus mentes miatt es a kod karbantarthatosaga miatt erdemes egyetlen ISR-bol valo visszaterest fentartani (egy db RETFIE). Ezert a ket fajta pelda, egyik GOTO-val ugrik el a szubrutinra majd az GOTO-val vissza a megszakitas kezelo kileptetojere, a masik hasonlo de az CALL-lal van megoldva. A CALL-nal a stacket hasznalod ami nem biztos hogy szerencses megszakitasban, de ez megint csak firmware-tol fugg (hogy a fo programreszekben mennyire hasznaltad intenzivel a CALL-okat).

Remelem kellokeppen osszezavartalak

Hát nem mondom hogy nem....de azért köszönöm! Megpróbálom "megemésztem" (ha sikerül) ...

Üdv. mindenkinek!
Egy rövid kérdésem lenne. MPLAB-ban a PCON regiszter POR és BOD bitjeit nem lehet módositani, vagy csak én vagyok béna?

Nálam lehet módosítani. 12F675-nél néztem.

Valamit nem jól állítottam be az MPLAB-on?
köszi

Te most amugy a simulatorrol beszelsz (MPSIM)? Nekem is sikerult allitgatni 690-esen... MPLAB 7.41 -esen probaltama amugy.

Hogy oldanátok meg C-ben(C18), hogy egy 20bites szám(jobb híján 24bites változóból) kikerüljön 8+8+4 PORTbitre úgy, hogy a 4bit egy 8bites port alsó 4 bitje és a felső 4 ne változzon.

Lehet erre valami uniont, vagy struct-úrát írni, vagy ezt csak függvénnyel lehet megoldani?

Ha csak függvénnyel oldható meg, akkor lehet, hogy egyszerűbb 3x8bites változót kezelni és az alsó 4 bitet maszkolni.

Ha van más ötletetek érdekelne! (ez egy EPROM_EEPROM_Flash égető lesz, ha ez számít...)

Köszi!
watt

en siman maszkolgatnam.. de lehet kiserletezni a bitfieldekkel is, csak nem tudom MC18-ban ez hogy viselkedik es most a gepem romokban hever, nem tudom kiprobalni. (Ubuntu alol nyomulok es amig nincs vmware-em addig MPLAB-om sem lesz, bar meg lehet a wine-nal megkiserlem felinstallalni hehe)

Szoval nem tudom ez megy-e rendesen:

struct {
unsigned short long bit:20
} husz;

Ez igy 24 bites teruleten lesz de csak 20 bitet hasznalsz ami persze pazarlas, de nyelvileg tampgatott.

Hozzaferes ugye:
husz.bit = 123123;

Erre en makrokat tennek amit az egyes byte-okhoz hozza fernek ill a legfelso 4 bithez, es irnek makrokat a port 4 bit lecserelesere is ami ugye maszkolassal megoldhato. Persze a portra is definialhatnal ilyen bitfieldes cuccot, es akkor teljes mertekben a forditora bizod hogy oldja meg a itek lecsereleset (az vagy optimalis vagy nem, de mindenesetre programozas szempontjabol kenyelmesebb mint a maszkolo makrok hasznalata). Pl lemasolhatod a header file-t es kiegeszitheted a sajat bitfieldjeiddel a mar meglevo bit definiciokat...

Üdv mindenkinek!
Szeretnék írni egy programot C be ami pontosan másodpercenként ad jelet 1/10 másodpercre addig míg nem kap egy jelet(jelhiány a jel).
valami ilyesmire gondoltam:

for(; {
if(!input(PIN_A0)) {
output_toggle(PIN_B0);
delay_ms(900);
output_toggle(PIN_B0);
delay_ms(100);
}
}

Kérdésem, hogy az if es rész vagy bármi más menyire befolyásolja az 1 másodperces jelet?
Menyi ideig tart egy egy hasonló sor feldolgozása?

Alapjaban veve annyira amennyi idobe kerul az utasitasok vegrehajtasa, belertve ha fuggveny hivas van az abban levo kodokat is. Amugy ez igy azt eredmenyezik, hogy amig a jel megvan addig baromi gyorsan tekerni fog a ciklusodban, es abban a pillanatban mikor a jel eltunik ujra bele erkezik az 1/10 masodperces dologba. Ha pl ez egy bill lenyomas akkor a pergesmentesitest meg kell oldani mindenkepp, kulonben lehet ugy erzekeled hiaba nyomtad meg a billentyut meg mindig nem reagal (csak 1 mp mulva). Ill nyilvan ha a jel kevesebb ideig tart mint 1 mp akkor lehet nem is veszed eszre, hogy a jel ott volt... pl a gombot kozben felengedtek...

Az elöbb begépeltem a programrészletet, de gépelés közben rájöttem, hogy elemi hibát követtem el és szégyenlem leírni. (kitöröltem) Az MPLAB viszont nem jelzett hibát!? Simán lehetett végigmenni rajta. Az elöbb kipróbáltam és nálam is működött. Bocsi, és köszönöm.

Üd!
A jelhiány több mp ig tart.
Fix logikai értékre ugrik, nem kapcsoló.
Lényeg, hogy ha ismét van jel akkor a másogperces rész pontos legyen.

Ha az MPLAB-ban a Debugger menüben kiválasztod az MPLAB SIM-et, akkor feljön a Debugger menü alatt egy STOPWatch pont, amiben meg tudod nézni mi mennyi ideig tart. Persze ehhez a megfelelő helyekre break-eket kell tenned, valamint be kell állítanod a settings... -nél az órajelet is!

Az mplabbal még nem barátkoztam össze de megpróbálom.

A "pontos" eleg relativ fogalom. En timerrel mernek kapasbol, ha "nagyyon pontos" kell akkor pedig inkabb egy orakvarcrol tekert timert hasznalnek. Ezek a waitms stb megoldasok lehetnek kielegitoen potosak, de egy stoppert pl eleg nehez beloni. Szoval a "pontos" alkalmazastol/feladattol fugg mit jelent.

Ja, amugy a toggle fuggvenyek szandekosak? Van olyan allapot ahol inverzbe valt ez az egesz es akkor epp az ellenkezojet kell csinalnia annak amit "normal esetben" csinal?

Ezt az égetőt szerintetek érdemes megvenni kezdésnek?

A másik témában már leírtuk, hogy mit vegyél. Nem volt eléggé érthető?

De érthető volt! USB-re vagy párhuzamos portra vegyek égetőt. Ez pont párhuzamos portra köthető.

Azt is leírtuk, hogy Pickit2-t vegyél, hamár venni akarod.

Pl. azért rizikós, mert így ránézésre senki meg nem mondja neked, hogy milyen programmal fogod tudni működtetni, és az milyen PIC-eket támogat. Azaz ha veszel, akkor olyat vegyél, aminek a dokumentációja elérhető, a kapcsolása ismert. Vagy inkább építs egyet magad! Javasolták az oshon-t, az elég jó ebben a kategóriában.

Sajnos a párhuzamos portok is kezdenek kihalni, a laptopok 99%-án már ma sincs, az USB/párhuzamos átalakítókkal kapcsolatban meg már hallottam mindenféle véleményt. A soros portra tervezett JDM-típusú égetőktől meg a jóérzésű villamosmérnöknek borsózik a háta, nem véletlenül nem szoktak azok üzembiztosan működni.

Akárhogy is, a legjobb választás egy USB-s égető lenne, esetleg egy gyári PICkit2 vagy annak egy utánépítése. Ezekről is volt szó itt korábban - az egyszerűbb verzió annyiból össze is rakható, mint amennyiért ezt a vaterást árulják, de a használhatósága fényévekkel jobb. A gyári meg kb. 2x annyi.


OFF

Indult egy topic, PIC-KEZDÉS címmel, kissé heves lett az indítás, ezért most zárolva van. Pedig ha ott tényleg csak azokról lenne szó, hogy ki hogyan indult el a PIC-es témában, mi az, amit az abszolút kezdőnek el kellene olvasni, át kellene látnia, mielőtt PIC-et ragad és égetőt akar építeni vagy venni, akkor talán tényleg lenne létjogosultsága egy olyan topicnak is. Mert ennek, amibe most is írunk, a mérete visszariaszt sok kezdőt a végigolvasástól. Mi a véleményetek erről?

ON

Nem...

Akkor megdobnátok egy USB égető kapcs. rajzal amit meg is tudok építeni? Ne smd legyen. A Pickit2 ben pic van. Hogy építsek úgy égetőt hogy ahhoz is égető kell?

Szerintem inkabb a Topi fele kezdocikknek nem artana tartalmaznia a "tamogatott egetok listajat" - amien ilyen JDM fele zagyvasagok nincsenek, PicKit2 es klonjai ill ICD2 ha az meg realisnak szamit. Kezdok nem hiszem, hogy production programmert akarnanak venni ezer de akar 80 euros aron, ugyhogy azokat ki is lehet hagyni.

A kezdo cikket pedig jo lenne hirdetes szeruen a PIC-kel foglalkozo topicoknal feltuntetni szoval konyebb lenne megkeresni - en jelenleg csak ugy keresem meg, hogy tudom van egy ilyen, de amugy szerintem jol el van dugva.

(Ja, es nekem sem artana befejeznem a wikin a PIC-es temat )

Hát pl. úgy tudsz PK2-t építeni, hogy vagy van egy ismerős, aki azt az egy szerencsétlen PIC-et beégeti indulásnak, vagy pl. innen a fórumról is biztosan lehet találni valakit, aki szívesen segít ebben.

De ha úgy gondolod, hogy végképp nem járhatók ezek az utak, akkor akár próbapanelen össze kell lógatni egy LPT-s oshont-t, és azzal beégetni a PK2 firmware-ét.

Bővebben: Link

Szilva klonja nem smd-s, es szerintem ha szepen megkered valami kis koltseg mellett tud neked kuldeni felprogramozott PIC-et...

Igen, Topinak ki kellene vennie végre ezt a JDM féle ügyetlenségeket a cikkéből. De valamiért erre nem mutat hajlandóságot.

Amit belinkeltél ahhoz van valami normális kapcsolási rajz? Ami az oldalon van azon nem tudok elmenni.

Ez a rajz nem jó?