From: Eric Decker [mailto:[email protected]] Sent: Tuesday, November 19, 2013 20:49 To: Michiel Konstapel Cc: [email protected] Subject: Re: CC430
On Tue, Nov 19, 2013 at 3:36 AM, Michiel Konstapel <[email protected]<mailto:[email protected]>> wrote: What would be the best jumping off point for our CC430F5137 based platform? First the choice of the CC430f5137 isn't great. It doesn't have much code space and it has very little RAM. 32K code and 4K RAM. But if that works for you great. If you can handle switching to 2.4GHz, the CC2538 looks very interesting. Its an ARM Cortex-M3 core coupled to a 2520 radio. But I'd recommend, using the 5438 coupled to a 2520/2591 (with range extender). I've just finished rewriting the 2520 driver. Hi Eric, thanks for the quick and thorough reply. These are not development boards, but are intended to replace the 247 + CC1101 combination we currently use in nearly all our sensor nodes. Most of our networks have powered gateways and routers which do the "heavy lifting", and those have a 2418 to run CTP, Dissemination and other protocols. The leaf nodes don't need to mesh, and are only active when needed. Something like a 2418 would be hugely overdimensioned, and way too expensive for hundreds of nodes. The range extenders are very cool, we did some tests with the CC1190. But again, these need to be cheap and extremely low power. Would be nice to design them into a router, though. I'd also strongly recommend that you have somekind of non-vol storage that you can put core dumps into for failure analysis. tp-master has a Panic facility that I use for paranoid code. The mainline has a simple_panic which works well for debugging (put a single breakpoint in the panic code). But my main tag has a SD card with tons of storage and I put core dumps into that. If you are deploying in anykiind of reasonable fashion, things will go wrong. And figure that out will be the lion's share of time involved in making this stuff real. I write my code with that in mind. Oh trust me, we've been there and we got the t-shirts ;-) Pilot projects with 250 nodes are not fun after the third field update... But that was mostly sensor issues, the network stuff is pretty well debugged by now. Next project will have to do actual gateway-to-mobile-nodes routing though, not just collection, so that should be "interesting". Eric, since I know you've done a lot of work on the 5xx series, I've taken the liberty of CCing you personally. No problem. As far as I can tell, tinyos-main (https://github.com/tinyos/tinyos-main) has no 5xx support. that is correct. There are lots of differences between tp-master and tinyos-main(master). However, tp-master tracks tinyos-main as its upstream. I need to do a pull here shortly. tinyprod (https://github.com/tinyprod/prod ) does, but I don't know what branch I would want to start from; master, mm-core or tp-master? I'm working my way through the commit logs and code, but I could use some guidance. You want to port your changes over to a branch off tp-master. But you want to make sure it is a branch and then tp-master will be your upstream. The surf platform is based on the same chip, but it has not been updated recently. You should be able to start from the surf platform. It has bitrotted but shouldn't be too bad. Once you get your platform going and stable, I'd like you to put the simple part of your platform code into tp-master and I'll deprecate the surf code. But only if schematics are available for your platform. Otherwise I'll just keep the surf code as the example cc430 code. Are there known issues with it, or the x5xx support in general? Any gotchas I should look out for? the 5438 code is solid and the subset of that which is also cc430 code should also be good. But there is no one actively wacking on cc430 code (the processors are too constrained). So your mileage will vary. But you should be okay. Thanks. I've just got it transmitting and receiving, no major obstacles so far. I'll see if I want to adopt the 2xx USCI stuff from tinyprod. It should be better, but it's also different, and I don't have time to retest all the old stuff, so I may just stick with the "known bugs" tinyos-main implementation. I can probably spend another day on it, though. The merge was surprisingly easy! git mergetool with meld is pretty nice. Cheers, Michiel
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
