9 Replies Latest reply on Jan 18, 2017 6:50 AM by jeffr_71

    UART to BLE Bridge question


      I am looking thru the example documentation for the Bridge example and the 100 projects in 100 days info and am confused as to which BLE module to target.


      UART-to-BLE Bridge Using the EZ-BLE™ PRoC™ Module – KBA97015




      the 'supported kits' table indicates that I need to use a CY8CKIT-042CYBLE-022001-EVAL and that the CY8CKIT-042 with the PRoC BLE or the PSoC 4 BLE Modules are not supported, Yet the CYBLE-022001-EVAL EZ-BLE™ PRoC™ Evaluation Board uses a PRoC part.


      The link: http://www.cypress.com/blog/100-projects-100-days/project-020-uart-ble-bridge says it uses a PSoC 4 part.


      "The BLE Pioneer Kit with the PSoC 4 BLE module implements a BLE GAP Central device running a custom Profile and a custom UART Service. This Profile contains two custom Characteristics - one called Receive Characteristic and another called Transmit Characteristic. The Transmit Characteristic supports Notifications."


      What am I missing? What modules can I use for UART to bridge functionality? please provide links or part numbers so I can order the correct kit and modules.

        • 1. Re: UART to BLE Bridge question
                  What are you trying to accomplish? I tried example 20 in 100 projects in 100 days Ble and it worked as expected. I used the Psoc Ble 4 module plugged into the Pioneer base board and the Ble Dongle. If you just want a Ble UART device you should check out the Ez-Ble devices they will work well for that application.   
          • 2. Re: UART to BLE Bridge question

            What I was looking for was documentation clarification as to which module(s) work with the uart bridge example since the mentioned docs conflict. I am also looking at possibly connecting a ez peripheral to a smartphone as another option. I am close to ordering kits and want to get everything I need in one shot, so sny help is appreciated.

            • 3. Re: UART to BLE Bridge question

              You may want to look at the new EZ-Serial firmware as another option, which provides a BLE-to-UART bridge mode (CYSPP) in addition to many other features controllable via a serial protocol and some GPIO status/control signals:




              The page linked above lists all supported modules. You can find a detailed User Guide including API reference material on that page as well.

              • 4. Re: UART to BLE Bridge question

                Hi Jrow,


                I am looking for complete project and the code for EZ-Serial. In the download files all I see is .hex, app.cyacd and stack.cyacd.


                Where can I find .cyprj or .cywrk and all the files ?





                • 5. Re: UART to BLE Bridge question

                  Hello Vivek,


                  The source code for EZ-Serial firmware is not currently available; it is provided only in compiled form. Due to the project's complexity, designs which would require modifying EZ-Serial's internal behavior would, in the long run, be more efficiently implemented using the standard PSoC Creator IDE and custom programming from the start. I am not aware of plans to release the full source at this time.



                  • 6. Re: UART to BLE Bridge question

                    Hi JRow,


                    Thanks for the reply. I see in the datasheet that you are the main resource behind this EZ-serial .. congratulations.


                    Could you give details on how the UART Tx and Rx data is handled as compared to UART-BLE-bridge example ? 


                    Are the PWM pins P0.6 and P0.7 are disabled by default in Ez-serial firmware ? I would like to use these pins, which are SWDIO and SWDCLK for updating the Flash with my own firmware initially. 





                    • 7. Re: UART to BLE Bridge question

                      Hi Vivek,


                      Thanks! It's been a great project to work on so far.


                      If CYSPP data mode is active (CYSPP pin is driven low externally or has been pulled low internally due to connection and CYSPP GATT subscription as either client or server), then UART data is passed back and forth transparently. The only guarantee is that incoming data will be delivered to the remote device in the order it was received, though not with any specific chunk size. Depending on how much data is available in the UART RX buffer, each packet payload may be 1-20 bytes long. The hardware UART peripheral has an 8-byte hardware FIFO, which is serviced by a 128-byte software buffer.


                      CYSPP data coming in from the remote peer will be sent out the serial port in much the same way; always in order, chunk size not guaranteed but always between 1-20 bytes with one exception: if you have flow control enabled and the module's CTS pin high, outgoing data will be buffered internally (up to 128 bytes) until you assert CTS and allow the data to be transmitted.


                      Are there specific behaviors or UART characteristics you are interested in, relative to the UART-BLE bridge example?


                      Concerning PWM: yes, PWM output is disabled by default. Even if it wasn't though, you would still be able to use those pins for SWD operations at boot time if you implement the SWD protocol as required. That type of reflashing is always available, regardless of GPIO configuration.

                      • 8. Re: UART to BLE Bridge question

                        Hi Jrow,


                        Thanks for clarifying on reflashing. 


                        In case of BLE-UART: I am trying to send a big file, say about 1MB to an iOS device which limits the connection interval to 30 ms maximum. When exactly should I send "connection parameter update request" ? Is it just after the connection is done or after every data transfer ?





                        • 9. Re: UART to BLE Bridge question

                          Hi Vivek,


                          The connection parameter update request only needs to be done one time, and then it will remain in effect for the rest of the connection unless the master changes it again. However, I've never seen or heard of an iPhone doing this on its own.


                          Note that on the slave side, there is no "rejection" event that occurs if the connection parameter update request is ignored or otherwise not accepted by the master. You will know that it has taken effect only when the connection update event occurs on the slave side.