I think there are also reasons why designs may go with separate radio & microcontroller chips.
Much of the 802.15.4 is focused on the 2.4 GHz band, but of course the 900 MHz band is also available. This band offers significant propagation advantages in some environments. A product could be designed which can use the same PCB for both 2.4 GHz and 900 MHz by populating different radio chips and associated externals for the radio chip. Currently I don't see any 900 MHz SOC offerings, but I assume maybe I just missed them. When using separate chips, there are incentives to lower costs by using a smaller/cheaper microcontroller. Of course less SRAM also results in less power consumption too (even when sleeping); for parasitic power nodes this could be very important. Besides those technical reasons, I think there are a variety of 'human' reasons to keep code size down. People have been calling for the demise of small 8-bit microcontrollers for years, but they still seem to hang around. This is despite the fact you can buy a larger ARM device for cheaper than an 8-bit device. Their continued popularity shows that we cannot just dismiss them on technical grounds. Many potential 6LoWPAN users may simply be put off by large code requirements. Their current products mainly use 8-bit microcontrollers, hence they want to continue using the small 8-bit micros. I couldn't find the study I was looking for, but the next-best thing is this phrase from an Atmel WP [http://www.atmel.com/dyn/resources/prod_documents/doc7926.pdf]: " In 2006, 9% of 8-bit embedded applications used 64KB or more program memory, representing 26% of the 8-bit MCU revenue. Projections for 2009 say 14% of the 8-bit embedded applications representing 36% of the revenue will use 64KB or more program memory. [Source: MCU memory trends. Semico 2007] " Which still looks like a lot of smaller devices around to me. So why put size targets in the 6LoWPAN charter? It helps to keep the total stack something manageable. The idea of keeping the small devices on a gateway, free to run their own special protocols, seems counter-productive to me. Everybody should be welcome on the 6LoWPAN network directly; including those dreadful 8-bit micros. Otherwise the result will probably be a massive stack that doesn't fit most devices out there. I'm not saying we should limit ourselves to small devices, just we can't dismiss them outright. Regards, -Colin O'Flynn -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Henning Schulzrinne Sent: November 11, 2009 10:13 AM To: Richard Kelsey Cc: [email protected]; [email protected] Subject: Re: [6lowpan] [6lowapp] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] The charter is presumably a draft, not a consensus. The numbers in the charter seem to lack rigorous justification, so I'm not comfortable with them as they stand. So, yes, I'm suggesting to either drop the numbers or make them more useful. In addition, memory size arguments are not terribly helpful unless each proposal will have a canonical implementation in the I-D. At least from my experience, people are very bad at estimating implementation complexity, except that one's own proposal by definition has lower complexity than any competing proposals. Henning On Nov 10, 2009, at 6:13 PM, Richard Kelsey wrote: > Date: Tue, 10 Nov 2009 11:13:24 -0800 > From: Kris Pister <[email protected]> > > I think that today's things are being designed with > wonderful chips like your Ember EM351 and EM357 which > have 128kB and 192kB of flash and lots of RAM; like the > Jennic JN5148, the Freescale MC13224, the Dust DN2510. > They can run IP, they will run IP, and in many cases they > do run IP. > > Kris, > > Their wonderfulness aside, those chips are not what the > 6lowpan charter describes. Yes, I agree that rechartering > for bigger platforms would make our job easier, and could > reduce the number of new protocols needed. I am not arguing > for or against it, just asking you if you are proposing that > we amend the charter. If not, then we should use the specs > that it has. > -Richard Kelsey > _______________________________________________ > 6lowapp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowapp > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
