A slave nem tud startot küldeni, csak a master. Ha ilyenkor megfordítod a master-slave beállítást, miért kell az eredeti beállítás. Szerintem amúgy is logikusabb lenne ha a pic12 lenne a master, és egyszerűen adatot küldene a másiknak.

Start előtt átmenetileg masterra állítottam, de így sem megy. Még nem volt időm hoszabb vizsgálatra, mert egyéb teendőim vannak, de az a gyanúm, hogy a 32mx nem észleli. Bár az erratájában csak a megszakításra vonatkozólag van bejegyzés slave mód esetén, arra nincs, hogy az I2CSTAT start bitjét nem billenti be.
Nem kell az eredeti beállítás, egyenlőre csak tesztelgetem min hogy lehet spórolni. Na meg mint említettem a 32mx-el vannak gondok slave módban, de majd kiderül.

További tesztelgetés eredménye:
Működik a start-stop mindkét irányba, cím nem kell. A 12-esen elfelejtettem bemenetre állítani az IIC lábakat. Az ACK-ot gondolom csak üzenetváltás közben tudom kipróbálni, de majd tesztelem.
Viszont a 12-es rendesen megszivatott. Furcsa viselkedést tapasztaltam. Leírom, hátha valaki belefut. Belső órajel 32MHz-en (PLL-ON). (nem tudom kvarcról is csinálná-e illetve alacsonyabb órajelen is előfordulna-e, erre most nincs időm tesztelgetni.
PIC12F1840. Ha működő tápra kapcsolom fel akkor nem mindig indul el, de annyira, hogy semmi sem megy, még a watchdog sem. Erratában van írva ugyan a power on timer-ől valami, de csak a bitre tér ki. Mindegy, ez kiküszöbölhető, mert egyrészt amiben benne lesz ott úgyis a táp lesz kapcsolgatva, annak meg van felfutása,csak itt tesztelgetés közben egyszerűbb volt lehúzni mint másodperceket várni míg a labortáp pufferja lemerül. Valamint egy nagyobb kondit tudok rakni a bemenetre ami szintén lassítja a felfutást ha gyors a táp.

Sziasztok!

Bocs, hogy ide furakszom.
Egy olyan feladatot tűztem ki célul, ahol már nem elég a 16f... 8 bites család számítási teljesítménye.
Eddig csak assembly-ben írtam programot az mplab 8.91 verziójában.
Volt úgy, hogy 4kszót meghaladót is.
Keresnék valakit, aki megtanítaná az mplab x ide fejlesztői környezet használatát minimál szinten és
avval szóra bírni egy 16 bites pic-et (pic24 vagy dspic33).
Mindezt természetesen a processzor anyanyelvéhez közelebbi assembly-ben. (A többi nyelvet nem ismerem, nem is érdekel.)
Természetesen nem kérem ingyen, óránként 3000ft-ra gondoltam illetve minimum 12000ft-ra, de ha mondjuk 8-10 órára van szükség, az se baj.
Tehát szeretném, ha erre jelentkezne egy megfelelő tudású ember vagy ajánlanátok valakit, akit felkereshetnék lehetőleg Budapesten.
Köszönöm a figyelmet és a választ. (Kérem szépen, hogy lebeszélős tanácsokat, mint például:"magasabb rendű programozási nyelven kéne...", vagy ehhez hasonlót ne küldjetek!)

Sziasztok!

A WDT-vel kapcsolatban van egy kis logikai problémám. Maga a működése világos.
De mi vált ki pontosan egy WDT event-et ha a kód rendesen van megírva akkor a kódban nem lehet hiba, ha elektromos zavar váltaná ki nem feltételezhető hogy a WDT vel is probléma akad?

Pontosan mikor van értelme használni?

Hello! A WDT a kontrolleren belül, fizikailag is létező független áramkör. Működésbe lép, ha a pld. a program "eltéved" és nem az előírt dolgot hajtja végre. Végtelen ciklusba kerül, vagy időzítési hiba lesz. Ekkor a "kályhától" újra tudja indítani a programot, ami még mindig jobb, mint ha nem is működne. Ez ennyi, és nem több. Léteztek anno külső WDT áramkörök, vagy áramköri megoldások is készülékekben.

Lehet pontatlanul fogalmaztam, de pont az a kérdés, hogy mitől kerülhet végtelen ciklusba/téved el, egész pontosan hogy megfelelő hardware-es tervezéssel és software megírással elkerülhető a probléma vagy van értelme bővíteni a kódot úgy hogy WDT reset-ből vissza tudja magát állítani?
(Van külső EERAM, arra már nem emlékszem, hogy a WDT reset törli-e a ram-ot)

A hardware már megvan úgyhogy a külső wdt ugrott (ha a külső stabilabb lenne) de van belső (ha bármit is számít 32MZ-ről van szó).

Tucatnyi oka lehet.
Leggyakoribb ok az emberi hiba; hibás kód.
Egy lezáratlan sztringgel való művelet, egy hibás ugrás, egy feltétel amivel nem számoltál,
memória túlírás, túlcsordulás, ..., ..., ...
Emellett a PIC-be bejutó külső zavar is művelhet csoda dolgokat.

Röviden: a WDT-nek van értelme, nem véletlenül találták ki.

Szia!

Akár egy külső zavar is átbillenthet egy-egy bitet, ami már hibás működést okoz (bár ez ritka azért). Inkább a külső inputra történő téves reagálást emelném ki. Persze ha csak ezt mondom, akkor feltételezem, hogy a kód logikailag tökéletes.

PedigSziasztok!
Van egy laptopom, amin nincs soros port (sajnos ). Ezért vennem kellett egy USB - soros port átalakító kábelt. Erről a típusról lenne szó.
A soros port hiányából ezzel a kábellel kell összekötnöm az egyszerű JDM égetőmet. (Tudom , sokan nem szeretitek, de ezzel az égetővel nagyon sokszor égettem be már PIC16F628A és PIC16F84A csak soros porton keresztül, minden gond nélkül).
De most abba problémába ütköztem, hogy az USB-s konverter kábelen keresztül összekötött égetőbe hiába teszem bele a PIC-ket nem ismeri fel az égető program ( PICPgm). A JDM-et felismeri, hogy csatlakoztatva van. De az érdekes, hogy nemrég ugyanezzel az összeállítással sikeresen égettem be egy programot egy PIC16F876A típusú mikrovezérlőbe.
Esetleg valamit át kellene állítanom a programba vagy az illesztőprogramnál?
Köszönöm a segítséget!

A lap tetején a sárgában...
Az USB miatt nem működik...
Az usb csomagátvitelt csinál, "bit átvitelt" nem tud, szóval ha a pl rts-t akarod adott ideig bilenteni, az usb-n ez ez egy bonyolult kommunikáción megy át, soha nem lesz azonos idő, a jdm elhal.
Használj normális égetőt, az Ali-n, Ebay-on aprópénz a pickit2/pickit3 és debugolni is tudsz vele, meg majd minden pic tipust ismernek.

De akkor a PIC16F876A , miért sikerült beprogramozni?

Miért, miért? Toleránsabb lehet az időzítésre, vagy hosszabb impulzusokat használ, emiatt esetleg kevésbé időkritikus, meg lehet holnap már az sem megy, csak a nap-hold-mars szerencsés együttállásakor.
Fogj egy szkópot nézd a jelalakokat, mérj időket, és nézd meg az adatlapban az idők speckóit.

Az mplab x-et azzal kezdték el, hogy na majd minden oprendszerre megcsinálják a fordítót, és lesz a pic32-höz harmony. Ha az asm elég neked, még mplab sem kell. Van parancssoros assembler + linker. Persze lebeszélést nem írok, mert külön kérted, hogy olyat ne tegyünk

MPLAB X-ben nem tudok segíteni (mert csak MPLB 8-at használok), de a PIC24 assembly programozáshoz a PIC-kwik első fejezeteit érdemes megnézni (az A kísérleti áramkör előttieket). Sajnos, a dsPIC33 speciális utasításaival még nem volt időm foglalkozni.

Rendben, értem most már.

Üdv!

Nem tudja valaki a PL2303-as serial-USB konvertert lehet 1 csatornás logikai analizátorként vagy serial monitorozáshoz használni valami szoftverral?

A PICkit2 a maga 3 csatornájával nem lenne jó? Arra ügyelj, hogy a PGC és PGD vonalakat (4k7) ellenállással a földre húzza.

Most csak PK3 van kéznél.

Soros monitorként putty, Arduino és számos egyéb is használható, de mindhez szabványos soros adatok kellenek.
Egyéb jelekhez inkább egy ilyen alkalmas: Bővebben: Link

IIC akartam monitorozni, de most megoldom szkóppal.

Ezért nincs harag.
De az egy kicsit fura, hogy kérdezel, kérsz, és többé ide sem dugod az orrodat. Nem vagy kíváncsi rá, írt-e neked valaki. Különös tekintettel arra, hogy a kérésed jellege miatt valószínűleg privátban kapsz választ.

Srácok, szükségem lenne arra, hogy tudjam debugolni a 16F684-es PIC-emet, MPLAB-ban, PICkit2-vel. Valami "Header Interface"-re hivatkozik a program. Van rá valami megoldás, hogy magában tudjam debugolni?

Szia!
Ha jól látom, ebben a PIC-ben nincs benne a debug funkció. Ilyenkor egy hasonló, de debug funkcióval rendelkező típussal érdemes a fejleszteni, és utána visszatérni a debug funkcióval nem rendelkező típushoz. A header interface-ben is egy hasonló, de debug funkcióval rendelkező típus van.

Egy AC162155 kártya kell hozzá, amivel helyettesíted a mikrovezérlődet. Ja, meg egy PICkit2 - ICD2 átalakító kábel is kell. Én inkább belenyugodnék abba, hogy ezt a típust nem lehet debuggolni (kevés benne a hardver erőforrás).

Köszi srácok.. Akkor marad egy ideiglenes kijelzős debugolás..

Srácok, debugolnám kijelzőn akarnám nézni az értékeket, de úgy fest ez is megérne egy misét.
Nincs valakinek 16f684-re egy sima 2x16-os karakteres kijelzőre működő kódja?
Megköszönném a segítséget.

Köszi, úgy fest megoldódott.

Én a magam részéről külön teszt feltételeket szoktam beleírni a programba, és ledeket kapcsolni a feltételek alapján. Ugyan nem egy lépésben fogod így megtudni, hol és mi lehet a hiba, de pár próbálkozásból be tudod határolni az a pontot a programban, ahol másvalami történt, mint aminek szerinted történnie kellett volna. Kotorászol a környezetében, és előbb-vagy utóbb biztosan leesik a tantusz, miért történik, ami történik.

Ami még segíthet, az a körültekintőbb előzetes tervezés. Egyáltalán nem természetes, hogy ami körültekintően volt tervezve, és részegységenként előzetesen tesztelve is volt, az még mindig hibákat adjon az összeállítás után. Valamit nem csak picit, hanem nagyon el kellett ahhoz rontani, és az odafigyeléssel megelőzhető.

LCD kijelző már működik, így kicsit egyszerűbb az ellenőrzés.
Ami érdekesebb jelenség, az az, hogy ha beállítok egy timer2 megszakítást, akkor állandóan resetel a PIC. Tanácstalan vagyok.
Hátha ti látjátok a problémát:
Header
Init
Interrupt
While