I'm writing software to communicate with badly designed hardware. This hardware can communicate with linux pc (kernel 4.15) by RS485 line (9600 8N1) and it has very short timings: pc should reply in 2ms after receiving request from device.
I was able to solve this task using LOW_LATENCY flag and /sys/class/tty/ttySx/rx_trig_bytes file.
After opening port "rx_trig_bytes" file contents changes to "14", so I need write "1" to it after opening port to get good reply latency.
Is there any way to make this by API call or fix it after system boot / driver load ? Current realization looks ugly :(
Funny you find this way ugly, considering everything is a file in Unix, it should be the smart way.
I guess you are entitled to your own aesthetic sense.
If you want to make another buffer size the default you can always change it in the driver and recompile the kernel as suggested here.
Related
I'm using a LPC178 development board and I want to read a file present on a Windows PC. My dev board only has a RS2323 interface to communicate with.
How can I go about transferring the file from my PC to my MCU using a RS232 (serial) link? I found a reference which explains how to transfer data between a MCU and PC but it isn't about file transfers.
Afaik there is no easy solution for this like calling something like "copy" or "fopen" over RS232. I would be happy to be proven wrong here.
The fastest solution might be to write a little programm running on your Windows Host, which listens to your RS232 communication and pipes your communication into/out of the file based on your communication protocol. This can be done with standard file operations in the language of your choice, for example C, C++ or Python.
Your problem is one of the oldest in the book. How do you transfer files without fancy operating system abstractions. For RS232 (or any other serial method) there exists many file transfer protocols.
One of them is kermit. This is a protocol from 1981 and can transfer binary and text files. It is able to be embedded in a micrcontroller and there exists programs to transfer/receive using kermit.
alternative old site for reference
In the simplest case you would use a file transfer protocol such as XMODEM, YMODEM, ZMODEM or Kermit - these protocols were designed in the days before networking and the Internet were ubiquitous and deal with simple point-to-point transfers between two computers. They are supported bu most terminal emulator tools such as TeraTerm Pro or PuTTY so no specific PC software need be written, just the microcontroller end.
A more complex but flexible solution is to implement a TCP/IP stack and a PPP driver, and an FTP application layer - probabaly only practical if using a third-party TCP/IP stack and application layer. You can then use any FTP client for the PC end, so again no PC software required. While this may be overkill if all you need to do is transfer files, it has the advantage of allowing you to use the the single serial port concurrently for other data streams and application protocols such as Telnet. The disadvantage perhaps is that while Windows does support PPP it is buried within the dial-up networking and to be frank a pain to get working.
Very first step you have to do is ensure serial communication is working fine.
Send a byte continuously from mcu to PC and display it on some io console (for example: HyperTerminal, Dock light )
Receive a byte to mcu from PC and echo it back to PC.
Once you are sure that serial communication is working fine then select some file transfer protocol and implement it.
While you can select any of the available protocols or write your own protocol and implement it.
For purpose of discussion i select Xmodem protocol.
If you consider some other protocol you may stop reading answer here.
XMODEM is a simple file transfer protocol.
Refer http://web.mit.edu/6.115/www/amulet/xmodem.htm for detailed information.
You may implement Xmodem mcu side by reading protocol. Or may consider using open source also ( if available )
PC side i prefer to use HyperTerminal io console as it is compatible with Xmodem.
In HyperTerminal all that i have to do is configure settings and select file for transfer to mcu.
Now transfer any file to mcu using Xmodem protocol from PC.
What you do with received file in mcu is up to you : )
I have a question linked to Linux and serial port.
I want to be able to receive and send messages to a dedicated serial port and to redirect it to another port (/dev/tty).
For the first part, I’m able to dialog with my hardware equipment without any problem, but I’m just wondering if it’s possible to intercept and redirect message coming from a serial port #1 to another port #2.
To give more context, I had used a GPS Antenna and NTP open source software for years.
Since 2018, the new GPS antenna protocol has modified the order of bytes in the message used by NTP to steer and now it’s not working anymore.
So my idea is to put a simple C program (middleware) which fixes this byte ordering; but I’m wondering if I have to build a kernel-specific module or if it can be done in another way. The NTP software uses the symbolic link to dialog.
Thanks for your help.
You can probably use a simple redirect, look here:
Pipe One Serial Port to Another in Linux
If the ports are in different rates you can use stty or perhaps screen to adjust: https://unix.stackexchange.com/a/117064
If you need it to be in c program to manipulate it you can use the following: https://stackoverflow.com/a/6947758/8901188
Using c it will need to run in an infinite loop so it can constantly read, manipulate and write the data.
I have recently started learning to write Linux device drivers for a specific project that I am working on. Previously most of the work I have done has been with devices running no OS so Linux drivers and development is somewhat new to me.
For the project I am working on I have an embedded system running a Linux based operating system. I have an external device with is controlled via RS232 that I need to write a driver for.
Questions:
1) Is there a way to access serial ports from withing kernel space (and possibly use serial.h, serial_core.h, etc.), how is this usually done, any good examples?
2) From what I found it seems like it would be much easier to access the serial ports in user space by just opening dev/ttyS* and writing to it. When writing a driver for a device like this (RS232 device) is it preferred to do it in user space or is there a way to write a kernel module? How does one decide to write a driver as a kernel module over user space or vise versa?
Are drivers only for generic devices such as UART/serial and then above that is userspace or should this driver be written as a kernel module? I appreciate the help, I have been unable to find much information to answer my questions.
There are a few times when a module that communicates over a serial port may be in the kernel. The pppd (point to point protocol daemon) is one example as Linux has some kernel code devoted to that since it is a high traffic use of serial and it also needs to turn around and put the IP packets into kernel space.
Most other uses would work better from user space since you have a good API that already takes care of a lot of the errors that can happen. This also lessens the chance that your errors will result in massive system failure.
Doing things like this from user space does result in some latency. Reads and writes are buffered, and it's often difficult to tell where in the write operations the hardware actually is, and canceling an already succeeded write call isn't really doable from user space, even if the hardware hasn't yet received the bytes.
I would suggest attempting to do it from user space first and then move to OS driver if necessary. Even if it is necessary to move this into an OS level driver, you'll likely be able to get some progress made from user space.
I am writing a C program in Linux which will read/write to/from a serial port. I know the data that needs to be read and written on the port but I don't have a serial port to currently test this with.
Is there any way to simulate a serial port? Would reading/writing to a file be sufficient? I can have one process write to the file while another process reads that data and writes back other data to the file. Or are there others tools that can be used to simulate a port?
Thanks
Serial ports on Linux are terminal devices. A close simulation is to create a pseudo-terminal pair; the program that normally talks to the serial port is instead told to open the slave side of the pseudo-terminal, and the simulator writes and reads from the master side.
The pty(7) man page has more information.
Despite being an old topic, and my answer is not exactly something the OP was looking for, I decided to share my experience, as someone else might come across it like I did. Instead of straightforward simulation, I used the software called Serial to Ethernet Connector to gain access to the specific device I needed to test the app with. Worked nicely for me.
A character device, even something as simple as normal stdin and stdout should work if you don't care about attributes specific to port devices.
is it possible to capture some packets in promiscuous mode (e.g. using winpcap) and than force OS (applications) to receive them as they were sent for our MAC?
My observation is following. We can:
capture all network traffic using
promiscuous mode (winpcap)
filter/modify the packets using
firewall-hook/filter-hook
send packets to the network with altered MAC
I am not sure if firewall-hook can access all the packets which are available thanks to promiscious mode. Isn't it on the lower layer? If it can't, the only solution would be to capture desired packets and then resend them to the network with altered MAC?
I am networking novice so please be easy on me :)
Any help is appreciated.
Thanks in advance.
You have your toes at the line of white hat/black hat hackers. I know that my company actively watches for promiscuous NICs, hunts down the owners and kills (fires) them. Maybe if you ask us what you're trying to do, we can offer some suggestions.
If you're trying to analyze your network, there is software and/or hardware solutions that will probably do a better job. If you're just trying to watch interesting text flow across your network, well ... maybe you're still in college.
First, yes if your interface operates in promiscuous mode then you will receive everything 'on the wire'. Which is already one difficulty, nowadays many (if not all) networks are switched, which means a piece of hardware exterior to your system will already do some filtering before packets arrive at your system, so you'll first need to trick a switch into transmitting those packets to your end (can be done by sending out dummy arps, by configuring the switch, or by bad intent ;-) ).
Then if these packets receive at your system, what do you plan to do with them ? There ethernet frames will carry ip packets, typically with a destination ip address, which is already something which will not be on your host (and if it is, this implies that you will have duplicate ip addresses on your network, causing problems as well.
So the main question is, what do you really really really want to do ?
Once you have recieved a packet, it has already been clean through the protocol stack. I don't think Windows gives you the access into the middle of Winsock that would be required to somehow stick it back in.
More importantly, this is a really dodgy think to be looking to do. Whatever it is you are looking to do, I can guarantee you there is some better way to do it.