<First response removed by self>
Hopefully relevant.
Note: it is not the system that is adding on the parity or the like to the data that is received. It simply returning the data as sent to you by the device. And it is that data that is defined by the protocol.
7E1 or 7O1 - sends 8 bits of data, where the low 7 bits is your information and upper bit is the parity bit. (Luckily, we don't have to support MARK or SPACE)
https://en.wikipedia.org/wiki/Serial_port#Parity
Which I totally agree, can be a pain. I remember some system I worked on long ago, where the code had to generate the parity bit, before it would allow you to send the data.
Likewise, a pain to have to remove it.
As for the Pull Requests - Paul(PRJC) owns the code and obviously he can choose to take it in or not.
My check of the first file, I would not recommend it in the current form, as it will bust other functionality. For example, suppose I had turned on 9 bit mode which we don't enable by default as it doubles the size of the software queues. The updated code ands the data that is placed in the queue by either 0x7f (for your case) or 0xff which would bust the 9 bit data. Or 10 bit data in the case of T4.x.
Also I have no idea if it will bust other developers code, which maybe checks the parity of the bytes coming in against the serial specification.
Now if it were me, and I did not like to have my code have to do the and of the data, I would simply generate a simple wrapper class for the hardware Serial object, that did it for me, while isolating the changes to just my code.
Code:
class RemoveParityHardwareSerial: public HardwareSerial
{
public:
constexpr RemoveParityHardwareSerial(HardwareSerial &hserial) : _hserial(hserial) {};
void begin(uint32_t baud, uint16_t format=0) {_hserial.begin(baud, format); }
void end(void) {_hserial.end();}
virtual int available(void) {return _hserial.available();
virtual int peek(void) {return _hserial.peek() & 0x7f; }
virtual void flush(void) {return _hserial.flush();}
virtual size_t write(uint8_t c) { return _hserial.write(c);}
virtual int read(void) {return _hserial.read() & 0x7f); }
int availableForWrite(void) {return _hserial.availableForWrite(); }
protected:
HardwareSerial _hserial;
};
How complete the class needs to be depends on your needs. Also did not try to compile as typed here on the fly, so probably edit issues and/or more methods
that are needed.
But then: you could have something in your code that looks like:
RemoveParityHardwareSerial Serial1NP(Serial1);
And then simply use it instead of Serial1... You can also continue to call Serial1 methods if needed to fill in some things, maybe not in this simple wrapper.
Again if it were me, that is how I would do.