I am porting our base station SW which uses MT task to communicate with CC2530(mostly through UART). We use Z stack 1.4.3 before and we currently use Z stack 2.5.0. here are my several questions
1. there are bunch of serial commands have been removed? (for instance, SPI_CMD_SYS_CALLBACK_SUB_CMD). Is there any commands in new Z stack 2.5.0 to execute those functions?
2. There is one added mask MT_RPC_SUBSYSTEM_MASK used to parse command to different function array. So we need to add this bit into every our base station SW as long as it will communicate with CC2530?
3. In old 1.4.3 stack, the SYS_EVENT_MSG has a while loop to process msg. but this while loop is removed(in OAD MT_TASK it is kept.) I would like to know the reason for this change(it seems to me if we have stream data, the while loop style is better for efficiency. but probably not so good for fairness scheduling?)
In general, if we made our base station SW based on old z stack MT code(through UART), is there any suggestion we can make minimum change to new Z stack
thanks
Rui
1. I remember that command vaguely - something like saving busy traffic on the transport bus, MT host could choose to subscribe to the SYS sub-system callback or not (ditto for all of the other sub-systems), where a sub-system "callback" was just any AREQ from the MT to the host. Now, if the MT_SYS sub-system is built into the Z-Stack image (the ZNP, say) with MT_SYS_FUNC, then the all asynchronous stuff is automatically live. The tricky thing is with the ZDO callback functions - the MT host still has to ask for those specifically. A good example is just to skim the ZAP body of code, and what ZDO callback functions it registers for, etc. For example, look at void zapZdoSync(void).
2. The designation of the correct subsystem in the construction of the CMD0 byte of any message is absolutely necessary.
3. Yes - better "cooperative" behavior. But note in the ZNP project how the ZNP task is "elevated" to be a 50/50 equal as the highest priority task.
In general, it depends how the old code was architected. If every command was built it place, then you have to go to every place a command is constructed and update the code. But hopefully, a pointer to a buffer and a length and a sub-system are being passed as arguments to a generic packet builder. Again, the ZAP show a good example of architecting the MT host code.
Thanks, Dirty Hary
One question, the ZAP is only for MSP430? not for CC2530 pltaform?
ZAP = ZNP Application Processor, or ZNP host processor, or MT Master (where the ZNP is the MT slave)
So ZAP is for any processor, although due to the Copyright and click-through licensing, it cannot legally be ported to competitor's mcu's, it has been ported to the PC and to Linux. So, you could also port it to the CC2530 if you want to run one CC2530 as the ZNP host, and the other CC2530 as the ZNP.
Is there any possible that TI will change the structure of MT part substantially in the near future? I understand the reason to restructure this code into a more clear way, however, our base station won't use all commands(only a very small part), so we don't use pointer to parse command. instead, a lookup table for every command and its associated function is used. so I have to modify them in place one by one. So I would like to know whether this MT part framework is finalized?
Also is there MT for Z stack 1.4.3 introduction?
I can't answer that first question and doubt that anyone on the E2E can.
I found the attached document here:
C:\Texas Instruments\ZStack-1.4.3-1.2.1\Documents\Serial Port Interface_F8W-2003-0001_.pdf
Thanks
I noticed almost every MT related command name has been changed from 1.4.3 to 2.1.0, is there any detailed command mapping/change notes for them?