kissi megoldása elegáns.
Másik lehetőség a TMR1L és TMR1H törlése interruptban, és az így elvesztett 3-4 ciklus hozzászámolása a mért értékhez.
Ha jól számolom, "normál" paraméterek mellett (pl 4 MHz osc, 1/4 timer) 900 rpm alatt átfordul a tmr, tehát le kell kezelned, ez bonyolítja egy kicsit, mint ahogy ktamas66 is írta. Viszont itt már néhány számítási ciklus oda vagy vissza gondolom nem számít.
A felső fordulatszám saccra elvben csak űrtechnikával érhető el. (az interrupt mondjuk max 20 utasítás, ha utána adok még 150 utasítást a főprogrammnak, az még mindig 30 ezer rpm feletti mérést tesz lehetővé, és egy főciklusban akár több interrupt is lehet.
Remélem jól számoltam.

Nekem is ezek az értékek jöttek ki. Egyenlőre maradok ktamas66 által javasolt "nem kell foglalkozni vele" módszernél. A 900 rpm alsó határ bőven elég nekem és úgy gondolom, hogy a 30.000 is. Remélem hétvégén már tudom tesztelni élesben, aztán megnézem mit mutat.

Valamilyen időfigyelést úgy is bele kell rakni, mert különben honnan tudod, hogy a motor áll, és 0-át kell kijelezni. A felső fordulatszám mérésének a pontossági igényed szabhat határt, de magas fordulatnál úgysem kell minden mért értéket kijelezni (ezért kiszámolni sem), vagy ha szabályozáshoz kell, feldolgozni. Esetleg üzemmódot váltasz és átállsz frekvenciamérésre.

Nem lehet a timer órajelét leosztani? Az ezres váltószám a mérendő érték és az órajel között processzor erőforrás pazarlás.

Sziasztok.
Olyan kérdésem lenne hogy 2 pic között one wire protokollal hogyan lehetne megvalósitani a komunikációt??? (MikroC)

Ez a legegyszerűbb.Itt csak sorosként kell használnod .

Lehetne, de nem értem miért volna jobb.

Nem jól írtam, nem pazarol erőforrást, mert a megszakítás a timertől független eseményre váltódik ki. Csak az jutott eszembe, hogy elvileg elég lenne a felső mérendő érték frekvenciájával (vagy ettől egy konfigurálható értékkel nagyobbal) járatni a timert. Órajel leosztással a mérési tartományod tudod eltolni lefelé a mérési pontosság rovására. Ezt leszámítva szerintem sincs gyakorlati előnye.

Végig néztem és a kérdésem gyorsabban át tudom vinni az adatott ezzel mint sorosportal?

Mert ahogy nézem amikor az adatot küldöm "soros"portom működik.

Leegyszerűsítve ez soros kommunikáció,csak egyvezetékes.Annyiban egyszerű,hogy a hardver adva van.Gyorsabban nem fog menni,csak 1 picit lassabban,az echo miatt. Amúgy majd a megoldástól,távolságtól is függ,hogy mennyire gyors.1-2Mbps -t is tud 1-2 Pic kitolni,bár itt max. Kbps -ek lesznek elérhetőek .

Ha assemblyben programoznál, sonajkniz tudna segíteni. Olyan 1wire kommunikációt fejlesztett magának, hogy veri az összes "gyári" kitalációt, mind sebességben, mind stabilitásban. Persze ez csak két pic között működik.

ADC/DAC-vel kapcsolatos kérdésem lenne. Két jel különbségét szeretném megmérni a referenciához képest. A PIC24F ide vonatkozó kézikönyve szerint az 54. oldalon pont ez áll:
The transfer functions of the A/D Converter, in 12-bit and 10-bit resolution, are shown in
Figure 51-22 and Figure 51-23, respectively. In both cases, the difference of the input voltages,
(VINH – VINL), is compared to the reference, ((VR+) – (VR-)).

Hogyan kerül rá a VINH és VINL az ADC-re? A 9. oldalon ezt találtam:
bit 10 CSCNA: MUX A Channel Scan Enable bit
1 = Scan inputs are selected by the AD1CSSH/AD1CSSL registers as the MUX A input(s)
0 = Do not scan inputs

Az AD1CSSH/AD1CSSL bitjei az analóg csatornát választják ki. Jól gondolom, hogy kiválasztom a két csatornát, beállítom a CSCNA bit-et és azt fogja csinálni, amit fent idéztem?

Másik kérdés. Van egy GND és két analóg jelszint. Ha a GND-hez képest alacsonyabban levő jelszinthez képest szeretnék egy jelszintet kiadni a DAC-re, erre tudtok hardveres megoldást? Ki lehet matekozni prociból, de kimondottan PIC-be épített hardveres megoldás érdekelne.

Vagy matekozod szoftveresen, ha a végeredmény gnd fölött marad, és a negatívabb jelszint valami módón folyamatosan ismert (például statikus / szoftveresen beállított), vagy külső műveleti erősítő kapukkal összeadsz / kivonsz / tükrözöl.

Minden a GND fölötti lenne. A szoftverest próbálom kerülni, mert ahhoz meg kellene mérni a referencia jelet és mire kiadom a jelet ehhez képest addigra a referencia változhat. A külső műveleti erősítő rendben, csak gondoltam hátha tudja a PIC. De nem úgy néz ki...

Az első kérdést valaki meg tudná erősíteni?

Ha több paraméteres mintáid vannak, akkor struktúra szintjén szokás kezelni, mint bemeneti érték, a referencia értéke (aminek szabályozottnak kell lennie, nem szabadon ugrálónak), időbélyeg, meg még ami van, és azok együtt 1 minta adatai. Ha adatroncsolt mintáid vannak, akkor persze tényleg összetalálkozhatsz lehetetlen problémával, és senki sem tud majd azon segíteni.

Lehet, azért nem válaszolt rá senki, mert egy kicsit belecsapás a lecsóba. Be kellhet még állítani pár másik dolgot is, nem csak azokat. Hideg indítási inithez a 23. oldalon ott a leírás, elolvasod, kipróbálod az adott áramkörödben, és bármid is van a projectben az adott fejlesztői környezetedben, unit-onként tesztelsz.

A "referencia változhat" részt úgy értettem, hogy van a GND és két jel ehhez képest. Az alacsonyabb feszültségű jel a referencia (tehát nem az ADC vagy DAC referencia), amihez a magasabb feszültségű jelet kellene mérni. A változás teljesen kiszámíthatatlan. Emiatt nem jó, hogy először megmérem, majd kiadok a DAC-re egy feszültséget a mért értékhez (referencia) képest. Ezért csak a hardveres megoldás jó. Ha beépített hardverből nem megy, megcsinálom áramkörrel. A PIC-ben is van OPA, szerintem megoldható azzal.

Az első kérdés tervezés szempontjából lenne lényeges, hogy tud-e az ADC a különbözeti jelet mérni és milyen IO lábak kellenek hozzá. (A leírás általános, nem csodálkoznék, ha a konkrét PIC pont nem tudja.) Ha nem tudja, külső áramkör kell. Ha tudja, legyártatom a panelt és tévedek, akkor új panel kell. Meg szerettem volna spórolni a próbát, gondoltam hátha valaki csinált már ilyet.

Miért nem használsz szimultán mintavételezésre alkalmas PIC24H vagy dsPIC33 mikrovezérlőt? (már ha jól értettem a problémádat) Bővebben: Link

Más, ettől súlyozottabb szempontok is vannak. Az Atmel teljes választékában nem volt megfelelő proci. A Microchip választékában ez volt az egyetlen megfelelő típus. Követelmény a 3.3-5.5V-os működés, sok ADC, 2 DAC, 28+ láb, lehetőleg hardveres osztás/szorzás. Az összes jelfeldolgozó proci 3.3V-os.

Ezt kifejtenéd picit bővebben?

Nagyobb fordulaton a számolt impulzusok száma egyre kisebb, mondjuk 100 alatt a hiba már százalékban mérhető és az 1/x függvény miatt gyorsan nő. Ez avval is jár, hogy a kijelzett értékek is csak adottak lehetnek, így a kijelzés ugrálni fog két érték között. Ezért lehet, a mérési eljárást variálni kell: alacsonyabb órajel, hosszabb mintavételezés (pl. minden 16. jelre állítani a capture-t), több mérés összegzése vagy frekvenciamérés.

Sziasztok!

16F690et szeretnék programozni Pickit3al. Csatlakozásnál figyelmeztet, hogy ha 3,3Vos eszköz van rajta és a táp 5v akkor az eszköz tönkremehet, nem tudja a config IDt kiolvasni. 5Von programozva ez is a helyzet, viszont 3,3Von jó.....a bökkenő az, hogy utánna az ic csak 3,3Von hajlandó működni. A 16F690 nem 5vos, és nem 12-13Vos Vppvel programozható? A LVP kavarhat bele a dolgokba?

Ez csak egy figyelmeztetés, hogy figyelmetlenségből nehogy tönkretegyél egy 3,3 V-os vezérlőt. PIC16F690 estén ezt nem kell figyelembe venni, mivel az 5 V-os. (Progamozásnál a 12-13 V csak a programozás módba történő lépéshez kell, a tápeszültség ott is 5 V)

Az LVP programozást a konfigurációs biteknél célszerű letiltani, hogy a PGM lábat ne veszítsd el (LVP módban az vezérli a futási ill. programozási mód közötti váltást).


Ha az LVP mód nincs letiltva, és a PGM láb lebeg, akkor előfordulhat, hogy nem fut a program, mert az MCU átlépett programozás módba. Földre kell kötni.

Megjegyzés: nálam egy PICkit3 klónnal 5 V helyett 4.7 V-ra kell állítani a tápfeszültséget, mert a PICkit3 csak ennyit tud kiadni magából.

Ez engem is érdekelne. Keresgélek, de nem találok - tudnál linkelni?

Nem fogsz találni, privátban kell megkeresni és szépen megkérni.

Mert az egész semmi olyasmi, ami széles körben használt lenne. Szükség megoldásként néha handy, de ha saját eszközök közötti kommunikációra kell, általában egy nyitott kollektorral megbarkácsolt half duplex uart jobb szolgálatot tesz, mint a szoftveres one-wire. Ha mégis kell bármire az 1wire, használj bridg-et Bővebben: Link

Ezek szerint az álltalad vázolt megoldás tudja a 30m vezetéken, 100000bit/sec sebességet a tápfesz elküldésével együtt egy 2ér + árnyékolás vezetéken?

Sziasztok!
Miért nem tudom ezt hex-é alakítani? Rengeteg hibát dob, ha próbálom.
Ezt próbálom kis módosítással elkészíteni.

Próbáld ezt.

Azért szeretném azt, amit belinkeltem, mert másodperces felbontást szeretnék, s bőven elég az 1 órás időzítés.
De azért köszi!

Letöltöttem a módosított project csomagját, kibontottam egy alkalmas mappába, átneveztem a
PIC16F628A_Relay_Timer.c állományt, beletettem a hozzászólásodban találhatót PIC16F628A_Relay_Timer.c néven, lefordítottam... Teljes siker. uC 5.6.1