Szia !

Kicsit ide vág ,kicsit off ,de elakadtam.. Bővebben: Link

Ezt szeretném be aplikálni ,de elakadtam ,lehet ezt egyáltalán ?
Előre is köszi ! Üdv : István

Egy darabig kalibráltam, mire rájöttem mi is ez! Jópofa!
Belinkelni nem nagyon hiszem, hogy be lehet flow alá, de meg lehet írni a C alapján, bár a makrók(C makrók) miatt nem egyszerű, igaz nem látom át jelenleg teljesen a program működését.

Egy számítást tegyél a főprogram legelejére x =0

Sziasztok egy újabb kezdö kérdés: milyen beállitásokat kiván egy nokia 3120-as LCD kijelző a flowcode-tól? Nézegetem de ez font és e-block valahogy magas. Valakinek van tapasztalata?

Köszönöm a segítséget! A párhuzamos dolgot is megoldottam anélkül, hogy kivülről tudnám az ASM prográmozás összes parancsát..

A legtöbb programot érdemes a változók nullázásával kezdeni ,akkor nincs olyan helyzet hogy valamilyen random értékről kezd a program (kivéve amikor értéket kell adni a változóknak ! ) Csak csendesen megjegyzem az asm nekem is kínai

V5 - ben amikor létrehozol egy változót ,ott egyből lehet értéket adni.
Ha egyszer rááll a kezed ,megszokod !

Vazzeee még soha nem vettem észre ezt a lehetőséget , pedig már jó ideje birkózom a progival

Ja ,és akkor nem marad ki senki

Azt tudni kell, hogy ilyenkor egy programszó(vagy ki tudja mennyi a flow cserfessége miatt) elvész. Ezért csak akkor érdemes kezdő értéket adni, ha később a programban nem töltődik fel értékkel a változó.

Biztosan igazad van ,nem mentem bele a témába ,de viszont volt már bajom a "kósza" értékektől.Adtam értéket az elején és megjavult.

Persze, van mikor ez szükséges és elkerülhetetlen. Egyszerűen csak figyelni kell, melyiknek nem érdemes.

Értem ,köszi !

Nem, a program sebességét nem érinti és a további életét sem, egyszerűen csak felesleges programsorokat foglal le. Tudjuk, hogy milyen nehezen lehet beférni egy PIC-be, még egy nagyobba is, így nem mindegy, hogy mire használunk el programmemóriát.
Ha egy változó a program során más forrásból értéket kap, akkor nem szükséges értéket adni neki az elején. Ha meghatároz további dolgokat, akkor igen. Ennyi.

Ok. Jogos.
Igen, sok mindent meg lehet oldani alap ismeretek nélkül is flowban. Talán ez a nagyszerűsége is. (De attól, hogy tudok autót vezetni, nem vagyok autóversenyző)

Azért, javaslom olvass bele a PIC-ek felépítésébe, működésébe ahogy lejjebb más javasolta. Pár napot rászánsz, hidd el kitágul a világ. Még ha nem is mester leszel, de magad örömét, sikerét már megalapoztad.

Meg utána lehet máshogy terveznél valamit, jobban, praktikusabban, hatékonyabban.

Jelenleg nem tudom hol tartasz. Korábban átbeszélt módszerek szerint működnie kell csúszás nélkül, de hogy mindenre odafigyeltél-e azt nem tudom. Ez elég nagy falat, hogy most foglalkozni tudnék vele, egy vezérlőt programozok, mikor van kis szabadidőm, de ha tudok segítek, ha meg tudod fogalmazni szerinted mitől lehet, vagy szerinted miért nem szabadna, miután így és így oldottad meg...

Meg kéne nézni, hogy mit fordít be a flow, mert nekem gyanús. Az is, hogy nem lehet kiválasztani, hogy 8 vagy 16 bites módban működjön a timer (18F252-ben ilyen a TMR0).

Emellett még annyit, hogy a Timer0 eleve 256-os osztás(8bites módban), amit előosztóval 32*256-ossá, azaz 8192-essé lehet állítani, ekkor a 32768 Hz-ből, 4Hz lesz, amit te is mérsz! Szóval a blokk felületén nem jó értéket látsz, hibás a számítása!

Közben talán rájöttem a hibára is, mégpedig, hogy nem veszik figyelembe a külső forrás beállításánál, hogy nem Fosc/4-el kell számolni, mint a belső oszci esetében.

Ennél a megoldásodnál a megszakítás többet árt, mint használ. Persze a kijelzés miatt, mindenképpen megszakítás kell(kivéve szakaszos mérés, ami szünetel a kijelzés alatt). Ezért érdemes ilyenkor használni a hardver adta lehetőségeket(CCP1 capture mód).

A kérdésedre, hogy melyik megszakítás prioritása a magasabb, egyéke sem. De ha kihasználnád valahogy a flow által nem támogatott prioritásos megszakítást, akkor sem kapnál pontos értéket soha, mert a megszakítás lekezeléséhez idő kell és nem mindegy, hogy mikor jön a megszakítás, mondjuk pont akkor mikor a másikat kezeled le(a magasabbikat), akkor az mérési hibát okoz a következő körben. Hagyományos megszakításkor ez eleve elkerülhetetlen. A CCP automatikusan eltárolja a timer1 értékét, annyi idő mindig van, hogy a következő megszakítás előtt még lekezeld, azaz kiolvasd a CCPR regiszteereket, az sem okoz mérési hibát, ha a CCP int egy másik megszakítás lekezelése alatt érkezik.

Kár volt eltérni a CCP módszertől...

A freki-periódus-impulzus mérőben így mérek. Neked csak azt kell megoldanod, hogy a Timer1-re vezeted a mérendő jelet, a CCP1 bemenetére pedig ráviszed a mérőjelet. A Timer1 különbsége fordítottan arányos lesz a frekivel. De ezt már próbáltad így, vagy valamit félre értettünk?

Mi meg voltunk győződve, hogy a mérő jelet a CCP1 megszakítására használod. De mindegy mit hittünk, ez így nem lesz pontos, csak nagyon sok macerával...

Igen. Nézd meg a lábkiosztást.

Mit mókoltál rajta?

Ezt csak akkor tudhatod pontosan, ha egy hiteles frekimérővel összemérted a mérődet.

Sziasztok!
Hétszegmenses kijelzőt kéne kezelnem ami menne is, csak az a baj hogy a hardver el van kissé bökve. Magyarán amikor az adott szegmensnek világítania kéne akkor sötét. A port kimenetén lévő ULN2003 a ludas mert invertál. A kérdés lehet evvel kezdeni valamit a hardver változtatása nélkül?

A programban állíthatod hogy közös anódos vagy közös katódos kijelzőt szeretnél e meghajtani, Ha jól emlékszem alapon közösanódos ha átállítod jó lesz .

Köszi bejött.

Sziasztok!

24 órás időzítőt szeretnék építeni, ami különböző napszakokban kapcsol ki-be fogyasztókat. Írtam egy programot, de óránként kb. 1mp-et késik.
Mivel lehetne pontosabbá tenni, esetleg milyen más megoldást tudnátok ajánlani?

Köszi

A Tmr2 rutinban a Ha count = 3125 értéket kell változtatni.
Mivel késik, ezért csökkenteni.

Szia!
Csökkentettem az értéket 3124-re, de most siet kb 0,2 mp-et óránként. Más lehetőség?