Idézet:
„Szerintem a csomagban található C forrás és az lst állomány nem fedi egymást.”

Az biztos, mert ha fednek egymast, akkor mukodne a program
Egyebkent az a furcsa, hogy a legelso csomagban levo .lst latszolag teljesen jo. Bemasolja a RAM-ba a tombot (bar azt az assembly reszt nem ertem teljesen), es a ciklusban meg is hivja WriteI2C1() fuggvenyt a tomb elemeivel, de bbb allitja, hogy az a kod semmit nem is kuldott ki az I2C buszon. Ez nekem nagyon nem kerek.

Mielőtt még kiküldene egyetlen byte-ot, beüthetett a watchdog.

A másodlagos precedencia szabályt én úgy értettem, hogy a dereference és a post inrement operátorok azonos precedencia szinten vannak, és annak okán a *p++ működésének az alapja csupán a balról jobbra olvasás - és _az_ másodlagos szabály.

Jobbrol balra, de ettol fuggetlenul ugyanolyan fontos, mint, hogy azonos szinten vannak. Jobbrol balra asszociativitas itt azt jelenti, hogy az operandushoz legkozelebbit kell elobb kiertekelni. Ebbol a szempontbol a ++ egy erdekes dolog, mert a tobbi egyoperandusos operatortol elteroen a ++ es -- lehet az operandus jobb oldalan is. Ha azt irjuk, hogy *++buf; akkor vilagos, hogy a ++ van elobb, aztan csak a *

Sziasztok!

Nagy nehezen sikerült belőni a hardveres debugot a pickit2-vel (mplab-x "természetesen" nagyon nem szereti értelmes hibaüzenettel boldogítani az embert, csak a nem sikerült csatlakozni és nem sikerült beszélgetni vele hibát mondta). Miután ezen túlestem, kiderült a turpisság, hogy vajon mi nem stimmel, de a választ a problémára még mindig nem tudom.

Első körben annyit, hogy a watchdog timer nem szólt bele a dologba, kikapcsolt és bekapcsolt állapotban is ugyan az történik. Ami változást hozott, az az XINST bit állítása (ami a debugoláshoz XINST=OFF-ként kell szerepeljen). Ha így XINST=OFF-ként fordítom a programot, akkor a pointer értéke gyönyörű szépen növekszik és a helyes címről indul el. Viszont azon az adott címen csak szemét van. Úgy tűnik, hogy amikor az adatszekcióba kellene kerülnie, akkor valahol elromlik a tartalom.

Ami még érdekes volt menet közben, hogy megpróbáltam egy másik globális változót létrehozni , de amikor így fordítottam, akkor a hex fájl nem fért el a picben, s erre figyelmeztetett is az IDE! Ha értékadás nélkül hoztam létre, akkor megint jól fordított (vagyis belefért a picbe a program, de ugyanúgy csak szemét van benne), így ezen a problémán laza eleganciával túlléptem.

Sziasztok!

UART kommunikációval kísérletezgetek, próbálok újrafelhasználható kódot kihozni belőle, de megakadtam. Egy pic18f14k22-es van terminál programmal összekötve (MPLAB X, XC8). Mindig oda lyukadok ki, hogy a beérkező karakterek csak egy meghatározott nagyságú tömbbe kerülhetnek, pedig én azt szeretném, ha kötetlen lenne a csevej . Engedélyeztem a RCIE megszakítást, a függvény lefut annyiszor ahány karakter érkezett be. Eddig rendben is van, eltárolom őket egy tömbben. A kérdésem:
A tömb nagyságát ugye meg kell határoznom a feltöltése előtt (vagy nem?), de akkor meg kell várnom, míg befut az összes karakter (honnan tudom mikor van vége?), hogy tudjam a string hosszát, ezután a tárolóból (FIFO?) ki tudom olvasni az RCREG segítségével, és így betölteni a tömbbe, de akkor így először be kellene futnia az összes adatnak, azután kiolvasni. Lehetséges ez, vagy teljesen elmentem egy rossz irányba?

Köszönöm előre is a segítő szándékot, remélem érthetően sikerült megfogalmaznom magamat...

Szia!

A kontroller memóriája mindenképpen behatárolja a maximális, egyidőben tárolható adatok számát, tehát be kell határolnod ( legalábbis a maximumát !)!

Vagy tudod előre vagy "adatcsomag vége" jelet küldesz ! Ha adatokról van szó, akkor nem tudsz adatvége jelet küldeni, mert valószínűleg bármilyen adat előfordulhat, míg ha pl. szöveget küldesz át, akkor lezáró karakternek nyugodtan használhatod a 0x00-t !

Azért sokan használjuk ezeket a megoldásokat és eddig még minden feladat megoldható volt vele, úgy, hogy hajrá !

Eloszor fogalmazd meg a feladatot. Aztan lehet beszelni tombokrol, pufferekrol.

Az ilyen pufferek tobbnyire arra jok, hogy a beerkezo karaktereket egy megszakitasi rutin beleteszi, es jelzi a feldolgozo resznek, hogy van adat a pufferben. A feldolgozo resz meg majd kiveszi a pufferbol, amikor ideje van ra. Ha sok mas dolga van, akkor a pufferbe tobb karakter is bekerul. De egyszer onnan ki kell olvasni. Ez egy sima queue, vagy ring buffer.

Az, hogy a beerkezett adatokkal mit csinalsz, azaz a feldolgozas mit csinal vele, az mar attol fugg, hogy mi az adat, van-e valami protokoll, stb.

Elofordulhat olyan is sokszor, ha a beerkezo adat fix formatumu, es nem tul hosszu adatcsomagokkal kell dolgozni, akkor a vevo megszakitaskezeloje osszegyujti a teljes uzenetet, es csak akkor ertesiti a feldolgozo reszt, amikor ez megvan. Pl. minden csomag STX karakterrel kezdodik, es ETX karakterrel vegzodik. De kezdodhet barmivel, es vegzodhet CR-rel, tok mindegy, a lenyeg, hogy legyen valami kerete a csomagnak.

Akkor számíthatok rá, hogy ha bármilyen modullal (wifi, bluetooth stb) akarok kommunikálni akkor azok ilyen kereteket fognak használni?

Sziasztok!

Sikerült megoldani a dolgot. A működő változatot mellékeltem.
Több apróságot kellett összeadni, s így most remekül teszi a dolgát. Az apróságok, amiket változtatni kellett:

A két tényleg fontos dolog, hogy az XINST legyen így beállítva, illetve, hogy a buffertömb megkapja a static kulcsszót. Ezután a konstans tömbömből egy ciklussal áttöltöm az értékeket a bufferbe és működik a bufferben lévő adatok kitétele a vonalra.
Ezután a buffer módosítgatása (pl. egyenes vonal kirajzolása) is simán működött, tehát jöhetnek a "nehezebb" feladatok (képpont változtatása, vonalak/formák rajzolása, szövegek, ...), de merthogy nem vagyok teljesen mazochista, így a következő feladathoz igazítva fogom ezeket összerakni

Akármivel is kommunikálsz, annak host oldalon van a magyarázata, milyen és miért olyan. Még mindig ott tartunk, hogy mi a konkrét feladat, amit elvégezni akarsz saját áramkörrel? Ha arra gondolsz, hogy küldeni bármilyen adatot a saját programodból a saját áramkörödnek, megnyugtatlak, egyszerű és sima feladatnak nézel elébe, nem várható, hogy túl sok problémád legyen vele.

Mondjuk ha túl sok adatot akarsz küldeni, amit göngyölegként kell majd kezelni, bölcsebb lenne egy pic több memóriával.

Sziasztok!

Vezetéknélküli kapcsolatot szeretnék megvalósítani 2x PIc 16F887 kontrolerokkal vevő és adó oldalon. Külső hőmérsékletet szeretnék mérni amit az egyik PIc feldolgozna és továbbküldené a másik PIc felé ami kijelezné azt a mért értéket. Milyen adó és vevő modult tudnátok ajánlani hozzá?

Szia! ESP8266.

A legegyszerűb pl. egy RF modul páros, UART kapcsolattal. Amit az egyik oldalon küldesz, az a másik oldalon megjelenik. Ezek általában programozni sem kell, csak bekapcsolni és egy-két lábra H vagy L szintet adni.

Mielőtt bármilyen rádiós ketyerét választanál, kellene mérni egyet abban a környezetben, ahová raknád, hogy melyik sáv mennyire telített. Kint a mezőn, vagy valami hegyoldalban általában használsz, amit csak akarsz, városi környezetben más a szitu. Kérdéses az eszközök szándékolt távolsága is, van-e közöttük rálátás, vagy egy egész domb lenne közöttük, esetleg sok100 km?

Az opcióid egyébként: IR, wifi (router kell hozzá), zigbee (router kell hozzá), custom RF, gsm.

Én hasonló feladatra nRF24L01 modult vettem. 2.4GHz-en kommunikál és egyszerű a használata.
A hosszabb táv miatt az egyik (adó) külső antennás, a másik a vevő integrált antennás.
Ár érték arányában szerintem az egyik legjobbnak mondható. (persze ez szubjektív)

Nem olvastam vissza milyen IDE-t használsz, de az mplabX magától Magától beállítja azt a bitet, a fordítástól függően.

MPLAB-X 3.51, és nem tette, hanem amikor debug módban indítottam volna, akkor figyelmeztetett, hogy állítsam be én (egy gyönyörű error üzenettel).

Sziasztok,

Arra lennék kíváncsi, hogy ha egy hőmérséklet értéket szeretnék továbbítani vezeték nélkül az egyik PIctől a másik Pic felé, akkor annak az elvét miként lehet megvalósítani?
Az én elgondolásom:
Adó oldal:
1.Hőmérséklet érzékelés egy érzékelővel
2.PIC1-en belül a mért hőmérséklet A/D átalakítása
3.A kapott digitális jelhez megfelelő impulzus sorozat generálása, amely megjelenik a PIC1 egyik kimenetén.
4. PIC1 össze van kötve az ADÓ résszel és küldi azt a bizonyos impulzus sorozatot

Vevő oldal:
1. VEVŐ modul veszi a jelet, demodulálja és megjelenik az a bizonyos impulzus sorozat a PIC 2 egyik bemenetén.
2. PIC2 feldolgozza ezt a jelet és egy LCD kijelzőn kijelzi ahhoz az impulzussorozathoz tartozó számszerű értéket.

Remélem érthetően fogalmaztam
Előre is kösz a választ!

Pár hozzászólással ezelőtt kérdezted meg ezt, kaptál is rá több választ, lehetséges megoldást. Egyik sem tetszik?

A kérdésem akkor csak az ADÓ/VEVŐ modulhoz kapcsolódott, milyet érdemes és nem pedig a konkrét teljes megvalósítás.
Szeretnék írni egy saját programot amivel a hőmérséklet érték átvitelt megtudnám valósítani és ahhoz kell, hogy ismerjem magát az egész elvét a dolognak.

Az elv kb okés, a konkrét megvalósításhoz pedig azokat a lépéseket kellene kisebb lépésekre bontani. Legeslegelső lépésként az angolnak mennie kell olvasás / megértés szintjén. Következő lépésként a választott pic adatlap letöltése, és elolvasása (kb 500 oldalnyi?). Csillió kérdésre fogsz választ kapni, míg az adatlapot végig olvasod. Jelezd, ha eddig megvagy.

Kösz a választ! Pár dolgot már megvalósítottam PIC-el. Az elvben nem voltam biztos, de ha úgy jó akkor azon a vonalon elindulok....

Van egy 1. PIC-ed ami az adó, azon egy hőmérsékleti jeladó, a jeladó jelét fogadod, majd azt már is nyers adatként közvetlen ki is küldöd vevőnek.

Vevő vagy is a 2. PIC meg szépen veszi és átkonvertálja majd kiírja LCD-re.
Ez szerintem nem bonyolult, ami majd okozhat meglepetést az tán majd a szenzor jelének fogadása és konvertálása. Persze lehet már olyan szenzort is vásárolni ami digitálisan egyből azt az értéket adja amit ki kell íratni.., ez rajtad múlik meg a pénztárcádon..

A vezeték nélküli kommunikációnak meg lesz úgy is egy portokólja amit be kell tartanod, szóval sok varia nem lesz vele.. Vagy jó, vagy nem..
Persze az optimalizáció is fontos, időzítés, (adatfogadás, küldés, fogadás, LCD frissítés..stb)

Ha az adatlap megvolt, a következő lépésnek azt javaslom, hogy döntsd el, melyik oldalt fejleszted elsőként. Az adó oldalt, vagy a vevőt? Válaszd, amelyiket kedved tartja, de bármelyiket is választod, tartsd észben, hogy azt tudnod kell az ellenpárja nélkül tesztelned. ha fel vagy szerelve pld ttl soros port / usb átalakítóval, kezdheted az adó oldalán a mért mennyiség hiteles ad átalakításával (tudnod kell kijuttatni onnét az adatot, hogy ellenőrizhesd). Ha nem vagy különösebben teszter cuccokkal felszerelve, kezdd a vevővel, mert annak ott a kijelzője visszajelzésként - és akkor építkezz "visszafelé".

A kettő pic közötti kapcsolat típusra végül mit választottál?

Szerintem fejlesztés közben mind két egységre tehet LCD-t, én legalább is mindig így fejlesztek, hogy van valami debug lehetőség rajta az MPLAB-on kívül is..
A minimális egy pár LED, de legjobb a kijelző, hogy lássam mit is csinál.

Még én sem kezdtem bele a fejlesztésnek, (ugyan ezt akarom majd én is elkészíteni, csak kicsit komolyabb kivitelbe és más funkcióval) de pl. én egyszerre mind kettőt meg fogom építeni és úgy tesztelni az oldalakat. Mondjuk SPI-s moduloknál persze ez tán könnyebb is, mert kevés a hiba lehetőség.

Csak kíváncsiságból, milyen project az, ami annyira jó ötlet, hogy egymástól függetlenül ketten is neki kezdtetek? Lehet, megyek harmadiknak

Ja semmi extra és még csak nem is titkos..
Egy olyan kis eszközt gondoltam fejleszteni ami egy vidéki kis faluban vagy utcában két barát közti free chat-et tesz majd lehetővé.. Gyakorlatilag mint az internetes skype vagy viber, hang hívás nélkül, csak szöveges üzenetek elküldésére.. (akár segély hívónak is jó lehet)
Mind ezt 2.4GHz-es vezeték nélküli modulokkal gondoltam megoldani..
Majd kiderül mennyire lesz élet képes és hogy mekkora távolságot tud majd áthidalni.
Láttam teszteket, ott 2.2km volt a legtöbb amit sikeresen áthidaltak, persze nekem majd tesztelgetni kell, sok épület, sok zaj.....

Adnék két tippet.

1. gsm internet. A gsm internet csomagok ugyan csomag korlátosak, de nem muszáj azokból ilyen 10 giga meg hasonlókat vásárolni. Megvásárolod csak a legkisebb csomagot - létezik 1 gigabyte is? Amikor az a csomag elfogy, akkor a net nem lekapcsol, hanem átáll valami 32 kbyte/sec-re, és a kártya rendelkezésre állási ideje alatt (valami egy év?) azt akár folyamatosan használhatod. Hátrány: év elején egyszer ki kell fizetni.

2. elektromos hálózatra ültetett fm jel. Megfigyelitek, hogyan van biztonsági trafókkal leválasztva a helyi elekromos hálózat, és arra ráraktok pld 10 Mhz-es fm jelet. Hátrány: ha sokan vagytok a hálón, nem ártana valami arbitráció központ is, és nem kicsike probléma azt normálisan építeni meg.

Még mindig a free és vezeték nélküli lesz a jó megoldás..
Úgy is ki akartam próbálni, hogy mekkora távot tudok kényelmesen áthidalni, aztán persze lehet semmire nem lesz jó, de egy kis mókának, fejlesztésnek, tapasztalatnak nem rossz.