Több érv is szól a hardveres megoldás mellett,csak bizonyos 32-es széria az eléggé el lett +%!+%,nekem semmi gondom a 24-esekkel. Egyszer beállítod a hardveres rész,és utána nincs gond vele,ha nem éppen 32-esekkel csinálod . Igen ennél a megoldásnál várakozás van,de a hardvereset használhatod megszakítással,DMA-val,pl. ott nem várakozol,addig a proci azt csinál amit akar.Ez a lekérdezős módszer addig jó,ameddig csak 1 dolog kell,de amikor már 2-3 dolog is megy,akkor már marad a teljes hardveres megoldás.

Az OE lábat kösd tápra ellenálláson(4,7k-10k) keresztül,akkor a kimenetek elméletileg lebegnek,így a tranyók bázisának a felhúzásával nem indulhatnának be.Az OE-re meg mehet 1 jumper a gnd felé.Amikor kész a programozás,akkor jumper fel,és kész is

Tud egy kicsit jobb is lenni a szitu, csak akkor alkalmazni kell az összes hozzávalóját a koncepciónak.

Példák spi használatra. Egyszer beállítod, és aszinkron alkalmazás design-ban úgy vetődik fel majd a kérés, hogy legyen elindítva egy nagyobb méretű adat átküldési folyamat. Szó nincsen arról, hogy bitekre várakozni. A kicsi teljesítményű picen globális változókban feljegyzed az adattömböt, és interruptot kérsz rá, hogy ha kiment az egy szem byte (8 biten nincs nagyobb buffer). Majd az interrupt rutin pakolja be a többit. 16 biten néhol már van 4 byte hosszú hardver buffer is, ott telepakolod egyszerre a buffert, és úgy kevesebb megszakítási rutinnal kell vessződnöd, mert 4 byteonként csak egyszer kell interrupt rutint futtatni. 32 biten 16 byte hosszú a hardver buffer. 16 és 32 biten létezik dma is teljesen lecserélni az interrupt koncepciót folyamatos byte küldésre. A dma időnként haltolja a cpu magot amíg használja a mikrovezérlő belső kommunikációját, de egy interrupt sem kisebb zavar, amikor éppen megérkezik. A dma ellen annyi szól, hogy az interruptot le tudod tiltani, ha vannak olyan időpillanatok, amikor szinkron időben minden egyes órajelre szükséged van, és az annyira fontos, hogy cserébe elfogadható, hogy pár funkció összességében több processzort egyen. A dma egy optimalizáció alkalmazás szinten nagyobb teljesítményre a real-time jelleg feláldozásának árán.

A fentiekhez képest szinkronban várni a buffer szabad bitre természetesen a lehető leghatékonytalanabb alkalmazás design. Azért használják mégis, mert nagyon egyszerű, és ha nem kell a mag semmi másra, minek bonyolítsd az életedet? Viszont azon ne állj akkor neki keseregni, hogy egy egyszerű program szerkezet már nem alkalmas konkurencia helyzetek lekezelésére - amikor is sok külön funkció mind futni akar a magon. Természetesen a hatékonyabb szerkezettel több a munka, míg felépíted. Konkrétan a sok sz**t csak egyszer kell beállítani, és utána nem. Ha állandóan kell hozzájuk nyúlkálni, akkor valamit nagyon félre terveztél. Kezdeti könnyítésként mondjuk próbálhatsz hibrid végrehajtási módszerekkel. Ami nem fontos eseményvezérléshez, azt hagyod szinkron idejű végrehajtáson, de pár dolgot átraksz interrupt vezérlésre, ami túl sok várakozással túl sok magot kajálna meg. És még a dma is bele férhet pár esetben, ha már úgyis mindegy, mi meddig fut - toldozol-foltozol picit. Teljesen aszinkronra átírni egy már meglévő programot általában nem szokott megtörténni. Túlságosan forralja az agyvizet Egy alkalmazást vagy eleve aszinkron design szerint kezdtél el, vagy sosem lesz az. Ha valami meglévő programot mégis át kell alakítanod, azt nem átalakítod, hanem a semmiből indulva újraírod mindenestül.

Induljunk ki abból, hogy csak 8 bites mcu-val foglalkozom.
Hogyan oldjam meg, hogy pl. I2C-n adatokat olvasnék, vagy írnék külső memóriára, de eközben oda kell figyelnem egy encoderről érkező jelre is, amit számlálni kell, összehasonlítani, és beavatkozni.

Igazából ez csak egy biztosíték.
Minden esetben mikor SPI2BUF kap értéket az SPITBF értéke automatikusan 1-re változik.
És mikor SPI2BUF értékét kiolvassuk nulláztuk SPITBF értékét.
A ciklusban való várakozás arra az esetre van fenntartva, ha gyorsabban futna le a kód mint sem fel tudná tölteni az SPI2BUF regisztert adattal.
Igazából, ha nem lenne ott akkor sem lenne gond, de hátha...

Amúgy teszteltem SPI kommunikációt és működik szépen 460-on is, de valamiért még sem akar működni összességében az SD kezelés. (ugyan az az SPI megy)
Fura, hogy ugyan az a kód alig különböző szinte ugyan azon PIC-en nem akar már működni.
Érthetetlen egyelőre ez a jelenség. Ötlet?
Sebesség vagy valami amire nem figyelek fel 795 után a 460-nál?
Sebesség és beállítások ugyan azok, csak az SPI változik kicsit, de azt külön most teszteltem és jó. (küldés és fogadás)

A programod második részét tenném megszakításba.. Számolás és összehasonlítás.
És most jött egy Déjà vu (dezsavű) érzésem...

Nos megtaláltam a hibát..
SD kártya lekérdezésénél van egy ilyen while ciklus.
795-nél nem volt a folyamat megszakítására szükség, de 460 esetében kellett bele tegyek egy korlátot. Most már tökéletesen működik.. Öröm van.

Általánosságban az események eredménye rögzítve van valamilyen memória tárolóban, vagy éppen jelvezetéken. Amikor interruptot használunk fel, és precízek akarunk lenni, olyankor szétválasztjuk az adatok feljegyzését a logikai feldolgozásuktól. Arra van az interrupt "alsó fél" és "felső fél". Amikor az esemény érkezik, interrupt kiszolgálót hívsz amiben nem csinálsz mást, csak lepakolod valamilyen modellezett fifo bufferbe az új eseményt. A programod főciklusa pedig fut aszinkron állapotgépekből felépítve, amik folyamat ellenőrzik azokat a fifo buffereket is, és ha találnak benne valamit, feldolgozzák. Egy kicsi teljesítményű pic-el persze lehetségesen nem tudsz akárhány eseményt akármilyen gyorsan feldolgozni, és az is lehet, hogy logikai szintre modellezve az információkat és azokat fifo bufferbe pakolni nem lesz elég memória bármilyen pic-ben. Ha elfogyna bármilyen erőforrás, használj nagyobb pic-et.

Nem teljesen erre gondoltam.
Hanem arra, hogy elindítom az adatok olvasását, de közben jön nekem egy megszakítás, és mondjuk csak 1msec múlva tér vissza a program, hogy kivegye az adatot. De közben már érkezik egy másik adat, ami felülírja. Van olyan lehetőség, hogy csak akkor jöjjön a következő adat, ha az előzőnek a vételét nyugtáztam?

Erre a van a megszakítási flag törlése.
Csak akkor jön újabb adat, ha azt törlöd és kilépsz megszakításból..

Handshaking esetén tudsz visszajelezni a túloldalnak. Anélkül nem. I2C esetén a handshake maximum alkalmazás logikai szinten implementálható, de az cudarul belassítana mindent. Az adatot el kell tudni venni időben. Elég gyorsnak kell lenned hozzá.

Ha az alkalmazás design már csilli-villi (karcsú interrupt alsó felek, aszinkron állapotgépekből van az egész főciklus, soha sehol nem akasztod meg az aszinkron folyamatokat), és már nem tudod tovább emelni az órajelet, mert maxon vagy, akkor biza kinőtted azt a pic-et, és valami gyorsabb után kellene nézni.

De tényleg csilli-villi minden és maxon vagy az órajellel? Egy i2c-nek maximális sebességen sem kellene gondot jelentenie. Mi mindent gyömöszöltél még bele abba a pic-be?

Nem jó ötlet azzal a flaggel vacakolni. Ha direkt nem törlöd a flaget, akkor ugyan nem kapsz újabb megszakítást, de a háttérben a hardver dolgozik tovább a "másik oldalon", és adatvesztésed lesz miatta.

Igen erre gondolni kell.
Ha rövidebb az idő és mondjuk nem lehet szabályozni az adat küldő egységet, akkor bizony szinkronba kell vele állni. De nem hiszem, hogy egy megfelelő PIC-el ezt ne lehetne megoldani.
Esetleg érdemes akkor egy buffert beiktatni, vagy kettőt, vagy változót.
Ameddig az egyik tölteni, addig az előzőt vizsgálni.
Pont így csinálom az USB-s és USART adat fogadást. (hardveres megszakításból)

Nem is nekem van vele problémám, hanem @sonajkniz-nek, és én is valami olyasmire gyanakszom, hogy alkalmazás szerkezeti a tényleges probléma. (Azt a bizonyos beiktatott változót meg a magam részéről az interrupt alsó fél fifo bufferjének neveztem.)

Szia!

A hardveres megoldásnak az az előnye, hogy nem foglalja a procit. Próbálok egy hasonlatot írni: ha pl. egy gyűszűvel akarsz megtölteni egy poharat, akkor az nagyon jó, ha a gyűszű jelez, hogy tele van ( ez a megszakítás kérés!). Ekkor átbillenteni a pohárba egy "pillanat", de "rögtön" reagálni kell, mert a gyűszű nagyon hamar túlcsordul. Az már a főprogram dolga, hogy a pohárból hordja el a vizet, ne tudjon megtelni ( ha nem elég gyors, akkor rosszul szervezel, nagyobb pohár vagy gyorsabb főprogram kell!), de ott már nem kell olyan gyorsan reagálni, mert van "puffered". Persze ennek az egésznek akkor van értelme, ha időegység alatt nem keletkezik több víz, mint egy gyűszűnyi , illetve az elhordás sebessége megfelelő ahhoz, hogy a pohár ne teljen meg!
Nagyon fontos, hogy a gyűszű tud jelezni, mert különben mindig rá-rá kellene nézni a gyűszűre, ami nyilván hátráltatná a többi dolog elvégzését és ez a nagy előny !
Ez így tuti működik, használjuk és hidd el, érdemes !

Periféria kezelés és a postai küldemények kezelésének analógiája:
- Programozott állapot lekérdezés: Ha levelet vársz, minden nap (órában, percben) elmégy a postára és megkérdezed megjött-e már.
- Megszakításos kezelés: A postás csenget, félbehagyod, amit csinálsz, átveszed. Itt te döntöd mi történjen. Fontos küldemény volt, átütemezed a feladataidat, nem annyira fontos, ledobod az asztalra és visszatérsz ahhoz, amit a csengetés előtt csináltál. Lényegtelen dolgot kaptál, egyből lekezeled (bedobod a kukába). Nem neked szól a küldemény - át sem veszed.
- Direkt memória elérés (DMA): Postafiókot vagy fiókokat bérelsz a legközelebbi hivatalban. Megbízod a hivatalt (felprogramozod a DMA vezérlőt), hogy bizonyos (egy forrásból érkező) küldeményeket meghatározott fiókba (memória területre) tegyenek. Kérsz értesítést, ha jött küldeményed (DMA megszakítás). Ezután figyeled az értesítéseket. Azzal a küldeménycsoporttal foglalkozol, amiről megjött az értesítés. Az értesítéseket lekérdezéssel és megszakítással is lehet figyelni.
- Autonóm periféria: Működik a vezérlő műveletei nélkül is, de a változásokat a vezérlő adja ki. A legjobb példa a video kártya. A két megjelenítése megy a CPU közbeavatkozása nélkül is, de megváltozásait a CPU adatmódosításai hozzák létre.

Ez nagyon frappáns !

Elnézést,hogy csak most reagálok. 1 msec az 1000 utasítás. Az Interrupt pedig olyan állatfaj, ami lehetőség szerint most végrehajtódik, és 20-30 utasításnál nem több. Pl. a vett byte-ot kirakja RAM-ba és állít egy pointert. A főprogram dolga a vett byteokat feldolgozni.

Ezért lassúak a PLC-k
Az encoder jelét ugyan a beérkezés pillanatában megszámolják, de csak a főprogramban dolgozzák fel.
Soha nem tudtam egyenlőségre vizsgálni a beérkezett jeleket. PIC-el, megszakításban sokkal pontosabb. Pedig csak 8 bites PIC-et használok, 16MHz-n.
Míg egy PLC 32 bites, és fut vagy 100MHz-n.
De úgy látom rosszul tettem fel a kérdésemet, mert bár sok hasznos információt kaptam, de egyik sem megoldás a problémámra.
Arról lenne tehát szó, hogy adatok érkeznek egy másik hardver eszköztől. Kapok egy jelzést, hogy adat fog jönni. Ez a jelzés kivált egy megszakítást. Beállítom a vételi csatornát és kilépek a megszakításból. De mire megérkezne az újabb megszakítás, inmár a vételi buffertól, pont előtte jön be egy megszakítás az encodertől. Elvégzem az encoderhez szükséges dolgokat, kilépek a megszakításból, de az máris újra belép, hiszen a buffer jelzése aktív. Csakhogy ez idő alatt már úton van egy másik adat, ami már részlegesen felülírta az előzőt.
A kérdésem tehát az, hogy van e arra mód, hogy a master addig ne küldjön újabb byteot, amíg a slave nem nyugtázta az előző vételét.

Pontosan milyen sebességgel, és milyen periférián érkeznek azok az adatok? I2C-t említettél korábban, de az nem szokott lenni PLC-ken. PLC-ken profibus van, vagy modbus, vagy szimpla digit i/o jelek.

A fizikai vétel az SSPSR bufferba történik, amikor kész 1 adat, akkor automatikusan áttölti az SSPBUF regiszterbe és az új adat újra az SSPSR-be jön! Ez azt jelenti, hogy annyi időd van a felülírásig, amennyi alatt bejön 1 adat, ez pl. a 400 kHz-es I2c-nél 1 bit 2,5 us, amiből a 8 bit az 20 us. A @16MHz-es PIC órajelnél 0,25 us 1 utasítás, azaz a 20 us alatt végrehajt 80 utasítást. Assemblyben v. C-ben nem kell ennyi az encoder lekezeléséhez, de amennyiben az így rendelkezésre álló idő kevés, akkor a hardver nem megfelelő, másikat kell választani ( pl. @64MHz-es PIC órajel PLL-el és akkor már 320 utasításod van!) !
Látható, hogy attól, hogy megkezdődik a következő byte vétele még nem íródik felül az előző, azt kell eldönteni, hogy elegendő-e a közbeeső idő!

Ha más jelsebességgel dolgozol, akkor ez alapján számolj!

Remélem sikerült érthetően leírnom ilyen korán !

Nem PLC-vel kellene kommunikálni, hanem egy másik PIC-el.
Még minden képlékeny, még csak tervezem, de szeretnék 8 bites PIC-nél maradni.
Egy moduláris rendszert szeretnék létrehozni, ha sikerül.

Köszönöm.
Ez is hasznos infó.

I2C-nél erre a Clock stretching-et használhatod.

Elfelejtettem külön leírni, de a működésből egyértelmű, hogy az első adat fogadásakor vagy ha egyszerre max. 2 adat jön, akkor "majdnem" 2*8 bitnyi időd van !

Szükséged van a multi-master multi-client elrendezésre, vagy elég a master-multi client?

És természetesen a sebességben is a méret a lényeg. Milyen órajelen akarod hajtani a portot?

Sziasztok
Egy szoftveres pwm et hogyan lehet megvalósitani vagy hogy szoktátok??
A szintenkénti villogtatást gyorsitjátok lassítjátok???
Segítségeteket elöre köszönöm

Egy nagyon egyszerű példa:


Ha változtatod a cmp (compare) értékét változik a kitöltési tényező. (Most nem tudom, ha növeled a cmp értékét csökken vagy nő a kitöltési tényező, szerintem csökken)

Ez persze nem feltétlen alkalmazható a valóságban mert megköti a processzort.
De egy timer-al simán megcsinálható ugyanez.

Vagy is gyorsabban kéne villogtatnom mint 1 mikrosec??

Ha egy ledet szeretnél fényerőszabályozni, oda elég maximum 150 Hz-es freki, és annak a 20x-osát ha berakod timer interruptra (3 kHz timer interrupt trigger), akkor 5%-onként tudod szabályozni a led fényerőt. 1 uSec-ig olyasmi miatt szerintem felesleges lemenni, az előző példa 333 uSec periódus időt feltételez. Nem ördöngösség 8 biten sem.