Ugyan azon gyártó, ugyan azon típusszámához kétféle, ellentmondó adatlap található...
Az egyik a mellékletben, a másik itt.

A Feher koromlakk csodakra kepes.

Egy kicsit casual, de kreatívnak hangzik Ha lekened körömlakkal a ledeket, az normálisan egybemossa a 3 külön led fényét?

Probald ki. 2 sima RGB led, lakkal es nelkule, majd nezzed. A simanal messzirol is csak a kulon szinek latszanak, a masiknal a kevert szinek.

Jó ötlet, kipróbálom
Én eddig vagy síkba köszörültem, vagy nyomtam rá melegragasztót, így mattítottam.

Próbáltál olyasmit is, hogy valami nagyon finom szemes smirglivel mattra csiszolni a felületét? A körömlakk úgy hangzik, mint ami fényerőt is csökkent, és cserébe melegíti a ledet

Azt hol kell beállítani,hogy ne ugráljon az ADRESH alsó 4 bitje plusz az ADRESL?Csak az ADRESH felső bitjeit látom fixen,azt is csak a legfelső bit híján.Hiába tekerem fel a potit a maxra,az MSB nem áll be.Megmértem a lábon,és csak 1,5V-ig megy fel.

Az utolsó bitet el szokták hagyni, és több mérés eredményét kell átlagolni.
De itt is le van írva több hozzászólásban is néhány módszer.

Tudnátok nekem abban segíteni, hogy MikroC alatt hogy tudok elemet törölni egy tömből? Van egy tömböm amit a programból alapból mondjuk 10 elemesre készítek. Ennek a tömbnek az egyes elemei tartalmazzák egy kijelzőre kiírt karaktersorozatok ascii kódját. De a kiírt szöveg (karakter szám) nem állandó lenne, hanem változna, attól függően, hogy a bluetooth modulon keresztül érkező "karakterlánc" mit tartalmazna... Jönne pl. egy 5 karakteres szó, akkor a 6.-10. karakterekíg üres lenne, ami látszódna a kijelzőn... Hogy tudom ezt orvosolni? Másik kérdésem, hogy soros kommunikációnál, ha minden beérkező bájtot beteszek egy tömb soron következő elemébe, honnan tudom, hogy melyik az utolsó bájtom? Számolnom kell? Mert mondjuk, a sizeof paranccsal lekérhető a tömb mérete, de az a üres karakterek helyét is tartalmazza, nem?

Ott valami nagy gaz lehet. Csinaltam mar egy par (100) analog feldolgozast de az AD legalso bitje is stabil szokott lenni. 12 bitesnel sem volt semmi gond. Merleg elektronika stabil mintha odarajzolak volna a szamokat. Egy egyszeru trukk: az indulaskor beallitom a csatornat, majd a kesobb egy ido lejartaval kiolvasom. Itt csatornat valtok, es tarolom az adatot. Majd megint idozites, kiolvasas. es igy tovabb. Termeszetesen lehet csinalni tomboket, ahol tarolom az adatokat es kesobb 4-8 meres utan atlagolom a csatornak adatai.

A szabványos C-ben a karakterláncot 0 kódú karakterrel szokták lezárni. A szabványos stringműveletek ezt használják pl strcat,strcpy.
Persze ettől te eltérhetsz, bárhogy értelmezheted a tartalmat.
Ha törölni akarod egy string tömb valamelyik elemét, akkor az első karakterét írd át 0-ra.
Csak akkor tudod átírni, ha a tömb a RAMban van...
Olyan string nincs ami "üres", "valami" van benne, vagy 0-ák, vagy szóközök, akármi.

Szerintem ne kapcsolgasd ki/be az AD-t, eleg, ha a konverziot inditod, a GO bitet majd torli maganak ugyis. Szerintem ez lehet a durva hiba. Aztan nem latjuk pl. a TAD idok beallitasat, stb, amik szinten befolyasoljak a finom merest - se tul nagy, se tul alacsony ne legyen, adatlapban le van irva, hogy hogyan kell kiszamolni.
Milyen es mekkora potit hasznalsz?

Fejtágító string kezelésről

Ansi c-ben a string tömb egy pointer lista (szoros követéssel pointerek egymás után), amik karakter tömbökre mutatnak.

Ansi c-ben a karakter tömb fix hosszúságú, fordítási időben eleve megmondod, hány byte van benne.

A karakter szám már kicsit vicces kérdés, ugyanis lehetnek azok ansi karakterek, unicode 8, 16, 32, akármilyen karakterek is, és nem mindig 1 byte kódol egy karaktert. A karakter bizonyos értelmezésben nem fizikailag 8 bit, hanem modellezett logikai egység. A microc-ről nem tudom, kezel-e olyat. A 8 bites ascii karakterek voltak 1 karakter / 1 byte alapon, amit az ascii 256 táblában találsz meg. Az újabb fejlesztések már másmilyenek.

Ami a stringet illeti, ansi c-ben a maximális hosszúsága van fordítási időben fixálva, de azon belül a logikai string lehet rövidebb is (hoszabb nem) futási időben.

Fordítási időben a fordító kiszámolja a címét, és ott kezdődik, végződni pedig akkor végződik, amikor sorfolytonos memória címeken futás időben elsőként 0-t talál a program (egyezményesen a 0 logikailag nem érvényes karakter, ezért az a lezáró karakter). A lezáró 0 kötelezően része a maximális hosszúságnak, szóval ha egy 8 karakteres stringed van, egy byte / karakterrel, akkor char enyem_string[9];-el kell megadnod a fordítónak minimum, különben bajok lesznek futási időben (nem fog "végződni" a string).

Tekintettel rá, hogy mindazok az adatok fizikailag a memóriában vannak, és a címük fix, azt nem tudod csak úgy törölni. A törlés a régi időkben úgy ment, hogy átmásoltad futási időben a régi tömb egészét új helyre, és kihagytad valamelyik elemet (akár a stringből, akár a string tömb pointerek közül).

A mai modernebb nyelvekben vannak láncolt pointer listák, meg vannak logikailag változtatható stringek is, amik +1 logikai szint mindkét esetben. Láncolt pointer listánál nem szorosan illesztett pointerek a felső szintű elemek, hanem struktúrák, amik legalább 4 pointert tartalmaznak: 1 pointer mutat a láncban egy előző elemre, 1 pointer a következőre, 1 pointer a kezdő "gyökér" elemre, és egy 4. magára az adat területre. Hálózatos adatbázis sejtek. És vannak a struktúrák a memóriában olyan sokaságban, ameddig csak bírja a memória. Olyan láncból törölni úgy szokás, hogy az előző elem next link-jét, és a következő elem prev link-jét egymásra láncolják, azáltal a közbülső elemet logikailag kinyisszantották (új elemet insertálni pedig épp fordítva, beleláncolnak egy újat). Stringek is vannak mutable típusok (változtathatóak). Azok a bizonyos linkelt adatterületek nem nyersen a stringet tartalmazzák, hanem mondjuk fixen 64 byte-nyi területek, amik pascal-os jelleggel egy első byte-on csak azt határozzák meg, hogy az adott területen hány byte érvényes (64 byte teljes terület esetén maximum 63). Ha karaktert törölnél, vagy insertálnál, arra az van kitalálva, hogy olyankor csak azt a kicsi területet kell újra írni, és nem mondjuk egy 16 megás stringet. A kicsi területeket soha sem töltik fel teljesen. Mondjuk beleírnak ilyen 45..50 karaktert, a többi üres hely. A fordító fordítási időben, vagy egy külön framework futási időben folyamatosan analizálja a használatot, és annak alapján eldönti, mennyire zsúfolja meg, vagy hagyja levegősen az adatterületeket. Ha többet kell kinyisszantani vagy insertálni (vagy valahol elfogyott a szabad terület, esetleg teljesen kiürült), akkor a felsőbb szinten új link elemeket láncol be / töröl ki, és a végén az értékes karaktereket precízen összeilleszti (töröl / beszúr valamelyik adatterületen). Mindazok a trükkök persze izomból memóriát meg cpu-t esznek, szóval kicsi teljesítményű mikrovezérlőkön (ilyen 8 bites meg hasonlók), az jellemzően felejtős. És hogy mindezekből mennyi van supportolva izmosabb mikrovezérlőkre, vagy esetleg magadnak kell mindent megírnod? Én azt nem tudom a mikroc-ről. Esetleg olvasgasd a lib-jei doksiját.

Nagyon jó kis összefoglaló, de szerintem a mikrovezérlő kategóriában maradjunk meg az egyszerű karakter tömböknél. Én sem használok mikroc-t de itt van egy rövid leírás a string kezelő függvényeiről.
DJozso:
Mivel nincs a függvények között (remélem, nem siklottam át felette) részterület törlést végző, legegyszerűbb, ha saját magad megírod (nem olyan nagy feladat, egy ciklus az egész). Kiindulási alapként annyit, hogy az strlen-el lekérdezheted a karaktertömböd aktuális hosszát (megkeresi hányadik helyen található benne az első 0 kódú karakter).

Kedves pipi! Erre volt szükségem, hogy boldoguljak az én saját kis szintemen. Nagyon szépen köszönöm!
pajti2: Lehet, hogy sok igazság van abban amit írtál, de nekem olyan, mintha nem is magyarul lenne. Nyilvánvalóan az én "tudásom" hiányos. Az ilyen "fejtágítókat" el szoktam menteni magamnak, majd később (mikor már jobban értek dolgokat), ismét átolvasom, és általában akkor sokat segít dolgok megértésében. Köszönöm a fáradozásod, hogy ezt mind leírtad.
benjami: Köszi az ötletet, én is ilyesmire gondoltam!

Gondolom nem valamelyik, hanem valamennyi (azaz az összes) elemét akartad írni. Ha az első karakterhelyre berakod a 0-t, akkor ugye "üres" (azaz 0 aktuális hosszú = "") karaktertömböd lesz.

Az OPTION_REG most csak nullán van,de kipróbáltam mind a 8 PS lehetőséget is,szinte semmi sem változott.1k ohm-os a poti,és beültetve 3,2 k-t mutat.

Elso feladat, hogy a ket szelsoseg mennyire jol mukodik. Tehat a labat levalasztod mindenrol es fixen vagy foldre vagy tapra kotod.
A programhoz ugyan nem tudok sokat hozzaszolni, leven c-ben irodott, de nem latom az AD beallitasokat, az adatirany-regisztereket (tris bitek jol allnak-e), valamint van-e valami mas mukodo periferiaval interferencia. Ezt az adatlapbol tudod meg, olvasd el az AD converter reszt alaposan.
Nekam akkor csinalt ilyet, amikor a mellette levo csatornara kapcsoltam veletlenul (valamennyire athall a ket AD egymashoz, ha lebegnek a bemenetek).

Hát pár LED esetében ez elmegy, de ha több szalagot kell belakkozni az kicsit frusztráló lehet

A láncolt listához szólnék.
Abban tévedsz, hogy 4 pointer van egy listaelemben. Nincs annyi, csak egy. Az, ami a következő elemre mutat. Tehát van egy pl. string eleme (de lehet más is) a struktúrának, ami az adatot tárolja és utána egy pointer, ami a következő elemre mutat. És van egy kezdő pointered, ami a láncolt lista első elemének címét tartalmazza. Tehát, ha ezt az első pointert legyalulod, felülírod véletlenül, akkor a teljes listád ugrik. Anno a tanárunk figyelmeztetett, hogy erre nagyon figyeljünk.
A láncolt lista utolsó elemét az a struktúra jelöli, aminek a pointere nem mutat sehova, azaz null pointer. Rövidíteni a listát pl. úgy lehet, hogy az utolsóvá tenni kívánt listaelemhez tartozó pointert kinullázzuk.

Biztos van sok különféle implementáció. Nem vagyok bennük napi szinten képben. Ha te mondod, hogy úgy van, én tényként könyvelem el

Lehet, hogy van más, továbbfejlesztett, célhoz igazított megoldás is. Én azt írtam le, amit anno láncolt listaként (heap-kezelés, persze PC-n) tanultam és le is kellett programozni. Meg kellett hozzá írni a kezelőrutinokat is.
Kis érdekesség, hogy a tanárunk elmondta, hogy először kínai lesz az egész. De le fog esni a tantusz és akkor egyszerre megértjük. És tényleg ilyen megvilágosodás-élmény volt, mikor megértettem.

1 pointer: egy irányú lista, ha az adatot maga a listaelem tárolja
2 pointer: kétirányú lista, ha az adatot maga a listaelem tárolja
2 pointer: egy irányba bejárható bináris fa, ha az adatot maga a listaelem tárolja
3 pointer: mindkét irányba bejárható bináris fa, ha az adatot maga a listaelem tárolja
+1 pointer, ha a listaelem adata önálló objektum, így a listaelemben csak a mutatóját tároljuk.
A gyökér elemre nem szoktak külön pointert belerakni a listaelembe, mert a legelső elem létrehozásakor annak már léteznie kell. Ha meg már létezik, akkor bármikor azonnal elérhető.
Aztán persze speciális igény esetén ezt lehet bővíteni (csak legyen aki átlátja).

Parazita kapacitásokat számolgatnék, és azon filozom, mekkora lehet a parazita kapacitása a egy sűrűn vonalazott nyákon mondjuk egy 2-3 centis vezetéknek a környezetéhez képest? Van olyasmiről valami gyakorlati tapasztalati érték? Nem nyuszit lőni kellene, hanem ráhagyásokkal számolni. Amolyan számold computerrel, mérd mikrométerrel, jelöld krétával, vágd baltával - és akkor is megbízhassak benne.

Szintén parazita kapacitás. Pic32mx5/6/7 család adatlapját néztem, és azon tűnődöm, hol van benne megemlítve a digitális bemenetek kapacitív terhelése a vonalakra? Én a magam részéről vaksi vagyok, és nem találom Amit találtam, az kimeneti terhelési határérték (50pf / 464 ohm). Azt megtaláltam. A bemeneti terhelési értéket viszont nem találtam meg. Bárki bármilyen pic adatlapban talált olyasmit?

Hali!
Én string tömbre gondoltam ss[10][20], te meg karatertömbre (vagyis egy stringre) ss[10].
A string tömb valamelyik(x) elemének "törlése": s[x][0]='\0'.
Amire te gondolsz karakter tömb ss[0]='\0'
Szerintem...

Igazad van. kicsit félreértettelek

A lábakat úgy kötöttem be,hogy az egyiket tápra,a másikat földre,a középsőt a PIC-be.

Jo, de kellene latni ket szelso erteket, hogy akkor is csinalja-e.
Az ADON-t ne kapcsold ki.
A PIC 4MHz-vel ketyeg? Mert csak ez van megadva, mint jo ertek, az AD konverziohoz, ha az adcon1 regiszter ugy all, ahogy.
Adatlapot nezted mar?

Nem értem a szélsőértékes kérdést.5V és 0V
A belső órajelen nem változtattam,az alap 4 Mhz-en megy.Az adcon1 regiszterhez nem értek,az adatlapot meg csak ímmel-ámmal nézem

Magyaraán: mennyire ugraál az eérteéked, ha GND eés mekkora az eérteéked, ha 5V keruül az AN8 bemenetere. Utaána meg lehetne proóbaálni egy feszuültseégosztoóval.
A PIC-ekneél az adatlap a Biblia, abboól tudhatsz meg mindent, hogyan eés mikeént muűkoödik. Ha rutinboól csinaálod (a maásiknaál is joó volt iígy...), oóriaási sziívaásokba futhatsz bele.
Nem tudom, a regiszter kiolvasaási sorrend itt szaámiít-e (adresl/adresh).