AVR Freaks

No, there has not been an update. You will have to define new registers in the header file for the radio and then initialize them in PHY_Init().

Registers with the same names will have the same addresses. You just need to add the new ones.

I would just use datasheet - go over the register list and add any registers that are extra compared to what you have for 230 (or better yet, 231).

But if don't have a battery operated device or you are satisfied with the way your current devices works, it might not worth the trouble adding them.

They are static initializations, you just read the description in the datasheet and set the values you like in PHY_Init().

As I said already, LwMesh uses a very small subset of all features. That's why drivers for 230 work for 233 without any changes. Header files for the transceivers include all registers and definitions, even if they are not used out of the box. This is done so that users could use them in their program without defining anything.

Migration note you are reading is not specific to LwMesh, of course, so it mentions everything.

You should not use DEEP_SLEEP mode, unless you plan to restore all registers on each wake up. You should look at Reduced Power Consumption Modes and associated registers.

You won't loose anything compared to 230, that's for sure.

230 had no HW security, so your current project is not using it, and if it works for you, then you can keep 230 for now. You can always switch later when 233 is officially supported.

You can use RF231 PHY as a reference, or just take entire RF231 PHY and use it instead.

Security key is transferred over SPI on each encryption, not only on power-up, so yes, HW security over SPI is way less secure than SW security.

You can use it with LwMesh, just leave protocol at its default value. You don't need to type an IP, because you don't have any IP connected devices.

If UIDs are sequential, then least significant bytes will be better.

But in any case, some sort of address conflict resolution will be required.

If they have different PAN ID, then there is no problem with address conflict.

You need to initiate sending straight from the appDataConf() callback. Instead of going into the APP_STATE_SENDING_DONE state, you must go into the APP_STATE_SEND state. You might need other changes.

All the project files are created and tested with AtmelStudio 6.1. You really should update from AS5.

A brief description of the porting process - uou need to pick the closets matching processor, search for all mentions of this processor in the source code, header files and project files and replace them with your target processor. After that you will need to address any hardware differences those two might have.

It will not be easy, you will have to spend time and learn how to do this. There is absolutely nothing I (or anyone else) can do about it.

Don't mix the stack and a particular application. Stack itself has nothing to do with the PC.

This application mimics the behavior of its counterpart from BitCloud, so it uses terms from ZigBee, so WSNMonitor could understand it. From the stack point of view it is a regular routing node.

Feel free to rename it to something else, for example, PC_GATEWAY. It won't change anything.

I don't understand your question.

Any device can send data to PC, even in BitCloud. It is just convenient to assign a device with a well known address (0) a gateway role. Coordinator is a "special" node in this sense.

In the dropdown menu there should be an option for COM port. I don't know why it is not there, it might be a W8 problem. WSNMonitor relies on a java library to interact with COM ports, which might not be available on W8. I'm just guessing here.

TRX registers become available after this peripheral is enabled. I don't think it is related to the issue you are seeing.

So what exactly runs away?

You do have 16 MHz crystal, right? Without it radio will not work.