Csak a módszer rekurzív, a programban bárhol elhelyezhető.
Ez az egész rendkívül egyszerű, két szorzás és egy összeadás minden mérésnél.
Nem függ a Te programodtól, sem bármilyen időzítéstől.
Mellékeltem 20 mérés eredményét átlagolva, n=2.

Az tiszta, hogy a startbit lehúzza a bemenetet, de ha rádugom pl. a PC-t vagy egy kijelzőpaneles kontrollert, az talán küld egy start jelet a csatlakozáskor?
A készülék honnan tudná, hogy küldheti az adatokat? Egyébként akár folyamatosan is küldhetné - az adatsor elejét könnyű azonosítani -, de üres csatlakozó esetén a kommunikációs programrészt átugranám, nehogy bezavarjon valami kóbor jel a főfeladatba.

ööö.... n az mit jelent a képletbe??? Az elem számot??

A berendezés csak megszólításra válaszol. Ha a vétel egy körforgó pufferrel történik, amibe a vételi megszakítás teszi be a karaktereket és az esetleges hibákat már itt lekezeli, nem lesz gond a főprogrammal. Ha van (megfelelő számú) karakter a pufferben, kiveszi a táviratot, ellenőrzi, dekódolja, végrehajtja. A keletkező üzenet karaktereit egy másik körforgó pufferbe pakolja és engedélyezi az adási megszakítást. Az adás ebből a körforgó pufferből ad, ha van benne adat, ha nincs letiltja az adási megszakítást.
Kiválóan működik.

Ezt a hibát kapok miért?

Ha pl egy Nextion kijelzőt dugsz rá a PIC-re, az megfelelő beállítás esetén a táp rákapcsolásakor küld egy adatsorozatot, hogy bebootolt. Ezt veheti a PIC és tudja, hogy onnantól kezdve küldheti az adatokat. Az is beállítható a Nextionba, hogy nyugtázza a vett adatotkat ... ha nem érkezik vissza a nyugtázás, le lehet állítani az adatküldést.
Ha meg az adatfeldolgozó egység is egy PIC, akkor ez az elv ahhoz is jó lehet...

Köszönöm a biztatást, akkor nem aggályoskodok tovább. Asztalon már működik, még a hibakezelését lehet csiszolgatni...

Köszönöm, de én egy vén hobbista vagyok, csak Nixie kijelzőről hallottam... De a második rész megfontolandó.

Nextionnak van külön topicja ...
Nextion editorral a kijelző nélkül is lehet próbálgatni a működést.
Editorba 1-2 kattintással létre hozhatsz egy szövegmezőt a PIC-ről meg soros porton kiküldöd rá a szöveget ... T1.txt=blabla szöveg + lezáró karakterek, és már meg is jelenik a kijelzőn, ami mellesleg érintőképernyő is, úgyhogy visszafelé meg akár "gombnyomások" is mehetnek ... szóval nem kellenek nyomógombok, 2*16-os LCD kijelző, meg még egy PIC, csak +5V meg az RX TX...

Én ugyanezt játszom, csak felpörgetett 1-Wire-vel. Plusz a kijelző kezelő PIC még 16 gombot is beolvas. Sokkal zavar-védettebb.

Rákattintottam egy-két Nextion videóra, tényleg elég intelligens darab. Eddig megfigyelésre egy 2x16-os kijelzőt, vagy PC-t használtam, majd később szeretném a szabályozást optimalizálni, ahhoz kellenének az adatok.

Ja ... többek között még grafikont is tud rajzolni ... kazánvíz hőmérséklet, külső/belső hőmérséklet stb ...

Én is a 1-Wire technikát használom, de gombok helyett egy potmétert figyel a komparátor. A skála igény szerinti nem folytonos diszkrét értékekből áll, így külön sávokban lévő hőfokokon kívül funkciók is hozzárendelhetők egy-egy potméterálláshoz.

Ha n=2, a szükséges két szám 0.6666 és 0.3333, ezt nem érdemes kiszámolni.
Nem függvény rekurzióra van szükség, csak az átlagot kell frissíteni minden mérésnél.
Ilyesmire gondoltam (ha van elég hely a lebegőpontos számításhoz):

Sikerült ahogy beilesztetted de akkor ez az "n" mire való???

Azt csak benne hagytam emlékeztetőnek, itt nincs használva.
Amíg kísérletezel a megfelelő értékkel, addig szükség van rá.
Ha megvan a megfelelő érték, fixen be lehet írni, vagy akár const double-ként deklárálni, vagy simán definiálni. Végülis a két érték bármi lehet, ha az összegük 1.
Fölösleges lenne minden alkalommal kiszámolni.

Az elektronikai problémát illetően konkrét kapcsolási rajzot kellene megkuksolni, milyen meghajtók vannak ott, amihez alkalmazkodni kell, és hogy annak a meghajtónak mit mond az adatlapja a tiltott zónás bemeneti feszültségre - valami akkor is csak kerülni fog a kimenetére, általában a default érték. Amikor a csatlakozót összedugod, és nincsen adatkommunikáció egyik irányban sem, akkor jellemzően default jelszint változás sincsen. A soros portot nagyon sokáig használta a világ, ki van találva, biztosan nem lesz csúnya problémád kábel hot plug miatt - vagy olyan legalább is nem lesz.

Ami problémád inkább lesz, az a földhurok. Soros kábellel jobb ötlet csak helyi eszközöket csatlakoztatni. Például a 20 méter kábel esete már rendszeresen fog tökretenni mindenféle eszközöket. Egyik volt ismerősöm pénztárgépeket szervízelt, amiket hosszú rs232 kábellel volt szokás egy másik szobában lévő számítógéphez hozzákötni, és ő úgy tapasztalta, hogy még egy szoba egyik sarkától a másikig is már jobb, ha van galván leválasztás, és el kellene fogadni a meghajtási gyengeségek végett a maximum 9600 baud sebességet. Próbálkozni persze mindig lehet bármivel, de sok év szervíz tapasztalatának az az utólagos statisztikája. Ahol lehetséges, ott azért érdemes átállni ethernetre, mert az trafós csatlakozókkal védett mindegyik csatlakozási ponton. Az ethernetnek nem a sebessége a legfőbb erénye, hanem a földhurok védelme - a mai fiatalok már azt sem tudják, mi az

A hőfok szabályozó típusát illetően páran tudni vélnek dolgokat, én annyira nem vagyok odahaza bennük, gőzöm sincs, mi az a Nextion vagy akármi, de a soros porton általában extra karakterekkel vagy időzítéssel oldanak meg frame szervezést.

Extra karakterekre a példa a base64 kódolás. Vannak engedélyezett 8 bites értékek, és tiltottak. Úgy persze áldozatul esik valamekkora sávszélesség, de az olyan. A frame startot és végét tiltott karakter jelzi. Tiltott karakter utána karakterek a következő tiltott karakterig 1 framehez tartoznak. Ha éppen olyankor dugod össze, hogy a frame adás kellős közepén van az egyik oldal, akkor azok az adatok már elvesznek. Ha olyankor húzod szét, hogy az előző frame végén még nem volt meg a lezáró karakter, akkor az is elveszik. Néhány alkalmazásban tudni kell dinamikus frame méretet használni, a frame pontos hossza nem lesz ismert, és csak menet közben derül ki, olyankor hasznos segítség.

Időzítésre példa a modbus rtu módja. Elvileg folyamatosan megy az adatcsere a soros porton (ott jellemzően rs485-ön), és ha az mégis megszakad 3 milli sec időnél hosszabb időre, az egy frame start. A frame startot csak szinkron felvételre használják, a frame szervezés utána már fix szélességű adatpakolászással, és adat értelmezéssel van megoldva (a frame elején érkezik, hogy milyen hosszú az a frame és hol fog kezdődni a másik).

Ha neked kellene megoldani mindkét oldalt, használhatnád, amelyik szimpi. Ha az egyik oldal már készen kapott, és alkalmazkodnod kell, akkor kellene valami gyártói leírás, vagy jó sokat méricskélni.

Huh! Ennyi szakmai információért máshol már pénzt kérnek... Nagyon köszönöm!
Szerencsére a projekt nagyon türelmes rendszert kezel: relékkel szivattyút és két termo-szelepet (3W ohmos), optocsatolóval gázkazánt. A szivattyú kapcsolgatásától tartottam, de alaptalanul, egyszer sem okozott zavart. Visszajelzésnek csak ledeket raktam be, ezért lenne jó időnként valami kijelző. (A Nextion kijelző valóban ügyes kis kütyü, érdemes rákeresni.)
Továbbiakban szeretném értékelni is a működést, de a számítógépet helyszínre vihetem, max. 1,5 m-re, gyakorlatilag zavarmentes környezetben. Az RS-232 9600 bauddal több, mint elég, negyed-másodpercenként tervezem a mintavételt, illetve a megelőző adatsor küldését. (De, ha tőlem kérnének tanácsot... :- Vegyen két bimetálos termosztátot, a mester meg azonnal beköti!)
Köszönöm mégegyszer

Sziasztok!

Olyan problémába ütköztem, hogy a 16f1788-nál a timer1 modul túlságosan lassan működik.

A belső órajel 32Mhz. Egy 360 lépéses szinusztáblát írok ki a DAC-ra megszakításban. Így elvileg egy 22,2 kHz -es jelnek kéne kint lennie, viszont szkópon is mérhetetlenül lassú jel jön ki. Mit ronthatok el, mi lehet a hiba? Mellékelem a teljes kódot is. Elvileg jónak kéne lennie, bár ahogy a probléma is mutatja nem . Ha nem a megszakításban van akkor szép gyors jelet tud kiadni, szóval nem a dac nem bírja.


Köszönöm !

Számoljunk egy kicsit:
A PIC 32MHz órajelről jár. Az utasítás végrehajtási ideje 4/32000000 = 125 ns.
A 22.222kHz periódusideje 1/22222 = 45 us. Utasítás végrehajtási időben mérve pontosan 360. Szóval, ha minden második utasítás a következő mintát írná ki a DAC számára egy PORT 8 bitjére, akkor is csak 90us alatt tudná fejezni a 360 minta kiküldését.
A programban 360 megszakítás belépés (latency + mentés), kilépés és még számtalan egyéb művelet történik...
Nézd meg, milyen assembly utasításokra fordul a program, mérj végrehajtási időket.

Szkóppal mérve is kb 0,5-1 Hz a freki (ezt már az enyém mérni nem tudja, csak saccolom). A problémám az hogy nagyságrendekkel lassabb az egész mint amilyennek lennie kellene. A te értékeddel is 11,1khz fele kellene lennie, de meg sem közelíti.
Mindjárt megnézem mit csinál assembly szinten.

UI.: Ezzel a lookup table megoldással nagyon szép szinuszt lehet kiküldeni , szóval köszönöm a linket és az ötletet mégegyszer !

Közben még felmerült bennem az is hogy mi a különbség a T1_INTERNAL és a T1_FOSC között ? Az internal 4-el osztott a fosc nem? Így néz ki az álltala fordított assembly.

Ha a TMR1 órajele ez Fosc/4 azaz az utasításvégrehajtási idő (TMR1CS<1:0> = 00), egy utasítás végrehajtás alatt a TMR1 regisztere is lép 1 -et.
Ha a TMR1 órajele ez Fosc azaz az utasításvégrehajtási idő (TMR1CS<1:0> = 01), egy utasítás végrehajtás alatt a TMR1 regisztere 4 -et lép.

Teória: Minden minta beírása után lekési a timer árfordulását, a TMR1IF -et az átforulás után tölni. Azaz, minden minta után vár még 65536-n ciklust, mire megint átfordul. Ekkor a frekvencia Fosc/4 beállításnál: 32000000 / 4 / 65536 / 360 = 0.339 Hz, Fosc beállításnál: 32000000 / 65536 / 360 = 1.3563 Hz.

11.111kHz -et csak akkor lehetne elérni, ha a programod csak a következő utasításokat tartalmazná:

Még ugrás sem lehetne a végén...

A teóriád tökéletesen helyt áll és a segítségével rá is jöttem a hiba elhárításra A probléma az volt, tényleg, hogy lekéste, túlcsordult és várt még egyet amíg meghívta megint a megszakítást. Viszont ez az én szoftveres hibám volt.
Az alábbi kód helyett:

Ez kell:

Amíg végrehajtotta a megszakítást addig túlcsordult és tényleg kellett neki várnia még egyszer 65535 (minusz a végrehajtási idők utána) időt.
Szóval köszönöm szépen megint!

Van arra esetleg supportolt mód is, hogy a pk2 / 3-al avr-t programozzak avr studio alól? Vagy továbbra is csak a community projectek használhatóak? Jelenleg studio 5 van fent, a 7 nem szeret települni, a 6-ot nem néztem meg egyenlőre.

Pk2 / attiny10 közvetlen programozási lehetőséget taglaló projecteket egyenlőre nem találtam. A pk2avrisp-t találtam meg, de az com0com drivert kér, amiből az ingyenes nem települ, a fizetőst meg "nem szeretem" Valamikor voltak itthon usb / rs232 átalakítóim, de mindet széthordták az ismerősök, és ofc soha egyet sem hoztak vissza. Ha tudsz adni linkeket, vagy konkrét tippet, hogy te hogyan oldottad meg, az nagy segítség lenne most.

Ez sem települ?

Feltelepült, köszönöm

Helyesbítenék: látszólag broken a cucc. Feltelepül, és meg is jelenik valami az eszközkezelőben, de nem az, ami kellene, és nincsen felismerhető COM port a számítógépen. Vacakoltam azzal a testsigning-el is, meg újraindítgattam, semmi. Neked sikerült azt a drivert használnod win7 x64 ulti sp1 alatt?

XP32 -n jól fut, a többit nem tudom...
Létre kell hozni egy port párt, be kell konfigurálni. ezek tényleg nem jelennek meg az Eszközkezelő listáján.

Eljátszadoztam vele mindenféléket, de a pk2avrisp a com0com-al nem ismert fel soros portot, és én ahhoz akartam használni. Amit találtam ( link ) az a nevétől eltérően nem free, fizetős az is, de van free üzemmódja, és azzal megjelenik soros port, amit a pk2avrisp lát, de más programok, mint putty, azzal sem látnak com portot, hogy kipróbálhatnám terminál emulátorokon keresztül. Szóval ajánlani egyenlőre nem merem senkinek azt sem. Programozót üzemeltetni használnám, és majd azzal derül ki, elég jó-e, de azzal még nem tudott kiderülni. Most kapom a pofonokat a programozással. Mikor már éppen égetném a kész hex-et, akkor derült ki, hogy az avrstudio5 az stk500-on keresztül mégsem támogatja a tiny10 programozását (tiny13 alatt nincs ott semmi). Vélhetően a TPI support a baja. Az avrstudio6.2 sem támogatja (ott is csak tiny13-tól fölfelé vannak), a 7.0 pedig fel sem települ. Szóval még kotorászok tovább, mi a fenét lehet csinálni.