Post by thread:my mpsim problems

Hello you all, First off all: sorry when this message is sended twice to you. It won't happen again! I am new on the piclist group. I have some trouble with the MPSIM simulator. A discussion is going on between me and Microchip, but they don't seem to be able to help me. Can someone help me ?? The conversations with Microchip are below ... Greetings: ... Sipke de Leeuw ... {Quote hidden}>Date: Fri, 15 Mar 1996 09:13:51 +0100 >To: spam_OUTWebmasterTakeThisOuTmicrochip.com (Webmaster) >From: Sipke de Leeuw <.....sdleKILLspam@spam@ensae.ericsson.se> >Subject: Re: Re[2]: mpsim > >Richard, > >Thank you for your quick respons. I still don't understand a few >things. You are right about the interrupt latency. It is described >for the RB0/INT pin. But I have measured the frequency on my test >pin RA1 as described in my previous mail under 1) and the frequency >doesn.t change at all, so I have measured no fluctuation of 0.5 us. > >So I think and I know almost sure that there is NO delta time of .5 us >when using TMR0 int, even though the simulator let me think there is. > >My second problem 2) is also still open: MPSIM does not caluculate the >interrupt latency for TMR0 int ok. MPSIM thinks the interrupt latency >of TMR0 int is 2Tcy in stead of 4Tcy. > >So my questions are: > >1) Is there a delta time for the interrupt latency when using the TMR0 > interrupt? According to my measurements there isn't !!! > >2) Does MPSIM makes a mistake when calculating the interrupt latency? > Again: according to my measurements it does !!! > > >Thanks. ... Sipke ... > > > > >At 15:12 13/03/96 -0700, you wrote: >> Sipke, >> >> The data book, states that for the RBO/INT pin interrupt that the >> latency is the same whether Inst (PC) is a single cycle or a 2-cycle >> instruction. It does not say this about the TMRO interrupt. >> >> The interrupt latency for TMRO is 4Tcy, which at Fosc = 8MHZ is 2uS. >> >> So it is possible that the interrupt occurs during the goto >> instruction and a delta time of .5uS is realized from time to time. >> >> Hope this info helps! >> >> Richard >> >> >>______________________________ Reply Separator _________________________________ {Quote hidden}>>Subject: Re: mpsim >>Author: Sipke de Leeuw <sdleKILLspamensae.ericsson.se> at Internet_Exchange >>Date: 3/12/96 3:26 PM >> >> >>Hi Richard, >> >>Ok, >> >>The best way to explain my problem is to give an example. >> >>I am using the TMR0 to give the program an interrupt every >>say 800 us. The program does the following thing: >> >>interrupt: >> ACKNOWLEDGE INT >> TMR0 := 0x31 >> toggle RA1 >> RETURN FROM INT >> >>main: >> while (TRUE) >> do nothing >> >>I have a breakpoint at address 4 (interrupt). There a two problems: >> >>1) The time between the interrupts are not always exactly the same >> as they should be according the MICROCHIP datasheets. Sometimes it >> is say 800us and sometimes it is 800.5 us. There seems to be a >> fluctuation of 0.5us. (I am running a 16C84 on 8 MHz clock) >> I think it has something to do with the 2 cycle instructions >> as GOTO and CALL. >> In the datasheets it is stated that there are no variable interrupt >> latency when using THR0. So the latency is not increased when the >> interrupt occurs when the processor is executing a GOTO intstruction. >> >>main >> NOP >> GOTO main >> >> In the code as written it occurs very often that the time between >> the interrupts are fluctuating a 0.5 us. When I change the code like >> this: >> >>main >> NOP >> NOP >> . >> . 100 times >> . >> NOP >> NOP >> GOTO main >> >> the problem does occur very less often. So I think it has something >> to do with the termination of the GOTO instruction by an interrupt. >> >>2) Using the code as described in (1). Suppose the MPSIM measured time >> between the TMR0 interrupts is 800 us. (using breakpoint) >> When the time is measured with a frequence counter (on RA1 pin) it is >> 1 us longer than MPSIM let me think it is! My Xtal is exactly running >> at 8MHz. It seems to be that MPSIM does not calculate the 1 us >> fixed interrupt latency extra when a TMR0 interrupt occurs. >> >> >>I hope I have explained my problem clear. If there are questions let me >>know. Thanks. >> >> >>Also have a great day.. ... Sipke ...

Sipke, I haven't seen a lot of other people reply to your request yet, but I will add my two cents on this. I have found that any simulator is going to give you an approximation of what's going to happen. I went through similar problems when I did my code for reading a TV I/R Remote Control. My first version, best case, only had four instruction cycles before the next edge would come in. This turned out to be too close and even though MPSIM indicated that there wasn't any problems, I found a bunch. (Which translates to mean the program couldn't read anything coming through.) My solution was to re-order the program so that I would have 40-50 cycles before the next expected interrupt. At this point, the program worked fine and correlated to the simulator. In the databooks that I have, interrupt latency seems to vary when the edge is received in the instruction timing. This may be what you're seeing here; the simulator doesn't accurately handle at what point the interrupt happens. I don't think this is a Microchip problem, I have seen the same thing on other simulators I have used. The only way you can be absolutely sure that everything will work down to individual instructions is to use an emulator pod (which costs mucho). I have found the best way to ensure your interrupt driven programs work correctly is to leave lots of "space" before and after your expected interrupts. The only analogy I can think of is in terms of Cp and CpK in manufacturing processes. Make sure that your code can handle input irregardless of whether or not the signals come in when you expect. Plot out when you expect them, then give a few instructions on either side and design your program to work right in the middle of that range. Sorry I can't be of more help, Myke {Quote hidden}>Return-Path: <.....owner-piclistKILLspam.....MITVMA.MIT.EDU> >X-Sender: sdle@ensae >Date: Thu, 28 Mar 1996 14:39:29 +0100 >Reply-To: pic microcontroller discussion list <EraseMEPICLISTspam_OUTTakeThisOuTmitvma.mit.edu> >Sender: pic microcontroller discussion list <PICLISTspam_OUTmitvma.mit.edu> >From: Sipke de Leeuw <@spam@sdleKILLspamENSAE.ERICSSON.SE> >Subject: my mpsim problems >To: Multiple recipients of list PICLIST <KILLspamPICLISTKILLspammitvma.mit.edu> >X-UIDL: f1ddf1a5569c441a66c2568944079114 > >Hello you all, > >First off all: sorry when this message is sended twice to you. It won't happen >again! > >I am new on the piclist group. I have some trouble with the MPSIM simulator. >A discussion is going on between me and Microchip, but they don't seem to be >able to help me. Can someone help me ?? > >The conversations with Microchip are below ... > Myke "We're Starfleet officers, weird is part of the job." Capt. Catherine Janeway

Hello, Thank you Myke for your information. I am aware of the simulator 'approximations'. I have't seen a simulator for a processor that works exacltly as the processor itself. Still I think it must be possible to make one ... I do have another, hopefully more interresting, question for this piclist. Is there a difference in interrupt latency time when using the TMR0 as interrupt generator? I personally don't think so because the TMR0 expires always at a known time synchronised to the clock, but I'm not sure. By the way: I'm using the PIC16C84. Greetings to you all: ... Sipke ... At 08:48 29/03/96 EST, you wrote: {Quote hidden}>Sipke, > >I haven't seen a lot of other people reply to your request yet, but I will >add my two cents on this. > >I have found that any simulator is going to give you an approximation of >what's going to happen. I went through similar problems when I did my code >for reading a TV I/R Remote Control. My first version, best case, only had >four instruction cycles before the next edge would come in. > >This turned out to be too close and even though MPSIM indicated that there >wasn't any problems, I found a bunch. (Which translates to mean the program >couldn't read anything coming through.) > >My solution was to re-order the program so that I would have 40-50 cycles >before the next expected interrupt. At this point, the program worked fine >and correlated to the simulator. > >In the databooks that I have, interrupt latency seems to vary when the edge >is received in the instruction timing. This may be what you're seeing here; >the simulator doesn't accurately handle at what point the interrupt happens. > >I don't think this is a Microchip problem, I have seen the same thing on >other simulators I have used. The only way you can be absolutely sure that >everything will work down to individual instructions is to use an emulator >pod (which costs mucho). I have found the best way to ensure your interrupt >driven programs work correctly is to leave lots of "space" before and after >your expected interrupts. > >The only analogy I can think of is in terms of Cp and CpK in manufacturing >processes. Make sure that your code can handle input irregardless of >whether or not the signals come in when you expect. Plot out when you >expect them, then give a few instructions on either side and design your >program to work right in the middle of that range. > >Sorry I can't be of more help, > >Myke > >>Return-Path: <RemoveMEowner-piclistTakeThisOuTMITVMA.MIT.EDU> >>X-Sender: sdle@ensae >>Date: Thu, 28 Mar 1996 14:39:29 +0100 >>Reply-To: pic microcontroller discussion list <spamBeGonePICLISTspamBeGonemitvma.mit.edu> >>Sender: pic microcontroller discussion list <TakeThisOuTPICLISTEraseMEspam_OUTmitvma.mit.edu> >>From: Sipke de Leeuw <RemoveMEsdleTakeThisOuTENSAE.ERICSSON.SE> >>Subject: my mpsim problems >>To: Multiple recipients of list PICLIST <PICLISTEraseME.....mitvma.mit.edu> >>X-UIDL: f1ddf1a5569c441a66c2568944079114 >> >>Hello you all, >> >>First off all: sorry when this message is sended twice to you. It won't happen >>again! >> >>I am new on the piclist group. I have some trouble with the MPSIM simulator. >>A discussion is going on between me and Microchip, but they don't seem to be >>able to help me. Can someone help me ?? >> >>The conversations with Microchip are below ... >> >Myke > >"We're Starfleet officers, weird is part of the job." > >Capt. Catherine Janeway > >

Sipke Wrote... >Hello, ... > >I am aware of the simulator 'approximations'. I have't seen a simulator for a >processor that works exacltly as the processor itself. Still I think it must >be possible to make one ... > Yes, I believe that it's possible to write one as well, and I was going to comment about how much extra time it would take for the Simulator to run. After thinking about it, it shouldn't be tough at all; the big change would be making the simulator input based on time rather than on cycles (as mpsim does). > >I do have another, hopefully more interresting, question for this piclist. >Is there a difference in interrupt latency time when using the TMR0 as >interrupt generator? I personally don't think so because the TMR0 expires >always at a known time synchronised to the clock, but I'm not sure. >By the way: I'm using the PIC16C84. > What I have seen (although with fairly limited experiments and monitoring equipment) is 3 cycles after the edge of the interrupt. I haven't seen any differences. Good luck, Myke "We're Starfleet officers, weird is part of the job." Capt. Catherine Janeway

> >I am aware of the simulator 'approximations'. I have't seen a simulator for a >processor that works exacltly as the processor itself. Still I think it must >be possible to make one ... > Yes, I believe that it's possible to write one as well, and I was going to comment about how much extra time it would take for the Simulator to run. I couldn't resist to comment that it all comes from a certain mindset. This list has some very sophisticated PIC users, who could probably spot and fix simulator bugs before breakfast. They won't, however, because the simulator is an opaque WinDOS executable. This is in contrast with the way things work in _my_ favorite environment, Linux: source (and tools to compile it) is available for everything, and if a bug bothers you enough, you fix it---there is enough users that statistically speaking bugs do get fixed, because someone will always get mad enough to do the work. I understand the need for companies to guard their intellectual property and all that, but such needs are often at odds with sophisticated users' requirements to see what is going on and fix things. I do hope that in the long term companies with open policies will prevail commercially. przemek