The MRF24J40 is solidly a Microchip product though, so I am hoping the example code will be better, when I find it. I have always found Microchips documentation to be superb, but sometimes the example code is not quite as good :-( What were your problems with the MiWi code and do you really think I should roll my own? This is only a small part of a large project and I can't afford to get stuck for weeks on bugs in my own code.
Hmm. Good question. It's not just one thing.
First off, the nature of the basic task IS complicated in that you have 2 nodes and a complex link between them. This is a complex thing to debug because you don't know which node might be the problem. Physically, my ideal testbench would use 2 computers and 2 ICD3's, but that's probably not going to happen. Of course, that's the nature of the problem, not of the code.
I guess my aggravation with the demo code is this. I suspect I'm mistaken on some points here, but not all, it's a collective pile of problems.
1) A lot of it is heavily tied to the Demo board. I don't use demo boards, and have no interest in using them. I'm sure it would probably compile and run OK but won't actually get me much further since this doesn't actually make it work on my boards and tasks. It has LCD writing tasks, LED flashers, temp sensor reading, and other code chaff I have no interest in. I need a driver and a simple program.
2) The "MiWi DE Basic Demos" code has a TON of ifdef switches in it for different targets, even though it's got target-specific project files. I'm divided in some ways because that seems like it would increase reusability in many ways, but the basic problem here is I can't read
through the code with it so much stuff which may or may not be part of the build.
3) The system makes use of NVM the dsPIC doesn't have. I'm not into adding external EEPROM and trying to integrate it into the project. We can write program space but that's somewhat complicated and even if there's code in the project which does that, I really have to know upfront exactly what it's doing to write a system around it. For example, writing program space usually means disabling all interrupts. I need to know in detail all about that because I may have timers which need to sample inputs at specific times and if you disable the interrupts for awhile then it can break things.
I'm puzzled as to why the system thinks it NEEDS NVM or was just added to improve reliability if a node loses power. That's actually pretty unlikely for me. It does not sound like something I'd want included in a getting-started effort at all.
4) Basically I'm looking for a standard code description of the code itself, NOT a presentation on how to run demo code, and not a high-level appnote on how these mesh networks work. Actual code, the tasks, the interrupts, what I need to integrate into a project. I can't find one.
5) The MiWi/Zigbee stuff uses a lot of network configuration, and that external Zena tool for configuration. I'm sure that's useful and all, but integrating into a project requires an incremental approach. To me, I was just puzzled. The documents were again all seeming to be limited to the context of working with a standard demo board, not applying towards a user project.
Basically, I'm looking through MiWi DE Basic Demos, Simple Example, Node 1. What does it do? How's it different than Node 2?
I'm looking at nvm.c, trying to understand the potentially complicated (or simple) NVM issues. "#if defined(PROTOCOL_MIWI_PRO)" OK, what's that define? "#if defined(NWK_ROLE_COORDINATOR)"... what's that? Oh wait "#if defined(ENABLE_NVM)"... yay, this sounds like a way to run without NVM. Will it run ok without it? What are the consequences? Do I need to do anything different?
I have no idea. I'm browsing the directory. PDF for this? Nothing here at all. App note? If there is, I can't find it, and I think I have them all.
6) I was looking for the incremental path here. As in, "this is how you verify the MRF24J40 driver is correctly sequencing the reset and communicating through the SPI". "This is how you verify you've got a link to another node". "This is how you send "hello" to is, and how it's received".
7) So, typically I don't go confused for very long without consulting Google, where I find people who have done it and documented the situation. But, I can't find anyone who has. There's very little out there, even though these modules have been out for years, and that's troubling. Of course not everyone who gets a project working blogs it, only a small % do. But that % goes up when there is little else out there about it. So far, dlindbergh, DarioG, and Clark Leach and a page on using it with the Arduino seem to pretty much be the sum of the community documentation on the MRF24J40, and almost nothing else. In fact, depending on your search term, THIS THREAD may be at the top of the Google results once you get past the official Microchip releases.
It seems a tragedy to me. I mean, the hardware looks great, it's got the specs I need and I don't care so much about it taking up a lot of program space, it looks mind-bogglingly useful for many people, the MiWi code looks like a LOT of work went into making it, and then they seem to have totally dropped the ball on documentation OF the code, given the complexity involved in applying it to a project.