Melyik a master, melyik a slave? Hogy néz ki a programod?

pic18 a master, pic24 a slave.

pic18 master code:


PIC24 slave code:

A PIC18 program elég hiányos, így nem tudom megállapítani, hogy mi a hiba benne.

A PIC24 program egy kicsit túlbonyolítottnak tűnik. Miért piszkálod az I2C megszakítás engedélyezését? Tudtommal adatküldéshez csak két utasítás kell:
Várakozást pedig semmiképp se tegyél a megszakítást kiszolgáló részbe!

A PICula projektem letölthető támogatói könyvtárában az include/picula_i2c.h és common/picula_i2c.c állományokat nézd meg! Különösen az i2c_init(), i2c_getc(), i2c_putc() függvényeket és az i2c_idle() makrót nézd meg!

PIC24-hez pedig a PICkwik projekt letölthető mintapéldái közül a chap13 mappában található i2c_slave_reverse_string.c programot ajánlom figyelmedbe.

Annyi mondjuk ennyiből is látszik, hogy a master nagy ívben tojik rá, hogy a slave küldött-e ACK-t, vagy sem, csak tolja a következő byte-ot...
Az ACK ellenőrzése nélkül abban sem lehetsz biztos, hogy a slave egyáltalán képes 0-ra húzni a két vonalat.

A PIC18-as kódban a 20.-ig sorig tökéletesen lefut, azaz az adat jelentkezik a PIC24 oldalán. Ezért nem másoltam be az összes subroutin kódot, úgy kicsit átláthatatlan lenne.

Csak a biztonság kedvéért tiltottam le a megszakítást. De az valóban nem való oda, csak teszt jelleggel írtam bele.

Melyik oldalon valószínűbb a hiba?

Nekem úgy tűnik, mintha az egyik hamarabb letudná a dolgot és vagy már átjött az üzenet és nem figyelte a pic18, vagy már nem figyeli és csak akkor küldi a pic24.

A send_data subrutin figyeli az ACK jelet. Az persze itt nem látszik, de egyébként figyelembe vettem és átjön a slave-től.

Az alábbi sor nem tudom, hogy mire kell:
,
de vagy ott, vagy a buffer kiolvasás után a masternek küldenie kellene egy NAK jelet a slave-nek, mielőtt stop-pal befejezed a tranzakciót.

Most így néz ki a subrutin. Visszaolvassa azt amit előtte beírt önmagának a master. Semmi nem jön a slave oldaláról. Egyébként a "call waitMSSP" az azért kellett mert az SSPIF is beállítódik amint megtelik a buffer és én azt vettem figyelembe. De egyébként sehogysem működik, nem kap semmit a slave oldaláról.

Nezd csak mit talaltam. A Philips I2C leiras magyaritasa.

Köszi szépen, átolvasom mindjárt. De volt 1 hiba a master kódjában, nem megfelelően nézte az ACKSTAT bitet. Nem jön válasz a slave oldaláról ACK formájában sem. Valószínűleg nem tudja lehúzni a vonalat. Ilyenkor hardveresen van hiba? Mit lehet ilyenkor tenni?

Pl. megmutatod, hogy hogyan inicializáltad az I2C alegységet és a megszakítási rendszert a PIC24-nél.

Pic24 inic:



Pic24 interrupt:

Én értem, hogy az assembly programozás/regiszterek direkt kezelése szép feladat vagy kihívás, de nem célravezető. Nem kell feltalálni a kereket, meg különféle makrókat saját magunknak definiálni, ezt megtette már a Microchip.
Jogosan tevődik fel a kérdés: miért nem használod ezeket? Amennyiben a tanulás a cél, úgy értem, de ha szeretnél valami biztosat, a leggyorsabb módja ha használod a fordítóhoz mellékelt könyvtárakat..

Bár a projekt konkrét, de 2 hónapja még abszolút kezdő voltam. Akkor assembly-vel kezdtem, mert szerettem volna mindent megérteni. Most már sok munka lenne átírni az egészet C-be, de a pic24-re már abban fejlesztem tovább.

Sikerült megoldani a problémát! A pic24 konfigurációs beállításaiban volt a hiba. Köszönöm a segítséget mindenkinek!

I2C1ADD = 0x0020; helyett I2C1ADD = 0x0010; kellett?

I2C1SEL_PRI

Kiemeltem, amit hozzátettem a konfig beállításokhoz. Nem néztem utána mit jelent, de így működik tökéletesen.

Mivel kimaszkolja a MASK = 0xff-el, így gyakorlatilag mindegy mit ír az addresshez

Sziasztok!
Szeretném megkérdezni, foglalkozott e valaki a CVfer feszültséggel PIC16F887-esen?
Elvileg RA2-n kelleni kijönnie, de sajnos nem jelenik meg...
A konfigurációm: ansel,2=1 trisa,2=1 vrcon= B'11100000'

Ha valaki tudja mit hagytam ki help pls!
Köszi:
Panzer

Szia!
A VRCON -ba olyan értéket írj, aminek az alsó 4 bitjén nem csak 0 van.
Ha jó bankokban állítottad az ANSEL és TRISA regisztereket, akkor már csak egy probláma lehet: A külső terhelés túl nagy.

ADCON1 / VCFG1 tartozik még ide a folyamatábra szerint.

Nekem megy
Ezek vannak nálam beállítva (nem biztos, hogy mind kell, de ami releváns lehet, azt beírtam):

Értem!
Nekem majdnem ugyan ez a beállításom:
ANSEL = 0x06;
TRISA = 0x0e;
ADCON0 = 0x85;
ADCON1 = 0x90;
VRCON = 0xe0

csak annyi,hogy én az adc-t külső ref-hez mérem, és a CVref is ennek a függvénye!
A terhelhetősége tudom, hogy kicsi, ezért egy 1x-es műveleti erősítő van rajta, és onnan viszem tovább.

Megvan a hiba!
A 10-s analóg csatornán állítottam be mérést, de az eszköz a 12-esre van kötve... XD
Minél régebb óta csinálom, annál pitiánerebb dolgokkal szivatom magam!

Köszi azért!

Sziasztok!
Végső elkeseredésemben írok, mert egyszerűen nem tudok rájönni, mit csinálok rosszul a programomban. Találtam a fórumban egy pic-es lakásriasztó kapcsolást amit megépítettem, úgy gondoltam saját programot írok hozzá, ami részben el is készült, de szeretném tovább fejleszteni szerviz menüvel, pin kód változtatás lehetőséggel, stb. A gond itt kezdődik, ugyanis ha megírom a program ezen részét, egyszerűen nem indul el szimulációban (persze a valóságban sem) Mellékeltem a teljes forráskódot (pascalban írtam) ha valakinek van ideje legyen szíves nézzen bele, mert én teljesen tanácstalan vagyok most már. Köszönöm előre is a segítséget!

Első ránézésre túl sok a kód, hogy ki lehessen hámozni a logikát belőle.. Egy tipp(én így szoktam): minden if nél adj meg egy matematikai műveletet, ne hagy hogy a fordító vagy az adattípusok különböző meghatározásai miatt elcsússzanak a feltételek.
Pl:
if not statusbit then ...
helyette:
if (statusbit=0) then ...
Nem állítom, hogy ez a hiba de az átláthatóság kedvéért mindenképp itt kezdeném a javítást...

Köszönöm a választ, javítottam amit ajánlottál, egyelőre semmi változás. Annyi plusz infóm van még, hogy a szimulációban (ISIS) pörögnek a hibák felváltva ez a kettő:
0x00D3 - Stack underflow executing RETURN instruction
0x00A3 - Stack overflow executing CALL instruction

Ez bizony elég csúnya.. Megtelik a veremtár, aminek két fő oka lehet: vagy túl kicsire lett beállítva, vagy a programban valahol szerepel egy rekúrzív függvényhívás.
Ellenőrizd a beállításoknál mekkora a verem (stack size).
A megszakítás kezelésében:
TMR1IE_bit := 1;
TMR1IF_bit := 0;
A második sor gondolom az interrupt flag törlése, de az első? Az engedélyező bit? Szerintem azt nem kell kapcsolgatni minden megszakításnál(?)

TMR1IE valóban nem szükséges, törölve. Amennyiben a főprogramból kihagyom a "armtmch: ..." (464. sor) illetve "baltmch: ..." (496. sor) részt a program hibátlanul fut. Hülye kérdés, de lehet probléma az, ha egy változó "túl sokszor" kap (más-más) értéket a programban? Gondolok itt pl a sor2-re például... a stack dolognak holnap utánanézek meló után, köszönöm az eddigi segítséged is!

Itt is látok egy valószínű problémát:
const _service = 1;
_monitor = 2;
_arming = 3;
_armed = 4;
_alarm = 5;

chpin = 1;
armtmch = 2;
baltmch = 3;
altmch = 4;
Ezek a szimbólumok a case elágazás lehetséges értékei. Nem emlékszem pontosan a Pascal hogyan kezeli ha egy case-ben több blokk szerepel ugyanazon értékre. Ugyanis lefordítva nálad ez történik. Ez szerintem nem jó így. A chpin től nem kéne újrakezdeni a számozást hanem folytatni (6, 7 stb).
case mode of
1: begin end;
2: begin end;
....................
1: begin end;
....................
end;
Nálad valami ilyesmi van jelen. Lehet, hogy ez teljesen fejreállítja a program futását, lehet nincs akkora hatása de akkor is ki kéne javítani s csak utána tovább lépni.