Initially, I saw that in the software distribution there was a BLE driver for HM-1X and was hoping to use that, but it obviously doesn't work. Question #1: Do I have to write my own driver for that Pmod BT2 or is there somewhere one available?Question #2: If I have to write my own driver and from the documentation from the digilent site, are the following statements correct (just to check myself)?

- in emsk_init.c, in the emsk_mux_init function, the set_pmod_mux function should be called with: PM1_UR_UART_0 | PM1_LR_GPIO_A to set Pmod1? Or should it be PM1_UR_UART_0 | PM1_LR_SPI_S ?- As per the documentation of th emodule, the first 4 pins are RTS,RX, TX and CTS. This means that this call should be made : set_uart_map(mux_regs, 0x1b);- If I end up writing a driver, is the pmwifi one the best I can use as inspiration?

Thank you.

Comments

1. To use Pmode BT 2, you need to write the driver by yourself.2. In embARC, PMOD1 is set to UART in default, so you can insert pmod-bt2 to PMOD 13. The pin map of BT 2 may be different with HM-1x, so you need to modify the pinmux config according to the EMSK doc4. For UART, RTS and CTS is not necessary,5. PMWIFI is based on SPI not UART. You need to refer the driver of HM-1x

Thank you very much for the help. I managed to get it working. I do have, if you don't mind, a few more questions:

It seems that the uart_read function from DEV_UART only reads at most 2 bytes. If I ask it to read 1 byte, the behaviour seems to be unpredictable. Like bytes get lost somehow. I can only replicate this behaviour when I'm sending 1-2KB per second, not when the traffic is very small.

Is that because of the bluetooth protocol itself? Is it the PmodBT2? Or is that the board itself?

Additionally, relatively often uart_control(UART_CMD_GET_RXAVAIL,...) would return zero, even though I know there should be more data coming. After a few tries (anywhere from 3 to 10), it gets on reading again. Currently, my read algorithm gives up after 500ms of read retries when zero is returned. Is that expected?

If this is an expected behaviour, would then make sense for the driver to implement some form of "caching" so that even when an application wants to read 1 byte, it will actually read at least 2 and then keep that extra one in memory for when the next read comes?

Because of the above issues, I tried to set the module to run at 921K baud rate via the "SU,92" command. Even though the command returned AOK, after module reset and uart_open(UART_BAUDRATE_921600); I was unable to communicate with the module at all, until I factory-reset it. Again ... is that to be expected? Even with a higher speed setting, would it be reasonable of me to expect the reading issues (2 bytes maximum/minimum) to be solved?

If you want to change the uart to another baudrate, just uart_open(baud) is not enough, because uart_open can be called by anywhere, so if the uart is opened before, if you want to change the baudrate, you need to use uart_control(UART_CMD_SET_BAUD, (void *)your_new_baud).

Since the uart_read and read_write is an blocked API, you can check the available bytes in uart fifo by UART_CMD_GET_RXAVAIL command, or you can use UART interrupt mode with UART_CMD_SET_RXCB, UART_CMD_SET_RXINT_BUF, UART_CMD_SET_RXINT commands.

There is an example in the embARC_2016.01 release, called example/emsk/buffered_serial, it demos the use of uart interrupt.

Thank you very much for the help. I figured that the FIFO was overflowing and I started implementing something similar to ez_sio. The example was invaluable to show me what I was doing wrong and how to fix my code.