Bővebben: Link

Köszi mindenkinek. Ezzel elleszek sztem

Szia!
Köszi a tippet. Úgy néz ki a tesztelgetés hogy 2 gép működik, mindkettőből egy USB->RS485 átalakító és ezek csatlakoznak az eszközömhöz. Egyik gépről vezérlem az eszközt valamilyen adatcsomagokkal a másik gépről pedig ha ugy akarom akkor csak terminálon keresztül ellenőrizni tudom a kiküldött adatcsomagokat és hogy arra mit reagál az eszköz. Ha csak 1 adatcsomagot küldök ki pl ( 0x00 0x05 0x02 0x83 0x00... ) ezt értelmezi ugy hogy 0ás cím 5 bájt hosszú csomag , 2es parancs 0x83 az adat , 0x00 lezárás.. és ha az adatban a legfelső bit 1es akkor villogjon. Namost ha egyik gépről ezt kiküldöm és a másikon csak ellenőrzöm az adatmozgást a 485ös vonalon akkor csak ezt látom semmilyen más adatcsomagot. Ekkor van az Néha hogy a timer nem indul el egyből hanem késik egy kicsit... mintha a kontroller sokáig gondolkozna.Majd továbbra is nulla adatmozgás és egyszercsak el kezd villogni(ez már ugye a timer miatt) Fura vagy fura?

Nincs valahol a programodban olyan feltétel, amiből nem szabadul ki programszál csak a feltétel teljesülésekor, de a feltétel nem mindig áll elő időben? Ha van akkor az ilyen ellenőrzéseket szüntesd meg és kezeld másképpen a folyamatot.

Szia!
Tehat az adat megerkezik a PIC-hez? A PIC ertesul is rola? Az adatot ki is tudta olvasni hiba nelkul a 485-os buszarol?

A PIC pollozassal vizsgalja azt az adat bitet, tehat ellenorizni kell, hogy:

1. Adat valoban megerkezett -- pl tedd ki a 8 bitet az egyik portra es LED-eken keresztul diagnosztiizaldd, vagy tegyel ra egy kijelzot, LCD vagy LED kijelzo amire a beerkezett adatot kiiratod

2. A pollozas nem akad-e el mashol, tehat az, hogy ellenorzod az adat 7. bitje magas-e azt a kivant ido intervallumokban lekerdezed

3. Miutan engedelyezted a megszakitast mashol nem tiltod-e le valami masik logika szerint (velemenyem szerint amugy sem szerencses megszakitasokat engedelyezni / tiltani, hanem helyette vezerlo flageket kell hasznalni amit a megszakitaskezelo ellenoriz)

Annyi még kimaradt az előbb a tesztleírásból hogy adatértelmezés után valamilyen választ is küld, és másik gépen ahol az adatmozgást figyelem csak ott azt látom hogy a gép elküldte az eszköznek és az eszköz azt a választ adta ami erre is vonatkozik. Program szerint csak végrehajtás után válaszol vissza az eszköz tehát ha nincs a picből kifelé jövő adat akkor megállt a program valahol, de ez nem történik meg mert az a válasz jön aminek kell, következő adatot is tudná fogadni stb.
Tehát a pontokra a válasz :
1 : adat megérkezik , plusz most ráhekkeltem egy ledet egyik kimenetre és a TMR1ON=1 parancs után a ledet felvillantom , ez is megtörténik , TMR1ON=0 parancs után a led elalszik , ez is megtörténik. Ennek ellenére néha ismétlen nagyon néha a timer mégse indul el.
2 : nincs időhöz kötve , 485ről ha jön adat az interruptosan van kezelve.
3: a magas szintű interruptot csak ez a timer használja, alacsony szinten van az usart kezelő. Sehol máshol nincs programban tiltva az interrupt, illetve csak az initben van engedélyezve és ennyi.
Már ilyen POR BOR WDT dolgokban gondolkozom hogy hátha ezek valamelyike késleltetné néha a timer indulását de nem jutottam előrébb. Ma pl csak egyszer volt ilyen hogy később indult el, általában azonnal villog ha azt akarom, de jobb lenne a 0hiba%.

Hol állítod be a TMR1ON-t és hogy döntöd el, hogy be kell állítódjon, majd hol ellenőrzöd a feltételt a LED bekapcsolásához, és hol törlöd a TMR1ON bitet?

Ezt miért tartod jobbnak ?

Steve

Szerintem úgy értette, hogy megszakítás közben nem szabad a megszakítást engedélyező biteket állítgatni, mert az zavart okoz!

Én használtam már megszakítás közben megszakítás tiltást/engedélyezést ( egy adott időponttól kezdve fogadhatott v. nem bizonyos típusú megszakításokat ), de nem okozott hibát és ilyenről nem olvastam még. Láttatok valahol ilyet publikálva?

Steve

Nézzétek el hogy nem másolom be az egész kódot, szavakkal leírom a választ :
Tehát jön egy adatcsomag aminek egyik bájtját megvizsgálva kiválasztódik egy funkció, a következő bájt pedig hordozza az infót ehhez a funkcióhoz. Egy switch utasítással válogatok a funkció választáskor , kb így :
switch(temp[1])
{
...
case 0x02 : ize(temp[2]);break;
...
default:break;
}

void ize(char x)
{
.....
if ( ( x & 0x80 ) == 0x80)
{
INTCONbits.GIEH=1;
T1CONbits.TMR1ON=1;
TMR1H=0x0F;
TMR1L=0xFF;
LATxbits.LATx1=1; //LED be
}
else
{
INTCONbits.GIEH=0;
T1CONbits.TMR1ON=0;
LATxbits.LATx1=0; //Led ki
disp_on();
}

az interrupt meg igy néz ki :
void hi_int_kezelo(void)
{
if (PIR1bits.TMR1IF)
{
PIR1bits.TMR1IF=0;
TMR1H=0x0F;
TMR1L=0xFF;
timer1++;
if(timer1>9)
{
if(LATCbits.LATC0==1)
{
disp_off();
}
else {disp_on();}
timer1=0;
}
}
}
Előosztások ugy vannak belőve hogy 100ms -ként van interrupt, szóval nekem mp-es villogás kell , ezért számol egy timer változó.
Led felgyúlladását és kialvását szépen megcsinálja első pillanatban szóval mindent jól megcsinál csak nagyon ritkán késik a villogás elindulása. Ha egyszer elindul akkor minden jó és szkóppal nézve is 1mpes a villogás, de az a késés kicsit zavaró. Persze ha olyan adatbájtot küldök amiben nincs legfelső bitben 1es akkor abbahagyja a villogást és ég, szal ez is jó, csak nagy ritkán nem indul el azonnal a villogás... Utána ha türelmes vagyok elindul, de nem kéne türelmesnek lenni..

Üdvözlet srácok!
Nem tud valaki egy olyan szimulátorról mi képes TFT-t és érintőpanelt is szimulálni?

A segítséget előre is köszönöm.

Én nem szoktam a megszakítás engedélyeket ki-be kapcsolni, elég, ha leállítod a timert. Nem hiszem, hogy ez a baj, de egy sorral kevesebb.
Akkor késhet, ha a Timer megszakításakor egy másik megszakítás kezelődik le éppen, pl. az USART-é. Ezt ki lehet küszöbölni, ha az USART-ot alsó prioritásba teszed. A Timeré úgy is olyan övid, hogy nem okoz gondot, ha megszakítja az USART lekezelését.

Igen így gondoltam én is, az usart low priorityben van , a timer meg High-ban. Persze lehet egy sorral kevesebb ez már azért van benne mert hátha emiatt késik néha az indulás
Viszont megpróbáltam most timer0 ával (pic18f14k22) és mostmeg abszolút nem megy :S Mit írtam el ? Kicsit éjszakáztam benne van a fáradtság is :
init() részlet:
T0CONbits.PSA=1;
T0CONbits.T08BIT=1;
T0CONbits.T0CS=0;
T0CONbits.T0PS0=1;
T0CONbits.T0PS1=1;
T0CONbits.T0PS2=1;
T0CONbits.T0SE=0;
T0CONbits.TMR0ON=0;
TMR0L=0x00;
INTCONbits.TMR0IE=0;
INTCON2bits.TMR0IP=1;

progi elején interrupt hívások
#pragma interrupt hi_isr
void hi_isr()
{
hi_int_kezelo();
}

függvény:
void hi_int_kezelo(void)
{
if (INTCONbits.TMR0IF)
{
INTCONbits.TMR0IF=0;
TMR0L=0x00;
LATCbits.LATC0=!LATCbits.LATC0;
}
}

A timer indítása ugyanaz mint korábban írtam, parancsértelmezésre elindul a timer , vagy leáll. Eközben egy lábat ki/be kapcsolgatok ellenőrizve azt hogy tényleg jól értelmezi-e a parancsot. Ezen a lábon jó a működés, szkóppal nézve a C0 lábat semmi reakció. Ötlet?

Sziasztok!

PIC program "erős" levédést szeretném véghezvinni.
Nagyjából annyit szeretnék, hogy miután felprogramoztam a PIC-et ne lehessen kiolvasni belőle a programot, és áttölteni egy másik Mikrokontrollerbe.
Az Mplab 8,46-os verzióját használom, és ott van egy olyan opció a "Configuration Bits" alatt, ahol be lehet állítani a Code Protect opciót a 300008-as, és a 300009-es cím alatt. Ez azonban szerintem nem nyújt megfelelő védelmet (könnyen eltávolítható).
Ha van valakinek erre bomba biztos módszere, akkor nagyon jó lenne. (habár ilyen nem létezik.)
a Programozóm: Pickit3

Pont erre talaltak ki, amire neked kell. Eltavolitasaval torlodik az egesz memoria. Az ujabb picekben mar finomabb vedelmeket is csinalhatsz, levedhetsz egyes memoriablokkokat kulon-kulon is.

Sziasztok !

Olvastam már erről a problémárol de választ nem találtam rá.
Hiba: MPLAB nem látja a PicKit2-őt az beállított procinál
(PIC16LF1824) de a Pickit2 programmer igen.

Próbáltam a boltilag hozzáadott 8.60-a nem látja, 8.73a-is de annál se.

Esetleg valaki tudja rá a megoldást ?

ui.: a pickit2 eredetileg nem látta a procit, de egy PK2DeviceFile-1.62.09.dat felrakása után tökéletesen megy.

Help me !

Szia!

A PICKit2 fejlesztését a Microchip abbahagyta, az újabb típusokkal nem egészíti ki a rendszert mindenütt. Annak csak örülhetünk, hogy a saját programjába belekerült... A PICKit2 -nél megjelent "Please consider the PICkit 3." még nem olyan erős mint az ICD2 -nél olvasható "Please consider the MPLAB ICD 3 (DV164035). The MPLAB ICD 2 is not recommended for new designs and will not support new MCU or dsPIC devices released after September 2010."...

1. Elindítod az MPLAB-ot, és a programozó "none"-ra állítod.
2. Lefordítod a programot.
3. Elintítod a PICkit2 programját, ás Auto Import funkcióval beégeted.
Ezután - amíg mindkét program fut- a programozó minden fordítás után beégeti az új programot.

Ay MpLab alól való működtetésnek jelentősebb része a nyomkövetés - a debuggolás. Az újabb fejlesztésű kontrollerek többségének nyomonkövetéséhez már a PICKit3 vagy ICD3 szükséges...

Sajnos.

Hát elszomorodtam, de nagyon köszönöm a válaszotokat.

Szia!
18F4523, TMR0, Hi INT, MPLAB 8.6 MPLAB SIM.
A TMR0L beírásakor az előtte értékkel feltöltött TMR0H törtlődik a szimulátorban és nem megfelelő időben szakít meg a Timer. A PIC-ben jól működik. _asm betétben is ezt csinálja, tehát nem a C a hibás elvileg. Láttál már ilyet?

Korrigálok, mert ha nem _asm betétbe írom, akkor a PIC-ben sem módosul a megszakítási ütem!

Bonyolódik:
Ha ezt írom:

nem megy a PIC-ben sem.
Ha ezt:

akkor igen, de így nem kompenzálódik a TMR0...
ASM betétben működik ez a PIC-ben:

De a SIM nem eszi meg egyiket sem. Kicsit morcos vagyok...

Esetleg próbáld meg úgy, hogy TMR0L+=0x10; hátha úgy mást fordít a fordító.

Ez jó ötlet volt, a PIC-ben ez működik, de a SIM-el valami nagy gubanc van! Nem emlékszem, hogy régebben lett volna ilyen! Lehet, hogy ezzel a PIC-el csinálja, megnézem!
Egyébként feltettem azóta a 8.73a-t, aztán a 8.36-ot is, ugyanez van. Talán a C18 lenne a hunyó?

Ha a PIC-ben jól fut a kód, szimulátorban nem, akkor szerintem a szimulátor a hunyó, mert végülis a fordító jó kódot állít elő.

Igen, de a SIM az a fordítóra támaszkodik, vagy az az MPLAB része? PIC specifikus, vagy minden PIC-re ugyan az? Itt inkább a Timer0-ra értem ezt, mert az mindegyikben azonos működésű, nem hinném hogy PIC-enként megírnák külön...

Feltettem egy projectet, amiben a hiba adott.
Egy képet is arról, hogy a TMR0H lenullázódik, hiába töltök bele értéket. Ha valaki tudna rá mondani valamit, annak örülnék! Köszi!

Én úgy gondolom, hogy a szimulátor az a fordító által előállított hex alapján dolgozik, maga a forráskódszintű nyomkövetés pedig az asm listán alapul. De ezt csak én feltételezem így, nem biztos, hogy valóban így is van.