Szia,

Az adatokat nem feltétlen kell a megszakításban feldolgozni...elég ha csak bepakolod egy változóba (vagy egy tömbbe) és amint ez megvan beállítasz egy flag-et amit majd a főprogramban figyelsz. Ha a flag '1' akkor feldolgozod az adatot (és nullázod a flag-et!) esetleg vissza küldöd TX-en, mindezt század másodperc alatt megoldhatod, így az echo majdnem valósidőben megy vissza.
Így mindig csak a főprogramban hívogatod azt a függvényt így nem lesz összeakadás.
Ha azonnal kell visszaküldeni az echo-t akkor a RX megszakításban bele is töltöd a fogadott karaktert a TX regiszterbe és közben egy másolatot készítesz róla a főprogramod számára.
Remélem, hogy nincs semmilyen delay meghívás abban a debug függvényben.

Szervezd át az egészet.
- Vegyél fel egy körforgó puffert (amiben legalább egy távirat elfér) a vételnek és egyet az adásnak.
- A vételi megszakítás a hibátlanul vett karaktert írja be a vételi pufferbe, ha hiba volt, kezelje le.
- A főprogram bogarássza a vételi pufferből kiolvasott adatokat, ha értelmes táviratot talál dolgozza fel.
- A feldolgozás eredményét valamint a diagnosztikai üzenetet az adási pufferbe írja be. Engedélyezi az adási megszakítást. Ha nincs elég hely a pufferben, várakozik.
- Az adási megszakítási rutin az adási puffer soron következő adatát küldi el, ha nincs adat letiltja az adási megszakítást.

Működik több példányban.

Kössz a választ!

Eredetileg az Arduino IDE-vel kompatibilis mpIDE-vel próbálkoztam, csak a mostani verzió, ami már nem külön környezet, hanem beépül az Arduinoba nem akar normálisan működni. Így áttértem az MPLAB X-XC32 eszközökre (pillanatnyilag MPLAB x 3.10, XC1.40 és Kubuntu 14.04 LTS 64bit).
Arduinohoz rengeteg mindenhez lehet libraryt találni a neten, első körben a karakteres LCD kezelést módosítottam. Nem is kellett sokat reszelni rajta.

40 MHz-es a processzor (B-jelű), 8 MHz-es quarczal van "hajtva". A kapcsolás szinte minimális, a Digilent chipKIT DP32-es kártyájának egyszerűsített klónját raktam össze. Az oldal tetejéhez közel ott a kapcsolási rajz, amit én is megépítettem. Az eredeti DP32-höz képest csak egy nyomógomb (a reseten kívül) és egy LED van rajta, a gomb a bootloader indításához kell, a LED meg szépen jelzi villogással a program feltöltés folyamatát. Csak kicseréltem a PIC-et PIC32MX170F256B-re, mert most nem kell az USB. PICkit3-am van.

A "#define GetSystemClock()" mibenlétével tisztában vagyok, meg azzal is, hogy ez és az órajel konfigurálása két külön dolog. A kérdésem arra vonatkozott, hogy valahogy le lehet-e kérni a tényleges órajelet, vagy csak bízni kell abban, hogy jól sikerült a beállítás? A konkrét beállításokat a neten találtam, kifejezetten a kezdők számára volt megfogalmazva 40 MHz-es órajel beállítása.

Végül is most az I2C-EEPROM programmal kipróbáltam változtatásokat, működött 20 MHz-es periféria, és 100 kHz-es I2C frekvenciával is. De értem, hogy a periféria órajelet nem érdemes így felhúzni, hacsak kifejezetten nincs rá szükség.

Az angollal meg csak-csak elvacakolok, azért a gugli fordító sokat segít. A fordítási baromságokat azért többnyire a helyére tudom tenni.
Én úgy szoktam magam jellemezni, hogy "elavult tudású számítógépes" vagyok, valamikor ez volt a szakmám, hol programozás, hol üzemeltetés.

Pontosan...

Van a pic-eknek két külön "programozása". Az egyik a config flash, amit a project forrásban pragmák formájában látsz (a kimeneti hex-ben ugyan úgy flash programozási értékek specifikus memória területre). Azoknak a hatása hardver környezetet állít be. Az órajel beállításához azt kell rendbe szedni. Ha az megvan, utána - ahogy írtad - megbízol benne, hogy az órajeled akkora, amekkorára beállítottad.

Ez lesz, köszönöm!
Más helyen használtam már ilyesmit, a webszerverre küldendő adatcsomagokat pufferolom hasonló módon, hogy ha épp nincs mobilnet akkor ne vesszen el a csomag. Mondjuk én gyűrűs buffernek hívom.

Üdv!
Már több napja görcsölök ezzel a fránya friend-del, már ezer példát megnéztem, de nem sikerül rájönnöm, hol hibázok. A kérdés az lenne, hogy az alábbiakban összelapátolt kis példában hogy a rákban tudom meghívni a "kettes" objektummal az "egy" class "sete" függvényét. A próbálkozásaimat kihagytam a mintából, mert egyik sem vált be. Egyáltalán jól raktam-e össze az osztályokat?
Az "igazi" programban az "egy" osztálynak lehetne több példánya is, illetve nem csak egy "ketto"-höz hasonló osztály lenne, amelyből hívnom kellene az "egy" bármelyik példányát.
(Remélem nem fogalmaztam túl pongyolán!)

A programomban, az adatmemóriában, függvényen kívül van definiálva pár tömböm melyek relatíve nagyok. Van kb három darab 1000 elemű, két 500 elemű, egy 200 elemű meg egy 50 elemű. Meg kellene növelnem a méretüket kb a másfél szeresükre. Muszáj, mert nagyon hosszú sztringeket kell feldolgozni. A probléma az, hogy ha átírom az elemszámaikat nagyobbra, akkor a program lefordul ugyan, de ha beégetem a PIC-be akkor elinduláskor a program eleje táján újraindul a PIC. Ha visszaírom a kisebb elemszámokat, úgy nem indul újra. Hogy lehet ez?

Egy kicsit bővebben, ha lehet? Valami egyszerűbb program részlet, pic típus, fordító?

dsPIC33EP512GP806 és XC16 fordító.
Közben egy csomót agyaltam rajta meg kísérletezgettem és arra jutottam hogy a probléma oka a következő: Az adatmemória 49% foglaltságú az MPLABX szerint, de ez ugyebár csak a függvényeken kívüli, statikus változókat méri. A függvényeken belüli helyi változókat nyilvánvalóan nem. Akkor indul újra a PIC, ha belép egy olyan függvénybe amelyben egy relatíve nagy, mondjuk 1000 elemű char tömb van deklarálva. Azt gondolom, hogy egy ilyen függvénybe belépve megpróbálja lefoglalni magának a helyi változókat, de azok túlmutatnak a mikrovezérlő adatmemóriájának méretén és ez okozza az újraindulást. Addig kísérletezgettem tegnap, míg sikerült is ezt reprodukálnom: egy függvényben le van foglalva egy 1000 elemű char tömb, ha ebbe belép a PIC akkor újraindul. Biztos hogy a belépés pillanatában indul újra, ellenőriztem. Ha a tömb elemszámát átírom 300-ra, akkor rendesen meghívódik a függvény és végre is hajtódik az egész, nincs újraindulás. Visszaírva 1000-re ismét újraindul.

Mondjuk a PIC amit használok annak az adatmemóriája 52kB, melynek az MPLABX szerint a 49%-át a statikus változók foglalják el. Erősen kétlem, hogy az egymásból meghívogatott függvényeim összesen többet foglalnának le dinamikusan mint a maradék 51%, azaz kb 26kB! Az rengeteg! De a mellékelt ábra mégis ezt mutatja.
Azt gondolnám, hogy a fordító ugyebár tudja hogy mely függvényből mely függvények vannak meghívva, ezt fel tudná térképezni. Azt is tudja hogy mely függvényben mekkora dinamikus változók vannak foglalva, így kimatekolhatná a legrosszabb esetet amikor a legtöbb, nagy méretű helyi változót lefoglaló függvények vannak egymásból meghívogatva. Szóval igazán szólhatna nekem hogy túl van foglalva a memória!
Arra is gondoltam hogy kipakolászom a programom összes változóját függvényen kívülre, így kiderülne hogy valóban ez okozza a problémát, mert így már beleszámolná a memóriafoglaltságba a fordító az összes változómat. De hát nem akarom elcseszni a programot, szerintem annál jobb minél kevesebb statikus és főleg minél kevesebb globális változó van.

Most nem tudom megnézni, de Project properties / xc16-gcc Memory model -ben van valami large memory beállítás, meg valami pipadoboz a nagy tömböknek talán? Az nem lehet?

Stack overflow?

Nem kell kitenned, elég ha static-ot elé írod, így a .data szekcióba kerül, nem a stcack-be híváskor. Az első hozzászólásban még azt írtad, hogy külső a tömb.

Nem tudom, hogy mire is használod azt a nagy tömböt de szerintem praktikusabb lenne pointer-t használni, így nem kell függvényen belül is lefoglalni egy nagy tömböt...

Én a friend fv. csak private/protected tagok láthatóságára szoktam használni.

És ha jól értem a ccpreference-en is ez van írva.



Mondtad, hogy nem teljesen vagy otthon az angolba nagyjából:
A friend deklaráció a class "testén" belül jelenik meg ami hozzáférést ad egy külső függvény vagy másik class hozzáfér azon class tagjaihoz ahol a friend deklaráció megjelenik.
Ez nem arra jó, hogy a ketto példánya meghívja az egy függvényét, hanem hogy hozzáférjen.

Tehát amit te akarsz csinálni azt nem a friend-el kell.

Ami neked kell azt 2 vagy 3 féle-képpen meg lehet írni talán ez a legegyszerűbb.
Öröklés (inheritance)


Na most amikor példányosítod a ketto-t akkor létrejön vele az egy is (ketto = derived class, származtatott osztály, egy = base class, alap osztály).
ha a public helyett private-t írsz (ez az alapértelmezett ha nem írsz semmit private lesz az egy) akkor azok a függvények/változók csak a származtatott osztály függvényeinek érhetőek el.

Remélem érthető amit írtam, ha kicsit fel tudsz rakni valóságosabb példát akkor elmagyarázom.

Két lejátszási lista amiben magyarul beszélnek a c++-ról gépes környezetben, mivel az XC32 standard g++ al fordít így ami a codeblock-s ban megy annak a PIC-en is mennie kell.
Kezdő, Haladó

Először is van egy struktúrám amelyben adatokat tárolok, összesen kb 60 bájtnyit. Ebből a struktúrából van létrehozva egy 200 elemű FIFO tömb, ebben pufferolja a PIC a küldendő adatokat ha épp nincs mobilnet. Na ez a FIFO már kb 12kB.
Négy UART-ot használok, mindegyiknél van egy-egy vételi puffer melyek közül némelyik 500 elemű, némelyik 1000. És mindegyiknél dupla pufferelés van, a sikeres és befejeződött vétel eredménye egy másik pufferba kerül hogy a következő vétel ne tudja felülírni. A WIFI modulnál ezen felül van egy 2048 elemű char tömb is az érkezett IPD üzenetek tárolására.

Van két 500 elemű amelyeket arra használok hogy sprintf()-el, strcat()-al és hasonlókkal szövegeket hozzak létre, illetve ezeket átalakítsam pl linkké. (A szóközből %20 lesz stb…). A mikrovezérlő a GSM modullal meg a WIFI modullal e-maileket is küld, viszont az e-mail megszületésének pillanatában lehet hogy épp nincs mobilnet ezért van egy 1000 elemű tömb amely egy szem e-mail tárolására szolgál. Van egy 200 elemű amely hasonlóképp egy SMS tárolására használatos. (A problémám egyébként pont az hogy ennek a méretét szeretném 200-ról 500-ra megnövelni hogy három egybefűzött SMS is beleférjen.)
Van még kb 100-200 bájtnyi egyéb kisebb, nem sztring tárolására használatos statikus változó is.

Lokális változóból jó kérdés hogy mennyi van. Azért nem tudok itt minden esetben pointereket használni, mert például a soros porton üzenetet kiküldő függvényem is formázott sztringet fogad bemeneti paramétereként és a függvényen belül a vsprintf() által lesz belőle elkészítve a sztring egy (1000 elemű) lokális változóban. Ugyan ez van az AT-parancsokat küldő függvényeimben is.

Aztán vannak olyan függvények amely TCP/IP kapcsolatot használva, mondjuk WIFI-n lekérnek egy weboldalt (pontosabban csak a headerjét) és annak headerjéből kimazsolázzák hogy mennyi az idő és év, hónap, nap, óra stb.-vel térnek vissza. Na itt a függvényen belül kell egy lokális tömb amelyben a TCP lekérésre kapott választ eltárolom hogy ki tudjam olvasni belőle az adatokat. Hasonló függvény van arra a célra hogy megtudjam, van-e épp internet elérés vagy sem. Vagy hogy egy adott szerver elérhető-e épp. Egy ehhez hasonló függvény a GSM modulnál USD kódokkal lekérdezi a szolgáltatótól hogy mennyi az egyenlege a SIM-kártyának. Az ilyesmi függvényeknél mindig kell egy 500-1000 elemű lokális változó.

Mondjuk ezek szinte soha nincsenek egymásból meghívogatva hogy egyszerre foglalják le a memóriát.

A code model és a data model "Large"-ra van állítva.

Köszönöm a válaszod, legalább most már tudom, hogy friend nem megoldás számomra. Amit adsz, öröklődés példát, azt ismerem. Ezzel viszont az a problémám, hogy az ős változói is megismétlődnek példányonként, ami nekem jelen esetben nem ok. Pillanatnyilag virtual class látszik a megoldás lenni, a fentiekhez hasonló "bonyolultságú" példával már sikerült olyanra csinálni, amilyent szeretnék.
Hogy egy kicsit konkrétabb legyen mire kell, I2C-vel ismerkedem most, és az egyes csatornákra vonatkozó változók csak egy példányban kellenek, akárhány I2C eszközt is használok. Viszont azért szeretném az I2C kezelést is objektumosra, mert nem csak egy I2C vonal van, és úgy gondolom, egyszerűbb osztállyal, példányokkal megoldani mint sima C függvényekkel.
Kössz a linkeket, megnézem. Amúgy találtam elég jó magyar nyelvű cpp leírásokat is, de én régen is (korábban írtam, elavult tudású nyugdíjas számítógépes vagyok, több programnyelvet is használtam anno) könnyebben indultam el egy működő példából, a dokumentáció akkor segített, amikor az alap már megvolt egy-két jó példából.

Ez a periféria hordozhatóság is több módon megoldható.
pár példa:


persze lehet másképp is csak mutatni szerettem volna pár példát.

Szerencsére van a panelon egy 128kB-os SRAM, a FIFO-kat kipakolom bele. Így kb 17kb memória felszabadul a PIC-ben.

Nézd meg a fordításkor keletkező map állományt. Benne megtalálhatod, mit hova helyezett a linker.

Láttam egy csomó gyári Microchipes fejlesztőpanelon hogy a PICkit3-at ráintegrálják a panelra, így csak egy USB kábelt kell rádugni a mikrovezérlő programozásához. Azt gondolnám hogy ez az "on board PICkit3" egy open source dolog, de nem igazán találok róla semmilyen információt. Rosszul keresek, vagy ez tényleg titok?

A pickit 3 open source, és nincsen róla semmi egyebet tudni, mint ami a doksijában is benne van. Kapcsrajz, firmware, mi egyéb kell még?

sziasztok
megépítettem a következő linken levő kapcsolást.https://www.hobbielektronika.hu/cikkek/nullarol_a_robotokig_-_pic_m...l?pg=4" target="_blank" >Bővebben: https://www.hobbielektronika.hu/cikkek/nullarol_a_robotok...l?pg=4

A probléma az vele,hogy az icét beleteszem és a hex filét áttnyomom égetésre ,a hexbe tesz mégegy sort.Ez miért van? Mellékelem a képet is.

Bocs ,ez a jó link.https://www.hobbielektronika.hu/cikkek/nullarol_a_robotokig_-_pic_m...l?pg=4" target="_blank" >Bővebben: https://www.hobbielektronika.hu/cikkek/nullarol_a_robotok...l?pg=4

Ezt a programot használtam.

Az ok az idő. A cikk írása óta több verzió jelent meg a programból és több olyan kontroller típus is megjelent, aminek a memória címzésénél nem elég a 16 bit. Intel Hex formátum

Akkor ez az égető nem jó hozzá? És a pic se fog működni amit égettem vele?

Van egy szörnyű gyanúm, hogy összetévesztetted a PICkit2-vel, ami tényleg nyíltforrású.

Jó lesz hozzá, a 16F88x -hez nem kell a címkiegészítés.