<?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>Higher Priority on UART1</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/22408/higher-priority-on-uart1</link><description> 
How can I increase the interrupt priority of UART1 of the
LPC2364? 
Due to heavy load on timer interrupts, I&amp;#39;m missing receiving
characters every 5 - 10 seconds. 

 
The initialization of UART1 is as follow: 

 
void enableUART1(void)
{
 VICVectAddr7</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/142016?ContentTypeID=1</link><pubDate>Mon, 02 Jun 2008 02:36:14 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a9633a0b-180d-4b83-861f-22f63b3d4d41</guid><dc:creator>marine boy</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi, people,&lt;/p&gt;

&lt;p&gt;
I&amp;#39;ve tried your project and It&amp;#39;s works fine...&lt;br /&gt;
Thanks again...&lt;/p&gt;

&lt;p&gt;
Regards,&lt;br /&gt;
Marine bOY&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/138790?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 02:58:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2c1f24fb-fe36-41d4-a9da-b9439405997b</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
Per&amp;#39;s comments are very correct. What you can do to calculate your
timing budget is create a table that contains all the time consuming
operations in your system in the form of period, duration, total
cost. if you know that your system should do all its work within
X[ms] (that is usually the least common multiple of all periods),
then you can calculate a worst case scenario and the CPU load. this
assumes of course a simple scheduling (non-preemptive).&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/135390?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 02:42:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f54d01d7-0d10-4cd5-b20c-939e078a3f29</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Try to measure the min/max/avg time consumed by each individual
interrupt.&lt;/p&gt;

&lt;p&gt;
Then look at the expected frequency (at burst rate) for the
individual interrupts. Check if you have the raw processing power to
fulfill your requirements.&lt;/p&gt;

&lt;p&gt;
Unless the protocol or connection mode have very strict timing
requirements for the serial communication, it may be far worse to
increase the UART priority.&lt;/p&gt;

&lt;p&gt;
You should - at all times - have enough processing power to be
able to service all critical interrupts within the allowed latency
and still have a reasonable amount of time left for non-critical
interrupts and any main loops. If you don&amp;#39;t have nested interrupts
(which really complicates your analyses) then you should consider all
interrupts as critical, and see what happens if all interrupt sources
are trigged almost at the same time, with the longest-running
low-priority interrupt arriving just before all others.&lt;/p&gt;

&lt;p&gt;
Will you still be able to service all interrupts (potentially
multiple high-priority interrupts before the last low-priority
interrupt) without failing any interrupt, and without failing your
narrowest timing-requirement in any main loop?&lt;/p&gt;

&lt;p&gt;
Everything isn&amp;#39;t testable but you need to produce some form of
confidence intervals for the system, or you need to perform
traditional testing at a significantly higher load (higher baudrates
with faster/longer bursts of data) etc. than the system will be used
for in real life.&lt;/p&gt;

&lt;p&gt;
In some situations you can let different parts of the software
drive a large number of LED and use a logic analyzer or similar to
trace the LED pattern. Just remember that a LED turned on/off in an
ISR does not represent the time needed to enter/leave the ISR.&lt;/p&gt;

&lt;p&gt;
Anyway - it is very important to have a lot of spare capacity,
since &amp;quot;normal&amp;quot; testing seldom manages to come close to worst-time
scenarios. Some worst-case scenarios may be hard to even identify,
and you can&amp;#39;t create a test case for a scenario you can&amp;#39;t
identify.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/124694?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 02:07:49 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a8ea44bf-a1a8-4cbd-9336-533ebde3e84f</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Now I will run some tests and look for some sideeffects
(timers).&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Are your tests going to catch that &amp;quot;little once-a-month&amp;quot; glitch ?
What about &amp;quot;once a year&amp;quot; ? If it&amp;#39;s a high volume product, or a
safety-critical product, these little glitches can turn into major
headaches.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;But I also will think about your inputs, specially at the one
about what I&amp;#39;m doing within the UART-interrupt.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
What you should do first is have a good, close look at your timers
ISRs. If they are starving the UART ISR, chances are good that there
is way too much work packed in the timer ISRs that can (and should
be) done outside the ISR.&lt;/p&gt;

&lt;p&gt;
Just out of curiosity, what baudrate are you running the UART at
?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/113976?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 01:08:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:06a43c11-a6ef-4958-a0d6-8a5244f10e84</guid><dc:creator>Peter Keller</dc:creator><description>&lt;p&gt;&lt;p&gt;
Many thanks to all of you.&lt;br /&gt;
For the moment, the problem seems to be solved by increasing the
priority. Now I will run some tests and look for some sideeffects
(timers).&lt;br /&gt;
But I also will think about your inputs, specially at the one about
what I&amp;#39;m doing within the UART-interrupt.&lt;/p&gt;

&lt;p&gt;
The other thing is setting the trigger to 14 chars and&lt;br /&gt;
look for the CTI.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/100697?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 00:47:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:13bd60e0-2866-4b58-9b01-2d8f6052a205</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;But what happens if I receive a string of only 11
characters?&lt;/i&gt;&amp;lt;p&amp;gt;&lt;/p&gt;

&lt;p&gt;
If you want to receive every single character, set the UART to
raise an interrupt as soon as there is one character in the FIFO. The
beauty about the FIFO is that even if the UART has received
additional characters by the time the uC starts the ISR, these
additional character are not &amp;quot;lost&amp;quot;, but stored in the FIFO, and you
can read them from there.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/100701?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 00:44:09 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f7401033-f659-4ad0-8bfe-f7ad823df3d8</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
You can get interrupts both when you pass the FIFO trig level
(configured in UxFCR) but you can also get a Character Time-out
indicator (CTI).&lt;/p&gt;

&lt;p&gt;
Chapter 16, paragraph 4.5 in the user manual describes this. You
will get a CTI when you have data in the receive FIFO but haven&amp;#39;t
received any new character in 3.5-4.5 character times. This interrupt
allows you to retrieve any remaining character from the RX FIFO.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/89073?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 00:36:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d405be2c-245f-417d-96e6-3590b6452d9f</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
I can only agree. FIFO and correctly implemented ISR (all of them)
should allow the processor to take quite a punishment without
dropping characters.&lt;/p&gt;

&lt;p&gt;
You have a data structure with a lot of start and stop characters
and timeout. Are you sure that you don&amp;#39;t let your serial port ISR do
too much work?&lt;/p&gt;

&lt;p&gt;
Are transmit and receive being multiplexed on the same wire, so
that you need to implement a bus logic where you very quickly has to
change the traceiver from transmit to receive when you detect an
end-of-frame?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/76339?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 00:33:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9e9daca4-f971-498d-9675-2f99cc149023</guid><dc:creator>Peter Keller</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Frank&lt;br /&gt;
That&amp;#39;s what I&amp;#39;m thinking about now.&lt;br /&gt;
But, I don&amp;#39;t understand this with the FIFO exactly:&lt;br /&gt;
If I set&lt;/p&gt;

&lt;pre&gt;
U1FCR = 0x01;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
then FIFO is enabled and will interrupt on every character.&lt;br /&gt;
But if I set&lt;/p&gt;

&lt;pre&gt;
U1FCR = 0xC1;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
then it will only interrupt on every 14th character.&lt;br /&gt;
But what happens if I receive a string of only 11 characters?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/51804?ContentTypeID=1</link><pubDate>Fri, 30 May 2008 00:05:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ef0220b4-8b06-4e40-806f-79bbec079bac</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;How can I increase the interrupt priority of UART1 of the
LPC2364?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Are you sure that this will solve your problem ? Instead of
missing UART events, your system might start missing (or reacting too
late to) timer events.&lt;/p&gt;

&lt;p&gt;
Have you looked into other ways to solve the problem ? According
to the datasheet, the UART on your device has 16 byte transmit and
receive FIFOs. If you use them, and your timer interrupts still need
more time than the UART needs to receive 16 bytes (for usual
baudrates, that&amp;#39;s a small eternity for a uC), then are you sure you
followed the KISS (Keep ISRs short and simple) strategy for your
timer ISRs ?&lt;/p&gt;

&lt;p&gt;
And if the FIFO is not large enough, there is still the
possibility of using DMA to handle the UART transfers, which will
basically give you a buffer size equal to any RAM you can spare.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/49962?ContentTypeID=1</link><pubDate>Thu, 29 May 2008 22:12:45 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6c574af-7fa9-4c97-8e8a-5ffeaaf2c414</guid><dc:creator>Robert &amp;#160;</dc:creator><description>&lt;p&gt;&lt;p&gt;
VIC (Vectored Interrupt Controller) in LPC23xx has registers
VICVectPriorityX (x=0..31) which set the Interrupt Priority for each
IRQ from 0 (highest) to 15 (lowest). After reset all priorities are
set to 15.&lt;/p&gt;

&lt;p&gt;
You need to set the priority for UART1 which will be in your case
VICVectPriority7 = 0 (highest priority).&lt;/p&gt;

&lt;p&gt;
Please check the NXP user manual for more details.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Higher Priority on UART1</title><link>https://community.arm.com/thread/49963?ContentTypeID=1</link><pubDate>Thu, 29 May 2008 12:38:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6fc899a6-ed41-4e69-95f7-e0c00f5bec7d</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
adjusting interrupt priority levels for an STR7 is done like
this:&lt;/p&gt;

&lt;p&gt;
via ST library:&lt;/p&gt;

&lt;pre&gt;
EIC_IRQChannelPriorityConfig(T3TIMI_IRQChannel, 1);
&lt;/pre&gt;

&lt;p&gt;
or directly:&lt;/p&gt;

&lt;pre&gt;
EIC-&amp;gt;SIR[IRQChannel] = (EIC-&amp;gt;SIR[IRQChannel]&amp;amp;0xFFFF0000) | (u16)Priority &amp;amp; 0x000F;
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>