<?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: board 100-pin package</title>
		<link>http://forums.leaflabs.com/topic.php?id=1329</link>
		<description>A place to share, learn, and grow...</description>
		<language>en-US</language>
		<pubDate>Fri, 22 Jan 2016 00:07:43 +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=1329" rel="self" type="application/rss+xml" />

		<item>
			<title>siy on "board 100-pin package"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1329#post-8163</link>
			<pubDate>Fri, 10 Feb 2012 08:06:00 +0000</pubDate>
			<dc:creator>siy</dc:creator>
			<guid isPermaLink="false">8163@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;Hmm. This is interesting. Perhaps it worth to do something like following: keep two male bottom rows as is, but provide double (either, male or female) rows at top located in parallel to bottom rows. This would enable use part of pins for external connections at breadboard and provide full set of pins at top, so top headers will be suitable for shields. Since for top header there is no need to maintain breadboard compatibility, double headers will not be an issue. Also, to get necessary pin count, additional top double header will be necessary (like in Native, perpendicular to side headers, but only two rows of pins rather than three). What do you think?
&#60;/p&#62;</description>
		</item>
		<item>
			<title>bubulindo on "board 100-pin package"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1329#post-8162</link>
			<pubDate>Fri, 10 Feb 2012 07:40:20 +0000</pubDate>
			<dc:creator>bubulindo</dc:creator>
			<guid isPermaLink="false">8162@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;I like the Native approach. especially if you leave the bottom of the board pins for the FSMC interface (which will require a dedicated board) or the C option. Although, I would prefer to have the female headers and a second row of male headers coming from the bottom. That would allow you to create a shield and prototype with the same design. &#60;/p&#62;
&#60;p&#62;The A option is not such a problem. All my breadboards are over 85mm, although not all of them have even spacing. Some split in the middle which can be a problem. &#60;/p&#62;
&#60;p&#62;Don't use double rows unless you already have expansion boards prepared for that design. I see that now with my discovery board, I can't plug it anywhere and I need to find headers to break those into breadboard. It's not that difficult, but it's messy and those flat cable to breadboard connectors are hard to come by. &#60;/p&#62;
&#60;p&#62;Regarding the D option. If all or most board manufacturers decided on a standard interface connector (something like Olimex makes on their boards), this would in fact be quite valuable. Since there is no such agreement, I think this would only make expansion designs a bit harder. Although, there is the advantage that one doesn't necessary need to piggyback the mains board and expansion.
&#60;/p&#62;</description>
		</item>
		<item>
			<title>siy on "board 100-pin package"</title>
			<link>http://forums.leaflabs.com/topic.php?id=1329#post-8161</link>
			<pubDate>Fri, 10 Feb 2012 06:49:05 +0000</pubDate>
			<dc:creator>siy</dc:creator>
			<guid isPermaLink="false">8161@http://forums.leaflabs.com/</guid>
			<description>&#60;p&#62;While working on the design of the board for the 100-pin package I've found that if I'll follow approach taken for Mini64 - provide as much MCU pins available on the headers as possible - then I need a lot of additional pins (comparing to Mini64). This is not a problem in general, but if preserving compatibility with breadboard is a goal, then there are not so many options:&#60;/p&#62;
&#60;p&#62;a) Extend outer rows to 32 pins each and inner rows to 16 pins each. This provides 2 x 32 + 2 x 16 = 98 pins which is more than enough for the 100 pin package (16 pins in package are used by GND/power/main crystal/etc. and are don't need to be broken out).&#60;br /&#62;
Pros: rather simple to implement and provides enough room for further extension (I think that it has enough pins even for 144-pin package).&#60;br /&#62;
Cons: not every breadboard can accept 32-pins; board will be rather big (at least ~85mm long).&#60;/p&#62;
&#60;p&#62;b) Use double pin headers for outer rows. This provides 2 x 2 x 20 + 2 x 8 = 96pins. Still more than enough for 100-pin package.&#60;br /&#62;
Pros: still simple for implementation, board will be rather compact&#60;br /&#62;
Cons: might not be breadboard compatible (at least not with every breadboard); &#60;/p&#62;
&#60;p&#62;c) Use something like Maple Native approach, i.e. two side rows and header with multiple rows at top. This approach allows to provide as many pins as necessary in addition to 40 pins in two side rows.&#60;br /&#62;
Pros: breadboard compatible, rational use of PCB space&#60;br /&#62;
Cons: preparing layout might be complicated if there will be more than 2 rows in top header&#60;/p&#62;
&#60;p&#62;d) Do not try to provide all MCU pins at headers. Instead provide as many as practical at side rows and provide dedicated connectors for SPI, USART, I2C at top.&#60;br /&#62;
Pros: obviously, not all pins are available for use, using alternative functions for pins will be inconvenient&#60;br /&#62;
Cons: simple use of dedicated interfaces&#60;/p&#62;
&#60;p&#62;I'd like to discuss this issue with community, and try to prepare board which will be convenient for as many use cases as possible. So, comments, ideas and suggestions are welcome.
&#60;/p&#62;</description>
		</item>

	</channel>
</rss>
