SoftwareSerial unexpected speed change during println

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm working on the following:

- ATmega32u4

- Atmel studio 7 solution, based on Arduino sketch to use SoftwareSerial.cpp

- Communication with the Arduino GSM Shield

- USB is activated to send information on terminal

 

When trying to sending the command "AT+CMGR=1", in ONE SoftwareSerial println call, I have:

 

"AT+C" are send at the desired baudrate of 38400bds (The port is open using .begin(38400))

But "GR=1" are send at the unwanted baudrate of 202bds

 

I used a logic decoder so there is no error possible.

 

What can causes the baudrate to change unexpectedly during a send?

Any help would be really accepted! Thank you!

Last Edited: Mon. Nov 5, 2018 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, I remove some Serial.print in the function calling the Softwareserial.println function. Serial.print that are NOT called!

 

Removing thoose Serial.print make the Softwareserial.println sending the whole cmd at the correct speed...

As they are not called, I do not understand why removing them change the behavior of my programm.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using a Leonardo or Pro-Micro?  Both have a built in h/w usart (Serial1) in addition to the USB (Serial), so why use softSerial?

What other interrupts have you attached in your sketch?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm using a Leonardo. I'm using the softserial because I have another device working with the Serial1 Usart.

The interrupts attached in my sketch are the following:

For Software serial:

- PCINT0_vect

For USB:

- USB_GEN_vect

- USB_COM_vect

 

For delay

- TIMER0_OVF_vect

 

For USART1:

- USART1_RX_vect

- USART1_UDRE_vect

 

I am considering changing for the Mega Arduino board. But I still wondering what causes the very strange behavior of this Software Serial.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moving to a platform with enough h/w usarts is best, but I would start by taking a critical look at all of your ISR()'s and make sure they are short and fast, no delays or calls to external functions or trying to perform long duration actions, as an AVR will block all other interrupts while in an ISR().  SoftSerial is very dependent on accurate timing and quick response to pin change interrupts, anything that blocks it will cause failures like your seeing.

If IRQ()'s are not short and fast, you may still have problems even using h/w usarts....

 

Your troubleshooting will involve determining what is blocking softSerial from doing its job during the time its sending that string.

 

Good luck,

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the ISR() used are from Arduino Sketch... so they should be short! ;-)

 

I would "understand" that for one (or more, but not all) bit, the timing whould not be correct due to another ISR blocking the execution.

What is really strange is that ALL the bits from ALL the bytes are send to the exact same timing corresponding to a 200bauds. It is like a "correct" way a working for the SoftwareSerial with a delay of 5ms between each bits...

 

Another strang thing is that removing a function call, not called during execution, change the behavior of the whole programm!

Last Edited: Fri. Mar 9, 2018 - 03:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What can causes the baudrate to change unexpectedly during a send?

 

Another further comment to add to Jim's guidance, above.

 

The baudrate isn't being changed in the classic sense.

 

The micro, however, is a single core device, it can only process one thread at a time.

So while your software serial routine is executing, one/many interrupts are interrupting the software serial code, and essentially inserting delays where you don't want them.

 

If you write a simple test program that uses the soft serial without any other interrupts running, you can verify that the soft serial routines and your PC end are working correctly, as expected.

 

Then work on adding in the other parts of your project's code.

 

You will need to structure the overall code such that either the other interrupts are not in use when you do use the soft serial routines, or the soft serial routines are not in use when the interrupts need to be running, (essentially the same thing, just a matter of priority and perspective).

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Moving to a platform with enough h/w usarts is best

+1

 

A software UART, by its very nature, is going to be at the mercy of other tasks taking the CPU.

 

If you're short of on-chip hard UARTs, you can always add off-chip UARTs via SPI or I2C ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

AntoineC wrote:
Another strang thing is that removing a function call, not called during execution, change the behavior of the whole programm!

 

Another possibility is running out of ram, i.e. stack space could explain the above behavior. 

What is your program space and ram usage list at the end of the compile.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Really the best thing to do in this situation is to use an MCU with enough UART ports so that you don't have to bit bang the interface. Bit banging will always be unreliable and will never work as well as hardware UART ports. 

This is an example of a atmega board with multiple serial ports.

 

https://www.kickstarter.com/proj...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't start spamming the site. One mention of this board is enough to catch people's interest.

 

Moderator

Last Edited: Mon. Nov 5, 2018 - 02:21 PM
Topic locked