[elektro] Nuvoton

[Bali Zoltan]

Köszi Gábor, megoldódott. Miután írtam,
eszembe jutott, talán HW. És igen, a kérdéses
port, amit bemenet módba kapcsoltam át, 5V-ra volt
húzva. A cucc meg 2.5V-os. Eredetileg a 2.5V-ra
volt kötve az az ág, amin a felhúzó volt, de más ok miatt
5V-ra tettem és elfelejtkeztem róla hogy más is megy
innen. Úgyhogy, mea culpa.

Üdv.  Zoli

2015.01.13. 18:18 keltezéssel, hg12345 írta:
> 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
>>>>>>>>
>>