-1

So I have a Gboard Pro (http://wiki.iteadstudio.com/Gboard_Pro) and I need to update the firmware on the SIM900 chip. The SIM900 chip is connected to hardware serial 2 (PINS 16/17 of the Mega) which I do not have direct access to. I am connecting to the main serial 0 (Pins 2/3) with an FTDI USB module. For the updating process, I need to connect Transmit (TX) of the FTDI to Transmit (TX) of the SIM900 and likewise with recieve. So I would like to mirror the pins of the serial pins if possible? This is what I've tried and didn't work:

void setup() {
// initialize both serial ports:
  Serial.begin(19200);
  Serial2.begin(19200);
}

void loop() {
  // read from port 1, send to port 0:
  if (Serial2.available()) {
    int inByte = Serial2.read();
    Serial.write(inByte); 
  }

  // read from port 0, send to port 1:
  if (Serial.available()) {
    int inByte = Serial.read();
    Serial2.write(inByte); 
  }
} 

closed as unclear what you're asking by user31481, Michel Keijzers, gre_gor, SDsolar, per1234 Nov 3 '17 at 21:45

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Are you sure 19200 is the appropriate baud rate? Does the programming operating need to manipulate the module reset or it's power-on button signal? According to the schematic found at your link, the signals are available on R10 & R11 before the level shifter or R13 & R14 after, and it should be a lot easier to solder fine wires there than to the IC pins if you want to just hold the ATmega in reset and deal with it using an external cable. – Chris Stratton Aug 28 '14 at 15:23
  • You may want to read the notes here: geekonfire.com/wiki/… – Chris Stratton Aug 28 '14 at 15:25
  • Also, how is it that you know the process fails? What tool are you using to perform the upgrade? – Chris Stratton Aug 28 '14 at 16:36
1

that should work. but remember you should connect TX of one apparatus with RX of the others..

so should be FTDI rx -> arduino tx S1(pin2?) -> arduino rx S2(pin 17?) -> SIM900 tx

other point of failure may be wrong baudrate

If you can communicate using serial monitor from FTDI to sim900, then this is not the case, and maybe you may have to connect other signal other than tx/rx like RTS or similar. I can't see any other problem

  • Yes, this is a problem with the description of what the poster wants to do, but it's irrelevant to the proposed software solution which moves data between hardware UARTs - there's no opportunity to get the wiring wrong because no connections are being made. – Chris Stratton Aug 28 '14 at 15:51
  • the poster never said the HW is working with simple communication. BTW expanded the answer to add baudrate check, and to take into account other Serial signal other than TX/RX – Lesto Aug 28 '14 at 16:10
  • If the FTDI-ATmega communication were not working, they would receive a failure upon trying to upload the sketch. – Chris Stratton Aug 28 '14 at 16:35
0

Some more info - it is not an int (16 bit number) but a char (8 bit number) that you are reading. Also storing the int/char in a temporary variable is not necessary. Wrong. See comment. :$.

You can simplify as:

void loop() {
  // read from port 1, send to port 0:
  if (Serial2.available()) {
    Serial.write(Serial2.read()); 
  }
  // read from port 0, send to port 1:
  if (Serial.available()) {
    Serial2.write(Serial.read()); 
  }
} 
  • it is an int because read() return -1 if no data is in buffer. But in this case your usage is good – Lesto Aug 28 '14 at 15:11
  • @lesto ahhh did not know that, thanks. – geometrikal Aug 28 '14 at 23:39
  • btw is fine your usage as you check that a byte is available, so read should never return -1 – Lesto Aug 29 '14 at 8:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.