New answers tagged

0

The only SoftwareSerial you a declaring is SoftwareSerial mySerial(10, 11); // RX, TX (And you you didn't use it afterwards). If the hardware serials Serial1, Serial2 or Serial3 are available (and already declared in the arduino.h header depends on the board you are using.


1

You can use the one provided by generating it with STMCubeMx. This is going beyond arduino though. But it is highly feasible.


0

SoftwareSerial is only a "good" choice (for certain values of "good") if you only use one instance, and that is the only serial port in the system. Using SoftwareSerial to read from 2 ports simultaneously is not possible. Using SoftwareSerial to read data in tandem with any other hardware serial ports will result it data loss. SoftwareSerial is only any ...


1

For what it's worth, I manage to make them working again by playing a bit with the settings of both modules. Using a simple test sketch I issued some AT commands to both modules; I had already tried setting them to the DEFAULT setup with AT+DEFAULT, but that was fruitless. I decided to left the mode as is (FU3), same for the serial rate (B9600), but I tried ...


1

SoftwareSerial can only listen to one port at a time. You cannot listen to both, no way. To really listen to both, you need an Arduino with more hardware Serial ports, where most of the protocol is done in hardware, thus can receive without CPU intervention. The Arduino Mega has 4 hardware Serial ports. Or you could impose a protocol on the Serial stream to ...


1

I cannot really narrow down the source of your observed problems, since the problem descriptions are not clear enough. But there are some obvious problems/potential for making it better in your code. In the Uno Code: It is totally unnecessary to use a timer interrupt for reading the SoftwareSerial interface. Instead you should write your loop() function ...


1

As Juraj stated in the comments, you have 2 instances of SoftwareSerial, but only one of them can listen to it's receive pin at the same time (this is because they rely on the same interrupts to sample the pin). When you call gps.listen(), you set the gps interface to listen on it's receive pin. Serial1 (the second SoftwareSerial instance) will then no ...


Top 50 recent answers are included