Ian - motes today have between 2kB and 10kB of RAM typically, and 50kB to 128kB of flash. Many have a separate flash with many hundreds of kB (slower, more energy intensive to access). Cheap processors have come a long way since the first motes in 2000/2001 where we had 8kB of flash and 512B of RAM (but still did some pretty neat things, e.g. http://robotics.eecs.berkeley.edu/~pister/29Palms0103). People are spoiled now, and it's only going to get worse. I mean better. Several companies have demonstrateded and/or announced motes with 32 bit processors and ten times more RAM and flash. These 32 bit cores often burn less power per MHz than the cheesy 8 bit processors with which they compete. You can assume that others will follow suit. In 0.18um CMOS, you get about 10kB of SRAM per square millimeter, and 100kB of flash per square millimeter. 32 bit cores are around a half a square millimeter. 8 bit cores are only about half that size. Radios and all of the analog peripherals are very very roughly 5mm2. In volume, tested functional chips cost very very roughly $0.10/mm2 . So today a 32bit core and 100kB of flash and 10kB of RAM is comparable in size to the radio+peripherals. Radios and most of the peripherals don't scale much as you go to 0.13um or 90nm, but the digital does, so in a few years the cost of the core(s) and memory will have shrunk by 2..,4..,8..X, or more likely the relative die area will be about the same, but you'll just have a lot more memory. Transmitted packets cost you a few milliseconds at roughly 20mA today, or roughly 100uC (microCoulombs). The trick is receiving the packet - how do you know when it's coming? There are several approaches: * If you're time-synchronized, then the receiver can turn on for a couple of milliseconds and cost you maybe 50 uC if there's no packet, and 100uC if there is one. If you do this once a second, that's 50uA to get 1/2 second average latency when idle, or 100uA to receive one packet per second. That's TSMP (time synchronized mesh protocol). * If you don't want to time synchronize, you can do preamble sampling. You still turn your receiver on regularly, and listen to hear if anyone is transmitting a long preamble. If they are, you stay awake until the packet shows up. This is LPL (low power listening) if you're a tinyOS person. You burn less charge on the listens - maybe only 20uC if there's nothing to hear - but you probably want to do them more often. If you sample once per second, then maybe you only burn 20uA to get the same 1/2 second latency, but...now the transmitter of a packet has to send a 1 second long preamble before each packet so that you stay awake, meaning a TX now costs 20,000uC, not 100uC. The receiver on average is going to have to listen to half of the preamble, which is going to cost 10,000uC if you only sample once a second. So you probably sample a lot more often, and burn a lot more power on idle listening. Not very efficient, but hey, at least it's easy. * If you're lucky enough to have a powered infrastructure, then use WiFi. Hmm. Try again: if you're lucky enough to have a powered infrastructure, and for some reason are still interested in using 802.15.4, then transmit whenever you want, and listen immediately after your transmitions to see if the local powered router has anything to say to you in return. ksjp -- Prof. EECS, UC Berkeley Founder & CTO, Dust Networks
________________________________ From: Ian Chakeres [mailto:[EMAIL PROTECTED] Sent: Wed 5/9/2007 6:34 PM To: 6lowpan; [EMAIL PROTECTED] Cc: Charles E. Perkins (work) Subject: [6lowpan] Re: 6lowpan devices constraints Also, I'm adding RSN. It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
