[elektro] Nuvoton
hg12345
hg12345 at freemail.hu
Tue Jan 13 18:18:35 CET 2015
Arra vigyáz, nem mindegyikben működik a bit-banding.
(A és D verziókban, de fordítja tölti....)
- A bemeneti lábra tettél kondenzátort, néhány nano csodákat tud tenni. persze ha mérendő áramkör tudja tölteni, egy soros ellenállás érdemes egy szűrőt csinálni elé.
- Az NUVUTON AD konverterek nem ismerik a külön programozható mintavételezési időt (sample hold), a mintavételezés a a működtető frekitől fűgg, írják, ha a belső hőmérőt szeretnéd mérni akkor csak max 300K mintavétel. Az igaz a külső egységekre. Amit használtam A és D típus ott a nem volt érzékeny a mérés, 10 bitet elég jól tudott.
Bali Zoltan <eltexto at freemail.hu> írta:
>Még egy APRÓSÁG. Ha ez a portbit mód váltó sor bent
>van a Main ban, P1->PMD.PMD3 = 0; (Port1 3. bit bemenet),
>ha egyszer is lefut(kivéve az port initet), elmásznak az
>AD értékek, melyek bemenetei ugyanezen a porton
>vannak nálam most AIN1, AIN2, AIN7 mér. Ami
>közel van a bit3 hoz, AIN2 5V helyett 6.1-et mér.
>Az AIN1 16.2 helyett 17.0 mér. AIN7-en 325 helyett,
>320-at.
>P1->PMD.PMD3 = 1; // kimenet
>A fentire nem érzékeny. Mehet update folyamatosan.
>Máshol nem bizgetem ezt a portot.
>Fél délutánt kísérleteztem vele (comment-uncomment).
>
>Asszem mennek a kukába a panelek.
>
>Üdv. Zoli
>
>
>2015.01.03. 16:30 keltezéssel, hg12345 írta:
>> A NOVUTON-t csak az 5V miatt és kis méret miatt használtam, az ST jobban bejött, a M3 még inkább :-)
>> Már az ST is vannak ilyen kis méretű eszközök.
>> Ár igazából amennyiért van Novuton annyiért ST is belehet szerezni.
>>
>> Bali Zoltan <eltexto at freemail.hu> írta:
>>> Hát mondtam, az USB látszólag leírás
>>> összehasonlítás és regiszterek alapján
>>> is ugyan az. De a B-n működött a
>>> double buffer, a D-n meg nem.
>>> Ez csak a rev-ben és memória mértben tér
>>> el. Na meg, amit még módosítottak rajta.
>>> Az a baj hogy semmit nem írnak le
>>> rendesen. Úgy kell kitotózni a debuggerel,
>>> hogy hogy is működik.
>>>
>>> Nekem meg, kezd Microchip érzésem
>>> lenni, gyengébb dokumentációval.
>>>
>>> De már úton vannak az M0-ás ST procik.
>>> Lehet drágábbnak tűnik, de ha nem kell
>>> ennyit kínlódni, már megérte.
>>> Na, majd meglátjuk.
>>>
>>> Üdv. Zoli
>>>
>>> 2015.01.03. 14:44 keltezéssel, hg12345 írta:
>>>> Szia,
>>>>
>>>> Az Mini51-re fejlesztettem, sok terhelés nem volt rajta, csak a procival párhuzamosan volt kötve samu S3 titkosított memória, minden 3.3V-ról járt + két led (2x1mA) és a listázó kimenet, nekem a melegedett a debugger stabja, ezért gondoltam, hogy probléma van. (ezek sokat nem fogyaszthattak, de időnkét a környezet is ráterhelt a debuggerre, sajnos erre ez időre se állíthattam le az ellenörzést...)
>>>> A rásegítés segített, utána a ezzel már nem volt probléma.
>>>>
>>>> Sok gondom volt az I2C busz árnyék feldolgozásával, a Mini51 max frekin a core M0 it kezelésse határon volt a SDA/SCL fázis detektálása.... Optimalizálás nélkül nem működött, optimalizálással meg addig nem míg a kód sorrended sikerült kitiltani az optimalizáció alól.
>>>>
>>>> Most várom a DE sorozatot, hogy kipróbáljam azon is jól fut a program, nem szeretnék úgy járni mint az MCHIP-vel amikor több száz darabot kellett kiforrasztani, verzió váltás miatt.
>>>>
>>>>
>>>>
>>>>
>>>> Bali Zoltan <eltexto at freemail.hu> í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]
More information about the Elektro
mailing list