From the sound of things, this circuit may be able to do quite well running EZ-Serial as long as it is able to rely primarily on UART communication for all event detection and state updates. Having more of the GPIOs connected (especially CYSPP and DATA_READY) would be nice, but the firmware is built to report all relevant info via API events in addition to providing various convenient status and control mechanisms via GPIO. The main potential challenges with a GPIO-limited implementation are these:
- Knowing when the CYSPP transparent data pipe is active, if you switch between CYSPP mode and command mode on the fly (specifically the transition from CYSPP to command, since the API event could theoretically just be part of the CYSPP data stream)
- Allowing the host to sleep and wake up without the DATA_READY signal (particularly if it does not have wake-on-UART capability)
Depending on the application requirements, these things may be irrelevant.
Can you describe what kind of host you want to connect via UART, and what kind of behavior you would like to be able to achieve using the module? I will be happy to check for any foreseeable problems.
I don't have easy access to the CYSPP signal. While in transparent mode, are you saying it may be possible that a payload data sequence of bytes received across BLE from the remote client (or from the Host across UART) can be mistakenly parsed by the API as an exit from transparent mode? So CYSPP signal is mandatory to implement.
If so, is there any way to get an EZ-Serial firmware image with custom I/O assigned.
My I/O constrained platform will be a peripheral server. It will be switched to transparent mode by the client (I assume). I plan to link to another BLE module running EZ-Serial as a central(?) client. It's host processor has no I/O constraints and access to all EZ-Serial I/O.
It sounds like you mostly understand the potential risk when the host doesn't have access to the CYSPP signal. However, there is no risk from anything sent from the UART-connected host, since there is no "escape sequence" or similar that will cause the module to exit CYSPP data mode. While the data pipe is open (controlled by the client or the CYSPP pin state), anything that the host sends will be queued and transmitted to the remote peer. The only risk comes from the client sending data that appears to the host as though the EZ-Serial module sent an API event, and then the host assumes incorrectly that the data pipe is closed (even though it is still open).
However, it is unlikely that such a thing would occur, especially if you have any control over the format of data being transmitted over the connection. The remote side would have to send the specific "ezs_evt_p_cyspp_status" byte pattern indicating data pipe closure, including the valid checksum byte at the end if you are using binary mode (which I assume would be the case for efficient MCU processing). The binary byte stream would have to look like this:
80 01 0A 01 00 25
Or if you are operating with the text-format protocol, like this (probably far less likely):
If you are developing a system that is meant to provide an absolutely generic data pipe, then this may still not be enough. However, as noted above, if you have even the slightest control (or foreknowledge) over what data is being sent from the client side, then it should still work.
At this time, it is unfortunately not possible to obtain pin-customized EZ-Serial builds.
So when the host server is in transparent mode, the API running on it will still parse the transparent data stream received from a client? ... looking only for the ezs_evt_p_cyspp_status event?
1 of 1 people found this helpful
It sounds like there might still be a bit of confusion. I would recommend reviewing Sections 126.96.36.199 and 188.8.131.52 in the EZ-Serial User Guide, especially the part discussing how to exit from CYSPP mode and what the limitations are. Section 184.108.40.206 describing the CYSPP state machine is also useful.
The EZ-BLE module running EZ-Serial firmware ties everything together, but it has two mutually exclusive operating modes (command mode and CYSPP mode). When the module is in command mode, all UART data from the host runs through the API parser. When the module is in CYSPP mode, all UART data from the host is directly buffered and transmitted to the remote peer, and the API parser is not active. In other words, it is impossible for the host to send API commands while the module is in CYSPP mode.
Also, the remote peer has no direct control over the module's operating mode (command vs. CYSPP) except when it subscribes to or unsubscribes from one of the CYSPP "Data" characteristics, which is a key step in activating CYSPP mode from the remote client side. The actual data stream sent from the peer device through the CYSPP data characteristics are always separate from the API. In other words, if the remote peer (not the local external host) sends a byte stream that matches the text-format or binary-format "gap_disconnect" API command using GATT write operations on the CYSPP data characteristic, it will not cause a disconnection to occur.
Where your confusion may be coming from here is the fact that both the module and the host device usually implement an API parser in order to communicate--they just behave in opposite roles:
- The module-side parser reads commands, and generates responses and events
- The host-side parser reads responses and events, and generates commands
The risk when the host wants to know whether CYSPP data mode is active or not but does not have access to the CYSPP GPIO pin is that there is a specific case that cannot be narrowed down to a single deterministic cause. Consider the following set of actions as seen from the external UART-connected host, in which a remote peer connects and activates CYSPP data mode:
- "system_boot" event received indicating system has booted and command mode is active
- "gap_adv_state_changed" event received indicating advertisements started
- "gap_connected" event received indicating a remote peer has connected
- "p_cyspp_status" event received with status=0x04 indicating RX flow control subscribed
- "p_cyspp_status" event received with status=0x05 indicating data mode is active
- "p_cyspp_status" event received with status=0x00 indicating data mode closed and command mode active again
Here is what this might look like as seen in a serial terminal on a host PC:
1 of 1 people found this helpful
The first five steps are deterministic. From a reset operation and floating CYSPP pin, there is exactly one possible cause and known outcome. However, the 6th step has two possible causes:
- The remote peer actually did close the CYSPP connection by unsubscribing from the data characteristic.
- The remote peer sent "
@E,000C,.CYSPP,S=00\r\n" as part of the transmitted byte stream.
The second possibility is extremely unlikely, but it is not technically impossible. If you know for certain that the data sent by the remote peer will never contain this byte sequence (or the binary equivalent six-byte sequence
[ 80 01 0A 01 00 25 ]), then you don't have to worry about this. Otherwise, the CYSPP pin state is required for absolute certainty concerning the operating mode.
(Sorry for splitting up the replies; I'm having some forum issues at the moment.)