Nem másoltam be az egész kódot, csak azt az ágat ami az
if (UART1_Data_Ready())
és azon belül. Szóval hagyd meg az eredeti részt, a while-t, meg mindent, csak az általam módosított részt írd felül azzal amit az előzőben csatoltam.
Remélem valamennyire érthető volt...

Igen , így csináltam.

Ha jól látom, {} jelekkel összefogtad ezt a részt és ennyit módosítottál.

Másold inkább be az egészet, mert vagy három másikon átsiklottál

pl. if (UART1_Data_Ready())
helyett az volt, hogy
if (UART1_Data_Ready() == 1)
Ami nagyon nem mindegy, mert az eredeti vélhetően azt jelenti, hogy ha az UART-on egy bájt adat jött, a módosított pedig azt, hogy az UART-on jött adat (bármennyi).
Ha egyszer az UART pufferbe fel tud gyűlni 2 bájt adat, az eredeti feltétel soha többet nem fog teljesülni.

A WatchDog ki van kapcsolva? Mi a helyzet a Brown-Out Reset -tel? Akkor írja ki a "PIC Start" -ot, amikor lecsökken valamitől a tápfeszültség?

A memset(puffer, 0, PUFF_SIZE); is elég időrabló lehet, elég helyette a pp = 0; puffer[0] = 0;

Rendben

Megnézem ezeket is, rámérek a tápra is

Így is bugos. Mellékeltem egy képet. Adtam tápot a cuccnak és küldtem neki a parancsokat.

A kék színnel én küldtem , zöld a kapott adat.

A végén kezdődik az érdekesség, 2 kikapcs jön 1 off szóra.

Hali!
Nem rágtam át magam rajta, De én a kommunikációt mindig egy kitüntetett karakterrel kezdem, ami a szükséges cuccokat ekkor alaphelyzetbe állítja.
Ha olvashatóan akarom akkor pl kettőspont...
De lehet ragozni, a kettőspont után jön a küldött szöveg hossza, az utolsó karakter után meg egy egyszerű összeadással képzett "checksum"...
Ez nálam jól működik évek óta, az esetleges hibás átvitel automatikusan kidobásra kerül.

Ez nem direktben a csatolt kóddal függ össze.
Lehet kétszeresen deklarált változó, lehet túlcsordulás, lehet az UART rutin hibája is.
A kimenet azonos azzal, mintha a kiemelt kódrész ismételten lefutna.


Viszont a puffer ki van nullázva, a pp változó szintén.
Okozhatná pl. ha a puffer változó 2x lenne deklarálva, vagy az UART rutin ismételten kiadná a korábban beszedett bájtokat, vagy egy szimpla túlcsordulás amitől behülyül az egész. Ezen a ponton némi tapasztalatot igényelne a hibakeresés, debugger használatát, ilyesmit.

Egyébként pont 30 fogadott karakter után akadt ki.
Reset után ha ugyanezt a tesztet ismétled, megint ugyanennyi adattól akad ki?
ps.: az UART.c-t csatolhatnád

Nem ugyanennyitől. Ez változó. Azt hol találom?

Ez a teljes kód:


Ezt lefuttatva , ilyen lesz a kimenet. Mellékeltem képet.

brown - out engedélyezve van , watchdog pedig tiltva.

Az MPLAB Snap sokkal jobb debugolásra, mint a PICkit3?

Sziasztok!
Az alábbi témában szeretném a segítségeteket kérni:
Az AD bemeneten mért 0-255 közötti értékkel szeretnék arányosan frekvenciát előállítani,
a bemeneti jel függvényében pl.:LED-et villogtatni.
Két megoldás jutott az eszembe:
1, IF szerkezet, de ez túl hosszú lenne, mert minden értékre meg kellene írni a feltételt
2, az AD értéket átadom a TIMER-nek, azaz a TIMER kezdeti értéke a bemeneti jel aktuális értéke.
Esetleg más megoldás? Vélemény?
ASM ötlet érdekelne.
Üdv.
VFR72

Pickit3 -al hogy debugolsz?

A megszakításban a timer lefutásakor váltasz állapotot a LED-nél és utána azonnal újra feltöltöd egy ideiglenes változóval. Ezt az ideiglenes változót töltöd fel a főprogramban kiolvasott AD-vel.
De ezt is lehet megszakításban, ekkor az "AD konverzió lefutott" megszakításakor kiolvasod az értéket, átírod az ideiglenes változóba, aztán új AD konverziót indítasz.

Lehet, hogy bizonyos típusoknál gyorsabb, de más típusokat egyáltalán nem fog kezelni. A Snap nem tud 5V -nál nagyobb feszültséget előállítani a Vpp számára.

Kiválasztod nyomkövetőnek az Mplab / MpLabX felületen. Újrafordítod a kódot "Debug" módban. Máris indíthatod a nyomkövetést.

Nem jó a kódod. Írtam neked egyet, ami akár jó is lehetett volna. Nem próbáltad le?
Minek töröm magam?


Amikor a fenti kód lefut, a pufferben az "off" sztring van.
A kód lefutása után ".ff" lesz a pufferben; a '.' helyére 0x00-t képzelj, szándékosan nem használtam C szintaktikát.
Ezután bejön az "on"-ból az első karakter. Mi lesz a pufferben? "off". Meg is találja majd a program.
Utolsó hozzászólásom volt a témához.

Én már teljesen nem értek semmit. Nem látom mi a különbség a te általad írt kód és a között , amit bemásoltam , leszámítva, hogy behelyettesítettem változóra az on és off szót.

Illetve amit hp41C mondott, hogy a pp = 0; puffer[0] = 0; legyen a memset helyett.

+ ezt a részt beletettem egy {} blokkba :

Mindegyik if ágban benne van a :



Ez kinullázza nem? Tényleg nem értem .

A szokásos mérnöki válasszal élnék a kérdésedre: Attól függ.

- Snap nem ad tápot, ha ez nem okoz problémát akkor pipa
- Ha 8 bithez akarod használni és 5V-os controller-el akkor meg kell nézni támogatja, de esélyes hogy nem fogod tudni a többséget programozni
- Viszont ha 3.3V-on dolgozol és 16/32 bites controller-ekhez használnád akkor megéri.
- 8 bithez ha ilyen 16-64k flash 4-32k RAM-ban mozogsz nem is feltétlen van értelme, mert adott esetben ki sem tudod használni emlékem szerint a PIC16F15xx-es controller-ek között volt olyan aminél nem tudtam hardware-s breakpointot be rakni.

A PICkit4 és a Snap a power és VPP gent leszámítva kb azonos->

A PICkit4 egy két bug-ot leszámítva nekem 32 biten (ott a 2MB-os flash-el és runtime breakpoint igénnyel szóba se jöhet a PICkit3) jobban szerepelt mint az ICD3 (amiben egy 16 bites PIC és egy FPGA megy a PIKkit4-ben nincs FPGA!!).
Szóval, ha combosabb controller-t programoznál akkor mindenképp a Snap.

Nem tudom milyen szinten vagy jártas a témában (kezdő,haladó,stb..), de ha kezdésnél vagy és mondjuk dev boardot akarsz használni és nem 8 biten akarsz indulni akkor a Curiosity board-ok egész jók viszont az onboard debugger egy rakás sz... (a schematic-on PK3-nak tűnik, de nem üti azt a szintet-se).
De ha mondjuk be ruházol egy board-ra és veszel mellé egy Snap-et akkor igazándiből semmivel nem kell törődnöd egyszerű blink, ADC, UART példák vannak és már tudod is csinálni (és mégsem arduino ).

Amire viszont figyelni kell:
Sem a PICkit3 sem a PICkit4 és a Snap-en sincsen komoly ki és bement védelem (valami van emlékeim szerint polyfuse 50mA-rel adott esetben semmit nem ér, tudom tapasztaltam)
Ha ezek fontosak lehetnek akkor nincs mit tenni ICD3/ICD4/Real ICE - ezekben már komoly védelem van.

Szerintem ezzel(is) lehet a gond:

Mármost ha a végét nézzük,ami legyen 19,látható,hogy belép,és az utolsó helyre 19(0-19) beírja a vett adatot,utána léptet,de a gond,hogy a nem létező 20. helyet kinullázza,ami érdekes dolgokat tud okozni
Javaslom a char puffer[PUFF_SIZE+1]; -et,vagy még van pár lehetőség.
Ha így sem jó,akkor majd még jobban átnézzük .

Ha a pufferben (ahogy Te írtad) ".ff" van, akkor a bejövő "o" beleíródik a 0. pozícióba (p értéke 0) és a következő karaktert a következő sor null karakterre írja. Azaz a pufferben "o.f" lesz, ami stringként kezelve egyetlen "o" karakter hosszú string.

Igazad van. Ez van amikor többen írnak egy kódot

Ez így felejtős, nekem kell a Vpp.

És is most vagyok túl egy kellemes hibakeresésen, szintén UART, de PIC24F.

Enabling the UART The UART module is enabled by setting the UARTEN (UxMODE<15>) bit and UTXEN (UxSTA<10>) bit. Once enabled, the UxTX and UxRX pins are configured as an output and an input, respectively, overriding the TRIS and PORT register bit settings for the corresponding I/O port pins. The UxTX pin is at logic 1 when no transmission is taking place.

Igen, beállítja a TRIS-t, a TX működik is, csak az RX nem, mert az alapból A/D és azt viszont nem írja felül. És erről az egész UART fejezetben nem tesz említést. Van egy szép 6 lépéses procedúra, hogyan kell konfigurálni a TX részt, van egy 5 lépéses procedúra az RX konfigurálásról, arról egy szót sem szólnak, hogy ja, az A/D-t kapcsold ki. Lehet mondani, hogy ez triviális, de hát számomra az tűnt triviálisnak, hogy ha bekapcsolom az UART-ot, akkor megfelelően beállítja az RX-t, ahogy azt a TX-el meg is tette.

Amúgy tetszik a 24-es család, bő 10+ évig PIC18-at programoztam, csak az fájdalmas, hogy túl sok a beállítási lehetőség, aztán ha valami nem jó, a hibakeresés is nehezebb.

Már egy párszor javasoltam, hogy a következő mondat kerüljön be a fenti sárga részbe, mert visszatérő téma:
- Ha analóg bemenetként is használható lábat digitális lábként szeretnéd használni, feltétlenül állítsd át digitálisra mert csak úgy fogod működésre bírni!

Később tudom csak ezt kipróbálni. Ezek szerint az egész puffert ki kellene üríteni. Én azt hittem , hogy a



Váltózók kinullázzák. De akkor csak a puffer tömb 0. elemét nullázom ki vele ha jól értem.

Bár ha ez így van , akkor az is egy megoldás lehet, ha csak ennyi lenne a hiba, hogy az összes elemét kinullázom sorban, vagy tévedek?

Igen a puffer[0] = 0; csak a 0. helyen lévőt nullázza ki.
Használhatod a memset-et is,de elég ide a kövi nullázása is,mert így is kizárja,hogy azonos legyen az előzőekkel,ahogy Hp41C is írta.Itt a gond az utolsó pp++ -nál van,mert kilép a tömbből,és az utána lévő címre ír be nullát.Javasolhatom:

Így meg nem lesz lezárva, ha pont az 1. sorra úgy jut el, hogy pp = PUFF_SIZE-1.

Már több napja megy itt a foltozgatás, amikor egy megszakításos, körforgós puffer -rell más rég működne...