[elektro] Nuvoton

[Bali Zoltan]

Aztán, még egy furcsaság. A TIMER capture
funkciónál  van a capture mód, a kiválasztott
élváltásnál(vagy mindkettőnél) bekerül a számláló
értéke a capture regiszterbe. Igen ám de resetelni
csak software-el lehet, vagyis a következő mérésnek
nem az előző élváltás a referenciája, hanem a szoftware
miatt késett reset. Vagy megvárni amíg a
számláló eléri a periódus regiszter értékét.
De ez meg minek, hisz két(több) capture esemény közti
időt akarom pontosan tudni. Először örültem
mikor felfedeztem a másik módot:
"
Event Reset Counter Mode 6.13.5.5
It also provides reset counter function to reset
TDR value while edge transition detected on
TxEX pin (x= 0~3). In this mode, most the
settings are the same as event capture function
except RSTCAPSEL (TEXCON[4]) bit should
be as 1 for select TxEX transition is using as
the event reset counter.
"
Persze csak azt csinálja amit leír, nem azt amit az
én logikám diktált. Nevezetesen, hogy a triggerre a
resetet azután csinálja meg, miután beírta a számláló
értékét a capture regiszterbe. De nem!
El nem tudom képzelni, hogy a fenti idézett mód
mire használható.

Üdv.  Zoli


2015.01.03. 11:07 keltezéssel, Bali Zoltan írta:
> Szia Gábor!
>
> Hát, elég nagy a káosz a revizíókban.
> Használtam A, B és most D rev.-et.
> Ismerem a különbségeket, nagyjából.
> Még az elején töltögettem adatlapokat,
> amit most már nem találni meg a honlapon
>    A, B rev.-ről. Mindig az aktuális adatlapot
> nézem. Remélem :) .
>
>
>   >A nálam a tápfeszültség csökkenés okozott debug problémát. Főleg
> akkor, ha a debuggerből kapta a tápot.
>
> Ezt kifejtenéd bővebben? A panel, jó ha fogyaszt 30mA-et.
> Minek izmosabb táp?  A dinamikus rángatásra
> meg elég megfejelni a 100nF kondért 1-22uF-al.
> Nem?
>
> Én most rá applikáltam a debugger panelre
> az USB -ről  schottky helyére egy
> MC78PC25NTRG 2.5V LP stabot,
> a csatira menő diófát meg kikötöttem.
> A cucc 2.5V-ról jár, így nem bolondítja
> meg az AD-t, ugyanis az a tápról referál.
> De 5V-os cuccnál is vacakolt a debugger.
>
> Köszi
>
> Üdv.  Zoli
>
> 2015.01.02. 19:36 keltezéssel, hg12345 írta:
>> Hi
>>
>> Nézted melyik altípust/verziót  használod, sajnos vannak közöttük eltérések, és nem igen találsz infót róla. A honlapon nekem nem sikerült.
>> AN,(BN,CN elvileg nem került forgalmazásra), de amit most forgalmaznak a DN.
>> A (B,C) tudta pl. bitbandinget, de az (A,D) nem. Szóval van különbség ezek nem okozhatják a problémát?
>> Minél újabb annál több kiegészítő funkció van benn, vissza felé biztos nem kompatibilis!
>> Sok helyen van apró különbség, bővítés, TMR, USART....stb.
>>
>> A nálam a tápfeszültség csökkenés okozott debug problémát. Főleg akkor, ha a debuggerből kapta a tápot.
>> Egy izmosabb 1117-3.3V SOT89 tokot építettem rá, innen adok tápot egy schottky diódán keresztül, azóta nem volt problémám a debuggal.
>>
>>
>> Bali Zoltan <eltexto at freemail.hu> írta:
>>> Hali!
>>>
>>> Eddig el voltam vele. De most már nagyon
>>> unom. Egy saját USB kezelést írtam rá pár
>>> éve (NUC120LC1BN) siker0lt probléma mentesre
>>> csinálni. Ha gond volt, mindig és hibáztam.
>>> Ezt most átraktam NUC120LE3DN-re. Ami működött
>>> az előzőnél a max. sebesség kipréselése miatt,
>>> a double, buffer (váltogattam a buffer szegmens
>>> címet a regiszterben) ennél nem működik.
>>> Tudomást sem vesz róla hogy átírtam és az előzőt
>>> küldi el. Nem gond, most nem kell speed, vissza
>>> írtam egy pufferre.
>>>
>>> Közben nyüstölöm az M051-et. A TIMER-el vacakolok.
>>> Lehet én vagyok béna 3 napja, de nagyon gáz érzésem
>>> van. Az egy dolog hogy elejétől szarul működik a debug,
>>> gondoltam majd javítják, de nem. Még mindig keveri a
>>> töréspontokat hol működik ha leteszek egyet, hol nem.
>>> Ha bent hagyom a töréspontot és újraindítom a debugot,
>>> akkor működik. Néha elveszti a fonalat. Szóval bizonytalan.
>>> Így nem lehet debuggolni, hogy nem tudom most azért nem áll
>>> le a töréspontnál, mert ez a valóság, vagy mert épp úgy gondolja.
>>> Most jutott eszembe, van másik is, majd azzal is megpróbálom.
>>> Hátha HW gond van(A FW új drivernél már jó néhányszor
>>> frissítette).
>>> Vissza a TIMER-re, ahol valaki debounce lehetőséget lát,
>>> és anomáliák vannak, kapcsolja ki. Ha nem, nálam a
>>> Capture módban, a TEX bemenet magas esetén, ha resteltem CEN = 1
>>> estén a CRST-vel a TIMERT, generált egy TEXIF-et. Debounce
>>> kikapcsolásra megszűnt. Most vettem észre. hogy inicializálásnál
>>> a TIMER0 mexakítás engedélyezésekor lefut egy TIMER0 IT
>>> (betettem egy töréspontott és oda lép mindjárt az engedélyezés
>>> uton. AZ IT lefut üresen mivel shared és az IF bitek szelektálnak.
>>> DE nincs egy IF bit bebillenve. 3 napja szórakozom vele.
>>> De még mindig lehet én vagyok a béna.
>>>
>>> ez a kritikus pont configurálás után:
>>>
>>>     /* Step 5. Enable Timer0 module */
>>>     TIMER0->TCSR.CEN  = 0;          // már ezt sem engedem
>>>     TIMER0->TCSR.CRST = 0;          // már ezt sem resetelem
>>>     TIMER0->TCSR.WAKE_EN = 0;       // már ezt sem engedem
>>>
>>>     NVIC_EnableIRQ(TMR0_IRQn);      // Enable Timer0 Interrupt
>>>     /* A követkeő sorra lépve már lefut az TIMER0 IT /*
>>>     /* pedig még nincs semmi engedélyezve /*
>>>     TIMER0->TISR.TIF = 1;           // Write 1 to clear for safety
>>>     TIMER0->TCSR.IE  = 1
>>>
>>>     TIMER0->TEXISR.TEXIF    = 1;
>>>     TIMER0->TEXCON.TEXIEN   = 1;
>>>
>>> Hozzáteszem ez az init IDLE előtt van nem indulásnál,
>>> tehát előtte jó néhány clock kikapcsolásra kerül,
>>> portok beállítása, periféria reset, stb.
>>> A fentit többféle sorrendben, variációban kipróbáltam,
>>> semmi.
>>>
>>>
>>> Bocsi, hosszú lett és érthetetlen :).
>>>
>>> Üdv.  Zoli
>>>
> -----------------------------------------
>            elektro[-flame|-etc]