Description

STM32F1 and STM32F4 series are not supported

Steps To Reproduce Problem

n/a

Hardware & Software

Board: BluePill based on STM32F103; BlackPill based on STM32F401/STM32F411 Shields / modules used: BluePill , BlackPill Arduino IDE version: 1.8.19

Version info & package name (from Tools > Boards > Board Manager): STM32 MCU based boards by STMicroelectronics v2.3.0 Operating system & version WIN10

Thank you!

Description

Describe your problem.

Does not appear to have support for ATMEGA328PB.

Steps To Reproduce Problem

Please give detailed instructions needed for anyone to attempt to reproduce the problem.

Just try compiling for ATMEGA328PB

Hardware & Software

ATMEGA328PB

Errors or Incorrect Output

Error while detecting libraries included by C:\Users\maeso\Documents\Arduino\libraries\AltSoftSerial\AltSoftSerial.cpp

Support Request for Arduino Portenta

The new Arduino Portenta has several UART's if using the Breakout Board but by itself it only has SerialUSB and Serial1 at D13, D14, which would be fine if it were single core but it is a dual core board. Any chance of getting AltSoftSerial working on this board. I would test any changes you suggest.

I tried #define ARDUINO_AVR_SODAQ_MBILI which would use pins 5, 6 but it errored on #define ALTSS_BASE_FREQ F_CPU

I will search a bit about that. Any opinions on if this could get running?

As a user I need to reverse the sense of the RX and TX lines to communicate with a particular piece of hardware as in SoftwareSerial, but I also need the full-duplex communication support of AltSoftSerial.

Description

Please see Pull Request #59

New feature. Add the Inverse flag to AltSoftSerial Library with appropriate constructors. In the Transmission and Reception code, invert the outputs with the flag is true. When the flag is the default value of false, the code functions exactly as before. The original constructors are unchanged.

Steps To Reproduce Problem

New Feature.

Hardware & Software

Tested with an Sparkfun RedBoard Arduino Arduino IDE version 1.18.10 Teensyduino version (if using Teensy) 1802 Membership Card running MCSMP20J ROM (with inverse logic on the RX and TX lines) and for regression testing 1802 Membership Card running MCPSMP20A ROM (with positive logic on RX and TX lines)

Arduino Sketch

// Change the code below by your sketch (please try to give the smallest code which demonstrates the problem)
#include <Arduino.h>
/*
  Serial Connections for 1802 Membership Card MCSMP20J

  Arduino Pin     MCard1802
    9 (TX)        /EF3 (RX)   P1 - 27 
    8 (RX)          Q  (TX)   P1 - 12
    GND             GND       P1 -  1 (or P1 - 30)
*/

//Note: SoftwareSerial is *NOT* Full-duplex and won't work here.
#include <AltSoftSerial.h>

//RX pin 8, TX pin 9, with RX and TX inversion
AltSoftSerial altSerial(true);

void setup() {
 //Initialize serial for input and debugging
  Serial.begin(115200);
 //Initialize AltSoftSerial for communication to 1802
  altSerial.begin(1200);
  Serial.println("Ready!");
  //Establish communication with <CR>
  altSerial.write('\r'); 
}

void loop() {
  // If anything comes from Arduino IDE
  if (Serial.available()) {      
    // get the new byte:
    char nextChar = (char)Serial.read();            
    altSerial.write(nextChar);     
   //wait a bit for 1802 to process character sent
   delay(20);
  }
  if (altSerial.available()) {
    // get the new byte:
    char inChar = (char) altSerial.read();

    //Mask off high bit
    inChar = (inChar & 0x7F);
   //Write to Arduino Serial Monitor
   Serial.write(inChar);
  } // if altSerial.available
}

I have submitted pull request #59 to add the support for the inverse argument to the AltSoftSerial library. Merging Pull Request #59 will close this issue.

This pull request implements the inverse flag so that AltSoftSerial inverts the sense of RX and TX similar to the inverse flag in SoftwareSerial library.

Unlike the earlier pull request from @BikeMike, the inverse flag affects the sense of both the RX and TX pins. The earlier request only inverted the sense of one line, so it was a partial implementation. This pull request is a full implementation.

This code has been tested with an inverse serial line device, and a device running with the normal sense of the lines. Code that ran fine with AltSoftSerial runs fine with this change.

I implemented this change because I needed to reverse the sense of the lines to communicate with a particular piece of hardware, but I also need full-duplex communication.

This change allows me to run AltSoftSerial to achieve those goals.