Relatively new to arduino.
on a nano, i would like to receive (only Rx) two serial 9600 baud signals and pack them into a combined higher baud rate serial Tx/Rx serial line.
Do i need to mix hardware serial, softwareSerial and Altsoftwareserial in a specific way or is there a better solution?
thanks for tips.
Hi, here's an idea to consider. A maple mini clone. Similar to Nano but slightly larger, very cheap on eBay, programmable with Arduino IDE and, most importantly, 3 hardware serial ports!
There is a whole support forum for using it with Arduino IDE.
Paul
Do i need to mix hardware serial, softwareSerial and Altsoftwareserial in a specific way
What you are thinking of doing can not be done, you would know that if you understood what asynchronous data actually is.
The solution is to get extra hardware serial ports.
I thought a Mega 2560 had the extra hardware?
Four UARTs in fact.
Yes but he has a nano.
Well, you told him to forget the Nano, and PaulRB suggested something else entirely, so I felt it was fair game.
9600 baud, eh? Sounds fairly tame.
If I could reprise my skills from the 1980s, I reckon I could write machine code to do two serial receivers and a serial output in software without too much trouble. Of course, AVR machine code is different to 6803 (Micro CoCo) and there would have to be some study involved - it would be looking a little more like a paid job, wouldn't it?
And as you implied, I would want a really good explanation of "pack them into a combined" serial stream. 
I used to give my students the problem of converting a data stream at one baud rate to another with a buffer and ask how long would it be before the buffer over ran.
I had to point out to them that this was the same problem they had all done in junior school with bath tubs and water taps.
I have two serial sensors, each delivering data packets asynchroneously over its own 9600 baud line (one sensor occupies 60% of UART time, the other 20% of UART time).
Although I agree that is is always good to have performant hardware, but in this case, availability of the boards, space limitation in an embedded device and power supply were all restrained.
So I stayed with the Nano:
Rx from Sensor1=hardwareUART Rx on pin 0 at 9600
Rx from Sensor2=softwareUART Rx on pin 8, at 9600 using the AltSoftSerial package
TxCombined to WiFi module=hardwareUART Tx at 9600
As receiving a serial signal (determining start bit onset, sampling at suited locations) in 1/9600 sec needs to avoid data loss and leave some computing time, I considered it important to have a compact main loop.
Loop:
- if Serial.available() then receive one character per iteration to a circularBuffer1, .
- if altSoftSerial.available() then receive one character to a circularBuffer2 including a SYNC marker and a channel identifier.
- choose one of the buffers for transmission:
- if a buffer contains at least one packet, transmit 1 character per iteration to the Serial Tx (the other buffer blocked from transmitting) until a packet (including a SYNC byte and a channel identifier) has been transmitted, then switch transmitting to the other buffer if it has at least a packet of data.
EndLoop;
This way, I have succeeded in combining the two channels, up to now without signal loss (needs more testing). Apparently, the AltSoftSerial package does a good job using interrupt handling.
But as Paul proposes as doable,
having a software solution that handles two (or more) software UARTs would certainly be a great contribution.
Well, sounds as if you have been working at it and had success.
Your solution sounds just fine - unless you need to expand it further, the combination of hardware and software UARTs should be adequate for the job you describe, and there would be no benefit in using two software UARTs rather than one software and one hardware.
Your use of the hardware separately for transmit and receive clearly suits your purpose, and you have as I commented, determined your "packet" protocol to distinguish the two data streams. Nothing further to do - as such - other than some possible "fine tuning".