I'm working with 2 little machines with limited unix tools. Both are conected between each other via serial. I'm transfering binary data, so the devices are on raw mode. The sending machine is sending files to the other one and between there's a delay of X ms (specified as parameter). I would like to know if it's possible to measure those delays on destination machine in order to identify how many files are coming. Till now i was using cat < /dev/ttyS5, but this is not a option to my purpose.
Any idea?
Thanks
IMHO the easiest way is to write a little program which is waiting for bytes on the serial line.
Everytime a character arrives some sort of timer/timestamp is reset.
Another thread could be evaluation this timer/timestamp in a loop and increment a counter if it's larger than a defined value.
But please be aware that you might experience delays from the serial line as there's the kernel and its scheduler "in between". Furthermore you'll need appropriate locking of course!
Related
Sorry for my bad english first.
I'm currently working on an Arduino project which is really simple.
I'm working on an attendance logger for my school to know how much time students are spending studying.
The RFID Reader part is working fine. When a tag is detected, I'm storing the value and the time in a SD Card.
Every hour, my system have to send the logs to a web server to store it in a database and here come my problem. I'm struggling with the ethernet part.
Indeed, when I'm performing a HTTP Request, my sketch is "blocked" and students can't use the system anymore.
It's a real big problem, because if there are like 200 lines in my logs, sending those throught a request, one by one, will take really long.
I'm already aware of using millis() to use "multi-tasking".
I have absolutly no idea about how to send requests without "blocking" my sketch.. I'm not looking for someone to write my sketch. I just want to know if there is a way to avoid the "blocking" effect of the ethernet shield when I'm performing a request.
Thanks for your help.
Even if you send one by one, you dont have control over the server side. you have no gurantee that the server will Always response within a certain timeframe.
if your system is very busy, then this may not be your perfect solution.
on other hand, just a thought though, (I dont have personal experience with ethernet shield.)
you could send data serially from first arduino to second ardiuno, individually, every time RFID is detected. This should not take much time compare to the time to send 100 lines of logs. Now, one by one, second ardiuno can save these data in its memory until it is finally sent to server.
now when second arduino is busy sending data to server, we can collect some those RFID reading in first arduino's memory, and pass to, when the things with server is done.
to check if second arduino is bg, we could set a pin high in second arduino until the server part is done.
but still, I dont see why do you have to send it every one hour. I am asuming you have your reason.
If you still want to save some time, the make a parallel data transfer between two arduino, instead of serially.
I'm reading and writing the characteristics from my board using bluez-4.101. using gatttool.
sometimes i get Characteristic Write Request failed: or read failed.
Frequency of these errors is like 2/10, is there something that i can do to make full proof, if it is usual, I'd like to reduce the timeout i get before failing.
If you say the frequency is not 100% then this is probably not a software issue. Rather, you might have to bring that your devices are brought closer together so that there is less chance of interference, or that your advertising device has a higher tx power.
Unfortunately there is no option through the BlueZ commands to reduce the timeout. I'm guessing you are using the gatttool command to interrogate the gatt table on the other end. Use #gatttool --help-all for a full list of the options and you will see that the timeout is not one of them.
Is that possible to achieve Inter process communication using any terminal or serial ports in AIX or Unix?
I would like to achieve this by using commands/scripting only where one process writes a string on terminal and another process reads same terminal and processes that string. I know that using pipe also this is possible but I do not have enough idea on that.
Also is there a way we can determine which all ports/terminals are available in AIX machine?
Or is it possible to create new terminal at run time (not the boot time) that will be used by only above two processes?
I think what you want are pty's? Or, another option would be unix domain sockets.
The answer to your first question is "no"... not really. When you write out to a tty, that output is sent out to the real device and not available to be read back.
The list of tty's on a system is: lsdev -Cctty
Creating tty's at run time is possible but not really what you want either. A tty is a child of a serial port and you can not add serial ports arbitrarily. They are real things. With AIX and Power systems, you can add devices while the system is up (hot swap) but that is getting (I'm assuming) way far off your original topic.
The basic different between a pty and a unix domain socket is a pty mimics the output and input process of a real tty in one direction. This is what telnet, rlogin, ssh, and many other daemons use when connections come in. It is easy to make ksh believe that it has a real tty by using pty's. If you don't need that, then they are added trouble that you don't need. Find a link on how to create and use a Unix domain socket and you will have what you need (or a pipe but a pipe requires a parent / child relationship which I assume you do not have).
I need (to design?) a protocol for communication between a microprocessor-driven data logger, and a PC (or similar) via serial connection. There will be no control lines, the only way the device/PC can know if they're connected is by the data they're receiving. Connection might be broken and re-established at any time. The serial connection is full-duplex. (8n1)
The problem is what sort of packets to use, handshaking codes, or similar. The microprocessor is extremely limited in capability, so the protocol needs to be as simple as possible. But the data logger will have a number of features such as scheduling logging, downloading logs, setting sample rates, and so on, which may be active simultaneously.
My bloated version would go like this: For both the data logger and PC, a fixed packet size of 16 bytes with a simple 1 byte check sum, perhaps a 0x00 byte at the beginning/end to simplify recognition of packets, and one byte denoting the kind of data in the packet (command / settings / log data / live feed values etc). To synchronize, a unique "hello/reset" packet (of all zero's for example) could be sent by the PC, which when detected by the device is then returned to confirm synchronization.
I'd appreciate any comments on this approach, and welcome any other suggestions as well as general observations.
Observations: I think I will have to roll my own, since I need it to be as lightweight as possible. I'll be taking bits and pieces from protocols suggested in answers, as well as some others I've found... Slip,
PPP and HLDC.
You can use Google's Protocol Buffers as a data exchange format (also check out the C bindings project if you're using C). It's a very efficient format, well suited to such tasks.
Microcontroller Interconnect Network (MIN) is designed for just this purpose: tiny 8-bit microcontrollers talking to something else.
The code is MIT licensed and there's embedded C and also Python implementations:
https://github.com/min-protocol/min
I wouldn't try to invent something from scratch, perhaps you could reuse something from the past like ZMODEM or one of its cousins? Most of the problems you mention have been solved, and there are probably a number of other cases you haven't even though of yet.
Details on zmodem:
http://www.techfest.com/hardware/modem/zmodem.htm
And the c source code is in the public domain.
I'm asked to read from and write to a half-duplex serial connection using POSIX calls (more specifically, writing in C on Linux 2.6.x). I'm having slight troubles finding detailed information on that particular model (most pages concentrate on full-duplex) and as I am getting slight anomalies when reading, I wanted to check whether maybe I am doing something wrong here.
With a half-duplex serial connection, I can only read or write. This is not a problem, as there is no unsolicited incoming data on the line - the only time any packages are sent to me (for reading) is when I asked for them beforehand.
So what my code does is to write() to the port whenever something needs to be sent. Should this data result in a response (something I know beforehand), I simply read(). There are no special functions I am calling - but maybe I should? And is this approach correct? I.e. write when the line is free?
I would read the Linux kernel source documentation, there may be a text file about the serial driver; if not, you could read through the actual driver code to see what it does (it's not as scary as it sounds, I promise!)