A régebbi pic-ekkel nem sok baja van a pk3-nak sem. Az pedig még Ethan Hunt-nak is lehetetlen küldetés lenne, hogy mplab x-re áttérés után ne legyen problémája

Te sem sokat olvasol vissza.
Kb 10 hsz-el ezelőtt írtam, hogy lehetetlen, valamit elnézett.

pajti2: Nekem semmi bajom vele az X után sem.

xitibi: Mint pajti is írta néha frissít. Ezt annyival egészíteném ki, hogy az MC site-ról nem sűrűn, viszont minden család váltásnál firmware-t cserél a Pickit3. Ha pl Most PIC10-et akarsz programozni , de előtte meg PIC18-al dolgoztál, vagy fordítva. És ezt eljátssza az összes család esetében PIC10-től a PIC32-ig. Ezt az egyet nagyon utálom benne. Alapjában semmi gond vele, de volt már olyan projectem ahol egy pic12 és egy pic18 dolgozott össze és hajam téptem amikor váltogatni kellet köztük a fejlesztés közben.
Lényeg, ha így leakad akkor első lépés, hogy bezárod és ujraindítod a programot, de mint cross51 írta el kell felejteni a PicKIT3 programot (vannak nyűgjei), használj Mplab-ot. Ha ujraindítás sem segít akkor a Pickit-et is lehúzhatod az USBről és vissza. Még egy dolog. Az a karos foglalat is csak akkor jó, ha tudod mit raksz bele, PIC-enként kölönböző lehet a bekötés. Ha tudsz angolul akkor ajánlom figyelmedbe Pickit 3 user guide és mindig olvasgatni kell az aktuális PIC adatlapját is (Microchip oldalról minden letölthetö), legelőször is az ICSP részt ez a programozó csatlakozás. Remélem így inításként elég ötletet adtam.

Szerintem aki nem tanult előtte másik IDE-ben programozni nem fog problémát okozni az X, mint amikor én elkezdtem nekem se okozott, az más tészta, hogy a VS megismerése utána azt mondom, hogy egy rakás ..., de a 8.xx-ektől nekem még mindig fejlesztőbarátrabnak tűnik az X.

Azt hiszem ezt szerettem volna az indulásnál. Elkezdem alaposabban tanulmányozni. Köszönöm!

Értem. Volt pénzed, vettél. Igazad van. Én kérek elnézést. Nem is akartam semmit számon kérni, csak egy kicsit futurisztikusnak tűnt az állításod. Azóta több kép is került fel tőled, de egy sem igazolja az eredeti állításodat...

Nos akkor lehet hogy ezt talán ugy kellett volna mondani hogy " Elméletileg nem lehet vele olvasni de ha teszel fel pár képet nagyon szívesen segítek hogy legalább a helyes úton indulj el És jól tanuld meg használni a készüléked."?

Üdv,
Készítettem egy digitális órát pic-el. Szeretnék bele ébresztési funkciót is beépíteni. Egy nagyon egyszerű dolog is elég volna, nem szeretnék dallamokat lejátszatni, elég lenne valami sípoló hang vagy ilyesmi. Hogy lehetne ezt megoldani a legegyszerűben? Erősíteni is kellene a hangot?

Ennek (vagy hasonlónak) adsz 5 V-ot és már sípol is: Bővebben: Link.

Az ott a linken piezo elektromos cucc? Egy óránál számíthat a fogyasztás is.

Igen, az. Gondolom nem non-stop fog sípolni. Ugye kérdés az is, hogy miről megy az óra. Elem vagy hálózat?

Sziasztok! Szeretnék áttérni assemblyről C-re. 16 bites picre írnék programot. Érdemes MPLAB X re váltanom és pl XC16 comilert választanom, vagy sima MPLAB és C24 compiler? Periféria könyvtárat kell külön letölteni? vagy valamit? Segítséget előre is köszönöm!

Az X ugyan folyik a csapból is, de a terjedésének legfőbb oka, hogy az új cuccokhoz csak annak van támogatása. Ha meg tudod oldani a téged érdeklő feladatokat a régebbi MLA libekkel, és van pk2-esed is, én azt tanácsolnám, ne térj át X-re, maradj a C30-nál (C24 ?).

A C30-hoz fel kell rakni az MPLAB-ot (a toolchain egy része abban van, elég idióta módon), utána a C30-at (az MPLAB is jelezni fogja neked), és utána még telepíteni lib-ek gyanánt azt az MLA-t, amiben találsz számodra szükséges project nyersanyagot.

Eddig MPLAB v8.9/ MPASM30-at használtam illetve használok. Viszont már egy ideje érzem hogy át kell térjek egy magasabb szintű nyelvre, mert kb napokig írom azt ami C-ben órák alatt megírható lenne. Gyári pickit3-mat használok. (van épített pickit2-m is régebbről). Felrakom akkor az MPLAB v8.9-re a C30-at. A alap perifériák kezeléséhez (ADC, SPI stb.) kell külön libeket keresnem? Bocs ha buta kérdés, de nem világos milyen libeket kell feltenni C30 telepítése után.?

Erre valók a makrok. Ha magadnak írsz jól átgondolt makrókat, és azokat megfelelően alkalmazod, ugyanolyan gyorsan tudsz programozni, mintha C-ben tennéd, csak kevesebb lessz benne az univerzalitás miatti programszemét. Ergo: gyorsabb lessz a programod.
Például, behívom a programomba include-val az osztó rutint. Ez tartalmazza a makrot is. A rutin 4 részből áll. 8, 16, 24, és 32 bites osztás. Úgy van megírva, hogy előszőr azt nézi meg, hány bites az osztandó. Ezálltal egy pl 16 bites osztást nem a 32 bites rutinnal futtat le, ami álltal nem veszít processzor időt.

Igazad van, de konkrétan egy quadrocopter PID szűrőjét szeretném megvalósítani, és asm-ben nem bírom megcsinálni. Asm-ben mire működésre bírtam egy szines tft kijelzőt, az is napokba tellt. Saját karakter készlettel fix méretben pedig kb egy hét volt mire megcsináltam az abc-t és a számokat 0-9 ig.. C-ben elvileg van rá könyvtár és kész. Szeretem részletesen írni a programokat, de néha már kiábrándítóan lassan haladok.. Persze nem vagyok profi programozó, főleg netről (kezdőknek szánt tananyagokból forrásokból pdf-ekből stb) tanultam anno 4-5-éve amit tudok. Most már ezzel a projektemmel haladni szeretnék mert kb 2 éve csinálom. Persze az effektív munka kb 2 hónapnyi. Tudom hogy a C kód nem túl optimalizált, és teleszemeteli a memóriát, de ez már nem 16F ,hogy spórolni kelljen... A valódi probléma igazából a PID szűrő illetve kálmán szűrő megírása, feltételezem könnyebb C ben integrálni/deriválni stb.

Próbálom olvasni a program memóriát ...
Resetel a PIC.
Ha jól látom az RCON regiszterben, akkor a TRAPR Trap Reset Flag bit 1 a reset után.

Ennek mi lehet az oka?

Kezeld le a Trap kivételeket saját rutinokkal, azaz töltsd fel a Trap hibavektorokat, mert alapból mindegyik a Reset címre mutat, így bármilyen hiba újraindítja a procit! A belépési pontról már biztosan tudni fogod hogy milyen hiba történt. (Akár csinálhatsz olyan hibamegjelenítő rendszert is mint amilyen Amigán az ún. "Guru", akkor tudni fogod mindig hogy hol és miért akadt ki a proci.)
Valószínű egyébként hogy páratlan címről akarsz szavas adatot olvasni, vagy csak elkószál a programod.

Részemről ha valamit meg akarok csinálni, maga az alkalmazás az első. Végig kotrom a példa projecteket, mit tudok megspórólni a saját munkából. Van temérdek sok külön verziójú MLA ilyen-olyan támogatásokkal. Van róla egy lista is a hozzá fűzött doksiban, hogy mit lehet találni abban a kiadásban, és annak milyen PIC-ekhez van támogatása. Végigkotrom a lehetőségeket, és utána választok MLA verziót, meg az abban található lib-ek szerint PIC-et - amihez támogatás van. Úgy felvetni a problémát, hogy konkrétan 16 bites PIC-et akarsz használni, én nem különösebben értem, de ha te érted, akkor okés.

Az alap perifériák kezeléséhez még akár a PIC adatlapjában is találsz példa kód részleteket. Én olyasmire utaltam, mint például usb otg funkcióval host-ként használnád a PIC-et, és logikai szintű függvényeket akarsz egy arra rákötött egeret kezelni. Ahhoz bizony egybe kell gyúrni ezt-azt. De egy alap szintű periféria kezeléshez semmi szükséged MLA-ra, vagy Harmony-re, vagy bármire. Csak egybe rakod a kapcsolást, kiollózod a PIC adatlapjáról a kód részleteket, meggyúrod magadnak, és készen lesz.

Hali!

MPLAB Harmony-val szívok, mivel nem sikerül egyik lábat sem kimenetre állítanom a konfigurátorban. A típus: PIC32MX170F256B, DIP28 tok.
A Harmony HELP (nekem) nem működő műveleteket javasol . . . ., a Direction gomb tiltva van, mint ahogy a MODE(ANSEL) gomb sem aktív !
Ez egy számomra teljesen idegen logikával készített konfigurálási mód (még tudnám "dicsérni") , amit pedig szeretnék használni.
A PIC 24-es és 33-as sorozatban használom a PPS-t, persze nem harmony-val, hanem "kézzel" egyenként beírva a C kódba.Ezt itt meg szerettem volna spórolni . . .
Tud segíteni valaki ?
Minden ötletet köszönök.

Idézet:
„Asm-ben mire működésre bírtam egy szines tft kijelzőt, az is napokba tellt. Saját karakter készlettel fix méretben pedig kb egy hét volt mire megcsináltam az abc-t és a számokat 0-9 ig.. C-ben elvileg van rá könyvtár és kész.”

Akkor nevezzük nevén a gyereket: nem az a gond, hogy nem tudod megcsinálni, hanem sokkal jobb az, hogy már valaki megcsinálta helyetted.

Azért egy 16bites piccel akarom megcsinálni ezt a projektet, mert a szenzorok is 16 bites értékeket adnak, és nagyobb számítási tartomány áll rendelkezésre nagyobb számítási sebességgel. Biztosan van olyan guru, aki egy 8 bites 16F-essel is meg tudná oldani egy radio modul kezelését, IMU szenzorok adatainak kiértékelését-átlagolását-fúzióját, és a 4 ESC vezérlését is megoldaná szoftveres PWM-ből, de én nem tudom. Egy pic24H-val viszont jelenleg "csak" IMU modul szenzor adatainak összegyúrásának megírása állít elém akadályt. Az alap perifériák kezelése természetesen nem okoz gondot. A uC programozást anno 16F el kezdtem majd 18F fel folytattam, az USB és a CAN-on kívül használtam már szinte az összes átlag perifériát. C-re csak azért vetemednék, mert a könyvtárak sok időt megspórolnának nekem.

Akkor ezzel azt mondod, hogy aki C-t használ az egy lusta, más tollával (könyvtáraival) ékeskedő? Szerintem azzal, hogy asm-mel kezdtem az pic-ekkel való ismerkedést, többet tudok a lelki világukról, mint aki kizárólag C-ben programozza. És nem kevés időt töltöttem azzal, hogy megírjam a saját algoritmusaimat erre-arra. Most sem az a gondom, hogy nem szeretném asm-ben megírni amit akarok, hanem hogy nem tudom.

Nézd ez egy örök vita, nem akarok nagyon belemászni, de ha belegondolsz a C nyelve nem más mint valaki más által előre megírt könyvtárak, de ezt te magad is leírtad az előbb én meg beidéztem.

Idézet:
„Most sem az a gondom, hogy nem szeretném asm-ben megírni amit akarok, hanem hogy nem tudom.”

Ha nem tudod megírni asm-ben amit kell az nem nyelv hibája, hanem a megfelelő tudás, rutin hiánya. Biztos vagyok benne, ha rászánod az időt akkor meg lesz a siker is. Az egyik kedvenc idézetem egy programozói könyvből: "Amit nem lehet Pascal-ban megírni, azt C/C++-ben meg lehet. Amit nem lehet C/C++-ban megírni az Assembly-ben meg lehet. Amit nem lehet Assembly-ben megírni azt nem lehet megírni!"
Persze neked legalább annyi előnyöd van, hogy ha MpLab-ban megnézed egy C program fordítása után a program memóriát akkor érted is amit látsz, nem úgy mint az aki egyből C-vel kezdte.

Na mindegy, szerintem egy állás ponton vagyunk valahol, mert én is asm párti vagyok, viszont szögfüggvényeket sin,cos,tan,integrálás,deriválás, vagy akár gyökvonást nem tudok alkalmazni, ez persze az én hiányosságom. Ezt akartam csak C-vel pótolni.

Persze ezek nem egyszerű, kezdőknek való feladatok, de elképzelhetőnek tartom, hogy ha egy ilyen programrészt lefordítasz és megnézed a végeredményt lehet, hogy megérted az elvét és a homlokodra csapsz, hogy"Basszus! Ezt 100 sorral kevesebből is meg lehetne csinálni!"
Hozzátenném még, hogy a szögfüggvényeket, meg a gyökvonást azért nem tudjuk legtöbben manuálisan kiszámítani, mert már nem is tanítják. Megelégszünk azzal, hogy a számológép tudja vagy le van írva a négyjegyű függvénytáblába és kész. Ez is olyan "C-s" dolog, már valaki megcsinálta, csak használni kell.

Bocsi a belevauért.
Írod, hogy gondjaid vannak pl. a szögfüggvényekkel. Valójában "csak" annyi a problémád, hogy nem ismered a matematikai hátterüket, azt, hogy hogyan lehet egyszerű alapműveletekkel és bitfésülgetéssel megvalósítani. Én anno tanultam, hogy hogyan számol belül az ALU (még 8086-ossal), mert a processzor ostoba, mint a cipőtalp, viszont baromi szorgalmas. Nem tud mást alapból, mint összeadni, negálni, léptetni (illetve a bool-algebra elemeit). És ezekkel kellett lépésről-lépésre pl. egy szorzást vagy osztást elvégezni - papíron. Baromi szenvedés, de ugye ezt az ALU már tudhatja, mert kapuelektronikával megvalósították. De alapáramkörileg, azaz logikai kapukkal mást nem lehet, csak összeadni (xor), negálni, léptetni. Minden mást ( kivonás, szorzás osztás) kombinációs hálózatokkal valósítanak meg.
Anno a függvénytáblázatokat is alap matematikai műveletekkel számolászták ki. Nem volt számológép. Neked is az asm-mel azt kell csinálnod, hogy az adott processzor (ne feledd, a mikrokontroller csökkentett utasításkészletű) lehetőségeivel, alapműveletekkel leírni, algoritmizálni a bonyolult matematikai feladatot. A C nyelv környezetében annyit tettek, hogy mindezt függvénykönytárakkal már megírták neked.

Szia! Igazad van, de ha tudnám algoritmizálni pl a deriválást, most nem tartanék itt (tanultam én is alap digitális elektronikát, flip-flop-ok, tárolók, multiplexerek stb) Üdv!

Szeretném lezárni ezt a hitvitát!
Bár én kötözködtem először Balagemannal, most mégis neki kell igazat adjak!
Ahogy Pali79 is írta:"nem tanítják".
Mikor először kellett PIC-re linealizációs számítást írnom, órákig bújtam a netet a képletéért.
NEM TALÁLTAM MEG!
Végül az Unitronics PLC fejlesztőkörnyezetének súgójában bukkantam rá.
Ezek alapján kénytelen vagyok egyetérteni Balagemann álláspontjával.
Én sem szeretném saját kútfőből újraalkotni pl. a gyökvonás képletét. Ettől még szerintem megmaradok hithű assemblysnek.

Kicsit had pontosítsak. Kapukkal az alapműveletek: and, or, invert. Azokból képezik le már a xor és nand műveleteket is, amikkel egy bites regisztereket, meg összeadókat gyártanak. És utána azokra építik rá az összeadást, kivonást, osztást, szorzást.

A sinus, cosinus, gyökvonás, és logaritmus is olyan alapműveletek eredménye, csak azokhoz paraméter táblákat is használnak többlet bemeneti adatként. A matematikai koprocesszorban is ugyanúgy paraméter tábla van beégetve a műveletekbe huzalozással, meg statikus rom cellákkal, ahogyan az emulátor libek is csinálják szoftveresen. Esetleg low-range mcu-val azért nem különösebben lehetséges olyat számolni, mert elvárások lehetnek a műveletek pontosságával, és a pontossághoz munkamemória is kell. A több memória nagyobb pontosság, amire elemi számításoknál talán még nincsen szükség, de egy hosszú képletet végigszámolni már kellhet olyan helyeken, ahol a hibák összeadódnak, utána összeszorzódnak, és utána még hatványozódnak is. A 16f / 18f mcu-kat simán csak nem olyan műveletekre találták ki. A 32-eseket leszámítva nincsen annyi memória egyik mcu-ban sem, hogy az akár csak statisztikailag jelentős lehessen komolyabb matematikai műveletekre.

Ha valaki az alapokkal gondolt ismerkedni, jelenleg nem a pic-ek kapcsán kellene kotorászni, hanem irány az fpga-k világa, és a vhdl libek. Ott kőkeményen mindent meg fogtok találni utolsó bitig lebontva. Viszont a kész libek már ott is olyanok, hogy hiába van minden lebontva utolsó bitig, ha egyszer 938 szinten vannak egymásra építve a műveletekre leképezhető műveletek. Nincs ember, aki azt mind real-time észben tartaná. Attól bárki annyira be tud kattanni, hogy ámokfutó sorozatgyilkos lesz belőle, vagy nem tudom Nem egészséges dolog lelkileg olyasmire használnunk az agyunkat, amire nincsenek természetes tulajdonságai. Valamennyi állóképessége van mindenkinek, valamennyit át tud látni a folyamatokból, de amikor érzi, hogy már sok, akkor abba kell hagyni. Szellemi baleset-megelőzés gyanánt még annyit szükségesnek érzek hozzá fűzni, hogy még ha valaki asm-hez hozzá is van edződve, a vhdl akkor is ki tudja készíteni. Pláne, aki nincs is hozzáedződve. Az elején csak kicsi lépésekkel lehet haladni, és majd jut a történet, ameddig jut.

Szia!
Szerintem maradj a manuális port beállításnál.Csinálj mindent meg,mert az X eléggé érdekes dolgokat tud művelni.
Baromi jó dolog,hogy be lehet vele tenni 1 csomó mindent(tcp,usb,spi,i2c,stb.),de szereti elrontani a beállításokat. Max. tegyél be mindent ami kell,és abból csinálj magadnak 1 jó project-et,libet.De nézd át,hogy miket csinál,mert már én is szívtam azzal,hogy hülyeségeket állított be.A végén meg állítsd be magadnak a portokat.Amúgy amikor elindítod a harmony-t,akkor látod,hogy mit tölt be,nálam 4-5 dolgot nem tud betölteni,és pont a pin az 1ik,szerintem azért nem engedi neked is.Majd pár év múlva használható lesz .Bár programozni jobb benne mert mutatja a feltételes fordításokat ,ami elég jó hosszú kódoknál