2

I have an Arduino which sends data serially in 115200 baud rate.

There is an application that receives data from Arduino in 9600 baud rate. The code is

    // Arduino USB serial converter setup
    // Set control line state
    mUsbConnection.controlTransfer(0x21, 0x22, 0, 0, null, 0, 0);
    // Set line encoding.
    mUsbConnection.controlTransfer(0x21, 0x20, 0, 0, getLineEncoding(9600), 7, 0);
    //mUsbConnection.controlTransfer(0x21, 0x20, 0x001A, 0, getLineEncoding(9600), 7, 0);

Then in the getLineEncoding() function

private byte[] getLineEncoding(int baudRate) {
    final byte[] lineEncodingRequest = { (byte) 0x80, 0x25, 0x00, 0x00, 0x00, 0x00, 0x08 };
    switch (baudRate) {
    case 14400:
        lineEncodingRequest[0] = 0x40;
        lineEncodingRequest[1] = 0x38;
        break;

    case 19200:
        lineEncodingRequest[0] = 0x00;
        lineEncodingRequest[1] = 0x4B;
        break;
    }

    return lineEncodingRequest;
}

There is a switch case stracture for setting the baud rate as 9600, 14400 or 19200. But I want it to be 115200 Can anyone tell me how I can do that?

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
ilkengin
  • 191
  • 1
  • 4
  • 12
  • Restored the original poster's Arduino tag; although the code concerns the Android half of the system, the goal is to talk to an Arduino and this will help the question be found by others trying to solve that problem. – Chris Stratton Jul 14 '14 at 14:29
  • @ChrisStratton, they're communicating over a serial line, the Android device doesn't care what's on the other end of the line. – Cristian Ciupitu Jul 14 '14 at 14:31
  • 1
    No, they aren't communicating over a serial line, they are communicating over USB using a virtual com port scheme implemented by the Arduino. It so happens that one of its parameters is a virtual baud rate, but that baud rate (and "serial line" link it governs) only ever actually exists between two chips which are both located on the Arduino board. The point though is that this is a question which comes up often amongst people working on Arduino; it's not unique to that, but it is the context in which it was asked and likely to be viewed in the future. – Chris Stratton Jul 14 '14 at 14:33
  • @ChrisStratton This is rather fundamental aspect of the whole thing. Would you mind me asking 2 questions? 1) Would this explain why I never seem to identify place in code where baud-rate is set to the Android device itself? (Rather I only see Android sending the control transfer with baud-rate to the Arduino.) Does it mean there is nothing on the Android side to set the baud-rate to? 2) The controlTransfer call made from Android and Serial.init made in Arduino code are both for *different* targets on Arduino, i.e. NOT setting the baud-rate to the same chip, right? – Jaroslav Záruba Apr 28 '17 at 09:50
  • @ChrisStratton if you wouldn't mind I phrased those questions into a standalone SO post: http://stackoverflow.com/q/43679630/224239 – Jaroslav Záruba Apr 28 '17 at 11:56

3 Answers3

7

Here is a modified function that generalizes your function above for other baud rates:

private byte[] getLineEncoding(int baudRate) {
    final byte[] lineEncodingRequest = { (byte) 0x80, 0x25, 0x00, 0x00, 0x00, 0x00, 0x08 };
    //Get the least significant byte of baudRate, 
    //and put it in first byte of the array being sent
    lineEncodingRequest[0] = (byte)(baudRate & 0xFF);

    //Get the 2nd byte of baudRate,
    //and put it in second byte of the array being sent
    lineEncodingRequest[1] = (byte)((baudRate >> 8) & 0xFF);

    //ibid, for 3rd byte (my guess, because you need at least 3 bytes
    //to encode your 115200+ settings)
    lineEncodingRequest[2] = (byte)((baudRate >> 16) & 0xFF);

    return lineEncodingRequest;

}
Cristian Ciupitu
  • 20,270
  • 7
  • 50
  • 76
epichorns
  • 1,278
  • 8
  • 9
  • Pleasure is all mine. Glad I could help. – epichorns Jul 14 '14 at 13:14
  • Oh and I forgot: if you accept this answer, you can flag it as accepted, therefore wrapping up your question. – epichorns Jul 14 '14 at 13:19
  • [@TylerH](http://stackoverflow.com/users/2756409/tylerh), while it's true that radical code edits are not usually accepted, I don't think that @epichorns minds if the OP changed the code a bit so that it would work for him. – Cristian Ciupitu Jul 14 '14 at 14:32
  • No, he doesn't mind at all :-) I am a bit curious about the compiler that the OP used though, because not every compiler complains, and even blocks compilation, due to the lack of explicit type cast like this... – epichorns Jul 14 '14 at 14:45
  • @epichorns, isn't downcasting of integer types illegal in Java, so it's independent of the compiler used? For example I was getting "error: incompatible types: possible lossy conversion from int to byte" with a plain Java compiler (java-1.8.0-openjdk-devel-1.8.0.5-3.b13.fc20.x86_64). – Cristian Ciupitu Jul 14 '14 at 15:11
  • Very possible... In this case, the poster is probably using an Android compiler for this, and I think that the default compliance level is Java 1.6 in this case. I've tried it in a test Android project, and yes, casting down doesn't yield errors. Personally one of my main gripes with Java is that kind of thing, and the fact that there is no unsigned variables allowing you to do low level stuff easily... – epichorns Jul 14 '14 at 17:04
  • Yes I am using ADT. @epichorns – ilkengin Jul 15 '14 at 09:16
6

You can also try these.These are found from this link

conn.controlTransfer(0x40, 0, 0, 0, null, 0, 0);// reset
                    conn.controlTransfer(0x40, 0, 1, 0, null, 0, 0);// clear Rx
                    conn.controlTransfer(0x40, 0, 2, 0, null, 0, 0);// clear Tx
                    conn.controlTransfer(0x40, 0x03, 0x001A, 0, null, 0, 0);//Baud rate 115200

Baudrates:

* 0x2710 ----------------- 300
* 0x1388 ----------------- 600
* 0x09C4 ----------------- 1200
* 0x04E2 ----------------- 2400
* 0x0271 ----------------- 4800
* 0x4138 ----------------- 9600
* 0x809C ----------------- 19200
* 0xC04E ----------------- 38400
* 0x0034 ----------------- 57600
* 0x001A ----------------- 115200
* 0x000D ----------------- 230400
* 0x4006 ----------------- 460800
* 0x8003 ----------------- 921600
dEePU
  • 195
  • 5
  • 18
4

A good overview of a what you can do with controlTransfer() and FTDI-Chips can be found here ftdi_sio.h.

typedef enum {
  ftdi_8U232AM_48MHz_b300 = 0x2710,
  ftdi_8U232AM_48MHz_b600 = 0x1388,
  ftdi_8U232AM_48MHz_b1200 = 0x09c4,
  ftdi_8U232AM_48MHz_b2400 = 0x04e2,
  ftdi_8U232AM_48MHz_b4800 = 0x0271,
  ftdi_8U232AM_48MHz_b9600 = 0x4138,
  ftdi_8U232AM_48MHz_b19200 = 0x809c,
  ftdi_8U232AM_48MHz_b38400 = 0xc04e,
  ftdi_8U232AM_48MHz_b57600 = 0x0034,
  ftdi_8U232AM_48MHz_b115200 = 0x001a,
  ftdi_8U232AM_48MHz_b230400 = 0x000d,
  ftdi_8U232AM_48MHz_b460800 = 0x4006,
  ftdi_8U232AM_48MHz_b921600 = 0x8003,
} FTDI_8U232AM_48MHz_baudrate_t;
mobo
  • 405
  • 3
  • 7