sparkfun / SparkFun_Swarm_Satellite_Arduino_Library

An Arduino library to enable communications with the Swarm M138 satellite modem
Other
28 stars 11 forks source link

Testing on AVR Platforms? #26

Closed aparr001 closed 2 years ago

aparr001 commented 2 years ago

Subject of the issue

Was this ever tested on AVR platforms? It appears the serial port cannot keep up with the required 115200 baud rate. The Arduino website claims it will work on all platforms. https://www.arduino.cc/reference/en/libraries/sparkfun-swarm-satellite-arduino-library/

Your workbench

Platform: Mayfly Datalogger ATmega1284p 8MHz Device is wired using Serial1. Powered using USB

Steps to reproduce

First communication command to modem fails. We have verified the command is being sent and the modem is replying with a proper response using an o-scope and a serial decoder module. The microcontroller always gets the first character correct and then fails to properly receive subsequent characters properly in the string. They are always corrupt.

We then sent simple commands from a PC terminal using Serial instead of Serial1 port on the board and saw the same behavior. This should be using hardware serial and we even utilized SerialEvent to speed up things the best we could. Slower baud rates work just fine.

Expected behaviour

It should work

Actual behaviour

We suspect it fails due to the underlying serial code not emptying the hardware UART buffer fast enough.

PaulZC commented 2 years ago

Hi @aparr001 ,

The library does work on AVR platforms - provided the processor has enough RAM. It works on ATmega2560 using Serial1 - I've just re-tested it. But it will not work on the ATmega328P (as used on the Uno and our original RedBoards) - that does not have enough RAM.

Looking at the specs for the ATmega1284P, it should work OK. 16kB of RAM should be more than enough. Yes, you should use the second hardware serial port (Serial1, TXD1 and RXD1) when connecting to the modem.

I do not have a Mayfly to test, but - looking at the schematic - it should work OK using Serial1. It is all 3.3V IO, which is good. (Some older ATmega boards are 5V only). Please check you do not have an XBee inserted - that uses RXD1 and TXD1 too.

Please also check you have opened the split pads on the modem to disconnect TXO and RXI from the CH340.

I'm happy to discuss further - but, without a board to test, I don't know how much help I will be

Best wishes, Paul

aparr001 commented 2 years ago

@PaulZC I can send you a mayfly logger at my own cost if you want to test. RAM isn't the issue. I think it isn't fast enough to keep up. Are you running the ATmega2560 at 8Mhz?

PaulZC commented 2 years ago

Hi,

I saw your post on the EnviroDIY website. I agree, it could be the voltage and/or clock speed which is causing the issue.

The ATmega2560 I have is a 5V board running at 16MHz. I'm using level-shifters to interface to the modem's 3.3V TXO and RXI.

I'm going to close this issue as it looks like it is hardware or compiler related - not an issue with this library or the SparkFun modem board. But please feel free to ask more questions and I will help if I can.

Good luck with your project! Paul

PaulZC commented 2 years ago

PS. A simple loop-back test will show if Serial and Serial1 can run at 115200. Connect TXD1 to RXD1 and run the following. Anything you type in the terminal / serial monitor should be echoed back without errors.

void setup()
{
  Serial.begin(115200);
  Serial1.begin(115200);
}

void loop()
{
  if (Serial.available())
    Serial1.write(Serial.read());
  if (Serial1.available())
    Serial.write(Serial1.read());
}
aparr001 commented 2 years ago

A loop back test works fine. Which I suspected it will. This is because the TX is also rate limited, in terms of bytes, by the CPU speed or serial driver inefficiencies. When you hammer on it with something that sends bytes literally back to back like a USB to serial converter, it fails.

aparr001 commented 2 years ago

Tried it with a Teensy 4.1 and things work. So can confirm that the MayFly Logger will NOT support it.

PaulZC commented 2 years ago

Thanks for the update. I’m struggling to believe it is a problem with the ATmega1284P hardware. My hunch is that the issue is linked to the way Serial is implemented in the board package software. But it’s just a hunch…

All the best, Paul

aparr001 commented 2 years ago

I agree. I'm almost certain it is poor implementation of the serial.