<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="bbPress/1.0.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>LeafLabs Garden &#187; Topic: I2C ISR problem</title>
		<link>http://forums.leaflabs.com/topic.php?id=68749</link>
		<description>A place to share, learn, and grow...</description>
		<language>en-US</language>
		<pubDate>Fri, 22 Jan 2016 00:18:30 +0000</pubDate>
		<generator>http://bbpress.org/?v=1.0.2</generator>
		<textInput>
			<title><![CDATA[Search]]></title>
			<description><![CDATA[Search all topics from these forums.]]></description>
			<name>q</name>
			<link>http://forums.leaflabs.com/search.php</link>
		</textInput>
		<atom:link href="http://forums.leaflabs.com/rss.php?topic=68749" rel="self" type="application/rss+xml" />

		<item>
			<title>Mike McCauley on "I2C ISR problem"</title>
			<link>http://forums.leaflabs.com/topic.php?id=68749#post-97593</link>
			<pubDate>Wed, 09 Oct 2013 05:47:17 +0000</pubDate>
			<dc:creator>Mike McCauley</dc:creator>
			<guid isPermaLink="false">97593@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;There is a problem with i2c_stop_condition() in i2c.h in libmaple.&#60;br /&#62;
After setting CR1, it waits for the stop condition to occur after the last byte is received. Since this routine is called by  _i2c_irq_handler() it has the effect of putting this polling loop inside the ISR, causing *all* interrupts to be blocked for the entire last byte of the transfer (about 30us in fast mode). This can have serious effects on other ISRs.
&#60;/p&#62;</description>
		</item>

	</channel>
</rss>
