[elektro] Nuvoton

[hg12345]

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]
>> -----------------------------------------
>>            elektro[-flame|-etc]
>
>-----------------------------------------
>          elektro[-flame|-etc]