I’m having issues that I thought someone might be able to help with. I connect BlueSmiRF to your rs232 shifter board (RX<->TX). I can open up two ckermit terminals and everything works great.
I am a bit confused by your wiring. Do you have schematics we could look at?
The BlueSMiRF expects TTL. The shifter board will convert TTL to RS232 and vice versa, but requires power from the TTL side of things (VCC is normally 5V or 3.3V).
If you can, attach the BlueSMiRF directly to your micro if you can get to TTL signals.
If not, you’ll need to attach the Shifter to the RS232 port on your project, power it with 5V, power the BlueSMiRF with 5V, and attach TX of the BlueSMiRF to the RX on the Shifter and vice versa for RX/TX.
I’m wired just as you suggested. I’m using both a serial port from the PC and Bluetooth. I’m only using the serial port to test the C code before connecting it to a microprocessor.
I write a byte out to the serial port using ckermit and try to read on the bluetooth port but get the EAGAIN error. If I increase the amount of bytes written, eventually all the bytes get sent and the read on the bluetooth port gets all the bytes…even though the previous reads fail.
My first guess is that the BlueSMiRF is buffering data, but if that were the case, then the ckermit terminals wouldn’t work either…but they do!
My second guess is that it’s my C code, but the code works when opening the serial port.
I’m wired just as you suggested. I’m using both a serial port from the PC and Bluetooth. I’m only using the serial port to test the C code before connecting it to a microprocessor.
I write a byte out to the serial port using ckermit and try to read on the bluetooth port but get the EAGAIN error. If I increase the amount of bytes written, eventually all the bytes get sent and the read on the bluetooth port gets all the bytes…even though the previous reads fail.
My first guess is that the BlueSMiRF is buffering data, but if that were the case, then the ckermit terminals wouldn’t work either…but they do!
My second guess is that it’s my C code, but the code works when opening the serial port.
Sorry if this is confusing to you, but it’s confusing to me too
I guess what I’m looking for is a GNU termios C program that can read/write a single byte over the BlueSMiRF.
If you’re getting EAGAIN from read(), that means that you’ve put the descriptor into nonblocking mode and there’s no data available to read right then. EAGAIN means “try again later”. You either need to put the descriptor into blocking mode (in which case read() will wait until there is some data, and then return it), or use something like select(), poll(), or SIGIO to be notified when there’s some data to be read.
Blocking mode is the default, so you must be putting the descriptor into nonblocking mode somehow, maybe by passing O_NONBLOCK to open() or by using fcntl(…, F_SETFL, O_NONBLOCK) (or the equivalent ioctl), or by calling some termios function which does one of those things.
