Hi there,
I have a customer reporting the following scenario, implemeting peer to peer bi-di communication with F2274 + C2500:
- 8 Tx-Rx pairs (TX1-RX1, TX2-RX2 and so on) are set up in a near location.
- Each pair is configured for a peer to peer communication, and only talk to their corresponding TXx and RXx.
- Even though they are identified as TX and Rx, they both transmit and receive data.
o TX transmits 28x4 bytes packets of information.
o RX receives 28x4 bytes of information.
o RX transmits 1 byte as acknowledge.
o TX receives 1 byte as acknowledge.
- When having a single pair in communication, (TX1–RX1/TX2–RX2/TX3–RX3...) the protocol described in the bullet above is completely executed.
- When a second pair is turned on (TX2 – RX2) it affects the communication in both pairs.
o TX receives does not receive 1 byte as acknowledge.
o This behavior is common to both pairs and other pairs turned on.
- Every TXx has a counter for on acknowledge received, so it resets when a defined number of counts has been reached.
- The code is based in SimplicTI v2.0.
I have placed the projects in the following link:
\\www-mkt\wwwroot\Internal\Docs\FSO\MEXFSO\LeMaBa\Shared\CIDESI these are based on the 2 simple End Devices with bi-di sample codes.
QD0164_IAR_RX.zip contains the code for the "RXs" (please refer to main_LinkListen_bidire.c)
QD0164_IAR_VWDT+Ack.zip contains the code for the "TXs" (please refer to main_LinkTo_V5.c)
Has somebody experienced something similar?
I'll really appreciatte if somebody could provide a feedback on what's causing the failure when more than 1 pair of TxRxs is working.
Regards,
Leo
Hi Leo,
The latest release version of SimpliciTI is 1.0.6 -- you mentioned v2.0? Not sure what this customer is really working with.
Hi xyzzy,
Thanks for taking the time to review my post, I meant v1.0.2.
Whew, I was worried that a release might have happened while I wasn't looking...
Actually, 1.0.2 goes back a long way, any chance to get the customer's app ported to 1.0.6? Support would be a lot simpler...
I have actually already suggested that to customer. What steps are necesary to migrate from 1.0.2 to 1.0.6?
what are the chances to support what they have now? they might want to migrate next week after a demo session they are preparing.
Thanks,
Hi team,
any ideas or suggestions? please
thanks,
I would highly suggest porting to a newer version. You could port to v1.0.6, or you may try waiting for SimpliciTI v1.1.0 (which I was told would be released around the end of March). SimpliciTI v1.1.0 should support CCE, so you won't need to port to the CCE compiler like you will with v1.0.6. I'm going to assume that porting protocol versions won't be much more involved than replacing the SimpliciTI protocol files and recompiling, but I have no idea what your project layout is.
Some things that would cause trouble:
1) One of your pairs linked to devices in another pair. This could happen if they were doing a SMPL_LinkListen when the new pair issued a link request.
2) Make sure the addresses for your devices are different (e.g. 78, 52, 40, 12). Try incrementing the last byte when changing addresses as I believe this will take advantage of more efficient message filtering (i.e. your device won't waste time looking at packets not meant for it).
Although, if it was the above two, I don't see how you would have even managed to send data successfully. Those just popped into my head though
3) It's not a SimpliciTI error, but misuse of the SimpliciTI API or other programming error. It seems strange to me that SimpliciTI would suddenly drop the communication link after already successfully sending 28 bytes of information, but who knows with v1.0.2. Unfortunately, I can't look at your code. The links don't work for me.
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.