Keress ra a "PBUS" szora. Ez egy egydrotos kommunikacio. Mindenkinek van sajat cime, es csak a neki szolo uzenetet veszi. Itt egy pelda. En csinaltam ilyen halozatot, es szepen dolgozott. A SW termeszetesen CCS C-ben van irva.

Nekem ez nem jó mert minden dali eszköznek lesz kihúzva külön kábel.

Attol meg lehet egy labra kotni a kabelt.

Szeretném én megírni a dolgot, csak az a baj, hogy a c ismeretek hiányosak még most pl itt akadtam meg:



Nem tudom a c-be írni az adott bitek értékét. Nem értem hol hibázok.

Ha lehet, kapcsold ki az optimalizálást. Olyan okos, hogy kiszedi azokat az utasításokat, amik fel nem használt változók értékét módosítják. Esetleg c legyen volatile:
volatile int c;

Ebben a formában betettem még egy c=data, C egyenlő is lesz százzal viszont bitenként nem íródik a c.
Szerintem nagyon rosszul csinálok valamit.

Onnan még valami hiányzik...

Mikor simán értéket adok a data-nak fő rutinban akkor bitenként megjelenik az érték a watch ablakban...

mi és honnan?

..csak a lényeg, a dali üzenetté konvertálás és a küldés.

Lehet hogy elbeszélünk egymás mellett nagyon titokzatos vagy... ott tartok egyenlőre hogy a 100-as érték átmegy a függvénybe, de a belsejében a c nem akar íródni a data változó bitenkénti értékével ez még messze nem a dali kommunikáció. Azt kéne megoldani hogy a függvényem működjön. Esetleg nem tudnád bedobni mplab alá a kódot és megvizsgálni?

A globális data változónak nincs értéke, így nem sok értelme van kiszedni bitenként. A write_dali-ban használd a bit_test fügvényt.

bit_test(változó, hányadik bit)

Amikor a write_dali(100); al meghívom a "int write_dali(int data)" függvényt akkor nem kapja meg a 100-as értéket?

Megkapja a 100-ast, de a data0...data7-ben nem a 100-as bitjei vannak, hanem semmi. A data0...data7 fordításkor kap értéket, mégpedig azt ami a globális data változódban van.

Köszönöm a válaszodat nagyon sokat segített a tanácsod

Sziasztok fiúk, a véleményetek érdekelne. Egy számomra furcsa jelenségre lettem figyelmes, lehet, hogy valakinek van tapasztalata ill. megoldási ötlete az ügyben.
Egy saját távdetektoros mérőműszert fejlesztek PIC18F4620 MCU-val. A lényeg, hogy 3 féle megszakítást akartam használni a kéziműszer programjában:
1. az #int_timer1 egy késleltetést működtet, amely a bekapcsolás után a detektor szenzor bemelegedését hivatott "kiváratni" a felhasználóval, valamint a várakozási idő alatt elvégzi a detektor beazonosítását, paramétereinek egyeztetését RS232-n keresztül. Ez a megszakítás és a hozzá tartozó rutin tökéletesen működik.
2. az #int_rda figyeli a detektortól beérkező üzeneteket annak rendje és módja szerint getc() rutinnal. Ez a megszakítás és a hozzá tartozó rutin is tökéletesen működik.
3. az #int_rb figyeli a kéziműszer billentyűzetét amely a rb4,rb5,rb6 lábakra van kötve. Használom a felhúzó ellenállások aktiválását, stb., aktiváláskor normálisan inicializálom a b portot, ahogy azt kell. Nos, ennél a megszakításnál van a bibi. Teljesen mindegy, hogy milyen rutint írok hozzá (az #int_rb alá), akár üres rutint is, már az is elegendő a hibajelenséghez, ha az #int_rb sort beírom, tehát ha kikommentelem, akkor nincs hiba.
A hibajelenség pedig az, hogy ha beírom a megszakítás sorát, akkor a főprogramban a megszakítások engedélyezése utáni résztől kezdve jelentősen lelassul a program futása, a 2 perc várakoztatásból 3 perc lesz, elmegy az UART időzítése is, ezért azután mindenféle értelmetlenséget vesz és a futás egyre csak lassul. Ha kikommentelem az #int_rb sort, akkor semmi gond, minden tökéletesen működik. Próbálkoztam a megszakítások prioritásának beállításával, stb., de nem segített semmi.
Hardveresen a billentyűzet bekötése jó, cikluson belüli időzített figyeléssel megszakítás használata nélkül megoldottam a billentyűzet kezelését, tehát ez a rész is jól működik.
Lehet, hogy ez a 4620-as valamilyen típushibája, mert ilyennel nem találkoztam más típusoknál (4520, 4580) ? A compiler v5.011, de a v4.140 alatt lefordítva is ugyenezt csinálta.
Van valakinek tapasztalata, ötlete? Mert ezzel a megoldásommal is működik szépen a cucc, de nem igazán "elegáns"...

Szia!

Nem használom a CCS-t, de az RB changed funkció megszakításánál a PORTB olvasásával kell emlékeim szerint törölni a jelzést( nézd meg az adatlapban, mert most nincs előttem és régen használtam!), a leírásod alapján úgy gondolom ez elmarad és emiatt folyamatosan visszatérve a rutinba jelentősen lelassul!

Felfutó/lefutó él be van állítva? Felhúzó ellenállás, stb... okés? Megszakítás prioritás be van állítva? Van elég idő a megszakítást lekezelni? RB-nél ha lefutott a megszítás, törlöd a megszakítást kérő flag-et? Nem túl nagy a megszakításban lekezelt rész?

Az RB megszakításkezelésében kiolvasod a PORTB -t, törlöd az RBIF -et? Az errata -ban levő megszakítással kapcsolatos megjegyzést olvastad?

Jo lenne ha a megszakitaskezeles programreszleteket felraknad, es igy tobbet lehetne esetleg mondani. Igy latatlanban eleg nehez kitalalni mi is lehet a problema.

Sziasztok, köszönöm a segítőkészséget!
Idemásolom a lényeges kódrészletet, talán így többet láttok... Egyébként így belegondolva arra hajlok, lehet hogy a timer1 megszakítás miatt nincs ideje végrehajtani az rb megszakítást? Mindegy, nézzétek:

Ugy elso ranezesre ( igy koran reggel, kicsit meg almosan) az IT rutinokbol talan nem kellene hivogatni a GLCD irasat. Nem ismerem ezt a "Exologo_GLCD.h" includot, de gondolom a grafikus LCD kezelese van benne. Ezek altalaban idoigenyes muveletek, es Te addig fogod a procit IT-ben tartani, amig ki nem irtad a kiirandot. Talan jobb lenne ugy szervezni a programot, hogy az IT-ben bekovetkezo esemenyekhez hozzarendelni 1-1 bitet, amit az IT bekovetkezesekor allitassz, majd ezeket figyelni a foprogramban es ennek fuggvenyeben elvegezni a feladatokat (kijelzes, szamitasok, i tak dalse).

Pont ugyanezt látom. Ezért is írtam Jossz-nak, hogy flag-ekkel operáljon a megszakításokban és ne felejtse el visszabillenteni őket a lefutás után.

Köszönöm az ötleteket Neked is és Vicsys-nek is. Az Exologo_GLCD.h-ban csak egy adatmátrix van, amelyet egyszer olvas fel, ebben van a cég grafikus logója. Mindenképpen úgy tűnik, hogy egyszerűen az rb-nek nincs elég ideje végrehajtani a megszakítást. A flag-ekkel történő grafikus operációt is belevariálom a főprogramba, tuti, hogy segít. Az RDA csak 2 másodpercenként kap adatot, tehát ez lassú, ellenben mi van akkor, ha a Timer1-et úgy paraméterezem fel, hogy ne 10 ms-onként generáljon megszakítást (a kommentben rosszul írtam, mert most nem 0,1 s-onként szakít meg, hanem 0,01 s-onként), hanem mondjuk 100 ms-onként, mert nekem úgyis csak minden kerek másodpercben kell kiírnom a képernyőre egy működési jelet. Ez így minimum másodpercenként 90-el kevesebb db megszakítást jelent, lehet, hogy ez már elég lesz az rb működéséhez? Szerintetek? Csak holnap este tudom kipróbálni, ezért érdekelne, hogy szerintetek megér egy próbát?

En ugy szoktam csinalni, hogy valamelyik timert felhasznal0m egy "tick" generalasara, es egy (vagy tobb) szamlalot szamoltatok vele lefele. ha elerem a "0" erteket akkor egy bittel jelzem a foproginak, hogy itt az ido pl. a kijelzesre, vagy mas muveletre. Mellette meg pl az timer IT-ben szoktam lekezelni a gombok beolvasasat is, mert a RB IT nem ad jo lehetoseget a gombok prellmentesitesere. Erre szinten van egy szamlalom, amivel meg tudom poldani a biztonsagos beolnasast.
Alljon itt egy pelda az altalam alkalmazott megoldasra: Itt a TMR0 van hasznalva, de semmi akadalya a TMR1 hasznalatanak sem.
A gomb beolvasashoz a mellekelt includot alkalmazom, aholis a "#define Buttx" hatarozza meg a fveny visszateresi erteket a bemenet kombinaciojanak megfeleloen. Lehet tobb gomb egyuttes lenyomasahoz is hozzarendelni visszateresi erteket. Ja persze en altalaban 10 mS "tick" idot hasznalok, es igy ennek tobbszoroset tudok hasznalni a klf. idozitesekre.

Kiváló ötlet ez a Timer IT-n belüli gomb beolvasás, köszönöm! És köszi a headert is...
Tulajdonképpen most végül is én is hasonlóan olvasom be a gombokat a RDA-ra történő várakozás alatti "üres idő"-ben a végtelen ciklus belsejében elhelyezett gombmegnyomás vizsgálattal, de a Te megoldásod mindenképpen praktikusabb és elegánsabb, engedelmeddel "asszimilálom"... Így azután meghagyom is a 10 ms-os megszakítási időt is a Timer1 IT-ben...

Egeszsegedre!!

Sziasztok!

Egy karakter vétele után hogyan tudom kitörölni a soros vételi puffert, hogy az üres legyen?
A processzor: PIC18F14K22
Kössz.
Üdv: B

Kiolvasással vagy a vevő letiltásával és újraengedélyezésével.

Ha jól értem a RCREG nevű regisztert akarod törölni, kiolvasás után. Nos, az én tudásom szerint ezt a regisztert kiolvasás után nem kell törölni, azt elvégzi automatikusan a CCS. De ha kiolvasás után te szeretnéd jelezni a kiolvasás tényét, akkor nem az RCREG -t kell törölnöd, hanem a PIR1 regiszter 5 -k bitjét az RCIF -t kell nullára állítanod.

A törlést több módon el lehet végezni. Például deklaráljuk a "B" portot, és annak egy bitjét, majd azt töröljük. Valahogy, így gondolom,

#byte PIR1 = 0xF9Eh
#bit RCIF=PIR1.5

majd kiolvasás után:
RCIF = 0;

Remélem, jól olvastam ki a címeket az adatlapból.....
Üdv.
Subi