Sziasztok!
Az nem gond ha minden ciklusban (másodpercenként kb 20-szor) olvasok az eepromból?

Szerintem ha csak olvasol az nem hinném, hogy gond. Ha annyiszor írnál gyorsan elfogyna Mikrochip által beígért 100 000 megbízható írási ciklus.

Igen azt tudom, hogy az írási ciklus viszonylag rövid, éppen ezért kérdeztem rá az olvasásra is, biztos ami tuti alapon.

Azért várj meg más válaszát is. Ennyit nem olvastattam még én sem.

Az olvasás nem bántja az eeprom tárolócelláit, hiszen csak annak az eredményét kapod meg a kimeneten, hogy az adott cella vezet-e vagy sem. Az olvasás nem nyúl a cellához.
Az írás viszont igen, így az élettartamát csökkenti.
De az írás a szomszédos tárolócellák állapotát is "rongálja", azaz a tárolt bitek megőrzését rövidíti (a töltésbeinjektáláskor a szomszédos cellákra is hatással lehet az impulzus, a kialakuló térerőugrás, ezért nem kívánt elektrondiffúzió indul meg, veszélyeztetve a nem írt cellák tartalmát is). Ezért kell (az adatlapok ajánlják), hogy ha az eeprom csak egyes részeit írogatják is, időnként az egészet frissíteni célszerű.

Helo! "1 voltnál nullát írjon ki, és 3,5 voltnál 100-at" Csak hogy Te a táblázatosban fordítva kérted.. Lerajzoltam a kapcsolást, de mivel ennek a PIC-hez köze nincs nem ebbe a topikba tettem, hanem ide..

Nagyon köszönöm a segítséget, hálás vagyok!

Uart kommonikációt készülök megvalósítani PIC-el ...
A kérdésem milyen stratégiát érdemes követni?
Változó hosszúságú csomagok érkeznek.
Hogyan fogadjam az adatokat? Uart megszakításból, vagy a főprogramból figyeljem van-e beérkezett bit? Egyből "értékeljem" ki a beérkezett bit-et, vagy tároljam le a beérkezett adatokat egy tömbbe?
Hogyan tudom megakadályozni, hogy az egymás után érkező adatcsomagok egymásra érjenek?
Ha pl. megszakításból fogadom az adatokat és tömbbe tárolom, hogyan tudom megakadályozni hogy felülírja egy újabb beérkező adatcsomag a régit, miközben esetleg még folyik az adatok feldolgozása?
Ha letiltom a megszakítást és közben adat érkezik azzal mi lesz?
(Mindezt C nyelven írnám, nem a konkrét megoldást várom, csak egy iránymutatást ... )

Tipikus best practice robosztus alkalmazásokhoz:

Megszakításban fogadod az adatokat. Építesz külön "bottom half"-ot, ami megszakításban átveszi az adatot, és lerakja egy pici memória bufferbe. Az a memória buffer azért nem csordul túl, mert pici mérete ellenére is elég nagy ahhoz, hogy az alkalmazás logikai szintjén a főciklusban aszinkron futó külön "upper half" folyamatosan át tudja venni belőle az adatokat hamarabb, mint hogy túlcsordulhatna. Az alkalmazás szintű buffer pedig sokkal nagyobb, és jut benne hely mindenre.

Aztán hogy mennyire kell robosztusat építeni, azt nem jelezted. A fenti összetevők és kidolgozottság roncsolható az igényekhez mérten, és úgy elfér kevesebb erőforrásban is. De azt már a te dolgod felmérni annak alapján, hogy milyen feladatot gondoltál megvalósítani.

-Az adatcsomagok nem érnek egymásba, ha elég nagy memória buffereket képezel ki az adatátviteli és feldolgozási sebességhez mérten.

-Ha letiltod a megszakítást, és közben adat érkezik egy megtelt bufferbe, akkor az új adat elveszik, némelyik típuson hibaflag is felkapcsol, sőt az uart működése is leáll, amíg az overflow-t nem törlöd, de annak részleteit lásd az adatlapban. Ne tiltsd le a megszakítást. A megszakítási rutinok nagyon picikék legyenek, és korlátozódjanak csak adatbeolvasásra, amit memóriabufferelsz, de azon túl megszakítási rutinból nem csinálsz vele semmit.

Harmony kérdés:

Leírom a frankót, még mindig bottal sem piszkáltam, szóval nem tudom, mennyire gáz. Olvasgattam olimex fórumot a pic32mz dev boardok lassú fejlődése kapcsán, hogy vajon mi az oka a kicsike kínálati skálának, meg felkerestem az ubw32 tervezőjét megkérdezni tőle, tervezett-e mz-hez is boardokat, amik a jövőben várhatóak termék kínálatban, és összesítve annyi a visszajelzés, hogy a harmony annyira hasznavehetetlen, és valami chipKIT is annyira bughalmaz a 32mz-ken, hogy mindenki normális sdk-ra vár, és addig senki semmit.

Szóval a kérdés. Épített már bárki működő usb kliens cuccot 32mz-vel harmony libekkel?

Ezeket a puffereket hogyan valositsam meg? Létrehozok egy x elemű tömböt es abba irom a vett adatot az utolso üres helyre, az első helyről meg kiolvasom az adatot , törlöm, a többit meg egyel előbbre léptetem?

Érdemesebb nem tologatni az adatokat, hanem egy mutató értékét kell változtatni, ha elérte a végét, akkor mutasson újra az első elemre. Legegyszerűbb a 8,16,32,64... elemű tömb, ilyenkor egyszerűen levághatók a magasabb helyiértékű bitek. A tömb lehetőleg 0-tól induljon.
Két mutatót kell alkalmazni, az egyik írásra, a másik olvasásra szolgáljon. Ha egyformák, akkor üres a puffer. Ezt nevezik FiFo-nak (First in, first out).

Sajnos így van. Amikor a PIC32-ezést kezdtem egy idő után belekóstoltam a Harmony-ba, míg rá nem jöttem, hogy sajnos semmire nem jó.
Én mindent megírok magamnak, elmondhatom, hogy én írtam, a saját szellemi termékem és végül de nem utolsó sorban nagyon sokat tanulok belőle.

Kössz hát NCO tényleg nincs

Korábban kérdeztem már, hogy hogyan lehet átadni a vezérlést, hogy a RAM területen fusson
a PIC18F46K22 és onnan majd vissza ? akár ha FSR0-2 ben adnám a RAM címet vagyis tetszőleges.
Ekkor írt valaki a POSTINC ről is de már keresésre nem ezt adja ki.

Apropo, ha a PCH és L értéke a program futás közben MOV al módosítja, akkor tényleg odaugrik
és ha igen akkor a PCH ra már azonnal vagyis akkor nem lehet a 2 értéket így beírni, mert közben már az egyik módosítására elugrik és a másik értéket nem lehet megadni.
Hogy is van ez? Persze ezt így nem használnám, mert nem fix ugrás kell a RAM ba.
Kössz

A válasz egyszerű: Sehogy.

A PCL írására az alábbi történik:
A PCU átmeneti tárolója beíródik a PC 20..16 bitjeire, a PCH átmeneti tárolója beíródik a PC 15..8 bitjeire, A beírt érték a PC 7..0 bitjeire (a 0. bitnek 0 -nak kell lennie).
Mivel a PC megváltozik, a végrehajtás az új címen folytatódik (prefetch törlése miatt egy nop végrehajtódik).
A movf PCL,w utasítás hatására a PC 20..16 bitjei a PCU átmeneti tárolójába, a PC15..8 a PCH átmeneti tárolójába, a PC 7..0 bitjei pedig a WREG be íródik be.

Miért kell két külön buffer?
Miért nem lehet csak a megszakításban egy nagy?

Ezt nem igazán értem. Kifejtenéd hogy mit is vághatok le és miért?

Egy 55 elemű tömb esetén a mutatók módosítása:

Egy 64 elemű tömb esetén a mutatók módosítása: // más 2 hatváhyra hasonlóan működik

Üdv!

PIC32 input change notification. Beállítottam mindent. Pull-up, felfutó él stb. A gonom az, hogy bekapcsoláskor kapásból csinál egy megszakítást, akkor is ha a flag nullázása és megszakítás engedélyezése a legutolsó beállítási művelet. Ki tudom valahogy kerülni? Persze azon kívül, hogy a kódban figyelmen kívül hagyom a legelsőt.

Tipp: memóriából futtatni a pic-ek közül a 32-es családok tudnak. Ha kell az a feature, válassz azokból valamit. A legegyszerűbbekből (32mx1/2) van pdip tokos is.

Mert amíg az alsó bufferben kotorászol, a megszakítást le kell tiltani, amit nem tehetsz meg hosszú időre. A felső oldal meg nem lehet időkritikus. Bármilyen hosszan tudnod kell a bufferben kotorászni. Az csak úgy jön össze, ha kettő külön buffered van. A megszakítási rutinból írod az alsót, amiből másolásnyi időre a megszakítást letilthatod, de csak annyi időre. Ha megszakításokat is kezelsz, az mindig kényes kérdés. Azokat nem szabad hosszú időre kizárni.

Az pedig szimplán nem hatékony, hogy az alsó buffered túl nagy legyen.

Szerk:

Fifo buffer példa kód Bővebben: Link - ugye jól megy az angol?

Sziasztok!
Az elmúlt napokban átolvasva, átgondolva a dolgokat született ez a vázlat. Ránéznétek, hogy a PIC bekötése illetve az elképzelés működőképes-e így?
Próbapanelen működött egy kis lábszámú ICvel.
A kapcsolás egy terepasztalon állítja a vágányúthoz a váltókat, a 12V AC motorok diódával váltanak irányt a megtáplálástól függően.
A program ha pl. K1 ÉS K2 low akkor "végigkattogtatja" a kimeneteket megfelelő sorrendben és időzítéssel, a nagy áramfelvételt elkerülendően egyesével.
Sima portműveletek és időzítés, nekem csak ennyi megy.
((Esetleg valami ötlet ami egyszerűbbé teheti a megvalósítást? Csak hogy milyen irányba lehetne tovább tanulni. ))
Köszönöm előre is!

Csak egy megjegyzés a kacsoláshoz. A gombnál az a 470 ohm egy kicsit karcsú.
Igaz egy gombnál még elmegy, de ha több is van akkor már elég szép áramfelvételt okoz.
Felhúzónak 10k a megszokott, de minimum 4.7k. Kódra nem tudok mit mondani látatlanba. Minek ekkora PIC, hány váltóról van szó?

Első ránézésre is halálos a PIC -re. A 18FxxJxx széria 3.3 V -os.

Ez lett volna a másik megjegyzés, csak ezt lekéstem.

OUT: 26 (13 váltó, váltónként 2 irány)
IN: 12 nyomógomb.
A másik állomáson kicsivel több, de az másik IC, (85j10).
Egyszerre max. 2 gomb van lenyomva.

Megint csak én voltam a figgyelmetlen. Lefutó élen volt.

Köszönöm az eddigi segítségeket!
Az angolom pont olyan jó, mint a translate.google.com ... ja ... nem ... annál is rosszabb!

Milyen hibát okozhat, ha nem tiltom le a megszakítást, amíg az alsó pufferben kotorászok?

Így nagyjából olvastam amit írtál. Azt nem láttam, hogy C vagy assembly, ha C amit az interruptban használsz buffer az volatile legyen.

Ha nem használod másra az interruptot maximum annyi fog történni, hogy az újabb beérkező adatok kiolvasás alatt elvesznek és túlcsordul (ha 8 bit) az RCREG, ha 2 byte-nál több érkezik.

De a dinamikus adattömbök mozgatására van nagyon sokféle lehetőség.
Amit én használtam utoljára, az első két bájt a tömb mérete.
Másik lehetőség, ha a 0-a nem használt karakter akkor azzal tudod mérni a beérkező adat méretét.
Arra, hogy mikor olvasható másolható a buffer erre is többféle elgondolás lehetséges.
Van a pajti2 szerinti, ehhez hasonló van egy pl 5ms timer, ha nem érkezik adat és 5 ms lejárt akkor úgymond tudod, hogy nem jön több adat egy darabig, feldolgozhatod.
De szerintem a legjobb módszer ha van mondjuk a küldött adat elején egy pl.: 8 byte-os struktúra ami tárolja a tömb méretét esetleges egyéb fontos info és egy ilyen küldhetem, fogadom byte/bit szerű.
Amihez egy "master" kell aki elküldi ezt a bitet, hogy küldnék utána várja a slave/slave-ek válaszát, ha nem jön válassz újra és így tovább amíg nem érkezik olyan válassz, hogy jöhet az új packet.
Ez kicsit hasonló lehet az RS232 RTS CTS-hez, de én inkább az USB-nek a felépítéséből vettem ezt az ötletet.

Ennek nem örülök
gondoltam soros úton RAMba nyomatok végrahajtandó feladatokat PCvel
a végrehajtása után térjen vissza az események figyeléséhez, de ezzel
szertefoszlott a terv hogy a PIC en csak egy kis program legyen és a lényeget
a PC prog csinálja.
Szóval akkor mindenre felkészített progit kell rá írnom, hogy tudjam használni
95% ig a nyákon kész minden. huhhh
Hát most nem hiszem, hogy átállnék PIC32 re a RAM futtatási lehetőség miatt.
Kössz