Na pontosan az a bajom az adatlapokkal amit megfogalmaztál.
Rutinos felhasználók, profik számára írják, profik. Közben elfelejtkeznek arról, hogy ők is voltak kezdők, és ami a számukra egyértelmű, az egy kezdőnek nem az. Bár lassan két éve foglalkozom PIC programozással, és nem csupán ráérő időmben hobbiból, még mindig szánalmasan kezdő vagyok ahhoz, hogy egy profiknak készült adatlap mindenben a segítségemre legyen.
Ismételten jó példa a DS1821-es adatlapja. Most már, hogy megértettem (legalábbis remélem) az 1-Wire működését, a korábban számomra érthetetlen adatlap egészen beszédes lett. Csupán ez a célom. Megérteni hogyan működik, és hogyan kell használni. Ebben viszont nem partnerek ezek az adatlapok. A kínai vagy japán nyelvűektől meg mentsen meg az isten engem.

Írd kis betűkkel az utasítást:
asm("btfsc PORTB,2")

Sajnos ők vannak többen, ráadásul az a munkájuk. Az idő pénz...

Valójában amit profik írnak, az bőven elég részletes ahhoz, hogy a szükséges alapokkal azt a részt tökéletesen megérthesd. Az más kérdés, ha neked sokkal szájbarágósabban kell valami, mert az alapjaid hiányosak, felületesek, és főleg, nem figyelsz arra, amit már megtanultál. Úgy egy kicsit nehéz. Olyankor még alapozni kellene előtte.

Megint csak nehéz időnként azt megértenünk, pláne, ha mindenre kígyót-békát kiabálsz, hogy időnként tényleg hulladék egy adatlap, és az a bajod, hogy noobok írták (mert néha bizony olyan is van, főleg koreai felebarátaink részéről stb) vagy csak türelmetlen voltál megint annyira, mint egy másféléves kisgyerek, amikor már elfáradt, és azért hisztizik, mert pihennie kellene. Olyankor nem igazat adok neki, hanem beteszem a járókába, és alvás van. Felőlem ugyan toporzékolhat, aludni fog, és pont.

Adnék egy tippet a pic adatlapokhoz. Te programozható egységnek akarod őket kezelni, és az rossz szemlélet. A pic-ek áramköri blokkok, amiknek csupán _mellékesen_ van programozhatósága is. A végrehajtó egység a pic egyik összetevője, és nem maga a pic. Próbáld meg állapotgépek halmazaként szemlélni a pic-et, és máris logikusabb lesz az adatlap felépítése is. Ugye a lábkiosztás és "big-picture" blokk után a következő legfontosabb, hogy kell a stabil ütem jel (oszcillátor leírás), aztán az egyes funkcionális blokkok (mint az i2c is, de az összes többi is), utána jön az, hogy azokat a blokkokat össze is tudja fogni a pic - és csak ezen a ponton érkezel el a programozáshoz, és az utasítás készlethez. Végül még az elektronikai korlát értékek, és a tok mechanikai paraméterei vannak az adatlapban. Meg lehet szokni, csak próbáld meg elfogadni, hogy az egész pic világnak van egy fejlődés története, és történeti okokból olyan az adatlapok felépítése, amilyen. Egy kialakult szokványt hirtelen leváltani az újoncok miatt sohasem volt bölcs dolog a történelemben egyáltalán semmivel sem. A fiatalok majd tanulnak, és vagy megszoknak, vagy megszöknek, de ugyan ne rúgják már ki a ház oldalát, hát hol élnek ők? Amiben idővel még fejlődtek mc-ék, az a dokumentációs "preliminary". Néhány fontos tulajdonság előnézetként ki van rakva az adatlap legelejére, és annak is lehetnek fejezetei, a tényleges klasszikus adatlap csak az után következik. Akár néhány mechanikai paraméterre vonatkozó figyelmeztetés ott lehet az oszcillátor leírás előtt. Az nem káosz, az előnézeti információ. A tartalomjegyzékben egyébként nagyon könnyű ugrani.

Mindent összevetve: a kezdők mindig flamelnek picit, azt már megszoktuk, semmi baj, kijár neked is a tanulópénzen háborgás ideje, csak ne vidd túlzásba.

Mielőtt legközelebb véleményt alakítasz ki valakiről, és dörgedelmesen lehordod, vedd a fáradtságot, és keresd meg a témával kapcsolatos első hozzászólását. Olvasd végig az összeset, és ne az utolsóból ragadj ki szemelvényt mint Jehova tanúi a bibliából!
Többek között ezt is írtam:

Ha beérném azzal, hogy mások által létrehozott függvényekből építgessem fel a programjaimat, (ami aztán vagy működik, vagy nem) nem assemblyben programoznék, hanem C-ben vagy hasonlóban.
A korábbi oldalakon UART kapcsán, meg hangrögzítő kapcsán voltak kérdések.
Jöttek is a jó tanácsok! Írd ilyen, vagy olyan programnyelven, használj arduniot, mert ott vannak kész függvények.
Na ezekre nem vagyok én vevő. Ha nagyon bonyolult dolgot akarok csinálni, kevés munkával, arra PLC-t használok. Kisebb feladatokhoz használok PIC-et. És nem egyszerűen programozni akarom, hanem érteni, hogy mit miért csinál! Ha ez ezen a fórumon bűn, és megvetést szül, akkor inkább kiszállok.

Ez pont nem érzékeny kis- és nagybetűre, próbáltam.

Az adatlapok felépítése (legalábbis a nyolcbiteseké, amit én ismerek) ugyanarra a kaptafára épül. Nem kötelező a fejezeteket sorban egymásután végigolvasni, arra alapoznak, hogy azt a 30-40 utasítást ismeri, aki a kezébe veszi. Ha már az x-edik típus adatlapját nézed, és nem akarod rossznak látni, akkor megtalálhatod a logikát, és használhatóságot.
Ezek nem tankönyvek, az a cél, hogy elégséges alapismerettel gyorsan használhatók legyenek.

Talán ez segít.

Üdv!
A következővel kicsit elakadtam. Két pic beszélget SPI-n. Az működik, hogy a mester küld egy adatot a slave-nek, a slave buffer int-je csinál csinál egy megszakítást és kiolvasom a buffert. Nade, mikor csak adatot kérek a slave-ből, akkor az honnan tudja, hogy kiolvasták a bufferből az előző adatot, és beteheti a következőt? Az SS lábat nem tudom figyelni, mert azon nincs port megszakítás, a folyamatos port figyelés meg sok prociidőt venne el. A másik: azt jól értelmeztem, hogy amikor küldök egy bájtot a mesterből, és az a kapcsolat jellegéből adódóan egyúttal kiórázza a slave bufferét (ha közben ezt nem írtam, akkor értelemszerűen az előzőleg küldött adatot tartalmazza) azt nincs lehetőségem kiolvasni és eltárolni a mesternél?

Bocs, hogy beleszólok, de szerintem a PIC-ek adatlapjában eléggé szájbarágósan van leírva minden (igaz, angolul). Nem kell pl. előtte elolvasnod több oldalt a soros port működéséről mert le van írva benne, hogy használd abból meg már meg lehet érteni a működését is. Lényegében elég annyit tudni róla, hogy van start bit, stop bit, RX, TX, meg hogy baud és 8-9 bit. Talán van is itt HE-s cikk róla, elég annyi elméleti tudás is az első sikerélményhez.
Az adatlap meg részletesen leírja neked, hogy mit csinálj a regiszterekkel és bitekkel, hogy működjön a dolog, kitérve azokra az esetekre is, hogy mikor nem fog működni a kommunikáció, mire kell odafigyelni.
Én mondjuk egy új kommunikációnál amit még nem használtam, van hogy egyből a hozzákapcsolódó regiszterekkel kezdem az ismerkedést (nem szeretem a sok rizsát én sem), szóval egyből belecsapok a lecsóba és miközben olvasom az adatlapot, úgy el is kezdem az inicializáló függvény megírását. Majd ha nem ismerek pl. egy bitet, akkor utána nézek az adatlapban, hogy kell-e az nekem első körben vagy sem. Persze előtte elolvasom a neten pár sorban pl. az I2C működését.

A C nyelv alapjait meg ajánlom mindenkinek megismerni, mert vele könnyebb papírra vetni egy készülő algoritmust is, amit aztán könnyebb lesz átírni assembly-re. Én mikor assembly-ben kezdtem programozni a PIC-eket, akkor is igazából papíron C-ben kezdtem kidolgozni egy-egy függvényt.
Meg ne hogy azt hidd, hogy ha C-ben van egy kész függvény akkor azt már használni is tudod. Ha nem netes példákban nézel utána a használatának, akkor bizony meg kell nézni a header és source fájlokban a gyári függvényed felépítését. És ekkor rájössz, hogy te se tudnád jobban megírni a függvényt így nem is írsz sajátot.

Angol: Firefox-hoz létezik egy úgynevezett Google Translator kiegészítő. Ezzel automatikusan tudsz szótárazni szavakat, mondatokat, nem kell gépelned semmit. Ha böngészőben nyitod meg az adatlapot akkor a nem szkennelt pdf-eknél is működik a dolog.

DS1821: Ha valamit nem értesz egy adatlapból, akkor keress egy másik hasonló alkatrészt, annak az adatlapján talán érthetőbben le van írva a kommunikáció működése. Például ha a DS1821 helyett a DHT11 adatlapjával kezdesz, akkor talán hamarabb célhoz értél volna. Ha jól látom mind a kettő hasonló kommunikációt használ.

Kérdésem első fele megoldódott. (Ilyenkor 255-öt tölt be a bufferbe, ez ugyanúgy létrehozza a vevőoldalon a megszakítást).
A kérdésem másik része még mindíg nyitott...

Nincs azzal semmi gond, ha valaki valamit nem ért. Azért vagyunk itt, hogy egymásnak segítsünk.
De előfordul, hogy nehéz segíteni valakinek, aki ezt a szándékot nem ismeri fel.
Nem említenék itt szerénységet, önkritikát, tiszteletet, némi szakmai alázatot.
Tetszik, nem tetszik, de ezek a személyes- és szakmai fejlődés alapjaihoz tartoznak.

Az spi természetéből adódóan full duplex. Pont annyi adat megy ki, amennyi bejön, azt átlag fel lehet használni. Az első kimeneti adat azonnal átíródik az adás-vételi regsizterbe, a következő már a kimeneti fifo-t tölti. Ha a kimeneti fifo egyszer már megtelt, és utána ürült benne hely, általában van rá megszakítás, mint ahogy arra is, hogy van beérkezett adat. Ha nem találtad meg az adatlapon azt a megszakítási mechanizmust, linkeld, melyik pic-ről van szó.

Ha csak olyan gondba ütköztél bele, hogy az első megszakítás után valamiért nem érkezett meg a többi, jelezném, hogy az egyszer aktívvá vált megszakítást "kinullázni" szokás mindegyik pic esetében, azt sose felejtsd el.

Tipp: némelyik pic adatlapján részletesen leírt "best practice"-t is találni lehet kódmintákkal. De valami egyszerű "hello spi" példa mindegyiknél lenni szokott vagy kóddal is kirészletezve, vagy legalább részletesen leírva.

Alapvetően teljesen jól működik a cucc(megszakítások, etc.), csak az nem egyértelmű, hogy a második küldött adat mikor kimegy, akkor avval egyidőben "kiórázódik" az első a slave-ből. Ez az adat (is) eltárolódik/kiolvasható a mesterből? Vagy azt a pic figyelmen kívül hagyja? Mert most kiküldök 8 bájtot, , majd azután csinálok 9 kiolvasást, ez eléggé időtpazarló... Gyorsabb lenne, ha a második adat kiküldésekor már egy általam a slave bufferébe írt (válasz az első adatra) adat jönne vissza. Ez így pont a fele annyi idő. 16f1824.

Az idővonalad úgy néz ki, hogy amikor beírod az első byte-ot a master kimeneti regiszterébe, az onnét átíródik az adásvételi regiszterbe, és a kimeneti fifod üres lesz (jön majd az int is elvileg). Az az int azonnal jön meg, amikor a kimeneti byte még el sem indult, épp csak indulófélben van. Ami byteot akkor írnál a kimeneti regiszterbe, az már várni fog pld. Azután telik el idő, aközben az adásvételi regiszter a mastertől írja átfele az adatot a slavenek. Az alat az idő alatt csinálhatsz a pic-el bármit, nem kell azt kivárnod. De ha mégis fontos kivárni, egy byte jellemzően hamar kimegy. Miközben megy ki, jön befelé a slavetől amit ő küldött, vagy dummy byte, ha nem írtál még soha semmit a kimeneti bufferjébe, esetleg nem volt mit küldenie, az alapértelmezett adat akár 0x00 akár 0xff, akár az utoljára elküldött byte újra, azt nem tudom, pic adatlapon talán írja, de az is lehet, legjobb lesz megnézned a saját szemeddel. A lényeg, hogy miközben a master kiküldte az adatot, jött is valami befelé, és az az adásvételi regiszterben bitenként összeáll, majd amikor összeállt, átíródik a vevő fifo regiszterbe, és kapod az interruptot, hogy kiolvasható adatod van. A háttérben pedig ami újabb byte-ot a master fifo-jában hagytál esetleg, az már átíródott az adásvételi regiszterbe, miközben az interruptod éleződik, és elindult kifelé. Ha hamarabb tudja kiírni, mint hogy te kiolvasod a beérkezett byte-ot az input fifo-ból, és az adásvételiből azt az új beérkezett byteot is (akár újabb dummy, ha más nem) már rakná az input fifoba, miközben az még tele van, akkor lesz egy overflow error-od. Az spi modul jellemzően blokkol, az overflow bitet "kézileg" ki kell törölnöd, addig az spi nem fog több műveletet végezni. De az is picje válogatja, az adatlapot végig kellene skubizni, hogy a te esetedben mi fog történni. Ilyesmin filozol?

Értem, és közben kipróbáltam: így a második küldött adattal megkapom az elsőt a slave-től. Mi az elegánsabb megoldás mester oldalon: ismerve, hogy a küldési idő ~8usec, várjak 10 -et és azután olvassam ki a mester oldalon a tárolót (most így próbáltam), vagy mindenképpen inkább a BF bitre várjak?

A 16 bites PIC24 családot tanulmányozom. 3 ICSP portja is van. Gondolom, ezt azért csinálták így, hogy arra köthetem a programozót, amelyik lábait egyébként nem használnám semmi más feladatra. Azt nem találom az adatlapon, hogy ezt én szabadon döntöm el, hogy melyikre kötöm, vagy valahogy be kell állítani, melyiket akarom használni? Valaki tömören össze tudná foglalni, mire kell figyelni több ICSP portos PIC használata során?

Emlékezetem szerint programozásra bármelyiket használhatod, ( persze csak párban, az összetartozó CLK és DATA lábakat). Debug-hoz pedig a config szóban ki kell választanod hogy a 3 pár közül melyiket akarod használni.

Hmm, éppen skubizom, hogy a 16f-nél kicsit olcsóbban van legyártva az spi. Itt egy árva darab fifo regiszter sincsen, csak ugyan az az 1 byte-os átmeneti tároló. Szóval a folyamat annyi, hogy kiírod az 1 byte-ot, és utána vagy programozottan várakozol, vagy megszakítást állítasz be hozzá, de kivárod valahogyan, és amikor megjött a BF, akkor kiolvasod a vett byte-ot. Miután kiolvastad, utána írd ki a következőt. Hogy programozottan várod-e ki, vagy beállítod az IF bitet, döntsd el te. Az interrupt mcu mag kímélőbb, a programozott pedig egyszerűbb kód.

Sziasztok. Pic18F46K22 interrupt rutin mérete korlátozott? TMR0 belső órajelről 64us időnként interruptot csinál. Ha rövid az interrupt rutin, minden jó. Ha hosszabb (egy határon túl), akkor hiba van, kijelzőn zűrzavar. A rutin futásideje kb.20us, jóval rövidebb, mint két interrupt közötti idő, ebbe belefér. Ha megnövelem az interrupt időt TMR0 prescaler 2 helyett 16 -ra, jóval hosszabb iinterrupt idő esetén ugyanaz a hiba, tehát nem itt a hiba.
Konfigurálás, bekapcsolási beállítás:
'----- Interrupt, Timer0 -------
T0CON = %11000001 'timer0 konfigurálása
INTCON = %10100000 'interrupt konfigurálása
Interrupt rutin végén: INTCON = %10100000, törli T0IF bitet
A program basic, port lábat programból állítok interruptnál, és rutin elején is magasra, végén le, ebből látom az időket.
A basic program kb. 20 sorosig jó az interruptban, ha több, akkor van a hiba.
Köszönöm.

Csatolhatnád a teljes kódot.
A hosszabb rutinnál nincs stack tulcsordulás?

Nincs méret korlátozás, de a lehető legrövidebbre kell törekedni. Ha egy megszakítási okhoz terjengős feldolgozás járul, a feldolgozást a főprogramban kell elhelyezni. A megszakítási rutinban csak a fontos adatokat kell megszerezni, elmenteni, stb., és jelezni, hogy van új feldolgozandó adat. A számolás végén a főprogram jelezheti, hogy van újabb kiszámolt érték, egy timer megszakítás figyelheti vagy egy software megszakítás értesítheti a kiszolgálót, hogy vegye el. Amíg a megszakítás fut a saját szintjének kérése nem okoz újabb megszakítást, de figyelhető a megszkítási rutinból is. A magasabb szintű megszakítás kiszolgálása alatt az alacsonyabb szintű kérés nem jut érvényre, meg kell várnia a magasabb szintű kiszolgáló végét. Így előfordulhat, hogy egy kérésből egy elvész, azaz az első kérés és a kiszolgálásának megkedzése (pontosabban a jelzőbitjének törlése) között újabb kérés érkezik.
Mit is csinál az a program?

Bizony rossz gyakorlat: "az Interrupt rutin végén: INTCON = %10100000, törli T0IF bitet", mivel a megszakítás azelőtt lesz engedélyezett, mielőtt a stackk -ról a visszatérési címet levette volna a kontroller.
Használd helyette a IT0F = 0 formát (bcf INTCON , T0IF). A megszakítás engedélyezését a retfie -re kell bízni.

Elektro.on, Hp41C .
Köszi a segítséget, csatolom az interrupt basic kódot. A retfie nem tudom hol legyen elhelyezve.
Ez 8 csatornás fordulatszám mérés. Interrupt figyeli a 8 db.portb lábon a magas szint megjelenést 64us időnként, ekkor beszámol "forda" változóba (utána másik hétnél "fordb, fordc, stb.)
Egy csatornát csatoltam, utána sorban van a többi 7, ugyanez, csak a változónevek mások. A 8 -ból hármat betehetek interruptba, rendben működik. a negyediknél kijelzőn zavar lesz. Portc.4 lábon szkóppal látom, hogy rendben megjelenik az interrupt, portc.4 lábat kapcsolja belépéskor magas, kilépéskor alacsonyra. 20us a 8 csatorna működési ideje, van rá 64us.
Ha ugyanez a basic főprogramban van polling módon, akkor tökéletesenműködik.

Húúha..
Nem túl átlátható a kódod.. És jobb lenne alul a kód gombal beszurni.
Így basic -ban most értelmeznem kell, mert én inkább pascal - ozok.
De a helyedben megszívlelném Hp41C javaslatát, és a főprogramba beraknál egy eljárást amit a megszakításból meghívhatsz.

Kimaradt a végén: INTCON = %10100000

Nem is tudtam a kód beillesztésről, de így sokkal jobb.
Mi az az eljárás amit megszakításnál meghívok? Nem értek nagyon ehhez.

Az eljárás PL. Basic ben:
Sub Procedure eljárásnév ...

Ezt ismerem, de interruptból kiléphet főprogramba, ott lenne az eljárás? Tehát csak az eljárás hívását végezné az interrupt?

Igen, kiléphet. Erre használja a Stack -et. Bementi a PC állapotát, Ugrik az eljárásra, majd amikor azzal végzett akkor a Stack -ből kiveszi az utolsó PC címet ami ugye jelen esetben a megszakítási rutin és onnan folytatja. De ugye egyrészről figyelni kell, hogy ha több rutiból ugrálunk ide oda, ha a Stack túl csordul gondok lesznek...
Valamint ami még fontos, ilyenkor a regiszterek állapotát is el kell menteni , illetve vissza állítani. Én MikroPascalt használok , ez a fejlesztő környezet erről gondoskodik. (Lehet, hogy a te Basic -ed is, de azért nem árt ezt is észben tartani...)

Melyik basic ez?