<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>strange swi problems</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/21726/strange-swi-problems</link><description> 
Hello, 

 
I&amp;#39;m working with the MCB2370 board which runs a small program that
puts the adc value onto an oled display and blinks a led every
second. 

 
I&amp;#39;ve created a 1 msec interrupt using timer0 which determines
which task should be started, handling</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: strange swi problems</title><link>https://community.arm.com/thread/99249?ContentTypeID=1</link><pubDate>Fri, 25 May 2007 07:22:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6efcb74b-a1b6-42af-a601-29b10d80435e</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
If you can only start one &amp;quot;process&amp;quot; every ms, and every &amp;quot;process&amp;quot;
is guaranteed to not consume more than 0.3ms - exactly why do you
need nested interrupts?&lt;/p&gt;

&lt;p&gt;
If you have more interrupt handlers that may trig during your
&amp;quot;process&amp;quot; call, then your 0,3ms assumption will not hold anymore.&lt;/p&gt;

&lt;p&gt;
If ADC is the only extremely time-critical task - why not use a
superloop, but let the ADC samples be retrieved by the ADC conversion
interrupt, and stored in a buffer?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: strange swi problems</title><link>https://community.arm.com/thread/75133?ContentTypeID=1</link><pubDate>Fri, 25 May 2007 06:42:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ffde2717-0f66-4d8e-8b79-f7975c961e87</guid><dc:creator>Sander Wiggrs</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;v made the timer interrupt like this so 10 different processes
can be started every 1 msec. In this program only two processes are
enabled but in the future the adc will be started from this routine
too.&lt;/p&gt;

&lt;p&gt;
I don&amp;#39;t use a normal loop since timing of the adc samples is very
critical in my application.&lt;br /&gt;
Every process takes only about 0.3 mSec. so I don&amp;#39;t think this will
be the problem.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: strange swi problems</title><link>https://community.arm.com/thread/50783?ContentTypeID=1</link><pubDate>Fri, 25 May 2007 05:44:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f3163896-cab8-48e1-9b78-b6b22bb2ab5e</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
You have a 1ms interrupt that is incrementing a variable called
something with &amp;quot;10ms&amp;quot; every tick...&lt;/p&gt;

&lt;p&gt;
What is the run time of your function calls? Recursive interrupts
can be quite funny if your function calls can&amp;#39;t keep up.&lt;/p&gt;

&lt;p&gt;
Why don&amp;#39;t you use a normal loop in the main application, which
sleeps until you receve an interrupt, and then checsk which &amp;quot;to-do&amp;quot;
bits that have been set by the interrupt?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>