- 12V Akku mit 280 Ah bauen         
Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 38

Thema: C-Programm auf XC866 'verzählt' sich

  1. #1
    Ampfing
    Gast

    C-Programm auf XC866 'verzählt' sich

    Anzeige

    E-Bike
    Hallo zusammen,

    ich habe in etwas komplexeres Problem.
    Ich möchte einem Microcontroller vom Typ Infineon XC866 von einem Rechner mit W2k über eine 8-Bit-Verbindung insgesamt 5 Byte übermitteln. Dazu hat der Rechner eine GPIB-Interfacekarte. Vor dem Controller hängt das Gegenstück zu dieser Karte. Sprich, wenn ich im Programm auf dem Rechner sage, ich möchte das 2. Bit im 5.Byte der GPIB-Nachricht setzen wird eine bestimmte Leitung an der Karte vor dem Controller auf high gezogen.
    So habe ich also meine 8 Bitleitungen von der Karte an den Controller verdrahtet. Eine 9. Leitung benutze ich, um dem Controller mit einer steigenden Flanke zu singalisieren, dass jetzt 8 Bit anliegen und er diese bitte 'abholen' soll. Auf die steigende Flanke reagiere ich mit einem Interrupt.

    Im folgenden also meine Interrupt Service Routine (ISR) für die 9. Leitung:
    Code:
    void TriggerISR() interrupt 8
    {
    	IRCON0 &= 0xfb;					//reset IR-Bit of trigger
    
    	switch (counter)
    	{
    		case 0:
    			time1 = P3_DATA; 		//get LSB of time
    			if (time1 == 0)
    			{
    				P0_DATA &= 0xf8;
    				P0_DATA |= 1;
    			}
    			else
    			{
    				if (time1 == 1)
    				{
    					P0_DATA &= 0xf8;
    					P0_DATA |= 2;
    				}
    			}
    			break;
    		
    		case 1:
    			time2 = P3_DATA;		//get 2nd byte of time
    			if (time2 == 0)
    			{
    				P0_DATA &= 0xf8;
    				P0_DATA |= 0x3;
    			}
    			else
    			{
    				if (time2 == 1)
    				{
    					P0_DATA &= 0xf8;
    					P0_DATA |= 0x4;
    				}
    			}
    			break;
    
    		case 2:
    			time3 = P3_DATA;	  	//get MSB of time
    			if (time3 == 0)
    			{
    				P0_DATA &= 0xf8;
    				P0_DATA |= 0x1;
    			}
    			else
    			{
    				if (time3 == 13)
    				{
    					P0_DATA &= 0xf8;
    					P0_DATA |= 0x7;
    				}
    			}
    			break;
    
    		case 3:
    			phase = P3_DATA;		//get phase information
    			if (phase == 0)
    			{
    				P0_DATA &= 0xf8;
    				P0_DATA |= 0x6;
    			}
    			else
    			{
    				if (phase == 128)
    				{
    					P0_DATA &= 0xf8;
    					P0_DATA |= 0x1;
    				}
    			}
    			break;
    
    		case 4:
    			switch (P3_DATA)
    			{
    				case 0:
    					usePhase = 0;		  	//-> phase ignored
    					mainc = 0;				//use serial contactors
    					break;
    				case 1:
    					usePhase = 1;			//-> phase important
    					mainc = 0;				//use serial contactors
    					break;
    				case 2:
    					usePhase = 0;	 		//-> phase ignored
    					mainc = 1;				//use main contactor
    					break;
    				case 3:
    					usePhase = 1;			//-> phase important
    					mainc = 1;				//use main contactor
    					break;
    			}
    			break;
    	}
    	counter++;
    }
    Dabei stellt P3_DATA meine 8 Eingänge dar, an denen die Bytes empfangen werden sollen. An P0.0 bis P0.2 hängen drei high-aktive Dioden, die ich angebracht habe, damit ich mir anzeigen lassen kann, an welcher Stelle im Programm ich bin (debuggen geht leider nicht!).
    Und nun mein Problem:
    Wenn ich eine Byte-Kombination übergebe, die in den if-else-Blöcken abgefangen wird funktioniert alles wunderbar. Wenn ich dagegen eine Kombination übergebe, die nicht in den ersten if-else-Block reingeht springt er mir anscheinend über den zweiten break drüber (Vermutung!) und macht auch gleich noch den case 2 mit.
    Anschaulich heißt das:
    1. Byte = 1
    2. Byte = 0
    3. Byte = 13
    4. Byte = 0
    5. Byte = 2
    --> alles passt!

    1. Byte = 2
    alle anderen Bytes sind egal, er macht mir, sobald ich das zweite Byte übermittle (z.B. ne 0) zuerst ganz kurz die Dioden für die 3 an, anschließend sofort die Diode für die 1!

    1. Byte = 1
    2. Byte = 2
    3. Byte = 13
    4. Byte = 0
    5. Byte = 2
    --> alles passt!!!

    Ich hoffe mal, ihr versteht was ich meine. Wenn nicht fragt bitte nach, dann versuche ich es auf eine andere Art zu erklären.

    Was ich schon alles versucht habe:
    1. In den verschiedenen cases jeweils den counter auf die nächste Zahl zu setzen (statt counter++ am Ende)
    2. In den if-else-Blöcken eine else im if, mit einem return (damit er auch sicher aus der Funktion aussteigt)
    3. einen anderen Interrupt zu nehmen
    4. den switch durch 5-if-Abfragen zu ersetzen
    5. die if-else-Blöcke durch switch mit default-Zweig zu ersetzen
    Hat leider alles nichts gebracht!

    Wieso reagiert das Programm falsch, wenn der erste Wert nicht im if-else-Block abgefangen wird???

    Ich hoffe mal, ihr könnt mir helfen, bin echt schon am verzweifeln!
    Danke fürs lesen und viele Grüße

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Verflixte Sache.
    Setz den Interrupt erst am Ende zurück
    Mach den Reset auf die Led nur EINMAL und zwar vor dem Switch.
    D.h es leuchtet nur was, wenn irgendwas aufgeht.
    Wenn du das Strobe-Signal einzeln setzen kannst, laß' mal die ganze "if"-erei weg uns zeig mit den LED nur 1,2,3,4,.,, für den Counter (binär, logo)
    Der Strobe u. Counter sollten ja schön der Reihe nach kommen.
    Wenn das nicht geht, geht sonst auch nix
    Kommen die Strobes zu schnell, dann setzt immer nur bei einer Zahl eine Led (als Trap)
    --> Es muß mal sicher sein, daß das Zählen funzt, dann geht's erst weiter.
    Es ist zwar reiner Schamanismus, aber schreib in die Switches am Ender jeweils den "default: break;" dazu, nur damit's keine Ausreden gibt.
    fürs Erste
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Ampfing
    Gast

    Jetzt wirds richtig toll....

    Guten Morgen,

    danke für die schnelle Antwort! Bin gestern nur nicht mehr dazu gekommen noch weiter zu basteln.
    Hier also meine Erkenntnisse von heute:
    Ich habe die ganzen if-else-Abfragen auskommentiert, das IR-Bit erst am Ende der ISR rückgesetzt und den Counter an P0 ausgegeben. Und jetzt wirds richtig mysteriös:
    Wenn ich eine Kombination übergebe, die VORHER im if-else des 1. Bytes abgefangen wurde geht alles gut, er zählt ganz normal bis 5 hoch und ich bin glücklich.
    Wenn ich eine Kombination übergebe, die nicht im if-else des 1. Bytes enthalten war (s. Anfangsthread), dann zählt er 1 - 2 und sofort 3 - 4 - 5 - 6!
    Ich habe also ein Oszilloskop drangehängt und mir mal angeschaut, was auf der Interruptleitung passiert. Fazit: Egal, was ich für Werte übergebe, es schaut immer gleich aus (okay, mit gewissen Toleranzen, die von der 'Echtzeitfähigkeit' von Windows kommen)! Sprich, es wird definitiv nur ein Interrupt ausgelöst!!!
    Hab auch bei beiden switches einen default: break eingefügt, hat auch nix gebracht.

    Hast du vielleicht noch Ideen??? Hast ja geschrieben fürs erste

    Im folgenden nochmal mein Code (in der neuen Fassung):
    Code:
    void TriggerISR() interrupt 8
    {
    
    	P0_DATA &= 0xf8;
    	switch (counter)
    	{
    		case 0:
    			time1 = P3_DATA; 		//get LSB of time
    			break;
    		
    		case 1:
    			time2 = P3_DATA;		//get 2nd byte of time
    			break;
    
    		case 2:
    			time3 = P3_DATA;	  	//get MSB of time
    			if (time3 == 0)
    			break;
    
    		case 3:
    			phase = P3_DATA;		//get phase information
    			break;
    
    		case 4:
    			switch (P3_DATA)
    			{
    				case 0:
    					usePhase = 0;		  	//-> phase ignored
    					mainc = 0;				//use serial contactors
    					break;
    				case 1:
    					usePhase = 1;			//-> phase important
    					mainc = 0;				//use serial contactors
    					break;
    				case 2:
    					usePhase = 0;	 		//-> phase ignored
    					mainc = 1;				//use main contactor
    					break;
    				case 3:
    					usePhase = 1;			//-> phase important
    					mainc = 1;				//use main contactor
    					break;
    				
    				default:
    					break;
    			}
    			break;
    
    		default:
    			break;
    	}
    	counter++;
    	P0_DATA = counter;
    	IRCON0 &= 0xfb;					//reset IR-Bit of trigger
    }

  4. #4
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Wenn das 1:1 die SOurce ist, dann hast du einen Hund drin.
    case 2:
    time3 = P3_DATA;
    if (time3 == 0)
    break;
    case 3:

    ! Break ist nur, wenn time3 == 0 !!
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  5. #5
    Ampfing
    Gast

    Abschreibefehler

    Oh, da habe ich mich vertippt. Hab das Problem, dass ich auf 2 Rechner arbeiten muss, weil der Code-Rechner keinen Netzanschluß hat...
    Die if-Abfrage ist im Originalcode nicht drin!
    Also einfach
    case 2:
    time3 = P3_DATA;
    break;
    case 3:

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Ich glaub' dir ja gerne, aber genau bei dem Fehler würde er so wie beschrieben reagieren. (break ist kein Formalismus, sondern das Kommando: "jump loop-exit", kann also auch bedingt aufgerufen werden)
    Also, der Code ist (wirklich) so (abgespeckt) ?:
    Code:
    void TriggerISR() interrupt 8 
    { 
       P0_DATA &= 0xf8; 
       switch (counter) 
       { 
          case 0:          time1 = P3_DATA;         break; 
          case 1:          time2 = P3_DATA;         break; 
          case 2:          time3 = P3_DATA;         break; 
          case 3:          phase = P3_DATA;         break; 
          case 4: 
             switch (P3_DATA) 
             { 
                case 0: usePhase = 0; mainc = 0;   break; 
                case 1: usePhase = 1; mainc = 0;   break; 
                case 2: usePhase = 0; mainc = 1;   break; 
                case 3: usePhase = 1; mainc = 1;   break; 
                default:                                         break; 
             } 
             break; 
          default: 
             break; 
       } 
       counter++; 
       P0_DATA = counter; 
       IRCON0 &= 0xfb;               //reset IR-Bit of trigger 
    }
    Gut. Da aber für das Lämpchenleuchten der ganze Switch irrelevant ist, läuft ja eigentlich nur das:
    Code:
    void TriggerISR() interrupt 8 
    { 
       P0_DATA &= 0xf8; 
       counter++; 
       P0_DATA = counter; 
       IRCON0 &= 0xfb;
    }
    d.h mit switch und break hat das Problem, wenn noch vorhanden, nix zu tun.
    Jetzt kontrollieren wir, ob der Interrupt wirklich nur einmal gerufen wird

    Code:
    static (volatile?) char  bB = 0;
    
    void TriggerISR() interrupt 8 
    { 
       if (bB & 1)    
        P0_DATA = 0x07;   // alle leuchten--> doppel interrupt
       else
       {
          bB |= 1;    
          P0_DATA &= 0xf8; 
          counter++; 
          P0_DATA = counter; 
       }
       IRCON0 &= 0xfb;
       bB &= ~1;    
    }
    dadurch ist das p0-data setzen und counter++ abgesichert

    FÜr weiteren Support wäre eine disassembler-liste hilfreich.

    Wie gesagt, das einzige, was ich ausschließe, ist, daß sich der Controller verzählt. Der Fehler liegt im Interrupt oder doch im Code, auch wenn wir's nicht sehen.
    wie sind die Daten definiert ?
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  7. #7
    Ampfing
    Gast

    Fehler liegt bei dem Interrupt

    Hallo Robert,

    ich habe es zwar etwas anders angestellt als du, aber ich bin mir mittlerweile definitiv sicher, dass ein 2. Interrupt ausgelöst wird, wenn ich die 'falschen' Werte übergebe.
    Ich habe das ganze herausgefunden, indem ich in der ISR nacheinander in jeden case ein EA = 0 (verbietet global ALLE Interrupts) eingefügt habe. Wenn ich den in case 1 reinschreibe und Werte übergebe geht zunächst die erste LED an (für case 0), dann die 2. und dann is Ruhe. Wenn ich die Zeile in case 2 reinschreibe 'verzählt' er sich wieder. Das heißt doch, dass definitiv ein zweiter Interrupt ausgelöst wird, oder?
    Dann ist nur noch die Frage woher...
    Ich würde dir ja gerne ein Bild von meinem Oszilloskop schicken, aber leider kann man hier ja keine Anhänge an den Thread hängen und auf ftp-Server darf ich von hier scheinbar nicht. Also muss ich dir halt so versichern, dass es nur insgesamt 5 steigende Flanken am Eingang des Controllers gibt. Und die 3. kommt ganz sicher erst nachdem er bereits den counter auf 3 erhöht hat.
    Das mit dem Disassembly wird vermutlich relativ schwierig, weil das wieder nur über Screenshot gehen wird, befürchte ich. Da hab ich aber auch schonmal reingeschaut und finde da ehrlich gesagt keinen Fehler. In einer Simulation (ohne Hardware) funktioniert das Programm auch einwandfrei.

    Im Anschluß nochmal ein Originallisting meines aktuellen Programms:
    Datei main.c:
    Code:
    //declaration of functions
    extern void PortInit(void);				//declared in ports.c
    extern void InterruptInit(void);		//declared in int.c
    
    //declaration of variables
    volatile unsigned char counter;					//counter variable for number of trigger events
    volatile unsigned char time1, time2, time3;		//time in ms (LSB to MSB)
    volatile unsigned char phase;					//phase information
    volatile bit usePhase;							//0 if phase is not used, 1 if phase is used
    volatile bit mainc;								//1 if main contactor is used, else 0
    
    void main (void)
    {
    	PortInit();						//initialize the ports
    	InterruptInit();				//initialize the trigger-interrupts
    	counter = 0;					//set starting value for counter
    	EA = 1;							//enable all interrupts globaly
    
    	while(counter < 5);			//wait for 5 transmissions from the computer
    	/*if (mainc == 1)
    	{
    		P0_DATA &= 0xf8;			//close the serial contactors (shoot is performed with main contactor)
    	}*/
    	while(1);
    }
    Datei ports.c:
    Code:
    void PortInit(void)
    {
    	P0_DIR = 0xb;				//P0.0, P0.1 and P0.3 are outputs
    	P1_DIR = 0x0;				//P1.1 is an input
    	P3_DIR = 0x0;				//P3.0 to P3.7 are inputs
    	//for testing:
    	P1_DIR |= 0xc0;				//P1.6 and P1.7 are outputs
    	P0_DIR |= 0x4;				//P0.2 is an output	
    }
    Datei int.c:
    Code:
    extern volatile unsigned char counter;					 	//declared in main.c
    extern volatile unsigned char time1, time2, time3, phase;	//declared in main.c
    extern volatile bit usePhase;								//declared in main.c
    extern volatile bit mainc;									//declared in main.c
    
    void InterruptInit(void)
    {
    	//set priorities of interrupts (shoot = 2, trigger and phase = 1)
    	IP1 = 0x8;							//reset bit for shoot, set bit for trigger
    	IPH1 = 0x4;							//set bit for shoot, reset bit for trigger
    	IP |= 0x4;							//set bit for phase
    	IPH = 0x3b;							//reset bit for phase
    
    	EXICON0 = 0x14;						//edge selection for the three signals
    	IEN0 &= 0xfb;						//disable interrupt for phase (individually)
    	IEN1 |= 0x4;						//enable interrupt for the shoot(individually)
    	IEN1 |= 0x8;						//enable interrupt for trigger  (individually)
    }
    
    void TriggerISR() interrupt 8
    {
     	P0_DATA &= 0xf8;
    
    	switch (counter)
    	{
    		case 0:
    			time1 = P3_DATA; 		//get LSB of time
    			/*if (time1 == 0)
    			{
    				P0_DATA |= 1;
    			}
    			else
    			{
    				if (time1 == 2)
    				{
    					P0_DATA |= 2;
    				}
    			}*/
    			break;
    		
    		case 1:
    			time2 = P3_DATA;		//get 2nd byte of time
    			/*if (time2 == 0)
    			{
    				P0_DATA |= 0x3;
    			}
    			else
    			{
    				if (time2 == 1)
    				{
    					P0_DATA |= 0x4;
    				}
    			}*/
    			break;
    
    		case 2:
    			time3 = P3_DATA;	  	//get MSB of time
    			EA = 0;					//disable all interrupts
    			/*if (time3 == 0)
    			{
    				P0_DATA |= 0x1;
    			}
    			else
    			{
    				if (time3 == 13)
    				{
    					P0_DATA |= 0x7;
    				}
    			}*/
    			break;
    
    		case 3:
    			phase = P3_DATA;		//get phase information
    			/*if (phase == 0)
    			{
    				P0_DATA |= 0x6;
    			}
    			else
    			{
    				if (phase == 128)
    				{
    					P0_DATA |= 0x1;
    				}
    			}*/
    			break;
    
    		case 4:
    			switch (P3_DATA)
    			{
    				case 0:
    					usePhase = 0;		  	//-> phase ignored
    					mainc = 0;				//use serial contactors
    					break;
    				case 1:
    					usePhase = 1;			//-> phase important
    					mainc = 0;				//use serial contactors
    					break;
    				case 2:
    					usePhase = 0;	 		//-> phase ignored
    					mainc = 1;				//use main contactor
    					break;
    				case 3:
    					usePhase = 1;			//-> phase important
    					mainc = 1;				//use main contactor
    					break;
    				default:
    					break;
    			}
    			break;
    
    		default:
    			break;
    	}
    	counter++;
    	P0_DATA = counter;
    	IRCON0 &= 0xfb;					//reset IR-Bit of trigger
    }
    Wie gesagt, das EA=0 in int.c deaktiviert nur alle Interrupts (war zum Testen).

    Vielen Dank für deine Bemühung!!! und viele Grüße

  8. #8
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Ich schau's mir genau an.
    Ein Tip aus alter Zeit:
    Wenn du deine PC mit einem Nullmodem-Kabel verbindest, kannst du mit
    c:>copy file.xx COM1
    bzw.
    c:>copy COM1 file.xx
    Text-Files transferieren. (MODE com1: baud, etc. nicht vergessen)
    Außerdem können viele Terminal-Emu-Programme das und auch binäre daten übertragen
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  9. #9
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Ich kenn den konkreten Controller leider nicht.
    Irgendwie kommen wohl deine Interrupts durcheinander, vielleicht weil du nur eine ISR für zwei Prioritäten hast ? (spekulativ)
    Da müßte man versuchen, die betreffenden Stellen im Datasheet auswendig zu lernen. Da muß ich wohl passen, tut leid.

  10. #10
    Ampfing
    Gast

    Disassembly

    Hallo Robert,

    jetzt hatte doch jemand Erbarmen und hat mir verraten, dass er einen USB-Stick hat...
    Ich habe mal die relevanten Teile des Disassembly rauskopiert (die 1000 NOPs dazwischen also nicht...).
    Code:
    TriggerISR
    C:0x0800    C0E0     PUSH     ACC(0xE0)
    C:0x0802    C0D0     PUSH     PSW(0xD0)
    C:0x0804    75D000   MOV      PSW(0xD0),#0x00
    C:0x0807    C007     PUSH     0x07
    C:0x0809    5380F8   ANL      P0_DATA(0x80),#IP1(0xF8)
    C:0x080C    E508     MOV      A,counter(0x08)
    C:0x080E    14       DEC      A
    C:0x080F    6012     JZ       C:0823
    C:0x0811    14       DEC      A
    C:0x0812    6014     JZ       C:0828
    C:0x0814    14       DEC      A
    C:0x0815    6018     JZ       C:082F
    C:0x0817    14       DEC      A
    C:0x0818    601A     JZ       C:0834
    C:0x081A    2404     ADD      A,#0x04
    C:0x081C    703C     JNZ      C:085A
    C:0x081E    85B00A   MOV      time1(0x0A),P3_DATA(0xB0)
    C:0x0821    8037     SJMP     C:085A
    C:0x0823    85B00B   MOV      time2(0x0B),P3_DATA(0xB0)
    C:0x0826    8032     SJMP     C:085A
    C:0x0828    85B00C   MOV      time3(0x0C),P3_DATA(0xB0)
    C:0x082B    C2AF     CLR      EA(0xA8.7)
    C:0x082D    802B     SJMP     C:085A
    C:0x082F    85B009   MOV      phase(0x09),P3_DATA(0xB0)
    C:0x0832    8026     SJMP     C:085A
    C:0x0834    AFB0     MOV      R7,P3_DATA(0xB0)
    C:0x0836    EF       MOV      A,R7
    C:0x0837    14       DEC      A
    C:0x0838    6010     JZ       C:084A
    C:0x083A    14       DEC      A
    C:0x083B    6013     JZ       C:0850
    C:0x083D    14       DEC      A
    C:0x083E    6016     JZ       C:0856
    C:0x0840    2403     ADD      A,#0x03
    C:0x0842    7016     JNZ      C:085A
    C:0x0844    C201     CLR      usePhase(0x20.1)
    C:0x0846    C200     CLR      mainc(0x20.0)
    C:0x0848    8010     SJMP     C:085A
    C:0x084A    D201     SETB     usePhase(0x20.1)
    C:0x084C    C200     CLR      mainc(0x20.0)
    C:0x084E    800A     SJMP     C:085A
    C:0x0850    C201     CLR      usePhase(0x20.1)
    C:0x0852    D200     SETB     mainc(0x20.0)
    C:0x0854    8004     SJMP     C:085A
    C:0x0856    D201     SETB     usePhase(0x20.1)
    C:0x0858    D200     SETB     mainc(0x20.0)
    C:0x085A    0508     INC      counter(0x08)
    C:0x085C    850880   MOV      P0_DATA(0x80),counter(0x08)
    C:0x085F    53B4FB   ANL      IRCON0(0xB4),#CCU6_CC60RH(0xFB)
    C:0x0862    D007     POP      0x07
    C:0x0864    D0D0     POP      PSW(0xD0)
    C:0x0866    D0E0     POP      ACC(0xE0)
    C:0x0868    32       RETI     
    
                     InterruptInit:
    C:0x0883    75F808   MOV      IP1(0xF8),#counter(0x08)
    C:0x0886    75F904   MOV      IPH1(0xF9),#0x04
    C:0x0889    43B804   ORL      IP(0xB8),#0x04
    C:0x088C    75B93B   MOV      IPH(0xB9),#0x3B
    C:0x088F    75B714   MOV      EXICON0(0xB7),#0x14
    C:0x0892    53A8FB   ANL      IEN0(0xA8),#CCU6_CC60RH(0xFB)
    C:0x0895    43E804   ORL      IEN1(0xE8),#0x04
    C:0x0898    43E808   ORL      IEN1(0xE8),#counter(0x08)
    C:0x089B    22       RET      
    
                     main:
    C:0x089C    1208B0   LCALL    PortInit(C:08B0)
    C:0x089F    120883   LCALL    InterruptInit(C:0883)
    C:0x08A2    E4       CLR      A
    C:0x08A3    F508     MOV      counter(0x08),A
    C:0x08A5    D2AF     SETB     EA(0xA8.7)
    C:0x08A7    E508     MOV      A,counter(0x08)
    C:0x08A9    C3       CLR      C
    C:0x08AA    9405     SUBB     A,#0x05
    C:0x08AC    40F9     JC       C:08A7
    C:0x08AE    80FE     SJMP     C:08AE
    
                     PortInit:
    C:0x08B0    75860B   MOV      P0_DIR(0x86),#time2(0x0B)
    C:0x08B3    E4       CLR      A
    C:0x08B4    F591     MOV      P1_DIR(0x91),A
    C:0x08B6    F5B1     MOV      P3_DIR(0xB1),A
    C:0x08B8    4391C0   ORL      P1_DIR(0x91),#T2CON(0xC0)
    C:0x08BB    438604   ORL      P0_DIR(0x86),#0x04
    C:0x08BE    22       RET
    Die erste Spalte ist jeweils die Adresse.
    Auf Adresse 0043 steht ein Jump auf die TriggerISR (sprich, das ist der Interrupt-Vektor für diesen Interrupt).

    Wieso habe ich einen Interrupt für 2 Prioritäten? Das mit IP und IPH kommt daher, dass es 4 Prioritätsstufen gibt und die 2 Bit auf die zwei Register verteilt sind.

    Nochmal vielen Dank und viele Grüße

Seite 1 von 4 123 ... LetzteLetzte

Benutzer, die dieses Thema gelesen haben: 0

Derzeit gibt es keine Benutzer zum Anzeigen.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests