Update 2011 May 29 The sample code and library have been substantially upgraded. See my newer post for the details.
Good progress last night and today. I get an interrupt for each received packet, working in both promiscuous mode and normal mode.
A fair bit of code to get here, compared to using xbees, but SPI is much much faster, and you don’t need to dick around with baud rates and getting clock timing perfect. UARTs are terrible. From the datasheet, and the little bit of information you can find on the web, it seems that these modules have some rather odd silicon errata. It seems the original datasheet was completely wrong. This is the only thing that I can think of to explain why you need to set up so many registers just to get it to work. The defaults in the silicon are all worthless. Oh well :) It works :)
Note to self: be careful to use mrf_read_long() when you want to use a long address, the address spaces overlap, so using mrf_read_short works, just doesn’t return anything useful.
Working code to get this far, with an AVR host is over at github
I read your message here a while ago, but only just recently did I actually look at your code and notice that there’s a mention of XBees. I think I can explain your apparent need to include two ignored bytes: XBees by default include proprietary stuff of some sort on top of the 802.15.4 specification! For details, assuming you’re using the original XBee/XBeePro modules, see the ATMM command on page 48 of the datasheet. Note that I once tried to get two XBees to talk to each other in strict 802.15.4 mode and had no luck (it seemed like they were happy to transmit data without the custom header, but would sometimes still try to interpret received packets which of course failed miserably if my application data happened to contain “interesting” values in the first few bytes), so YMMV if you go this route. However, if you never tried to get two MRF24J40s to talk directly to each other, and only ever tried to get communication between an MRF and an XBee, this would be the reason for the two extra bytes.
Er, this was meant to go on part 3. I’ll repost it there; you can fail moderation for this copy.
(reposted on both posts, for maximum visibility)
Interesting! That’s very likely. I have three xbee series 1 modules, and 2 mrf24jf0 modules, but for various convenience factors, (the existing network was all xbee series 1) I was probably mostly testing with an xbee on one side, and an mrf24j40 on the other. I had well established debug code for talking to the xbee on one side. I was never very happy with the two byte jump, but I never found anything that would explain it. Of course, now that I’ve seen the MM command, I can see the reason quite clearly.
Thank you very much! I’ll try and update the library and comments to mention this, but it won’t happen anytime soon. :( For better or worse, all my 802.15.4 devices are working and communicating, and I currently have nothing new planned for the network. Perhaps when it gets quiet at work…. HAHAHAH Actually, I’ll probably make it my mission to make an mrf34j40 library for the stm32L parts…