Akkor a másik megoldás egy framework készítése, amiben az összes szükséges funkcionalitást előre kidolgozod, és amolyan byte kódot küldesz le pc-ről, mint pld a dotnet csinálja. A formátumot megoldod magadnak. Akkor jó bármilyen pic, aminek a program memóriájában elfér a framework lib. Soros ramból is mellé rakhatsz bármelyik pic-nek, abban elfér a leküldött program.

A programmemóriát írhatod a programból is, nem RAM-ból kell futtatni.

Az alsó pufferben kotorászás a felső szint felől azt jelenti, hogy a fifo-ban a kiolvasási mutatót lépteted, miután kiolvastad az adatot. Ha nem akarsz megszakítást tiltani, biztosan legyen egy legalább akkora buffered, ami közel sem tud megtelni. Akkor nem kell a megszakítási rutinból még ráolvasni sem a kiolvasási pointerre is, hogy a szabad kapacitást ellenőrizd. De memória mennyiségben nem a leghatékonyabb olyat csinálni.

A gyenge angol nagyon nagy baj. Nem tudsz elolvasni egy adatlapot, moccanni sem tudsz a szakmai világban. Sajnos minden angol. Azt is gyűrni kell az elektronika és a szoftver mellé. Fogj egy szótárat, és szavakat egyesével hangyaszorgalommal mindig fellapozni, míg meg nem jegyzed. Legalább 2-300 alap szót és 40-50 mondatszerkezetet / szókapcsolatot fel kell tudnod ismerni ahhoz, hogy szótár nélkül a lényegét megérthesd egy műszaki angol szövegnek. Szótárat még akkor is kelleni fog használni, de már nem idegesítően sokat. Amíg az nincsen meg, meg vagy lőve. Ezen a fórumon tényleg mindenki szívesen segít, de ha hiába linkelünk egy tutorialt, mert le is kell fordítanunk neked minden alkalommal, az nem lesz úgy jó.

FiFo kezelésekor, módosításakor a megszakítást mindig tiltani kell.
Gondolj bele:
Kiolvasod az egyik mutatót, [itt beüt egy megszakítás, és módosítja] majd összehasonlítod a másikkal, és máris elindultál az erdőbe.

Ha valaki megmondja, hogy hol van amit keresek, akkor a Google.translate segítséggel többnyire ki tudom hámozni a lényeget ... úgyhogy köszönöm én az angol linkeket is! Ha meg példaprogram is van, az maga a kánaán ... azon szépen átrágom magam, kivesézve minden sort ...

Én nem hinném, hogy abból baj tud lenni, ha a buffer elég nagy, ergo nem tud annyira megtelni a buffer, hogy az írási pointer körbe érjen (és azt kikötöttük előzőleg). Ha meg éppen nem vettél át egy adatot frissen az adott főciklusban, majd csak a következőben, abból ugyan milyen baj lehet? Főciklus lépésekből van bőven elég.

Ez nem hit kérdése, ha a hibalehetőség fennáll, akkor ki kell zárni. Két utasítással hosszabb a kód mindössze, de kizárjuk a lehetőségét, hogy később, más projektben felhasználva a kódot, egy érthetetlen hibát kelljen keresni.

Nem is állítottam, hogy hit kérdése.

A kiolvasó rutinból ugyan rá kell olvasni az írási pointerre is, de írni nem kell, és olvasni is csak akkor, amikor a megszakítási rutin nem fut (ugyanis az szakítja be a főprogramot, és nem fordítva). A megszakítási rutinban az olvasási pointert kiolvasni sem kell, ha elég nagy a buffer, és tuti nem akadnak egymásba. Az egyetlen probléma, hogy ha valahol megszakítási szintről ráhívsz egy logikai szintű funkcióra, és ott a megszakítási rutin is kap egy megszakítást, amiben logikai funkciót hajtasz végre az adatbufferén. Na abból tud baj lenni. Ha olyat nem teszel, nem lesz baj.

Miért kell olvasni az írási pointert? Annak megállapítására, hogy van-e beérkezett adat?

Igen.

Isteni csoda folytán kiderült, hogy jéééé!!! az adatlapból meg lehet nézni hogyan kell bekötni egy soklábú TQFP tokos PIC-et. Köszönöm, nem kell gratulálni.
((rosszvicc...))
----------
Viszont szeretném megkérdezni, hogy ugyan az adatlap azt írja, hogy lehetőleg minél közelebb tegyük azokat a minimálisan szükséges kondikat és ellenállásokat a lábakhoz, (5-6mm) mégis mennyire zavarhat be, ha én azokat a "breakout"panelen kívül helyezném el? Nem vagyok felkészülve nagy volumenű SMD forrasztásra meg eddig csak DIP-ben foglalkoztam dolgokkal, ezt az ICt is ismerős segít betenni a helyére.
Illetve ha majd az áramkörön belül szeretném programozni az ICt de a PGD PGC láb I/O-nak van használva akkor beduzzog az LVP=off?

A terv az lett volna hogy egy pici program a PICen ellátná azt a feladatot
amit a PC küldene neki. A beérkező folyam, ha hitelesítésen átment a RAMcímen
start majd vissza figyelési helyzetbe.
Épp tegnap éjjel gondoltam, hogy ha PC által küldött csomag
a program memóriába flashbe íródna könnyen lehetne onnan futtatni.
Igen, de mennyi idő veszne el emiatt.
Mondjuk 256 os üzenetnél
jelentős veszteséggel kellene számolnom a RAMozáshoz képest?

Szóval a terv nem az lett volna, hogy a PIC re hónapokig írogassak,
hogy minden nekem kellő dologra fel legyen készítve.
Pedig ha a flashezés tényleg lassító tényező, akkor viszont csak az a lehetőség marad.

Köszönöm a kimerítő választ!
Most éppen az írással küzdök. Valamiért nem akar menni. Az adatlapban lévő példát használtam, nem ment. Kiegészítettem két pollinggal, hátha az a gondja, de továbbra sem működik, pedig mintha ezt a rutint használtam volna már korábban. A forrásban létrehozott "DE" táblát berakja rendesen, de futás közben nem írja felül az értéket valamiért.

Szia!
Ha alaposan átnézted - az adatlapokon vannak nyákterv javaslatok is az elhelyezésre. Nyilván minél rövidebb a távolság - annál jobb. Az, hogy mennyire jelent gondot - azt a saját körítésed is jelentősen befolyásolhatja, így ez eléggé egyedi lutri. Minél inkább ragaszkodsz a gyári ajánláshoz, amit laborban vizsgáltak be - annál inkább valószínű, hogy kevesebb meglepiben lesz részed. A többi - teszt és mérés kérdése. Nyilván minél hosszabb egy vezetőszakasz, annál inkább dominál a nyák szórt kapacitása, induktivitása, ellenállása és annál jobban beleszólhat az áramköröd működésébe nemkívánatos módon. Sokszor segíthet az is ha ki tudod kompenzálni - például a gyári ajánlástól eltérő értékek használatával.

Látszik, hogy már nem látok... Két betű felcserélődött valamiért, most jó.

Köszönöm!

Workaround gyanánt a működési frekit csökkentheted le. Aztán programja is válogatja, mi mindennel nyúzod meg azt a pic-et, ami burst áramot kajálhat, mert amiatt lesznek gyanús ön-reset jelenségeid, ha nincsen elég sok feltöltött kapacitás elég közel. Például az a/d és a pwm esznek rendesen, egy bitenként programvezérelt i/o állapotgép meg teljesen igénytelen.

Amúgy azt a dolgot, hogy pc-ről leküldeni programot, átgondoltad te azt rendesen? Amit terveztél, az egy just-in-time fordító + eleve int vektorokon keresztül moduláris környezet a pic-en, mint amilyen a linux kernel alap. Máshogy ugyanis képtelenség lenne tényleg nyers kód leküldését kivitelezni. Az a technológia ha létezik is pic-re, nagyon guru laborok mélyén létezik csak jelenleg, és 18-asokkal ők már biztosan nem foglalkoznak. Byte-kódozni meg ram-ból is tudsz egyébként is.

Néhány fogalom:
Kritikus erőforrás: Olyan több folyamat által használt adatszerkezet, eszköz, amin csak egy folyamat végezhet műveletet. (Nyomtató. - Milyen lenne, ha a konkurensen nyomtató programok eredmény pl laponként felváltva jönne ki a nyomtatóból...)

Kritikus szakasz: Olyan több folyamat által használt programrészelt, amit egyszerre csak egy folyamat futtathat. (folyamatok bözötti bufferek kezelése)

Kritikus művelet: Olyam programrészlet, ami kritikus erőforrást kezel.

A kritikus erőforrás lefoglalása, felszabadítása, módosítása műveleteket úgy kell megvalósítani, hogy ha egy folyamat belekezdett, a többi ne szakíthassa félbe.

A példában a buffer a kritikus erőforrás, a beírása és a violvasása a kritikus művelet. (Ha a kiolvasó, beíró rutint több folyamat is használhatná, akkor azok kritikus szakaszok is lennének.)

Primitív művelet: Olyan művelet, amit nem tud más folyamat félbeszakítani, lépései egymásután megtörténnek.

Egy elemi utasítás: Olyan utasítás, amit más folyamat nem tud félbeszakítani. (A DMA lehetősége is gondolni kell, amikor az utasítás feldolgozása során előforduló memória műveletek között a DMA (/ másik bus master DMA kéréssel) átírhatja a tartalmukat).
Pl. Egy decf valami,f a PIC16 és PIC18 elemi utasítás,de egy PIC24, PIC30,PIC33 esetében már nem biztos.


Ezekután: A megszakítás tiltásának kérdése attól függ, milyen utasításokkal oldjuk meg a műveleteket. Ha egy kritikus műveletet nem tudunk megvalósítani primitív utasítással a szakasz elején a többi folyamatot ki kell zárni, a végén a kizárást fel kell oldani. Nem biztos, hogy minden megszakítást le kell tiltani, elég ha az tiltjuk le, ami már kizárja a többi folyamatot. Megszakítási rutinból a saját szintet nem kell tiltani, csak azokat, amik félbeszakíthatják a kiszolgálóját.

Pl. UART vétel. Elegendő a RCIE -vel tiltani a vételi megszakítást a vételi buffer kiolvasási kritikus műveletében.

Ha nem akarunk mutatókat összehasonlítgatni, akkor kell egy harmadik változó, a tárolt adatok darabszáma. Ezzel sokkal egyszerűbb és átláthatóbb a buffer szervezés. A darabszám növelése / csökkentése (256 - ig) primitív műveletekkel megoldható (incf darabszam,f / decf darabszám,f).
Beírás: Előbb beírjuk az adatot, módosítjuk az írási mutatót, majd primit művelettel növeljük a darabszámot. Ha a megszakítás a régi értéket "kapja el", akkor vár majd még egy kicsit, ha az újat, akkor már jó adatot kap.
Olvasás: Ellenőrizzük, hogy van-e adat (nem csökkenhet más folyamattól), ha van adat, kiolvassuk, módosítjuk a kolvasási mutatót és primit művelettel csökkentjük a darabszámot.

Köszönöm az emlékeztetőt, ismétlés a tudás atyja. De akkor konkretizáljunk folyamatlistában.

Kikötések:
1. A buffer elég nagy ahhoz, hogy az írási mutató soha sem tudja beérni az olvasási mutatót (megtelt a buffer)
2. Az interruptokat mindenütt alsó fél layerek kezelik, az alsó fél szintjéről soha sehol nincsen ráhívás logikai funkcióra, mindegyikük csak a saját adatbufferében dolgozik (szerk: itt utólag egyszerűsítettem is, +tagmondat törölve).
3. Elfogadható, hogy egy éppen megérkezett új adat az adott főciklusban "nem érkezik meg", majd csak a következő ciklus fogja érzékelni.
4. Csak egy cpu mag van.

Interrupt rutin:

-beolvasni új adatot, ha van, ha nincs, kilépés
-beolvasni írási pointert változóból
-inkrementálni az írási pointert
-kiírni az írási pointert változóba
-kiírni a beolvasott adatot a címzett int_fifo tömb rekeszbe

Logikai rutin (főciklus része):

-beolvasni az írási pointert változóból
-beolvasni az olvasási pointert változóból
-ha a kettő egyforma-> nincs új adat, kilépés
-inkrementálni olvasási pointert
-kiírni olvasási pointert változóba
-beolvasni az új adatot az olvasási pointer által címzett int_fifo tömb rekeszből
->az a fentebbi új adat lesz, ami megy át az int_fifo-ból az alkalmazás szintű bufferbe, ott is hasonló rutinok, azt már nem írom le újra, irreleváns

Kíváncsian várom, milyen esemény sorrend tud integritás hibát előidézni a fenti folyamat esetén. Fogalmazzunk _egészen precízen_, ha kérhetném.

Kikötések:
1. A buffer elég nagy ahhoz, hogy az írási mutató soha sem tudja beérni az olvasási mutatót (nem telhet meg a buffer)
Akkor okozhat csak integritás hibát, ha az alábbi lépés nem primitív művelet:
-beolvasni az írási pointert változóból
Pl. a buffer mérete 8 bites gépen 256 -nál nagyobb.

Egyébként, ha megtelhet a buffer addigra, amig az olvasás el sem indul:
Ekkor nehéz eldönteni, hogy üres-e a buffer vagy tele van. Mindkét esetben az írási mutató 0.

Jellegében értem a problémádat, de egy valós környezetben vagyunk, ahol bizonyos elméleti jelenségek nem tudnak előfordulni. Például mert nincsen több magod párhuzamos végrehajtással. Egy magod van, amin csak interrupt rutin tudja beszakítani a főprogramot, fordítva nem. Ugye éltünk azzal a kikötéssel (2), hogy az interrupt rutinok csak a saját adat buffereiket kezelik, és nem hívnak rá logikai funkcióra - nem kerülhetnek konfliktusba a logikai funkciók az interrupt rutinok saját futásával. Ha egy interrupt rutin be is szakítja a másik interrupt rutint, lévén nem nyúlkál amannak a dolgaihoz, nem fog bajt csinálni a másiknak. Nyugodtan beszakíthatja. Azok futása tetszőleges időzítésű lehet.

Egy ponton kiegészíteném a kikötéseket:
5. A cpu teljesítményének elég nagynak kell lennie az interrupt rutinok kezeléséhez. Az interrupt rutinok nem futhatnak rá önmagukra legrosszabb esetben sem a gyenge cpu teljesítmény miatt. Konkrétan ugyan abból a megszakításból nem érkezhet újabb, míg még az előző sem futott le, mert annyi interrupt éleződött egyszerre, hogy mind beszakítgatták egymást, és nem bírta a cpu lefuttatni az előző rutint sem, míg már a következő is megérkezett.

Kiegészítés az interrupt rutinba tetszőleges helyre:
-hw megszakítás engedélyezése

Egyszerűen csak kifelejtettem belőle. Nem a globális interrupt a kérdés, hanem specifikusan pont az a megszakítási flag, ami éppen beérkezett, és aminek a rutinja éppen fut. Tehető bárhová a kikötés (5) miatt, a rutin legelején is jó helyen van.


Konkrétan az írási pointert illetően annyit jegyeznék meg, hogy a főprogram logikai funkciójának teljesen lényegtelen az írási pointer értéke, és azért is nem tud integritás hibát okozni. A byte-os kezelés folytán legrosszabb esetben ami előfordulhat, hogy egy beérkezett byte-ot nem fogunk abban a lépésben érzékelni, mert az összehasonlító művelet éppen beszakadt az interrupt rutin miatt. De éltünk azzal a kikötéssel (3), hogy az elfogadható. Az nem azt jelenti, hogy adat veszik el, az annyit jelent, hogy a következő főciklus lépésben fogjuk csak megkapni a byte-ot. Az írási pointert pedig ne akard értelmezni a logikai rutinban. Nincsen rá szükség. Az vagy pontosan egyezik az olvasási pointerrel (akárhány byte-on), vagy nem. Az értelmezése csak annyi. Az persze továbbra is gondot okozhat, ha az interrupt buffer valaha is betelhet, és pont végig ért a pointer, azért is egyezik az értéke újra, én is tudom, direkt azért is éltem azzal a kikötéssel (1), hogy az interrupt buffernek elég nagynak kell lennie pusztán mérete folytán biztosan elkerülni azt a lehetőséget - ugyanis még belső hiba visszajelzési lehetőség sem lesz, észrevenni sem tudjuk biztosan azt az esetet.

Egyébként részemről a visszajelzési hiány miatt is jeleztem, hogy én is jobb szeretem az interrupt tiltást, de ha már felvetődött a kérdés, hogyan lehet mégis anélkül megoldani, hát jeleztem, hogy bizonyos drawback elfogadásával van gyakorlati lehetőség arra is, és most arról az esetről értekezünk.

Éltünk a kikötéssel (1), axióma, hogy nem telik meg a buffer. Ha az nem telik meg, akkor is tud-e problémát okozni a 8 / 16 / 32 bit esete? Ha szerinted igen, hogyan?

Sziasztok!
Elemes vésztápláláson agyalok. Timer1-et hajtom egy külső óra kvarcról, ami egy sima órát működtet, mivel jó lenne ha áramkimaradás esetén nem kéne az órát újraállítani, arra gondoltam, hogy egy digitális bemeneten figyelném, hogy van-e hálózati áram. Ha nincs akkor mindent leállítanék csak a Timer menne és megszakításban léptetem az időt és ellenőrzöm a házózati áramot. Ha visszatér az áram visszaállítok mindent az eredeti állapotába. Mennyire életképes ez az elképzelés? Vagy jobb lenne inkább egy külső RTC-t használni?

Slendrián megoldás egy adott környezetben akár működhet is. Mint írtam, ilyen programrészeket egyszer ír meg az ember, utána már csak felhasználja későbbi programokban. Két-három év után már komoly mennyiségű hümmögést és fejvakarást eredményezhet egy ilyen megoldás.

Persze teljesen elméleti síkon, mert a konkrét esetre nem vonatkozik.
Legyen a buffer mérete nagyobb, mint 256 byte, egymagos, 8 bites kontroller DMA nélkül.

A kiolvasó rutin meghívásakor legyen 255 karakter már a bufferben, az írási mutató tehát 0x0FF.
Kezdődik a leírt kiolvasás:
1--beolvasni az írási pointert változóból:
1.1 az írási pointer alsó byte-ja az átmeneti változó alsó byte-jába.
1.2 az írási pointer felső byte-ja az átmeneti változó felső byte-jába.
2-beolvasni az olvasási pointert változóból
3-ha a kettő egyforma-> nincs új adat, kilépés
... folytatódik, de ott már nem okozhat bibát.

Ha a buffer író megszakítás (egy byte újabb adatot beír) az 1.1 és 1.2 között érvényre jut, akkor az átmeneti változóban 0x1FF lesz, ami nyilvánvalóan hibás, az olvasási mutatóval való összehasonlítás hibás döntést hoz (511 byte van a bufferben).

1--beolvasni az írási pointert változóból:
1.0 Megszakítás tiltás
1.1 az írási pointer alsó byte-ja az átmeneti változó alsó byte-jába.
1.2 az írási pointer felső byte-ja az átmeneti változó felső byte-jába.
1.3 Megszakítás engedélyezése

A fenti hiba nem jöhet lépre.
Ugyancsak nem jöhet létre ekkora buffernél 16 és 32 bites magokon --- csaak jóval nagyobb buffer esetén..

Sziasztok szerintetek eleg 4mhz egy orahoz ??? Pic16f628 al csinalnam. Nincs idomultiplex csak annyi hogy 1 masodpercenkent frissitem a kepet. (Talan valahol van 18mhz is itthon)

Bőven sok. Azt is rengetegszer kell leosztani ha 1 másodperces jelet akarsz.

Teljesen működőképes. A táp figyelésre oda kell figyelni, nehogy az elem feszültsége valahogy visszajusson a figyelő részre (a védődiódákon, vagy egyéb áramköri elemeken keresztül). Megmértem, amikor nincs táp 1,5uA a fogyasztás, de ez oszcillátorral van 0,5mp-es megszakításokal, közben a PIC alszik. Bővebben: Link

Na ez jó hír! Azt kell még kipróbálnom, hogy egy 16F886-os belső oszcillátorral elmegy-e 2 db ceruza elemről. Az adatlap szerint 4 MHz-en már 2V körül működőképes, de hiszem ha látom.

Idézet:
„Ha a buffer író megszakítás (egy byte újabb adatot beír) az 1.1 és 1.2 között érvényre jut, akkor az átmeneti változóban 0x1FF lesz, ami nyilvánvalóan hibás, az olvasási mutatóval való összehasonlítás hibás döntést hoz (511 byte van a bufferben).
”

Oké, lévén pusztán elméleti síkon vagyunk, a teljesítmény paraméterek is áldozatul eshetnek Hiba nem lép fel olyankor, ha az összehasonlítás eredményéből nem kívánsz bufferben lévő adatmennyiséget számolni, csupán azt meghatározni, van-e kiolvasandó byte a bufferben, vagy nincs. Bit szintű összehasonlítás, és nem matematikai számolás. Az interrupt buffert egyesével olvasod ciklusban, byte-ról byte-ra, mindig megismétled a teljes műveletsort.