Esp32 bluetooth uart bridge

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

ESP32 classic bluetooth to serial port adaptor

License

olegv142/esp32-bt-serial

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

ESP32 classic bluetooth to serial port bridge

Most existing bluetooth bridges are based on the Bluecore 4 chip. It is pretty old and has issues while working with baud rates higher than default 115200. The hardware flow control implementation on this family of devices seems to be the kind of the software one. The RTS signal may be delayed by an arbitrary amount of time so that working on baud rates higher than default leads to random buffer overflow and data lost unless you always transferring small chunks of data fitting entirely onto the receiver buffer. The ESP32 on the other hand provides an excellent platform for BT to UART bridge implementation.

The bridge has connection indicator output, serial data RX/TX lines and flow control lines RTS/CTS, the last one is optional. All 5 pin locations can be configured by running make menuconfig. Besides one can configure UART baud rate, buffer size and bluetooth device name prefix. The full device name consists of the user defined prefix followed by 6 symbols derived from the device MAC address. Such scheme is convenient in case you have more than one device since it provides the way to distinguish them. The supported serial baud rates are in the range from 9600 to 1843200 with 921600 being the default since it matches the baud rate of the bluetooth channel itself. So further increasing baud rate has no practical sense.

Just issue make command in the project directory

Unless you have dev kit with USB programmer included you will need some minimal wiring made to the ESP32 module to be able to flash it. The following figure shows an example of such setup with programming connections shown in blue. The connections providing serial interface to the your system are shown in black. You can use virtually any USB-serial bridge capable of working at 115200 baud. The IO0 pin shoud be connected to the ground while powering up the module in order to turn it onto serial programming mode. After that you can issue make flash command in the project directory and wait for the flashing completion. Then turn off power, disconnect programming circuit and enjoy using your brand new bluetooth serial bridge.

You can use hardware flow control CTS/RTS lines or ignore them depending on your system design details. Basically not using RTS line is safe if packets you are sending to the module’s RXD line are not exceeding 128 bytes. The CTS line usage is completely up to your implementation of the serial data receiver. If you are not going to use CTS line you should either connect it to the ground or disable at firmware build stage by means of make menuconfig. The EN line plays the role of the reset to the module. Low level on this line turns the module onto the reset state with low power consumption. In case you are not going to use this line it should be pulled up. The pull up resistors on the TXD and RTS lines are needed to prevent them from floating during module boot.

The ESP32 module is using the same serial channel used for programming to print error and debug messages. So if anything goes wrong you can attach the programming circuit without grounding the IO0 pin and monitor debug messages during module boot.

35mA in idle state, 110mA while transferring data at maximum rate. A little more than average but you have got high data rate and excellent range.

Exceptional. Several timer better than with anything based on the Bluecore chips. I’ve got stable connection with 10 meters distance and 2 concrete walls in between.

About

ESP32 classic bluetooth to serial port adaptor

Источник

ESP32 Bluetooth Bridge (Replaces HC-05)

Do you have a project where you’d like it to be possible for you to connect to (and potentially reprogram) another microcontroller over Bluetooth, but also want to have the flexibility to add new Bluetooth, BLE, or WIFI features? I previously used the HC-05 bluetooth module for providing Bluetooth tty access for interactions and programming; the ESP32, though, is only slightly more expensive and provides many features that the HC-05 cannot offer — including that it itself can be programmed over-the-air to add your own features and functionality very easily.

This repository contains a simple Bluetooth-to-UART bridge roughly mirroring how the HC-05 behaved, but adds a handful of new features:

• An escape sequence allowing you to break out of your serial bridge to send commands to the wireless unit itself directly.
• The ability to accept commands including one allowing you to monitor the bluetooth bridge via the ESP32’s UART1.
• Configurable pin connections for:
  • Indicating when a client is connected over bluetooth ( PIN_CONNECTED )
  • Allowing the bridged microcontroller to send commands directly to the ESP32 ( BT_KEY ).
  • Connecting to the Microcontroller’s reset line for debugging, flashing, and troubleshooting.
  • RX/TX output pins for connecting to the microcontroller.

  Commands

  flash_esp32

  This command begins an OTA flash of the ESP32 unit itself. In general, there is no need for you to run this command directly, instead use the included python script in programming/ota_flash.py to flash the ESP32 unit over bluetooth. See «Flashing the ESP32 Over-the-air» for details.

  flash_uc

  This command is designed to reboot an STM32 microcontroller into its serial bootloader by:

  • Pulling its BOOT0 pin high (see PIN_CONNECTED in main.h )
  • Pulling its nRST line low for 250ms (see UC_NRST in main.h )
  • Pulling its nRST line high

  At that point, the microcontroller will be ready to accept programming over bluetooth.

  reset_uc

  Briefly pulls the microcontroller’s reset line low to cause it to restart.

  boot0 [0|1]

  • When called without an argument: returns the current state of the BOOT0 pin (i.e. PIN_CONNECTED ).
  • When called with an argument of 0 : Pulls BOOT0 ( PIN_CONNECTED ) low.
  • When called with an argument of 1 : Pulls BOOT0 ( PIN_CONNECTED ) high.

  PIN_CONNECTED is generally connected directly to the BOOT0 pin of the microcontroller to emulate the procedure historically used for using an HC-05 unit to flash an STM32 microcontroller. You’ll notice that they are used interchangably throughout this document and in the source, but do know that you can adjust the state of this pin independently from its default behavior of indicating whether a client is connected.

  monitor [0|1]

  • When called without an argument: returns the current state of the serial monitor.
  • When called with an argument of 0 : Turns serial monitoring off.
  • When called with an argument of 1 : Turns serial monitoring on.

  Note that this is probably only useful if you are issuing commands to the ESP32 unit’s UART1 instead of communicating over Bluetooth.

  nrst [0|1]

  • When called without an argument: stops setting the state of the microcontroller’s nRST pin by reconfiguring the corresponding ESP32 pin as an input.
  • When called with an argument of 0 : Pulls nRST ( UC_NRST ) low.
  • When called with an argument of 1 : Pulls nRST ( UC_NRST ) high.

  unescape

  Exits «escaped» mode if the device had previously recieved the relevant escape sequence. This is useful for allowing you to re-enable pass-through functionality after issuing an escape sequence to send your microcontroller a command.

  Building the firmware

  First, make sure that you have installed the xtensa compiler ( xtensa-esp32-elf-gcc ) and that it is available on your PATH.

  Next, make sure you’ve cloned all necessary submodules:

  git submodule update --init --recursive 

  After that, set the IDF_PATH environment variable to point at your clone of the esp32 IDF (https://github.com/espressif/esp-idf) — and make sure that you’ve checked out a commit that is compatible with the version of arduino-esp32 in use. If you’re running this repository as it is now, that commit should be aaf12390 .

  Now, just ask it to compile:

  You’re now ready to flash that firmware onto the device. Note that if you are flashing over the air, you should follow the procedure described below under «Flashing the ESP32 Over-the-air» instead of following the usual make flash procedure.

  Escape Sequence

  Default: CTRL+D , CTRL+D , CTRL+D , !

  The escape sequence keys must be pressed at least 500ms apart from one another (and, obviously, no other keys may be pressed between each of your escape sequence bytes). This might sound a little strange, but this behavior exists as a way of making sure that the bytes transmitted as part of your escape sequence aren’t occurring naturally as part of some other data you’re intentionally transmitting to your microcontroller.

  If you want to make adjustments to this behavior, see:

  • main.h : BT_CTRL_ESCAPE_SEQUENCE_INTERCHARACTER_DELAY to adjust the minimum amount of time that must pass between each character of your escape sequence.
  • main.cpp ; BT_CTRL_ESCAPE_SEQUENCE to adjust the escape sequence itself.

  Flashing the ESP32 Over-the-air

  It’s possible to flash the ESP32 unit itself over blueotooth by using the included python script ( programming/ota_flash.py ); to do that, follow the instructions below.

  Note that flashing is essentially 100% safe for an ESP32 module; the device’s built-in Over-the-air programming functionality is cleverly designed and will not switch to the newly-programmed source unless it passes a verification procedure. If the flashing process fails for any reason, the installed code will remain unchanged.

  Building the firmware

  See «Building the firmware».

  Installing Dependencies

  From your clone of this repository, run the following commands:

  cd programming virtualenv . --python=python3 source bin/activate pip install -r requirements.txt cd .. 

  Flashing the firmware

  From your clone of this repository, run the following commands:

  cd programming python ota_flash.py /path/to/bluetooth/device 

  • Connect to the device you have specified (at which point, you will be connected via the pass-through to the connected microcontroller).
  • Sends the «Escape Sequence» mentioned above to escape the pass-through.
  • Issues the command flash_esp32 .
  • Waits for the ESP32 unit to be ready.
  • Sends the new firmware stored in ../build/bridge.bin .
  • Prints any messages received from the ESP32 unit during this process.

  At the end of this process, you should see one of the following messages:

  • : If the flashing process completed successfully.
  • : If the flashing process failed for some reason. Consult the other displayed messages to determine a potential cause for this flashing fialure. Note that failures are completely safe, and you can try re-flashing again as soon as you’d like.

  See python ota_flash.py —help for other options.

  Open Source Agenda is not affiliated with «Esp32 Bluetooth Bridge» Project. README Source: coddingtonbear/esp32-bluetooth-bridge

  Источник