Sziasztok még egy kérdésem lenne, hogy szerintetek spi-bus -on lehetne dali eszközzel kommunikálni?

Mi az a dali eszköz?

Közvetlenül biztosan nem, mert más a jelszint, más a protokol, s még a vonalak száma sem stimmel. Kell a két busz közé egy jeltolmács.

Olvastam, hogy a dali protocol Manchester kódolásra épül. Jó volna a pic valamelyik hardveres interface-et használni csak adni szeretném az adatokat, a pic és a Dali eszköz közé pedig tennék egy szint illesztőt. Jó volna használni a pc valamelyik hardverét a dologra, de ha máshogy nem megy bit szinten fogom kiküldeni az adatokat. Még egyszerűsíti a dolgomat hogy nem kel címezni a dali eszközt csak 8 bitet kell átküldeni.

Ezek között nézz szét!
Valamelyik topikban volt róla szó, hogy némi kompromisszum árán az SPI-vel lehet Manchester kódolást játszani, de akkor is csak több bit felhasználásával lehet egy bitnyi információt kiküldeni.

Szerintem simán meg lehet csinálni, csak az időzítésekre kell odafigyelni. Vagyis az SPI óraciklusa 833,33us/2 legyen. Nem tudom, hogy a BRG-vel le lehet-e ilyen alacsony szintre menni, de hát a TMR2-vel is lehet ütemezni az SPI-t, az meg elég pontos.
A 11 bites, rövidebb kódot 3 bájttal lehet átküldeni. Start bit: 0b11111101, a többit Manchesterbe átkódolni meg nem egy nagy feladat. Stopbitnek elég abbahagyni az adást, annál nem kell kód, csak magas szint min. 1667,67us-ig.

Egyetlen gond lehet, mégpedig az, ha a DALI vevő élvezérelt és nem mintavételező, mert két SPI bájt között lehet dummy él. De ez alig valószínű, mert alapjaiban mondana ellent a koncepciónak.

Sziasztok ! Egy érthetetlen jelenséggel küzdök, és örülnék annak ha tudnátok segíteni!
Egy PIC24HJ128GP502-vel küzdök már 2 hónapja, eddig nagyjából sikerült mindent megoldani. A próbapanelen 2 hónapja szinte mindig rajta volt a PICkit3 programozó, és bár észrevettem, hogy néha-néha bekapcsoláskor nem indult el az áramkör, de a 2. bekapcsolásra mindig működött. Közben csináltam még egy áramkört azonos PIC, azonos áramkör, eltérő programmal, de a lényeg az, hogy a tápfeszültség bekapcsolásakor már egyik áramkör sem indul el. Sem reset, sem hosszabb idejű kikapcsolás után sem. Mindezek ellenére, ha újra programozom a PIC-eket, akkor mindkettő problémamentesen működik. Ha 3 másodpercnél rövidebb rövidebb időre kikapcsolom a tápfeszültséget, akkor probléma mentesen újraindul mind a két áramkör, 3 sec.-nél hosszabb kikapcsolás után nem indul el egyik sem.
A PIC-eknél használtam a belső oszcillátort, 20-8-4 Mhz-es külső kvarc oszcillátorokat 15-től 30pF-ig különböző kondenzátorokkal, külső tápról, és a PICkit3 táplálással szintén, a feszültség mindkét esetben 3,25V.
Az oszcillátor SW beállításnál amit tudtam mindent kipróbáltam. A különböző oszcillátor beállításoknak, és éppen használt kvarcoknak megfelelően, az újra programozás után mindig elindul az áramkör, és ilyenkor a reset is működik. Az oszcillátor beállítás az elmúlt 2 hónapban nem változott, ennek ellenére mégis sikerült eljutni a működésképtelenségig. Találkoztatok már hasonló hibával?

Kapcsolási rajz, fényképek az áramkör kiviteléséről és a konfigurációs bitek beállításai kellenének a kérdés érdemi vizsgálatához.

Nem világos továbbá, hogy rajtahagyott PICkit3-mal jelentkeztek a bekapcsolási problémák, vagy anélkül (saját tápról). Az MPLAB-ban RELEASE vagy DEBUG beállításban történt a fordítás?

Szia ! A késő éjszakába nyúló probléma keresés nem mindig eredményes. A hiba okát már sikerült megtalálni, de a miértjét továbbra sem. A kapcsolás azt hiszem ismerős lesz:
Bővebben: Link
(Bocs! Ha nem jó a link beszúrás!) A programozás CCS-C-ben történik, és MPLAB release-ben.
Ma azzal kezdtem, hogy minden HW beállítást töröltem, csak egy LED villogás maradt a fő programban, majd egyenként kapcsoltam vissza az SPI-t, az A/D-t...stb. A "lefagyást" egy az UART RD megszakításában lévő
"ch = fgetc(UART1);" utasítás okozza. (azt még ki kell nyomozni, hogy miért) Nem térnék ki jobban a kódra, és a kapcsolásra, mert az nem változott a két állapot között. A probléma elvileg megoldódott, de a kérdés továbbra is az, miért indult el a PIC programozás után mindig, és miért nem, amikor csak egy sima bekapcsolás történt? Lehet, hogy ezt a kérdést tovább boncolgatni hiábavaló. Örüljön az ember annak ami működik.

Én biztosan nem mernék a CCS C zárt forrású függvényeivel dolgozni, hiszen nagyon nehéz kideríteni, hogy mikor mit csinál. Ráadásul, ha emlékeim nem csalnak, két soros port is van, de alapból egyik sincs kivezetve (programozni kell, hová legyen kötve), így nem tudom, hogy melyikről olvasna.

Megszakításba azonban nem kellene ilyen függvényeket hívogatni, vagy legalább le kellene kérdezni, hogy bejött-e már az a karakter, amit ki akarsz olvasni.

Ilyen megoldassal lehetne figyelni a soros vetelt:

Nalam igy mukodik. Esetleg soros port megszakitassal.

Igen! Megértem az aggodalmadat. Engem is zavar az, hogy vannak rejtett dolgok a CCS-ben. Erről már egy másik fórumban is esett szó. Köszönöm, hogy reagáltál a bejegyzésemre.

Nem kötelező azokat a rejtett dolgokat használni egyébként. És ma már azt sem mondhatom, hogy használd a gyári fordítókat, mert azokkal is van szívás bőven...

Kicsit tömény.. Van egy osram dimmelhető előtétem fénycsőhöz, ezt szeretném pic-el vezérelni.
Ha jól veszem ki a protokollból akkor először kell egy start bit majd 8biten az eszköz címe és 8 biten az érték. Nem tudom mi lehet az eszköz címe, igazából nem is akarok címet használni mert csak egyet fűzök a pic-re. Hogyan kellene ebben az esetben küldenem az adatokat a vonalon? Van ötletetek?

Persze hogy tömény, mert azt gondoltam, hogy a DALI protokolban már elmélyedtél egy keveset és csak a technikai megvalósítás hiányzik.

Mivel a DALI master/slave protokoll, cím mindig van. Kis szerencsével ez épp 0. A Manchester kódolás meg összesen annyi, hogy ha egy bit 1, akkor 01-et kell kiküldeni, ha 0, akkor 10-át. Tehát egy bitet két bitbe kell átdolgozni. Az a start bit, amit írtam, egy trükk. Az elején az egyesek megfelelnek a sima, felhúzott SPI data láb állapotának, a végén a 01 pont egy Manchester 1-es.

Itt egy doksi, amiben szemléletesen le van írva. Nem éppen PIC, de nagyon hasonlít.

Tehát úgy kell elindulni, hogy beállítod az SPI-t úgy, hogy egy bit hossza a 833,3us fele legyen. Így kezdődik az adás: 0b11111101 start bit) 0b10101010 0b10101010 (0-ás cím) 0bxxxxxxxx 0bxxxxxxxx (adat) befejezed az adást legalább 1667,67us-ig (stop). Az adatot előtte természetesen bitenként átkódolod két bájtba.

Sajnos ennél jobban nem oldható a töménység.

Nagyon szépen köszönöm, hogy foglalkozol a dologgal! Egyenlőre még nem használom az spi-t. Próbálok bit szinten a pic-el fényerő változást elérni az előtéttel. Kezdem érteni a Manchester miatt van az hogy 1 bit helyett kettőt kell küldeni hmmm... Nagyon sokat segítesz, biztos lesz még kérdésem. Köszönöm.

Segítségeddel sikerült életet lehelni a dimmerbe a cím amire reagál a 254.
Köszönöm

Hello! MPLAB v8.92 16F1509 PICKIT3-al mplabon belül nem tudom programozni a következő hibát dobja fel.


PicKit2 saját nem MPLAB-os szoftverével viszi.
Találkoztatok már ezzel a problémával?
Mi lehet a gond?

A sebesseget vedd kisebbre.

Mármint az órajelet vegyem kisebbre?

Nem, valahol lehet állítani a PICKIT Program Speed-et (MPLABX-ben így hívják), azt vedd kisebbre.

Használok nem találok ilyen speed dolgot..

Azt hiszem ott másképp hívják, talán Fast Programming..

Nem találok ilyesmit, szerintem egész más lehet a dolog mplabX-nél.

1. Elolvastad, hogy mit jelent a hibaüzenet? (A kéken megjelenő "PK3Err0035"-re csak kettőt kell kattintani.)
2. A hibaüzenetnél ajánlott lépéseket megcsináltad?

Természetesen elolvastam, és mint írtam nem nyúlok semmihez, csak kicserélem pickit2-re és a pickit programozóval lehet írni a procit, salynos pickit3-al Mplab alatt nem megy a dolog.

Sajnos ebben nem tudok segíteni neked, mert nekem MPLAB alatt sosem volt gondom, igaz kizárólag 18F családot használtam. MPLABX alatt viszont igen a 12F1840-el.

Nekem watt ezt javasolta (ilyen viszont nincs MPLABX-ben):
"A PK3-nál van olyan, hogy fast programming mód, mint a PK2-nél? Ha igen, akkor kapcsold ki!"
Hátha ez segít.

Van a program elején késleltetés, mielőtt a programozó lábakat kimenetre állítod? Saját tápot használsz, vagy a PICkit adja?

Még rácsatlakozni sem tud a PIC-re. MPlab X IPE alatt van programming speed ami állítólag segít, de ide alatt nincs ilyen opció. Nekem is volt ilyen gondom más PIC-el PK3-al. Nem volt időm telepítgetni X-et ezért nálam egy másik számítógép oldotta meg a gondot. Véleményem szerint a PK3 érzékenyebb az USB fesz-re és ha kicsit alacsonyabb mint kellene akkor egyes PIC-eket nem tud kezelni. Legalábbbis nem tudok másra gondolni, ha oprendszer és mplab verzió is stimmel, csak másik gépen.

Még megpróbálhatná a Pikkit 3 programmer-el hátha azzal megy, de abban sincs programming speed vagy egyéb időzités opció.