Most sorba van két 1206-os smd (ezeknek elméletileg 200V az üzemi feszültségük), az eddig nem füstölt el, viszont más helyen igen ugyanígy sorba kötve, de szerintem csak a disszipáció miatt (előtét kondi előtét ellenállása). Én 2512-esre gondoltam kicserélni őket, azoknak 300V az üzemi feszültségük és 2W-osak (szintén sorba kötve, mert ugye 325 V-unk van). Fontos lenne az smd kialakítás. Vagy nagyon nem ajánlott smd ellenállást beépíteni ilyen helyre?
Bővebben: Link

Normális tápegységekben 3-4 ellenállás van sorba.Az üzemi feszültség nagyon elméleti, mihelyst a panelre teszed, már romlott a helyzet, a folyasztószer, gyanta meg még ront rajta.

Mármint SMD esetén? Furat szerelt esetén azért elég 1db is szerintem mondjuk egy 500V-osból.
Egyébként láttam már olyan gyári áramkört amin csak két 1206-os ellenállás gondoskodott a kondenzátor kisütéséről.

Sziasztok!

Lenne egy kérésem, aki MPLAB v8.92 verziót használ, futtassa már le nekem a következő asm file-t
az MPLAB szimulátorában. (A spec function regiszterek közt lehet látni mi történik.)
Az a gondom, hogy a TMR6 os időzítő elindul, megy, lejár de nem kér megszakítást. Pontosabban az összes megszakításjelző bit 1 lesz és engedélyezve is van, ennek ellenére nem ugrik magas megszakításba. Arra lennék kíváncsi, hogy valamit elcsesztem vagy az MPLAB nem tudja ezt a PIC típust rendesen szimulálni. A TMR 5 ös is ugyanezt csinálja , a TMR 0,1,2 viszont működik rendesen.
Ezeket már használom azért kell az 5 ős meg a 6 os TMR is !

Köszönöm előre is.

Látatlanban: nem támogatja a PIC-et. Nézd meg, amikor kiválasztod a szimulátort, milyen színű a támogatás pötty. Ha nem zöld, csak sárga, akkor részben támogatott.
Én már áttértem X-re, lehet használni a régi fordítókat és nem vészesen lassú, viszont sokkal jobb a szerkesztője és watch is jobban elhelyezhető, variálható, forrás megjelenítése klónozható stb. Próbáld ki, nem bánod meg!

Igen igazad lehet sárga a pötty a szimulátornál most néztem meg .
Már nézegettem én is az X-et de még nem tudtam zöld ágra vergődni vele.

Köszi

Sziasztok!
Gondoltam végre kihasználhatom az új XC32 free c++-os verzióját és csinálok vele egy projektet. Persze linker error kapok akármit is csinálok. Sikerül lebutítanom a hibát, az alábbi 3 sorral előjön:
#include <vector>
vector<int> temp;
temp.push_back(12);

Ez a hiba első pár sora, de amúgy szép hosszú:
xthrow.o: Link Error: Could not allocate section .text._ZSt15_Xruntime_errorPKc, size = 980 bytes, attributes = code
data_init: Link Error: Could not allocate section .dinit, size = 928 bytes, attributes = code keep
c:/program files (x86)/microchip/xc32/v1.40/bin/bin/../../lib/gcc/pic32mx/4.8.3/crtbegin.o: Link Error: Could not allocate section .text, size = 552 bytes, attributes = code
malloc.o: Link Error: Could not allocate section .text.malloc, size = 548 bytes, attributes = code
fputs.o: Link Error: Could not allocate section .text.fputs, size = 404 bytes, attributes = code

Nekem úgy tűnik, hogy a default linker script fileból mindenre panaszkodik. Olyan, mintha nem tudná linkelni a c++-os dolgokat.
Találkozott már valaki ezzel a hibával? Google nem mond erre semmit.

Ha elakadsz, kérdezz. Sokan vannak, akik kapásból válaszolnak. Az X-ben máshogy kell beállítani ugyanazt, főleg, ha maradsz a régi fordítóknál. Nem túl bonyolult szerintem, csak más.

Hello mindenki!

Segítségeteket szeretném kérni a következő kérdésben: Egy optokaput építek melynek az lenne a feladata, hogy ha eltakarod akkor valamiféle hangjelzést ad (sípol). Intel 8051-re kellene assembly-ben megírni a kódot. Analóg jelet vizsgálnék vele, semmi extra. Valaki tudna ebben segíteni? Milyen oldalakon lehetne utána nézni ennek, vagy valakinek van valami hasonló programja?

üdv. B

Szia!
Egyrészt ez nem 8051-es topic, másrészt beírhatnád a GOOGLE-ba, hogy 8051 assembler...

Sziasztok!

Egy WiFi-s haletetőt fejlesztek éppen pic24fj64ga002 mikrovezérlővel mikroC-ben, ahol pont a legegyszerűbb résznél, egy nyomógomb megszakításánál akadtam el, jobban mondva egy érdekes jelenséggel találkoztam.
Az INT0-s láb fel van húzva egy 10k ellenállással tápra, a nyomógomb pedig földet kapcsol. Értelem szerűen az INT0 megszakítás lefutó élre aktív. Ha kihúzom a dugaszolós próbapanelból azt a vezetéket, amely a föld és a nyomógomb között van, majd visszadugom, akkor lefut ISR. Mindeközben a gomb nincs megnyomva. Tehát gyakorlatilag egy lógó vezetéket szúrok a földre, és ennek hatására INT0 megszakítás történik. Gondoltam, hogy valamilyen parazita kapacitásról lehet szó, majd tettem az INT0-ás láb és a föld közé egy 1-100nF-os kondenzátort illetve kihúztam a mikrokapcsolót a helyéről, de ez se segített. Ha logikai analizátorral figyeltem a lábat, akkor nem jött elő ez a hibajelenség. Mindazonáltal a megszakítás gombnyomásra hibátlanul működik, ahogy az áramkör/program többi része is. Az INT0/RB7 láb természetesen digitális bemenetnek van beállítva.
Megnéztem a kontroller erratáját, illetve rákerestem a hibajelenségre is, de nem találtam semmit. Van valakinek ötlete, hogy mi lehet a háttérben?

Üdv. m.joco

Lehet amit te földnek gondolsz az nem az...

A "gyakorlatilag" lógó vezetéknek és a nyomógombnak is van kapacitása. Esetleg még egy dióda segíthet rajta, de mivel ez nem olyan hiba ami a gyakorlatban előáll, úgy értem a kész áramkörben nem lesz vezeték dugdosás és az áramkör egyébként működik, nem kell vele foglalkozni.

Én a bemeneten mindig 1k-t használok ,mindig gnd re van húzva vele a láb és + ra kapcsol a gomb vagy a kapcsoló . soha még az árnyéka sem jött elő ennek a dolognak amit leírtál ...

Talélkoztam már ilyennel, illetve hasonlóval. Nekem az oldotta meg a problémát, hogy 1k ellenállással húztam fel a lábat.

Üdv!

A segítségétekre lenne szükségem. Egy PIC18F46K22-vel küzdök egy ideje. Mind a két UART működik megszakításos bejövö adatkezeléssel hibátlanul. A következő lépés egy SD kártya interface lenne, amit be kellene illesztenem a programba. Az SD kártya kezelő részt 18F4580-on írtam először, ahol tökéletesen működött. Copy + Paste és a szükséges SFR-ek névmódosítása után az UART megszakítás megszűnik működni. A bejövő karakterek nem okoznak megszakítást. Eddig sikerült kinyomoznom, hogy a következő programrész részleges kikommentezése megoldja a megszakítás problémát, persze ettől meg az SD kártya nem működik....


Ha ez így van benn akkor nincs UART interrupt:


Ha így, akkor működik az UART interrupt:


Ha jól tippelek a kettőnek nem nagyon van köze egymáshoz. A fenti programrészlet még nem része a futó programnak, vagyis az SD kezelést még nem hívom meg sehol...

Jó volna valami ötlet, mert kicsit tanácstalan lettem.... Köszi előre is!
Üdv
The_Saint

Szerintem azokban a call-okban van valami...
Tobb commentelest nem tudsz visszavonni?
Tudni kellene, hogy hol vannak a memoriak, mi a BSR allapota, stb.

Masfelol sokat segithet, ha az MPLAB szimulatoraban futtatod, ott szimulalt modon latod, mit rontottal el, mikor modosul a megfelelo regiszter.
Egyeb megszakitasok mukodnek?
Ha atpakolsz par uj memoriacimet?
Ha az egesz szubrutin helyet valtoztatod?
Sok lehetoseged van, en egy led-et szoktam kigyujtani elesben (ha addig eljut, akkor jo), de mostanaban inkabb szimulator. Eppen tegnap fedeztem fel, hogy a tblrd*+ es a tblrd +* mast csinal...
Miutan egy napig szivtam, hogy miert hagyja ki az elso karaktert az olvasasnal...

Üdv,

Ok, szóval pakolásztam a dolgokat ide oda, nem sok minden változott. A LED-es trükköt én is használom, bár nálam egy kijelzó is rá van akasztva, hogy néha többet láthassak egy blinknél. A végeredmény az lett, hogy újraírtam egy részt az SD kártya kezelésben.
Ha nem volt bent az SD akkor egy végtelen ciklusba került a program, amiből az UART megszakítás ki kellene léptesse... Ezért megszakítás a megszakítás, de sajnos ez nem teszi. Az érdekesség az az, hogy ha nincs dolga a CPUnak akkor is egy LOOP..NOP..GOTO LOOP ciklusban kering és abból simán kilép és kezeli az UART-ot. Egyenlőre a két UART-on kívül meg nincs másik megszakítás benne.
Az újraírás alapvetően a problémát nem oldotta meg, hanem csak megkerülte. 2mp után így vagy úgy de kiléptetem a SD-re várakozásból.
Sajnos még mindig nem értem hogy miért tűnik el az UART megszakítás ebben az esetben. Szóval ez a rész még ötleteket vár
De találtam egy másik problémát..lásd köv. hozzászólás...

Megszakításai rutinban vár az SD kártyára vagy az uart -ra.
Nem olvasod ki a RCREGx -et, ezzel nem törlődik a megszakítás kérés. A ráfutás (OERR) vagy keretezési hiba (FERR) nincs lekezelve. Akkor is ki kell olvasni az RCREGx -et, ha letiltod a vételt a hibák törlésére.

Biztos mindegyikőtöknek megvan a Kónya féle PIC programozós könyv régebbi kiadása, az a fekete borítós... A tippek trükkök résznél van pár minta a 8 és 16 bites változók hasonlítására. Na eddig én ezeket sikerrel használtam, viszont a minap egy érdekes dolog történt:
Az alábbi kódrészlet a könyv 213. oldalán a RAM > x résznél található:



Szóval ugrik ha a RAM > X

Ha X mindig 0 és a RAM értékét növelem 1-el, akkor PIC18F4580 esetében teszi is a dolgát egészen 0xFE10 értékig, utána viszont úgy ítéli meg, hogy az X > RAM....természetesen hibás működést okozva például egy LoadCell mérés esetében. Az okra eddig nem jöttem rá, nem volt időm foglalkozni vele. A problémát persze megoldattam egy másik hasonlítási eljárással.
Más is találkozott már ezzel?

Üdv
TheSaint

Üdv,



Ebben a loopban vár bármilyen megszakításra. UART1 és UART2 megszakítás esetén kezeli a bejövő charaktereket és törli a flaget... ahogy kell.
Aztán meghívom az SD inicializáló részt akkor eddig egy szintén végtelen ciklusban várt SD R1 válaszára. Mivel nem volt bent az SD ez ugye sose jött meg, de ennek ellenére ki kellett volna lépjen kezelni az UART-okat, de nem tette. Szóval itt tűnt el az UART megszakításra való reagálás.
Ha berakom az SD-t, mármint a kártyát magát, akkor inicializál, visszamegy a fenti loopra és utána minden normálisan működik.

Hogyan inicializálod az SD kártyát?

Ennyire higyj a "kész" megoldásoknak! Az addlw 1 utasítás okozhat átvitelt, amit a rutin nem kezel le.
X=0x0000 mellett működik RAM=0xFF00 -ig. Azonban, ha RAM=0xFF01 .. 0xFFFF, akkor az említett átvitel elveszik.

A SetTimer02s miatt kerüli ki a varakozó ciklust ha nincs benn a kártya és lejárt a timer. Ha benn van akkor nincs gond.
Ha kiveszem a timert, akkor benn marad ebben a ciklusban és nem kezeli az UART megszakítást...
Igazából azt nem értem, hogy az UART szempontjából semmi nem változik és mégsem kezeli. Kipróbáltam a TIMER0-t polling helyett megszakítással és az rendben van... de így pollingal egyszerűbbnek látom...
A fura a dologban, hogy átraktam az egészet 18F4580-ra és ott hibátlan... Ha van SD kártya, ha nincs a megszakítást akkor is kezeli, kivétel nélkül.

Szerintem igy nagyon nehez hibat keresni, hogy a fele a programnak olyan call, amit nem is latunk.
Pollinggal lekezelni egy megszakitast elegge...hmmm...kezdetleges.
Erdemes kutakodni a ketfele proci regiszterei kozott, mert elofordulhat IGEN KONNYEN, hogy ugyanaz a regiszter mashol van es az a bitje is mast jelent. Adatlap a mervado.
Amennyiben az egyikben megy, a masikban nem, velemenyem szerint nem programhiba, hanem felepitesbeli kulonbozoseg miatti hiba lepett fel.

Állítsd be az MpLab Sim -et nyomkövetőnek és kövesd a SD kártya inicializálást lépésenként. Közben figyeld a RCIFx bitet... Tegyél egy töréspontot a megszakítás(ok) belépési pontjára. Nézd meg mitől jutott oda a program. Mi nem látjuk át a programodat...

Kimaradt az előzőből:
Készíts két szöveges állományt, amiben a két uart által fogadandó táviratokat léírod. A két állományt egy-egy register injection stimulussar rendeld az RCREG1 és RCREG2 -höz. A stimulosokat aktivizáld (Apply). fordítsd újra a programot és indítsd el. Tegyél egy töréspontot a megszakítás(ok) belépési pontjára (pontjaira). A vezérlés meg fog állni a megszakítás belépési pontjain.

Fejlesztek egy berendezést, ennek az első lépése hogy a PIC-kel adatokat kell beolvasnom SD-kártyáról. Korábban ezeket az adatokat a PIC programmemóriájába tettem de az sajnos véges, az SD-kártya viszont már kvázi korlátlan adattárolást biztosít. Amíg a PIC-ben voltak ezek az adatok addig jó volt mert a fordító szólt hogyha szintaktikai hiba volt benne mert véletlen elgépeltem valamit. Viszont ha az SD-kártyáról olvasom be az adatokat egy txt fájlból, akkor ott nincs semmiféle biztosíték arra hogy abban nincs hülyeség. Ezért kellett írnom egy függvényt ami megoldja mindezt. Szépen soronként beolvassa a szövegfájlt és kimazsolázza belőle a megfelelő adatokat majd feltölt vele egy elég bonyolult struktúrát. A probléma az hogy annyi féle adat lehet a szövegfájlban és a legkülönbözőbb variációkban hogy a lehetséges esetek száma szinte végtelen. Példaként mutatok két esetet, a legegyszerűbbet ("J001") és egy elég bonyolultat ("J002"). Mind két adatcsomagot ugyan az a függvény olvassa be és minden egyes kis adatot a megfelelő helyre pakol. A kommenteket (a "//" jel után) figyelmen kívül hagyja és ha hibát talál akkor megmondja hogy a szövegfájl hanyadik sorában van a hiba és milyen jellegű. 28 különböző hibaüzenetet tud adni, ezzel nagyon részletesen a tudtunkra adja hogy pontosan mi is a baja a sorokkal. Tulajdonképpen olyan mint egy fordító program.

Itt van róla egy kis videó, itt beolvastatom a kártyáról az összes programot amit talál és mindet leellenőrzi: Bővebben: Youtube

Nem túl látványos dolog, de nagyon-nagyon fontos amit csinál.
Négy napig ezt írtam.

Bocsi, ezt nem ide akartam írni csak áttették ide.

Viszont ha már ide kerültem:
Nem tudtok esetleg olyasmiről, hogy az MPLABX olyat tudna hogy számolja hogy a projekt hányszor lett elmentve, lefordítva vagy beégetve? Tök jó lenne ha ezt a számot valahogyan applikálni lehetne fordításkor a programba egy konstansként, így egyszerű lenne a verziókövetés.

Az égetések számát szerintem nem tudja követni, de history-ja van azt tapasztalatból tudom. Mutatja a különbséget is az előzőleg mentett verziókhoz képest. Egyszer véletlenül elmentettem egy változtatást amit nem akartam, és több sor volt amit nem jegyeztem meg, history segített .
Azt nem tudom meddig tárolja az adatokat, de szerintem nem túl sokáig. 1 v. 2 hónap lehet max. utána kell nézni.