[elektro] PIC Soros port induláskor szemetel

Thu May 9 21:45:16 CEST 2019

Hi,

elnézést, hogy bele írogatok, de érdemes még 8, 16 bites eszközökre fejleszteni,  amikor árban hasonlót kapsz 32 biten, és garantálják pl. 10 év gyártást is hozzá.
Ha portolni kell egy másikra az se olyan nagy feladat. A fejlesztő eszközök  se igazán drágák, mert ugyan úgy ingyenesek az IDE-k, a gyári belépő debuggerek meg alátét áron kaphatóak, és alap helyzetben úgy is azt tudják ami a uC-be van beépítve....

Sebességben biztos gyorsabb, a kiépítettség manapság egy új 32 bites eszköz esetén mindig több mint kell... $1 már nagyon komoly IC-t kapsz, ~$4 meg már csodát.... Fogyasztásba se többek, most adtunk ki egy fejlesztést ami 7 évet fog menni egy CR2032-ről, nem hiszem hogy ennél sokkal kisebb fogyasztása lenne egy LF-s PIC-nek.

Nem rég lehet kapni $2 demo kittet (mást már nem ezen az áron van) ami valódi USB2 csatlakozású  debuggert (korlátlan HW törésponttal) és gyári égetőt tartalmazott. 

Azt hogy DIP tokozásban is létezik eszköz, viszonylag könnyen pótolható egy cél nyákkal, de gyártáshoz az SMD-nél nincs jobb...

Persze ha már maga a 8-16bit uC fejlesztés a kihívás akkor elnézést belekotyogásért.

Nekem 2010-ben lett tele hócipő a MCHIP féle kompatibilitással, amikor két azonos típusú eszköz nem volt kompatibilis egymással, majd ezt követően egy 80 lábú tok amiből nem adtak ki újabb típust, és kifogytam a memóriából.
Arról nem is beszélve maga a C nyelv mennyivel jobban illeszkedik egy szimmetrikus felépítésű 32 bites uC-hez ami HW szinten ismeri relatív és index címzést! (egy lokális változóhoz nem kell 5 (24 bites) alap művelet, hogy kiszámítsa a címét...    lehet hogy gyors a uC, de a futási eredmény nem ezt igazolja. 

A váltást nem bántam meg, csak azt, hogy nem előbb!

-------- Eredeti levél --------
Feladó: Pipi < lista at puzsar.hu (Link -> mailto:lista at puzsar.hu) >
Dátum: 2019 május 9 18:59:04
Tárgy: Re: [elektro] PIC Soros port induláskor szemetel
Címzett: elektro at centralnet.hu (Link -> mailto:elektro at centralnet.hu)
én a microchipet szoktam szidni, vannak projektjeim amiket rendszeresen át kell dolgozzak újabb picre
indult 16c76 (epromos ha jól emlékszem)-f76-f876-f1789 most f18876
A 18876nak van kb 32 bankja kismillio regisztere/perifériája amik véletlenül sem kompatibilisek semmivel
akár olyan szinten hogy a bitek ami az egyikben egy regiszterben vannak, az a másik picben másik bank,és 2 külön regiszterben
tudom stm-et kell használni, de hát ez van, a hw-t nem én csinálom, csak nyelem az sw-t...
vagy volt c505-f84a-f636-f18323/324 erre meg nincs low count debugger modul, az összes láb meg használt...
---
apropó pic24FVxxKA sorozatban futottam bele hogy a soros buffer kezelés szar, benne is lett kb a harmadik erratában
Out-of-order transmit data when buffer is filled. UART Transmit UTXBF flag may not indicate correctly
2019.05.09. 18:28 keltezéssel, elight írta:
> Ez lesz a következő (melós) lépés
> ha rövid úton nem tudok megszabadulni
> a szemeteléstől...
>
> Még van egy két tippen, azokat végignézegetem.
> Meg bepillantok az ASM be is..
>
> Egyébként igazad lehet,
> mert most is egy hibrid megoldással küzdöttem
> le a kezdeti UART nehézségeket.
>
> Úgy indult az egész,
> hogy a MikroC fordító a K42 beállításakor
> hibás ugrás címeket is befordított a HEX-be.
> Egy napocska nyomozással kiderült, hogy
> erre a chipre maga a fordítási eljárás a hibás.
> Fórumokon nézegetem, szerepelt is néhol
> a hibára utalás. Nézem a linkeket, ez alapján
> kiderült, a MikroC-hez kiadtak gyorsan
> egy Beta fordító változatot Januárban.
> És azóta is az van. Saját felelősségre
> használható felirattal. Teszteltem, és eddig ezzel
> a BETA-val azért már minden más programfunkcióm
> hibátlanul működik.
> Egyedül a PPS ( Perifheral Pin Select ) függvények
> nem fogadnak el minden hozzcsatolt paraméter.
> Be pöccentem és helyette írtam is már sajátot.
> Úgy egészen jó lett.
>
> Szóval ha rövid úton nem derül ki a megzakkanás oka,
> akkor egyértelműen az lesz amit mondtál.
> Elsőre az tartott ettől vissza, hogy kicsit
> jobban megbonyolították ebben a chipben
> az UART rendszert. Van pár extra tudás,
> még pl. DMX-et is tud hardverből.
> Lekezelni és letesztelni már szerintem nem öt perc.
>
> Szóval teszek még egy próbát először a hibakeresésre.
> Nem marad e ki valahol egy bitbuzerálás.
> Azután meglátjuk.
>
> Üdv István
>
>
>
>
>
> 2019-05-09 17:23 keltezéssel, Pipi írta:
>> Hali!
>> próbáld ki hogy ilyen csoda könyvtári függvények helyett saját kezedbe veszed az inicializálást/küldést
>> regiszterszinten...
>>
>> 2019.05.09. 16:56 keltezéssel, elight írta:
>>> Sziasztok.
>>>
>>> Most először próbálom a 18F45K42
>>> UART1-ét életre bírni..
>>> Ez a PPS kialakítású lábkiosztás kicsit megtréfált,
>>> de már úgy néz ki azt egészen uralom.
>>>
>>> TX jelem C7 láb és jelenleg csak adni szükséges..
>>>
>>> Tettem felhúzó ellenállás kívülről a C7-re
>>> Inicializálom a C portot,
>>> LAT_C7 = 1 ( Hi szint a sorosnak)
>>> Beállítom a C7 adairányt Outputra
>>> A jelem kifele Hi szintű.
>>> PPS beállításával átadom a C7 vezérlését a TX reg-nek.
>>>
>>> Inicializálom a soros portot a
>>> UART1_Remappable_Init(9600);
>>> // 9600 Baud, alap átvitel vezérlés
>>>
>>> Kiadok egy stringet, mondjuk "Hello world!"
>>> Uart1_Remappable_Write( 'x' ); parancsok használatával.
>>> + (CR) + (LF).
>>>
>>> Az a tapasztalatom ahogy a Terminal
>>> programot olvasgatom:
>>> A RESET gombot nyomogatva
>>> az esetek felében jól jeleni meg a string
>>> a másik felében valamiféle pár karakter hosszú
>>> szemét kerül a felirat helyett képernyőre.
>>>
>>> Nézegetem, de tanácstalan vagyok.
>>> Esetleg találkoztatok már hasonló jelenséggel?
>>>
>>> Szkóppal is nézegettem és még
>>> nem találtam zavaró tüskét a jeleben.
>>> Este majd előásom az analizátort is..
>>> Egyébként olyan mintha a baudrate
>>> némelyik induláskor elugrana,
>>> vagy a többszintű bufferből némi
>>> egyéb bit valahogy kicsoroghatna.
>>>
>>> 18F45K22 -vel tucat hasonló átvitelt elkövettem,
>>> ott még nem találkoztam hasonló hibával.
>>>
>>> Üdv István.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----------------------------------------
>>> elektro[-flame|-etc]
>>>
>>>
>>
>>
>
> -----------------------------------------
> elektro[-flame|-etc]
>
>
--
Pipi
http://www.puzsar.hu
-----------------------------------------
elektro[-flame|-etc]