想要使用CC2538，请问有没有类似于原来协议栈的 GenericApp 的空工程分享啊？

目前在cc2538上面只有基于Home Automation/Smart Energy profile的工程。后续会发布Z-Stack Mesh，包含GenericApp类似的工程，让客户只利用ZigBee的mesh功能，开发私有的应用。
建议先在Home Automation上开发，因为核心的Zigbee协议栈都一样的，等新版本发布以后，切换也比较方便了。

感谢VV回答
        另，我这边需要做一个数据量大概为40kbps的多跳传输，之前用CC2530，发现不使用协议栈的情况下，即，一个节点，初始化发射功率和信道后进行广播，范围内接受节点使用相同的信道可以非常同步的接收到数据。    当使用ZStack-CC2530-2.3.0-1.4.0协议栈后，协调器不论是使用短地址单播，还是广播，接收节点收到信息总会有个大概0.1秒左右的延迟（不定），甚至会丢包，即使是距离只有1米。  测试发射接收是否同步的方法为：发射或接收一个包后，LED进行状态翻转。
当发射间隔为每秒发送10次，根据LED闪烁同步情况，发现：不运行协议栈时，可以说完全同步，而且即使发送更大数据量如40kbps时候接收数据也完全没有问题；当运行协议栈时候，接收就会闪烁不定，产生了丢包。因为没有东西进行抓包，不知道究竟是没有发射出去，还是没有来得及接收。
实验需要进行多跳的40kbps数据量的测试（数据是发射端通过SPI接口接收数据进行多跳转发，每包32字节，每秒发送150次），感觉一方面是因为8位内核的2530运行协议栈后速度跟不上，所以才想使用2538。

请问：
1.这样分析是否正确？
2.使用了2538后，协议栈下，按如上数据量进行测试是否会提高？还是因为协议栈某些规定导致不能进行频繁的发送（每秒发送150次）。
3.2538的类似GenericApp的工程会在今年发布吗？因为现在Home Automation中，封装的实在是太狠了......

1, 从现象来说应该是正常的，当你用CC2530裸跑的时候，没有任何协议上的处理，需要发数据的时候就直接发出去了，而且接收方和发送方没有ACK机制。而且你发数据相当于直接在使用底层的Radio工作。当你使用Z-Stack的时候，你发数据是在应用层发下去的，中间还有NWK和MAC，而且是需要通过OASL调度来实现的，当你的MAC层需要发数据的时候，还会有信道冲突检测，如果信道被占用的情况下还要Back off，如果发送出去以后需要等待MAC ACK回来，如果没有回来需要重新发。所以整个过程加起来吞吐量就会减少很多。
2，CC2538的芯片处理速度会快一点，但是协议栈还是一样的，效果会好点，但是肯定达不到裸跑的效果。
3，会的，今年会发布。