Nem célom itt illuminati játékokat játszani, de ha nem valami eldugott helyen lévő beállítás az ok, akkor az is lehet, hogy a firmware-be direkt beépített korlátozás, amit nem tudsz majd kikapcsolni. Esetleg firmware csere valami nem gyári verzióra, de olyanok jellemzően nem léteznek, vagy ha léteznek is, azokban meg védelmi kiskapuk lehetősége miatt képtelenség megbízni.

Nem beállítás az ok, viszont a firmware nagyon is lehetséges, de....
A routerekben működő DDNS nem megy másik mögött. Itt egy téma erről.
Valamint ha létezne is valamii hakkelt firware, ami nem valószínű mert ez a telekom egyik új modemje, amit IP-TV mellé ad, akkor is necces lenne a csere, mert akkor meg lehet nem lenne net.
Mindegy is, az MC-s MAL lehet, hogy másképp működik, majd megnézem.

Nálam T-s iptv van, szokásos modemmel. A régi routerem ott van mögötte, és az ossza a megszokott módon a gépek között.. Benne az összes portforward, és a gyári DDNS.
A T-s modemben van olyan opció, PPPOE-Throught valami ilyesmi. Oda bele a pipa, és minden megy a szokott módon tovább.

Nem tudom mi nálad a szokásos modem,nálam sagemcom 3686-ot hoztak és hidd el, hogy ezzel nem megy. Nálam is a mögötte levő asus oszt mindent, meg az szolgáltatja a VPN szervert is, de a DDNS nem megy a sagemcom mögül.Rugóztam rajta eleget.
Bár ez lényegtelen, de a sagemcom 3686 VPN-je sem megy, de legalább átengedi az asushoz.

Nekem is volt szerencsém egy t-s sagecomhoz, de a típusszámára már nem emlékszem. Az a modem annyira szar volt, hogy 3 hónappal később, a hűség idő lejártával (hűség időn belül cseréltek egy régebbi, meghibásodott modemet) vissza is mondtuk a szerződést. Szerintem a te esetedben firmware történet lesz a jelenség mögött, és direkt jelleggel. Az egyik lehetőséged a hűségidő lejártával szolgáltatót váltani.

Használt már valaki kapacitív érintőgombokat a PIC saját belső ADC-jével és CTMU perifériájával? Van a Microchipnek erről egy application note-ja: Bővebben: Link
Még mintakód is van benne PIC18F-re és PIC24F-re. Megpróbáltam átírni dsPIC33E-re, de ez abszolúte semmit sem csinál:

Sziasztok!

Vettem egy PK4-et. Hogyan kell az MplabX-ben beállítani, hogy az mclr lábat ne tartsa resetben?

PIC32MZ DMA kérdésem lenne. RAM-ból próbálok kivinni 250db 16bites integert PMP-re (PMDIN).
DMA beállítások:
DCH0SSIZ: 500 (bájt)
DCH0DSIZ: 2 (PMP 2 bájtos)
DCH0CSIZ: 500 (500bájt kivitele után okoz eseményt.)

LogAnalizátorral nézem a WR-t a TFT-n, csatoltam a képét.

A probléma az, hogy a várakozással ellentétben nem 250 WR impulzus megy ki, hanem 125. Ha csökkentem a PMP órajelét 100MHz-ről 50-re, akkor még kevesebb (pl. 84). Az esemény bekövetkezik a DMA szerint, amikor szerinte kimegy az 500 bájt (250 szó), de ehhez nem történik meg a valós kivitel a PMP-re. A TFT-n is csak 125 pixel jelenik meg.
Mi okozhat ilyen hibát? Lehet, hogy a PMP lassú (100MHz), a DMA meg tolja bele órajellel (200MHz) az adatokat? Ezt azért le kellene kezelnie nem?
Nem találok szinkronizációs, vagy DMA lassító beállításokat, esetleg tudtok ilyet?
Köszönöm!

Leteszteltem, valóban minden második szót viszi ki a tömbből a PMP portra... ?

A RAM nem 4 byte/rekesz szervezésű? 500/4 =125 darab 2 byte-s szót visz át.

A DMA elvileg felismeri a változó típusát. Ha 8bites változók között, pl. flas tömb és ram tömb között történik az átvitel, nem kell megmondani, hogy 8 bites a változó. A páratlan, pl. 9 elemszámú tömböt is jól kezeli. Így arra számítanék, hogy tudnia kéne, hogy 16bites változókról van szó. A jelek azt mutatják, hogy valami más a baj, mert ha csökkentem a PMP frekijét, akkor a kimenő impulzusok száma is csökken, olyan, mint ha a DMA tolná 200MHz-el, de a PMP csak azokat tudja feldolgozni, amik akkor jönnek, amikor az előző szó kiment és készen áll. A frekik aránya miatt ez minden második, vagy egyéb arány. Lehetséges ez?

A tesztelést, ami említettem úgy végeztem, hogy minden második tömbelembe fekete pixel kódot tettem a fehérek mellé. Csak a fehérek mentek ki, amikor a fehér volt az első és csak feketék, amikor felcseréltem a sorrendet. Minden második szám kimarad.

Ezt okozhatná az is, amit említettél, de nem tudom hogyan lehetne megkerülni, ha valóban ez lenne a probléma.

Bár egyszer már kijelentetted, nem vagy kíváncsi a hozzászólásaimra )), de én megnézném milyen frekvenciával van járatva a dma?! Az is lehet, nincs beállítva valamilyen perifériák közötti szinkronizálást biztosító bit, és emiatt tolja egymásra az adatokat a dma!

Néhány újabb teszt: RAM-ban felváltva fehér és fekete kódok, 16bites egész típussal
DCH0SSIZ: 2
DCH0DSIZ: 2
DCH0CSIZ: 2
Egy kimenő WR imp. egy fehér pixel a TFT-n
DCH0SSIZ: 4
DCH0DSIZ: 2
DCH0CSIZ: 4
Egy kimenő WR imp. egy fehér pixel a TFT-n
DCH0SSIZ: 6
DCH0DSIZ: 2
DCH0CSIZ: 6
Két kimenő WR imp. két fehér pixel a TFT-n
DCH0SSIZ: 8
DCH0DSIZ: 2
DCH0CSIZ: 8
Két kimenő WR imp. két fehér pixel a TFT-n
32bites változókkal a 8:2:8 beállítás esetén
Két kimenő WR imp. egy fehér és egy fekete pixel a TFT-n
Ez valahogy nem stimmel...

Lehet, hogy rájöttem valamire. Jelenleg nincs bekapcsolva trigger funkció, de van rá lehetőség. Lehet, hogy lassabb perifériákhoz triggerelésre van szükség. Persze az jó kérdés, hogy 50-100MHz-es triggert honnan tudok ráirányítani, de körülnézek...
Nem találok csak más perifériáktól származó forrást, ez kilőve.

Lecsökkentettem az órajelet 100MHz-re és a perifériákat is mind 100-ra állítottam. Nem történt változás. Fogynak a reális magyarázatok. Kicsit kiábrándító ez a microchip...

Az ábrádból: A WR jel aktív ideje 10ns, ami a 100MHz periódusideje...
A Section 13. Parallel Master Port (PMP) DS61128G -beli 13.3.1.7WAIT STATES fejezet szerint a Wait cilkcusok száma legalább 2 TPBCLK.

Ha a Peripheral Bus Clock frekvenciája megegyezik az Fsys órajelével, akkor 2 Fsys órajelenként csak 1 adatot tud fogadni a PMP.

Rendben, erre gondoltam én is, de akkor hogyan működhet a DMA a PMP-vel? Mert az összes példán, amit láttam, semmi arra vonatkozó kódrész nincs, ami megoldaná az időzítést. Van esetleg javaslatod, hogy hogyan lehetne időzíteni a DMA-t?
Talán valamelyik Timerrel triggerelve, de akkor le kell kezelni minden szó utáni eseményt, ami olyan szinten erőforrás igényes, hogy semmi értelme a DMA-nak, mert kevesebb dolga van a PIC-nek egy sima ciklusban!
Erre mondtam nemrég, hogy még a 25MHz-es PMP is csak álomkép a gyakorlatban.


Nem egyezik meg, pont a fele, de ha lassítom rosszabb lesz.

Próbáld ki, hogy a dma órajelét sokkal kisebbre veszed a periféria órajelhez képest. _Sokkal_ kisebbre.

Én emlékeim szerint mikor a PMP-vel DMA-ztam (csak már nem tudom hol a kód).

Na egy kicsi előzetes, ha DMA RAM To RAM megy a cell size akkor mint a byte-os tömb méret és "egybe" átpakolja a tömböt viszont ha perifériára írsz akkor a cell size a az írandó regiszter mérete (jelen esetben 2 byte).
Na és úgy olvastam a Trigger szóba jött a DMA mindig kiír egy word-ot a force start után és várja a Triggert ami indítja a következő transfert Triggert beállítod a PMP flag-jére (IFSx) így a DMA meg fogja várni amíg a PMP kipakolja az adatot.

Ez azért is kell mert ha a kijelző nem bírja a PMP sebességét ugye lehet konfigolni hogy hogyan nyújtja az adat tartást stb...
Így a DMA nem írhat folyamatosan a perifériára mert össze vissza fog menni.

Vagy erre az előző hozzáoszlások PMP gyorsan megy DMA meg le van húzva kis sebességre (ha lehet állítani a DMA sebességét) az is ugyanez csak szerintem sufnisabb.

De MCP DMA doskiban látod hogy UART TX-re hogy kell beállítani a DMA-t:


(az UART nál is gáz lenne ha 9600 mellet folyamatosan öntenéd a registerre az adatot...)

Köszönöm, kipróbálom!

Neked is köszönöm, de a DMA-t nem lehet lassítani, az rendszer órajellel megy fixen. Ezért gondoltam, hogy a renszer órajelet csökkentem azonos szintre, de nem jött be.

Sikerült, köszönöm a segítséget! Van néhány fura dolog, de végül is működik. A leggyorsabb, amit el tudtam érni működést, 130nsec periódus, ami 7,692MHz. Nem túl acélos. Ehhez két órajel várakozást kellett beállítanom. Ettől kevesebb esetén ki se jut az adat a PMP-re, illetve a WR nem lesz aktív. Még tesztelem, de nem túl sok remény van a gyorsításra.

Milyen PIC-ről van szó a PBDIV hogy van beállítva? Kicsit keveslem, de ha jól láttam kijelzőhöz kell én az ILI9341-hez használtam amit emlékeim szerint ilyen 12-13MHz körül lehet hajtani és máshol sem nagyon mennek feljebb (kis felbontáson, nagy felbontáson meg kevés a PIC szerintem) tehát ha tudod húzni feljebb akkor sem tudsz olyan sokat nagyot lépni.

Van néhány ILI9341-es vezérlővel ellátott TFT-m. Több napi szívás után és számtalan inicializáló kód kipróbálása után sem sikerült elindítani rendesen, csak az ID lekérdezés megy. Tudnál küldeni egy általad használt inicializáló kódot? Hátha azzal valami csoda folytán hajlandó lenne elindulni mégis... Bár nagy reményeket már nem fűzök ehhez, de jó lenne ha mégis sikerülne...

Egy nagyon össze vissza piszkált kódom van ami MCP-ből Arudinóból meg amit találtam mikor elkezdtem TFT-zni abból lett összeszedve.
Nem egy effektív lib de a célhoz amihez kellet jó volt.
Nem igazán alkalmas multitask-ra se, de az init kódot látod, asszem olvasás nincs benne implementálva.

Ma már biztos nem így írnám és előre bocsi hogy kicsit katyvasz.
Valamint remélem nem okoz túl nagy problémát az inithez hogy C++-os

Nem számít! Amennyit eddig ezzel küzdöttem, attól minden csak jobb lehet!
Egyébként is csak az inicializáló kód érdekes nekem belőle!
Köszönöm, holnap áttanulmányozom és ki is próbálom...hátha?!

SYSCLK=200MHz, ezzel megy a DMA-is fixen. A PMP a PBCLK2-ről megy, osztás 2:1, azaz 100MHz-ről megy. Nem a TFT nem érzékeli a jelet, a jel ki sem megy a PMP-re, ha nem adok várakozást a WAITB=1, WAITM=1, WAITB=0 módon. Minden érték 1 periódus várakozást okoz, azaz 10ns-et. De ha a B-t 0ra veszem, nem megy ki impulzus a WR-re, akkor sem ha az M-et nagyobbra állítom. Ez a legkisebb időzítés, amivel a PIC működik nálam. A TFT bírná.
A másik ami inkább lassít, hogy be kellett állítanom a Cella megszakítást, mert anélkül a DMA nem volt hajlandó fogadni a PMP írás kész jelét. Ezt se értem miért van, még keresek megoldásokat, mert minden kivitelnél befut a megszakításba, ami értelmetlen erőforrás pazarlás, viszont nélküle nem indul el a folyamat a DMA-n.

A megszakítás nem feltétlen "csak" energiapazarlás, ha végig gondolod, hogy azzal a sebességgel a nyák vonalakat a parazita jelenségek miatt milyen árammal kellene meghajtani, hogy a jel biztonságosan átérjen. A pmp-vel sosem kötöttem közelebbi barátságot, de ha nem teljesen elmicsodált design, kell ott lennie egy visszajelző interrupt vonalnak, és arra ráállítva a dma-t lehetne visszalassítani valós elektronikai sebességhez (vagy periféria saját késleltető számlálójával). Az, hogy beállítod egy mcu belső órajeléhez, elméletileg biztos szép, csak éppen nem túl gyakorlatias hozzáállás. Szerénytelen véleményem szerint

Biztos hogy nem kell hozza cell transfer int nalam mukodott nelkule...
DCHxECON be van allitva DMA a force startal inditod ?

WAITB=1, WAITM=1, WAITE=1 beállítás után működik CHCCIE nélkül is. A megszakítás valószínűleg lefoglalta a PIC-et, így kijött az időzítés. Más magyarázat nincs rá, de furának fura.
Most azon vagyok, hogy korrekt megoldást találjak a 32000-es szó csomagok kivitelére, amiket a DMA_TRANSFER_EVENT_COMPLETE megszakításokban 24 egymást követő alkalommal kell kitolni (800*480). A jelenség az, hogy ha nem teszek várakozást (5usec) a megszakításba a DMA újra indítása elé, akkor eltolva kezdi kiküldeni a memória tartalmát. Ennek oka valószínűleg az, hogy a megszakítás olyan gyors, hogy még az utolsó kivitt PMP átvitel nem fejeződött be. Most, hogy ezt írom, rájöttem, hogy figyelni lehetne a PMP IRQ flag-et, de ez is várakozásnak felelne meg, méghozzá megszakításban, ami nem illik. Majd valamit kitalálok (pl. engedélyezem a PMP megszakítás és onnan indítom a DMA-t újra). Köszi az eddigieket mindenkinek!