Rendben megy köszi.

Üdvözletek!
Szeretnék kérni egy kis segítséget:
A csatolt programnak a következőt kellene csinálni:
megszakításból figyeli az uart1-et, ha 0xAA -jön, fogadja az érkező 5 byte-ot, begyüjti az RX_array tömbbe, mikor kész, a választ kiküldi TX-en.
Jelen állapotban, (kizárólag hibakeresés jelleggel) 3x van egymás után adatküldés: az első adatsorban a tömbbe gyűjtött adatokat kellene visszaküldje. Itt a hiba az, hogy a legelső vett byte helyett az utolsót küldi az első és az utolsó helyen is.
A második adatsor, amikor nem tömbből olvasom ki a küldendő értékeket, hanem direkt adom meg minden küldésnél az JÓ.
A harmadik adatsor, ami a sajátkezűleg , programból feltöltött adatokat kellene küldje, az viszont a vett adatokat küldi ki (kivétel az elején látható 0xC8, azt fogalmam nincs, honnan szedi egyáltalán).
csatoltam a C & ASM kódot és képet az adatfolyamról.A z alsó a vett adat. A problémám beírtam a flowcode topicba is, de sajna szerda óta nem jött válasz és tovább kellene lépnem.

Csak hirtelen amit látok.
Nem kellene nővelned a tömb indexét?

Kellene valami ami FCV_RX_ARRAY[i++] tömb indexét implementálja.
Mert így minden adat ugyan oda kerül.

ui: közben látom, hogy lejjebb egy feltételben növeled, és vizsgálod..
Jó bonyolult és feleslegesen sok kódot írtál

Nem én voltam...
Viccet félretéve, ezért írtam korábban, hogy a Flowcode nem szívbajos a helyfoglalást illetően...
Példaképp csatolok a 6 elemből álló adatsor küldését, ahogy én látom a Flowcode-ban:

Te nem tudod megírni a kódot?
Túl sok a felesleges sallang.
Nem tudom, de szerintem az, hogy az interuptban is függvényeket vagy makrókat hív meg, tök értelmetlen.
Egyszerűen lehetne a vett adatokat közvetlen az interruptban kezelni és leállítani a kommunikációt, ha az nem kell.
Majd a vett értékeket megvizsgálni és visszaküldeni.
A megszakításokat hardveresen kezelni, adatok fogadása, hiba kezelése megvan kb 10sorból.
Aztán egyéb vizsgálat és visszaküldés szintén kb 10sor, a beállítások meg szintén kb 10sor.
Tehát összességében mindennel együtt kb 30sorból meg tudod valósítani, lehet kicsit több, de nem ennyi amennyit ez a program generál.
Simán bele lehet zavarodni.

Amúgy azt kellene ellenőrizned, hogy a fogadott adatok meg egyeznek e azzal amit vársz, ha igen akkor a küldés része rendben van.
Aztán megvizsgálni egy kijelzőn vagy debugból, hogy a vett adat le e tárolódott, ha nem, ezt meg kell vizsgálni miért nem azt tárolódik le, aztán jöhet a visszaküldés,
Véleményem szerint a letárolásnál lehet valami bibi, nem vagy szinkronban.
Hardveresen kezeled a megszakítást?

Hardveresnél érdemes az összes beérkező adat egyből letárolni, feltételek nélkül, mert gyakorlatilag elcsúszik a szinkron, ha késlelteted a lefutást.

Üdv! Mit takar a te értelmezésedben a hardveres megszakításkezelés?

Azt, hogy nem befolyásolod az adat fogadást.
Amikor jön adat a hardver automatikusan megszakításba lép és fogadja ameddig jön, aztán ha vége az adatfolyamnak visszatér a munkájához.
Gyakorlatilag ennyi a lényeg.

Ez viszont most nem működik. Ugyanis 80-100 byte adatot kell fogadnom, 2400 baudon (majd). Az azért nem 1 ms... muszály közben mást is csinálnia a programnak, úgyhogy ki kell jönnöm 2 RxInt között.
Csak Flowcodban tudom megírni a progit, C betéteket csak akkor használok, ha muszály (tehát amit nem támogat a progi, pl lcd kezelés (nem intelligens lcd) vagy regiszterek kezelése, etc). Debug helyet én azt szoktam , hogy soroson küldözgetem ki a nekem érdekes változókat, ez eddig működött is. Most először kellene adatot gyűjtenem soros portról tömbbe, és ez valamiért nem jön össze. Ha egy-egy bejövő adatok kell visszaküldeni (tehát nem tömbben, hanem byte változóban letárolva), az eddig gond nélkül ment, de most valamiért nem a begyűjtött adatokat küldi, hanem egy másik tömbből olvas. Ha találnátok valami nyomot a c kódban amin elindulhatnék az nagy segítség lenne, mert próbáltam már teljesen más névre keresztelni a tömböket ,de az sem segített.
Egyébként nincs nagy baj a Flowcoddal (tudom ez itt most olyan mintha a zsinagógában jehovát hirdetném), vannak hibái, de használható. Az tény, hogy kb 2-3x akkora pic kell egy egy progihoz, mintha pl. C-ben lenne megírva.Viszont nélküle (nekem) nem menne...

Állítsd feljebb az átviteli sebességet.
Amúgy meg tök mindegy mennyi byte-ot küldesz, addig a programod megszakításban van ameddig fogad, majd ha végez visszatár a feladatához..
Ha jó a kód ennek nem szabad gondot okoznia..

A FLOWCODE-nak nem ismerem a képességeit, de a PIC-nek van legalább 1 átmeneti tárja a soros adat fogadásakor, azaz miközben érkezik az új adat, addig ő ráér elmenteni az előzőleg kapott adatot egy tárba megszakítással ( célszerűen indirekt eléréssel!, 2400 Bd sebességnél sokkal kevesebb, mint 1 bitidő alatt kényelmesen megcsinálja !) és csak a mentést végzi a megszakításban, nem kell sokáig várakoznia ! Ha bejött az összes adat, akkor azt csinálsz vele, amit akarsz !
Azt, hogy ezt hogy tudod a FLOWCODE-nak elmagyarázni, nem tudom, de a PIC tudja ( magát a módszert !) !

És mikrovezérlőn hogyan máshogyan lehetne kezelni? Legalábbis nem értem a kérdést

Ahhoz, hogy USART-on fogadj adatokat, nem lenne szükség a megszakításra.
De a megszakítás automatizálhatja a folyamatot és sokkal gyorsabb.
Eközben a programmal azt csinálsz amit akarsz, de ha jön egy kérelem, akkor a PIC kiugrik, elvégzi egy szempillantás alatt és a főprogram dolgozhat tovább.
Ha te kezeled programból az érkező adatokat sokkal lassabb és a főprogramot terheled le.
(ezzel szívtam nem olyan rég én is és pár lappal előrébb oda vissza ki is tárgyaltuk, talán még program kódot is találsz)
De most már én nem értem, hogy te miért nem érted.
Most vagy csak kötözködsz, vagy komolyan érdekel mi hogyan van és komolyan nem érted, hogy mire írtam a fentieket.
A hardveres kezelésnél azt értem, hogy a PIC ha akarod hanem, automatikusan megszakításba ugrik ha érkezik USART-on adat.
Ez független a szoftveres résztől fut majd le, és persze elég gyorsan. Nyilván te állítod be ezt is, de a hardver kezeli.
A szoftveres résszel (main() szekcióban) eközben meg utána is azt csinálsz amit csak akarsz..
Ez a lényeg..

Ez esetben nem a megszakítást kezeled hardveresen -> hanem az adatfolyamot kezeled megszakításból. Csupán arra próbáltam rávilágítani, hogy az általaf feltett kérdésre nem lehetett volna a jelen téma kapcsán értelmes választ adni. Nem kötözködöm, csak egy megjegyzés.

sziasztok ESP8266-al szeretnék kommunikálni! telefonnal sikerült is a pic kommunikál vele, a következő lépés lenne a pc-s vezérlé, de egyszerűen nem tudok hol hozzá kezdeni hogy milyen programmal milyen felülettel tudnék valami egyszerű kis progit össze hozni.... pl egy gomb ami egy egyest küld udpn egy bizonyos ipnek egy bizonyos porton ami a kódban van leírva.... delphire gondoltam hogy abban lenne egyszerű megírni... van ötletetek?

Javaslom a Visual Studio-t. Könnyen össze lehet dobni vele bármit, és támogat egynéhány programozási nyelvet. (Basic, C++, C#, F#, Python, Java)

Ha telefonról már sikerül - igazából az a bonyolultabb - a pc-s már gyerekjáték lesz. Csak végig kellene futni a checklisten:
-Az egy wifi cucc, kell egy wifi router a közelben
-a wifi routeren tudnia kell csatlakoznia az eszköznek (rálátás, távolság)
-értened kell a hálózati csomag irányítás elveit, ha ez nem zöld pipa, szólj, és mellékelünk olvasni valót
-az eszközhöz van külön sw stack, abban kell tudnod beállítani, amire szükséged van
-channel, jelszó, kódolás, talán mac filter, ami van a routeren ott is kezelned kell
-az eszköznek kell IP cím a wifi szegmensen, dhcp, vagy static dhcp
-ha dhcp, az eszköz keresi meg a pc-det, és a pc-nek kell static IP, ami lehet azon a hálózati szegmensn, vagy fölötte lévőn
-ha static dhcp, a pc-d keresi az eszközt, a wifi routeren az eszköz mac address alapján kell beállítanod a static ip-t, és ha a pc-d nem azon a szegmensen van, esetleg port forward is kelleni fog a routeren (igény szerint)
-ha a fentiek okés, és megvan az eszköz IP címe, azt a routeren mint dhcp klienst ellenőrizheted is a router admin felületén keresztül
-bármilyen programnyelv jó a pc-n, ami képes hálózati csomagot küldeni, és fogadni, immáron IP címeid vannak kapcsolatban, tudod a mac addresseket is, portok között udp-vel azt kommunikálsz, amit csak akarsz

Figyelmeztetés:
-Mielőtt csinálsz valamit, amit örök időkre hagysz ott másoknak, nem baj, ha tudod, a wifi csatorna mindenkié, és ha valamelyik eszköz "rendetlenkedik" bele, azt a többi rovására is teszi, szóval teszteld le alaposan a kütyüdet, hogy miközben folyamatosan működik, ki/bekapcsolgatod, a többi wifi eszköz kommunikációja zavartalan tud-e maradni

Üdvözlet.

A következő programmal kapcsolaban szeretném kérni segítséget.
Nem boldogulok a hex-ba való lefordításával. Megkérhetnék-e esetleg valakit, hogy lefordítsa nekem.
Egyébként egy peltier modul szabályozása lenne. Alul a kapcsolást is mellékelem.





Nagyon szépen köszönöm előre is!

Gyors volt

A kapcs rajzon nincsenek ott a nyomógombok az ra 4 / 5 lábakon. A programban már ott a supportjuk, de ha lebegve hagyod a lábakat, akkor ennél a pic-nél folyamatosan magasat fog érzékelni, ergo minden körben rá fog futni hogy egyet fel + várakozás, utána egyet le + várakozás részekre. Szerintem így ne hagyd, mert nem fog tetszeni.

Edit:

Nincs bekötve a reset láb se, az pláne ne maradjon úgy! Kondenzátor + ellenállás.

szia! koszi a segitseget!
a halozati csomag iranyitassal lehetseges hogy bajban leszek, de majd neten utanna nezek, vagy ha dobsz egy pdfet amiben jol levan irva azt megkoszonom
igazabol a pc-s progival vagyok bajban hogy abszolut nem tudok hozza kezdeni... delphiben probalkoztam de feladtam, valami mas kene

Elindulni azért nem tudsz, mert arról az oldalról nem lehet elindulni.

Magát az eszközt be tudod-e úgy állítani, hogy megjelenjen a wifi admin felületén, hogy van az az eszközöd, ami csatlakozott? Ahhoz tartozik egy stack, aminek futnia kell. Azzal az oldallal maximálisan képben vagy?

Rendben. Akkor ha jól értem akkor vmi hasonló kell mint a lenti képeken.

Van erre egy külön témakör ESP8266 wifi modul, ott kellene folytatni. A legegyszerűbb PC-s felület hozzá a webböngésző.

Egyébként Itt található egy kitűnő leírás (mely feltétezi, hogy a NodeMCU firmware van az ESP8266 modulra töltve.

Oh bakker, most nézem csak nagyítóval a képen, az ra5 egyben a reset láb is. Azt nem húzogathatod le kapcsolóval.

A programban ezt a sort:


írd át erre:


és a "le" gombot az ra3-ra kösd. De amúgy a kapcsolástechnika stimmel. Az ra5 lábat pedig húzd fel +5v-ra egy 10k-s ellenállással, és egy 10 nanos kondival a GND felé. Bár a pic16-ot nem tudom, mennyire kényes ebből a szempontból, azzal majd a többiek mindjárt kisegítenek. Mindenesetre ezt a pic-et a saját helyében már egyébként sem programozhatod ebben a kapcsolástechnikában, mert nagyon körbe van pakolva amúgy is. Programozáshoz máshová kell átraknod.

Ennél a picnél, MCLRE_OFF beállítás mellett, a reset láb sima bemenet. Nem kell se felhúzni, se átírni. Használható a gombhoz nyugodtan.

Köszönöm. Még az adc moduljához had kérjek egy tippet. Egyszerűen csak lesem azt a fejezetet az adatlapján, és nem találom az adc kikapcsolását. Persze az init résznél azokat a clear dolgokat sem értem, mert basic, és valószínűleg rendben van, mert eredetileg már működött, de többször ellenőrizni sosem árt. Hogyan kapcsol ki a 16-osokon az adc?

PIC válogatja, de nézd meg az ANSEL regisztereket.
Persze az is kérdéses melyik PIC-re gondolsz...

Köszönöm. Akkor ha jól értem maradhat az ra5-ön a LE gomb, a reset láb meg ugyan ez, de nem kell rá pluszban kötni semmit se.

Általában az ADCON0.ADON bit a főkapcsoló ( 0 bit). Viszont a 16F628-ban nincs ADC. De sebaj, I2C sincs.
A Clear a portokat teszi nullába, ha minden igaz. Szoftveres I2C-t használ és az a fő baj vele, hogy nem tudom ki tudja majd lefordítani a programot, mert úgy nézem, Oshon Pic Simulator-ban írták és kérdéses, hogy van-e itt valakinek olyan. (Nekem is csak a demo van meg, ami ehhez kevés.)

Üdv!

Biztos, hogy nem Oshonsoft PIC BASIC! Szerintem a Proton BASIC-re hajaz.
Oshonsoft BASIC lefordításban és kérdésekben állok rendelkezésetekre.

Üdv!

Akkor ha lehet én kérném a fordítását mert nekem sehogy se sikerült, bármivel is próbálkozok.