Using UNO for years with GSM shield
Use SoftSerial library extensively, also the Serial.overflow() function to detect overflows.
Same sketch with R4 gives compile error : overflow does not exist in SoftSerial library
Welcome to the forum
Do you even need to use SoftSerial on the R4 as it has 2 hardware UARTs ? Serial on the USB and Serial1 on pins 0 and 1
1 Like
I use the SoftwareSerial library to connect with the GSM shield on pins 2&3
How can i talk to the "serial" other than the Serial.read() and write functions?
Use pins 0 and 1 and the Serial1 object
Use it just like you would use Serial but use Serial1 instead, ie
Serial1.begin()
Serial1.available()
Serial1.read()
Serial1.print()
Serial1.write()
etc
Can I use pin 2&3 for the shield? and how to declare that?
However: my point was that suddenly the softserial library is not recognised by the newly UNO R4!!!!
The original Uno and the Uno R4 use different processors and almost certainly different versions of the SoftwareSerial library
You refer to a "GSM shield". What form does that take, ie does it plug on top of the Uno or connect via jumper wires ?
SoftwareSerial should be able to use those pins.
As mentioned before, if your setup is such that you can change to use different pins, it is often better to use ones which can use the Hardware Serial pins, such as pins 0 and 1.
However if you need to use SoftwareSerial and your code needs to detect when there was an overflow (data lost due to buffer being overflowed).
Looks like the SoftwareSerial code base that ships with UNO R4 only implemented a subset of the methods that are contained in the AVR version.
And for example does not implement:
bool overflow() { bool ret = _buffer_overflow; if (ret) _buffer_overflow = false; return ret; }
My guess is that it should not be hard for the Arduino developers to implement that in the renesas UNO code base.
Their code that adds a received character to a buffer:
rx_descr.ringbuf.put(data);
Would simply need to check to see if this call succeeded or not and add the overflow method which simply would return this state...
You might want to raise an issue up on github:
Issues · arduino/ArduinoCore-renesas (github.com)
And hope that maybe someone would implement it.
Good luck
EDIT: forgot to mention - if you are not using that call for much of anything you could simply remove it, as I believe the default size of the rx buffer is something like 1024 bytes and
I think you can change it on your declare of the object (constructor)
SoftwareSerial(uint8_t rx_pin, uint8_t tx_pin, size_t bufsize=1024);
1 Like
KurtE,
Thanks for information.
I developed a system that requires a GSM shield. I did connected that shield onto 2&3 because 0&1 are used for the
communication with the PC (through USB).
The basic UNO has only 32 kb memory and I encountered overflow problems which I resolved with a clear buffer and
detection of the overflow() .
I looked into using the UNO R4 with much more memory but I encountered the "not recognise" SoftwareSerial problem.
Maybe I can remove my extended overflow detection/clearing routines if I use the R4 with the larger memory.
But could you (or a link to) help me to understand the initial communication of the UNO boards.
How can we use pin 0&1 for the shield as the internal communication goes through those pins and through the USB?
i never really understood this and therefore needed to use other pins for the shield.
best regards
I will try... Maybe others who actually have more recently used any AVR based UNO boards, can fill in the blanks. My last UNOish board I have used was the Lynxmotion Botboarduino board, which was probably over 10 years ago...
The Short answer is, the AVR processor that is used on the UNO boards, only has one hardware USART (or UART)... That processor (ATMega328P)also does not have native USB either, so it relies on another chip to talk to the USB. Some versions have used I believe FTDI chips, others... The current UNO R3 uses another AVR processor for it (ATMega 32u2), which does have native USB and communicates to the main processor through the one hardware Serial port. As this is the only hardware Serial port on the board, they also connect the IO pins to the Arduino pin numbers 0 and 1.
If you look at the schematic on the product page:
UNO-TH_Rev3e.sch (arduino.cc)
At the area I highlighted in yellow you can see the IO pins going from the ATMega32U2 to the Atmega32P and the off pins 0 and 1 of the shield.
Note: with many newer processors that have native USB, such as the UNO R4 (especially the MINIMA), They do not need to use up a hardware USART for the USB, as such they instead route pins from one of their USARTs to pins 0 and 1. And on the R4, you use Serial1 to talk to these pins. The Actual processor on the UNO R4 actually have 4 USARTS on it. On the Minima by default you can only access one of them (Serial1), however you can also setup a hardware USART that uses pins 18 and 19 with code like:
UART UART2(18, 19);
#define SerialX Serial2
And on the UNO Wifi these pins can be used for Serial3. The other two Usarts on the Wifi are used to talk to an ESP32 board, one of which is used sort of like the UNO R3 in that it USB communications be default go through the ESP32 and are forwarded to the main chip through a USART, and the other one talks again to the ESP32 and is used for BT and WIFI communications.
Thanks, that is probably the case. However, I read this, as maybe they have a shield that they built where the shield is setup to use pins 2 and 3 to do serial communications to some device, and their existing code which uses SoftwareSerial does not build, and they are asking how to resolve this.
Kurt,
I did some more testing, still using SoftSerial and it does not work!!
I removed the overflow routine, but still the communication to my GSM shield fails.
The response from the shield is unreadable, because of baudrate, which I change with an AT command.
As the communication is not working correctly that doesn't work
Finally I can say that the implementation of Softserial is not working on the R4.
I was hoping to switch to the R4 model for more memory, but I do not think it will work.
You suggested to take it up with GitHub community but that seems a bit far fetched for me.
My question, would you like to take it up with them?
best regards
Dirk Vercauteren
Perk, belgium
Why ?
Hi,
because the shields use different ports than 0 and 1, and only Softserial allows to define other ports
because the modules installed would need physical changes if I switch to R4.
because the serial1 does not seem to have as may features as the softSerial
regards
Sorry, I am just a user like yourself. And my UNO R4 boards are in a cardboard box, in the cabinet.
But before anyone can really help you, you would probably need to provide some more specific detailed information. So far we know that the overflow method does not exist. And looks like some other methods are not there either, like flush(). But I don't think that is your problem, as it looks like it is busted on the AVR version as well. That is it does nothing, when it should empty their input buffer... We believe it is probably the MINIMA as of the sub-forum of this thread.
You mention that you change the baud rate with AT command... I would assume that after this, you would probably clear the input buffer and do a new begin command, with the new baud rate?
Which baud rates? If at all possible, you should try to provide them with simple test sketch that shows the problems, such that someone could reproduce the issue and hopefully find and fix the issue.
As for Github creating an issue, all that it requires is that you have a github account. And you are the only here that has enough information. If you do provide that information here on the forums, sometimes one of the Arduino developers who may be monitoring the forums will create one for you.
Good luck
Did you ever answer my earlier question ?
Really ?
That is ironic considering that you are complaining that SoftwareSerial on the R4 does not support the overflow() function