[elektro] Nuvoton

[Bali Zoltan]

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
>>>>>>
>>>>