8 RS422 Full duplex serial ports (using the good drivers) working at 38400bps.
I plan to use an MEGA because it as a lot of I/O.
My main question is : Is NewSoftwareserial able to handle 8 serial stream at the same time ?
If it can it's super. The next step is to add an Ethernet Shield and then creating an udp protocol that will multiplex the 8 streams and then sending it by unsing an Ethernet<->Fiber converter.
On the other side, the same board with the same ethernet shield.
The RS422 will be full transparent, ie each revceiver will send and get datas from the one at the oposite.
Do you think it is possble to realize it ?
Grag38
ps :
I already made some projects with arduino - ethershiled - nRF24L01 modules / also with 485 half duplex drivers.
I'm also a good programmer with C language and know how to write TCP/IP server/clients software.
Graynomad:
There are a few dual, quad and even octal UARTs around, you may have to use them.
Are you talking about maxim chip ?
May I get an reference ? Before I post I was thinking about max488 x 8 to realize it.
PaulS:
Is NewSoftwareserial able to handle 8 serial stream at the same time ?
No. It can manage one stream at a time.
I don't need a real realtime. I was tinking with some piece of code like :
pseudo code !
void loop()
{
bool dataToSend = false;
for (in485=0; in485<7; in485++) // check about data to send through the 8 485 ports.
{
if (my485[in485].available()>0) // there are some data, collect them
{
dataToSend=true;
putDatasInBuffer(in485);
}
}
if (dataTosend) // make an udp packet and send it
{
makeUpdPacketfromBuffer();
sendUpdPacket();
}
if (UpdPacketReceived) // ok we've got datas that come from ethernet
{
for (out485=0; out485<7; out485++)
{
ExtractAndWriteDataTo485(out485); // get them an write it to the right destination rs485 out port
}
}
}
Are you saying that newSoftSerial would not be able to manage it as fast ?
I don't want to collect datas into the computer. the connexion will be somting like :
Actually I think we are talking about two different requirements and their possible solutions. First the voltage/current driver/receiver requirements need to support RS-422 full duplex four wire serial links is easily met with the many TTL to RS-422/485 type driver/receiver chips.
However the requirement for 8 UART full duplex channels is quite a different challenge. The arduino meg boards of course have 4 hardware UART full duplex channels on chip so that doesn't solve the need for four more. I would think one nice solution would be to use the required number of I2C/SPI UART chips (along with the additional driver/receiver chips mentioned above) that are available such as this one:
NXP also makes SPI/I2C UARTs.
Example of a dual UART:
sc16is752
Skyjumper used this on a project a while ago, I am doing up code for another project now.
Have to change the crystal before I test. Blindly copied crystal from '2560 and didn't change the frequency from 16 MHZ to 11.0592 MHZ.
16 MHz can't be divided by anything to get 115,200, while 11.0592 /96 = 115200
CrossRoads:
NXP also makes SPI/I2C UARTs.
Example of a dual UART:
sc16is752
Skyjumper used this on a project a while ago, I am doing up code for another project now.
Have to change the crystal before I test. Blindly copied crystal from '2560 and didn't change the frequency from 16 MHZ to 11.0592 MHZ.
16 MHz can't be divided by anything to get 115,200, while 11.0592 /96 = 115200
is your post dealing with this subject ? not sure...
But I as read a lot of good advices from you on several post, I hope you could also conribute to this subject...
Well he's talking about a UART chip so I'd say that's relevant.
That SC16IS752 is a nice-looking chip, I'm currently working it into a design.
I plan to use an MEGA because it as a lot of I/O.
True, but you need UARTs not GPIO and it only has 4.
Now while Software serial cannot rub it's tummy and chew gum at the same time it may work IF the commands are staggered. IE if you can control the timing of the commands you could read 1, write 1, read 2, write 2 etc etc.
If the command timing is random/asynchronous then you have to use more UARTs and the SC16IS752 has 64-byte FIFOs so if your commands are < 64 bytes you don't even need to use RAM for buffers.
In both cases I see little benefit in using a Mega although the extra RAM may be useful for buffers if you can use SoftwareSerial.
I doubt SoftwareSerial is going to do the job you need. In fact, given the strict conditions that would have to be met for there to be even a hope that SoftwareSerial would work for more than 1 stream, I would say with confidence that it won't work. Now the UART Crossroads suggested, that's is worth your time. Two of those added to a mega would be 8 UARTs. Four of those coupled with some RS-422 driver chips and you are in really, really good shape. Then you can use any Arduino board you like.
skyjumper:
I doubt SoftwareSerial is going to do the job you need. In fact, given the strict conditions that would have to be met for there to be even a hope that SoftwareSerial would work for more than 1 stream, I would say with confidence that it won't work. Now the UART Crossroads suggested, that's is worth your time. Two of those added to a mega would be 8 UARTs. Four of those coupled with some RS-422 driver chips and you are in really, really good shape. Then you can use any Arduino board you like.
I found in old posts that you worked with that chip. Did you success on your project ?
Can you give us some schematics, or elements that will help me to realize it ?
CrossRoads:
Is the DSS Circuits I2C library used with this?
Or is it one or the other?
Do you mean with this chip or with the MultiSerial shield?
Either the standard Wire library or the DSS Circuits library will work with this chip. I use the DSS Circuits library because I need to talk to this chip from inside an interrupt service routine (ISR). The Wire lib uses interrupts, and therefore can not be used inside an ISR. The DSS library does not use interrupts, so it can be used inside an ISR.
But it's really amazing about looking for RCP SONY protocol. It's impossible to find it on the internet.
I would like operate an reverse ingeneeiring to 'decode' it.
Do you know a right way just to discover the baudrate that is used for an protocol ?
If I'm sure about this kind, It will easy to reverse the datas to understand the protocol.
But elsewhere, if someone get the RCP SONY protocol to drive all parameters from a braodcast video camera I will offer some drinks !