How would you connect 17(yes thats right seventeen) serial devices(sensors) and get data from them to a computer? 17 USB ports seems too much to expect. I was thinking 4 arduinos handling the serial communication and then i2c for controller to controller communication. and then finally master controller to computer. But this brings up a lot of questions...
is this the most optimal way of doing this?
how well does the software serial library support multiple devices @19,200?
Anyone tried anything similar? What did you do?
This was a question put to me by someone who called looking to buy a few arduinos. I've tried 4 serial communication on a single arduino @9600 and it worked fine.
I'd use an XMOS system for that. The $99 XC-1A board has a four-core XS1-G4 device with eight hardware threads per core - 32 threads. A UART can be implemented in each thread, and the board has a built-in USB interface.
Arduinos could be used, but the solution would be a lot more expensive and complex.
How would you connect 17(yes thats right seventeen) serial devices(sensors) and get data from them to a computer? 17 USB ports seems too much to expect.
You must be young (that, or forgetful, or senile, or maybe you are like a lot of us and just block those memories - how I wish I could forget; the JD does nothing)...
A long time ago, 17 serial dumb-terminals (and line printers) spread over an office building was a small installation...
XMOS chips are programmed in XC (a version of C for parallel processing), standard C or assembler. A UART is a few lines of XC:
// Simple UART demo
#include <platform.h>
#define BIT_RATE 115200
#define BIT_TIME XS1_TIMER_HZ / BIT_RATE
void txByte(unsigned char);
unsigned char rxByte(void);
out port TXD = PORT_UART_TX;
in port RXD = PORT_UART_RX;
unsigned char array[10];
int main()
{
int i;
while (1)
{
for (i = 0; i < 10; i++)
array[i] = rxByte();
for (i = 0; i < 10; i++)
txByte(array[i]);
}
return 0;
}
unsigned char rxByte(void)
{
unsigned data = 0, time;
int i;
unsigned char c;
// Wait for stop bit
RXD when pinseq (1) :> int _;
// wait for start bit
RXD when pinseq (0) :> int _ @ time;
time += BIT_TIME + (BIT_TIME >> 1);
// sample each bit in the middle.
for (i = 0; i < 8; i += 1)
{
RXD @ time :> >> data;
time += BIT_TIME;
}
// reshuffle the data.
c = (unsigned char) (data >> 24);
return {c};
}
void txByte(unsigned char c)
{
unsigned time, data;
// get current time from port with force out.
TXD <: 1 @ time;
// Start bit.
TXD <: 0;
// Data bits.
for (int i = 0; i < 8; i += 1)
{
time += BIT_TIME;
TXD @ time <: >> data;
}
// two stop bits
time += BIT_TIME;
TXD @ time <: 1;
time += BIT_TIME;
TXD @ time <: 1;
}
That code produces a UART running on a single thread. It can easily be replicated across several threads and cores using the par construct.
You must be young (that, or forgetful, or senile, or maybe you are like a lot of us and just block those memories - how I wish I could forget; the JD does nothing)...
Thanks! Adds to the feel good factor Yes I'm young, have always been. I started off with windows 95.
Well i didn't think of RS485. How do you think it can make a difference?
So you really are young, I started with a main frame and punched tape.
RS485. How do you think it can make a difference?
Because that is more of a bus protocol where the physical connections are common and each device is given an address. Then the master poles each address and only that device responds. It saves you having a stupid number of UARTs or trying to bit bang multiple instances which will appear to work for a bit but will fall over if it gets any degree of traffic.
Because that is more of a bus protocol where the physical connections are common and each device is given an address. Then the master poles each address and only that device responds. It saves you having a stupid number of UARTs or trying to bit bang multiple instances which will appear to work for a bit but will fall over if it gets any degree of traffic.
Seems logical.. will explore this.. However
RS-485 would mean adding a small MCU like a PIC or AVR to each sensor, though, unless the sensor has an MCU already that can be modified.
This could be a problem. Having 17 mcus Sounds a sure recipe for a lot of chaos.
Hehe the first OS I remember is Windows 98 Grin! Ah man I feel really young now..
Well i really started with DOS but then i wouldn't want to count on that as all i new was cd, md, format a: & del*.* (the last one was special i used to modify a bat file to run del . on the school computer!)
So you really are young, I started with a main frame and punched tape.
how was it? always wondered how these systems booted? and what people actually used them for?
Are you saying that each of the 17 sensors has an RS232 output and input but no processor?
If so then look towards getting a more realistic sensor. Virtually anything with RS232 on it has a processor in it somewhere.
If you say more about what these sensors are and what you are trying to do then maybe the advice will be better.
Virtually anything with RS232 on it has a processor in it somewhere.
If you say more about what these sensors are and what you are trying to do then maybe the advice will be better.
I'm clueless about this as well except for the fact that this is some kind of an IMU. As i mentioned earlier someone had called us to check if arduino can do this( we got listed on the site as a distributor) and i suggested the person to post it here on the forum however my curiosity got the better of me and i posted it.
That is a lot of devices to monitor, have you any information about the traffic and data rate? That is a lot of serial inputs, do you need outputs as well?
Without further information the answer would have to be no.
Depending on how your rs232 gizmos operate, you probably could use a board like below to multiplex the tx and/or rx lines between the arduino and the gizmos.
Yes I'm young, have always been. I started off with windows 95.
Sounds a sure recipe for a lot of chaos.