megszakítások !! egy pici elakadás!

Ha nem okoz gondot....

Bár azért én max egy jelzőbitet bebillentek ilyenkor és a kiirandó adatokat egy stringláncba másolok....

És a főprogramban kiiratom - de utána akkor a jelzőbit már 0 (megtörtént a kiírás) és az INT részen csak ekkor változik a string értéke....

kefeur

Ez ugye vicc !
Nekem nincs benne a Bascom - ban.
Na de van honnan letölteni ha valami hiányzik .

Köszi a példát

Én a Bascom 11193-at latom magam elott:
Samples/PCINT_CHANGE.bas

Kód: Egész kijelölése

'---------------------------------------------------------------------------
'                       (c) 1995-2005, MCS Electronics
'                             PCINT_CHANGE.BAS
' This sample shows how to use the PC interrupts
'---------------------------------------------------------------------------

$regfile = "m88def.dat"
$crystal = 8000000
$baud = 19200

Print "{027}[2J";                                           ' when you have a terminal emulator, this will clear the screen
Print "Test M88 ints"                                       ' init message

'The M88 and M168 can detect a level change on all port pins.
'We will just check on portB, pins 0-3

Config Portb = Input
Portb = &HF                                                 'activate pull up

Enable Interrupts                                           'enable global ints
Enable Pcint0                                               'we enable pcint0 as this has pcint0-pcint7
On Pcint0 Isr_pcint0                                        'we jump to this label when one of the pins is changed
Pcmsk0 = &B00001111                                         'enable pcint0-pcint3  (portb.0-portb.3)
'With pcmsk you individual select which pins must react on a logic level
'When you write a 1, the change in logic level will be detected.

Do
  nop
  'you can do anything here
  'But we show how to use the pin level change in manual mode without interrupts
  'Say we want to detect logic level change of pin 23, (PINC.0) / INT8
  Config Pinc.0 = Input                                     'you can also detect output changes but we use input
  Pcmsk1 = &B00000001                                       ' enable the bit of PCINT8 which is in PCMSK1
  If Pcifr.pcif1 = 1 Then                                   ' change detected
      Print "pinc.0 has changed"                            'in this case it must be pinc.0
      Pcifr.pcif1 = 1                                       ' write a 1 to clear the flag so we can detect it again
  End If
Loop


Isr_pcint0:
  Print "Pin change " ; Bin(pcmsk0) ; Spc(3) ; Bin(pinb)
  'As you see the mask does not change, so to find out which pin changed,
  'you need to read the PINB register.
Return

End

kefeur

Na igen .
Ez nincs benne.

Illetve mostmár benne lesz .

bgergo

Benne van az: C:\Program Files\MCS Electronics\BASCOM-AVR\SAMPLES

Megszakításban nem írok az lcd-re, csak a próba kedvéért raktam bele

kefeur

Az lcd nem oda való nálam, mert nincs rá idő .
Ellenben tényleg nem volt benne 4 másik mintaprogi sem a könyvtárban .
Sérült volt a progi .

Eddig nem tudtam mi volt a figyelmeztetés telepítés végeztével , már tudom .

gerry

Üdv!
Megen egy kis segítségre lenne szükségem.

Adott int0 és int1 megszakítások. Ezek IMPfel, IMPle vannak konfigurálva.

szeretném ezeket a megszakításokat egy disable interrupts utasítás után újrakonfigurálni, mert a programba máshol más funkciót szeretnék adni neki. Ha ezt megteszem, akkor a program az ujradefiniálási hibával kilép a fordítóból.
Lehetséges újrakonfigolni 1 programon belül ugyanazon megszakításokat, vagy csak 1szer a program elején?

Köszönöm

kapu48

Igen újrakonfigurálni lehet. De új belépési címet adni nem lehet!

Kód: Egész kijelölése

$regfile = "M16def.dat"
$crystal = 4000000

Dim Cntr As Integer , Cntr2 As Integer , Flag As Bit

On Int0 Button
Config Int0 = Low Level
'Config Intx = Falling
'Config Intx = Rising

Cls

Enable Interrupts
Enable Int0

Do
  Locate 1 , 1
  Lcd Cntr
  Wait 2
  Flag = 0
  Config Int0 = Falling
  Locate 2 , 1
  Lcd Cntr2
  Wait 2
  Flag = 1
'  On Int0 Button2        'EZT már nem lehet
  Config Int0 = Rising

Loop

Button:
  If Flag = 1 Then
   Incr Cntr2
  Else
   Incr Cntr
  End If
Return

Button2:

   Decr Cntr

Return

End

gerry

Értem köszönöm!

nobody_hun

Nem régiben kapu48-cal vívtunk szájkaratét

a megszakítások kapcsán, most én szaladtam bele egy dologba, amivel nem boldogulok:

Egy programon belül 3 megszakítást használok:
-Belső óra SECTIC-je
-Egy külső hw az INT0-n
-Hardveres soros port

Nos ez utóbbinál van a probléma. Rapszódikusan a chip újraindul, ha adatot küldök neki. Van, hogy folyamatosan 10-15 adatátvitelt lebonyolít, majd egyszer csak újra indul.

Ha nincs adatátvitel, a program hibátlanul fut, akár több napon át is.

Próbáltam, hogy soros fogadás elején letiltom az első két megszakítást, majd vissza, de nem segít.

Arra tippelek, hogy az ISR szállhat el (és vagy az SREG). Még azt nem próbáltam, hogy ez(eke)t elmentem és visszatöltöm.

Egyéb ötlet?

A HWStack/SWCheck/Frames-ból futsz ki.
A Bascomkönyv hibakeresés fejezetét lesd meg és a stcheck utasítás környékén keresgélj (plusz Err változó).

nobody_hun

Ez volt a baj, köszönöm a segítséget!

A paraméterekkel hívott sub-ban levő újabb paraméterekkel hívott sub-ok zabálják a stack-et...

Jó tanulság volt!

DOGMAN

nobody_hun írta:Ez volt a baj, köszönöm a segítséget!

A paraméterekkel hívott sub-ban levő újabb paraméterekkel hívott sub-ok zabálják a stack-et...

Jó tanulság volt!

Megosztanád, hogy miképp jöttél rá a helyes beállításokra?
Én is ilyen hibával küzdök:
program stabilan fut bármeddig, de ha elkezdem soros porton az adatokat küldeni neki, akkor 10-ből 8-szor lefagy, LCD-re irreális értékeket ír ki, és megáll.

Minél jobban lelassítom Pc oldalról a küldés ütemét (nem baudot!! PC-n fut egy program, egy timer van benne (ezt tudom lassítani/gyorsítani) ami egy 15 hosszú karaktersorozatot küld át a kontrollernek.), annál jobban ritkul a fagyás.
Tehát biztos hogy a Pc-ről érkező adatok mennyisége miatt van a galiba.

Feldolgozása: do loop-on belül inkey-el elkapom a soros port buffer tartalmát, és egy string változóba gyűjtöm, majd ha adott karakter ér be a bufferba feldolgozom.

Program persze nincs itt nálam, de eddig is ezen a módon olvastam a soros portot és sosem volt vele ilyen gond.

Hardveres PWM kezelés van, lehet hogy ez veszi el az időt a szoftveres feldolgozástól?
Ha átírnám megszakítás vezéreltre a soros port kezelést, akkor a lehet, hogy a hiba megszűnne?

A SUBban a stcheck utasítást kiadod és a kapott Error értéket kiiratod. Ha nem 0, akkor stack/frames hiba van.
Első sorban (ha van sszabad SRAMod), duplázd meg mindegyik értékét...

A Bascom könyv: Hibakeresés fejezet utolsó harmadában a megoldás:)

A soros vétel esetén érdemes berakni a Config serialin=buffered, 20 sort (20 karakteres buffered van:) )

DOGMAN

Robert írta: A soros vétel esetén érdemes berakni a Config serialin=buffered, 20 sort (20 karakteres buffered van:) )

Ez a sor bentvan...
Sub-ok nincsenek, gosub/return-al ugrok feltételeknek megfelelően az alprogramokra.
Ennek a soros buffernek a túlcsordulását lehet valahogy szoftverből detektálni, és pl mielőtt túlcsordulna üríteni?
Inkább maradjon ki adat, minthogy megfagyjon az egész.

Bascom könyv idevaló fejezetét természetesen elolvastam...
Ha a "A $Dbg utasítás..." fejezetben levő dolgot megcsinálom, fog küldeni egyáltalán adatot vissza?? Mert valószínűleg azonnal meghal a proci ha soros porton adatot kap. Ha elvileg így is tud visszaküldeni debug adatokat a terminálba, akkor ezt is kipróbálom.