Electronic – Bluetooth module EGBT-046S vs EGBT-045MS

A bit of background first: the distinction between incoming and outgoing RFCOMM (Bluetooth stack protocol for virtual COMs) ports is necessary because it's always one of the communicating devices that initiates the connection (a bit similar to TCP sockets - where you have server and client).

• The outgoing COM port is used when the PC initiates the connection to the remote device (opening the port initiates RFCOMM connection to the remote device).
• The incoming COM port is used when the remote device initiates the connection.

Once the connection is opened it is bidirectional, regardless of the type.

That said, this Bluetooth module supports both master and slave mode (see manual chapter 2), that's why it advertises 2 RFCOMM/SPP ports, I guess. If you want PC to initiate the connection, use COM6, otherwise use COM7.

Why you see no echo in PuTTY? By default there's no local echo, and you actually shouldn't see any characters you type (unless you short UART_RX to UART_TX, or have some real device attached there to communicate with). The module itself is transparent (in the data mode, that is).

Also, baud rate etc. shouldn't really matter for Blueooth connection - note, that chapter 3.2 refers to configuring the device via physical serial port (UART_RX/TX pins, i.e. from the device side), while 3.3 describes configuring over virtual port (i.e. from the PC side). I somehow feel you're confusing the module sides ;)

This excerpt from the manual is quite important:

To connect to FireFly, browse for services, you should see: “SPP” profile with a virtual COM port. Open this virtual COM port to create a Bluetooth connection. Once connected, the device will be in data mode allowing data to flow in both directions as if the serial port were locally attached to the PC. The device must be in command mode for configuration and programming. To enter command mode type “$$$” (three dollar signs) from either the remote Bluetooth connection or the local serial port connection. You must enter command mode within 60 seconds (configurable by setting the config timer).

Cool module, btw!

Sounds like a PIC 18F2550 is just the thing, or maybe a 18F4550 if the extra I/O lines are needed. I don't know why you say a PIC 18 is not easy. You say you are a programmer, so I don't see what you're afraid of. Perhaps nobody has done a MIDI USB interface ready for you to add the keyboard scanning code to, but certainly there are various examples of the basic USB driver out there. Microchip has some code, and so do I. My 18F USB firmware is available from the downloads page, and fits into our PIC development environment.

I've never done a MIDI device, but I sortof vaguely remember there is a USB class standard for that. If so, then it's really easy since you don't have to write a host driver and it will work with any OS that implements that USB class. All you have to do is look at the class definition, fill in the right enumeration data in the include file for that purpose, then send/receive data over the appropriate endpoints according to the standard.

Any other microcontroller will require something similar. Again, short of finding free USB MIDI firmware out there (which you say you can't find), you need to do pretty much what I said above regardless of what flavor microcontroller you use. USB is USB, so all the USB device peripherals in microcontrollers do pretty much the same thing with only a few details different.