I am thinking of creating a C program that will use picocom to read and write serial streams to ports (GPS module, NTPD). The c program will run on a Debian OS.
Is it possible to do this using Picocom? Is it bad design to interact with Picocom through c and system commands?
While that's technically possible, it's a bad idea; picocom is a somewhat uncommon tool, and it's primarily designed to be used interactively by a user. Trying to use it from within another application will be pretty weird.
It'll be much easier to interact with the serial port directly from your application. There's a nice introduction to doing that in the answer to How to open, read, and write from serial port in C.
Related
I've found that Elixir programs can run C code either via NIFs (native implemented functions) or via OS-level ports. Having read those and similar links, I'm not a hundred percent clear on when to use one or the other method (or something else entirely?), and feel it would be good to have a direct comparison available, for myself and other novices. Can anyone provide?
What are ports?
Ports are basically separate programs which are run separately from the Erlang VM. The Erlang VM communicates with the running port over standard input/output, and the resulting port lives behind an Erlang process that owns it and can facilitate communication between the port and the rest of your Erlang or Elixir application. Ports are "safe" in the sense that if the port crashes, it doesn't bring down the whole Erlang VM.
Porcelain might be of interest as a possible improvement and expansion over what's already provided in the Port module. System.cmd/3 also uses ports in its underlying implementation.
What are NIFs?
Native inline functions or "NIFs" are functions defined in what are essentially shared libraries / DLLs loaded by the Erlang VM and written using some language which exposes a C-compatible ABI. NIFs are more efficient than ports (since they don't have to communicate over STDIN/STDOUT) and are simpler in many respects (since you don't have to deal with encoding and decoding data between your Elixir and non-Elixir codebases), but they're also much less safe; a NIF can crash the Erlang VM, and a long-running NIF can potentially lock up the Erlang VM (since the scheduler can't reason about native code).
What are port drivers?
Port drivers are kind of an in-between approach to integrating external code with an Erlang or Elixir codebase. Like NIFs, they're loaded into the Erlang VM, and a port driver can therefore crash or hang the whole VM. Like ports, they behave similarly to Erlang processes.
When should I use a port?
You want your external code to behave like an ordinary Erlang process (at least enough for such a process to wrap it and send/receive messages on behalf of your external code)
You want the Erlang VM to be able to survive your external code crashing
You want to implement a long-running task in your external code
You want to write your external code in a language that does not support C-compatible FFI (or otherwise don't want to deal with your language's FFI facilities)
When should I use a NIF?
You want your external code to behave like a collection of ordinary Erlang functions (particularly if you want to define an Erlang/Elixir module that exports functions implemented in native-compiled code)
You want to avoid any potential performance hits / overhead from communicating via standard input/output and/or you want to avoid having to translate between Erlang terms and something your external code understands
You are reasonably confident that the things your external code is doing are neither long-running nor likely to crash (including, in the latter case, if you're writing your NIFs in something like Rust; see also: Rustler), or...
You are reasonably confident that crashing or hanging the Erlang VM is acceptable for your use case (e.g. your code is both distributed and able to survive the sudden loss of an Erlang node, or you're writing a desktop application and an application-wide crash is not a big deal aside from being an inconvenience to users)
When should I use port drivers?
You want your external code to behave like an Erlang process
You want to avoid the overhead and/or complexity of communicating over standard input/output
You are reasonably confident that your port driver won't crash or hang the Erlang VM, or...
You are reasonably confident that a crash or hang of the Erlang VM is not a critical issue
What do you recommend?
There are two aspects to weigh here:
Process-like v. module-like
Safe v. efficient
If you want maximum safety behind a process-like interface, go with a port.
If you want maximum safety behind a module-like interface, go with a module with functions that either wrap System.cmd/3 or directly use a port to communicate with your external code
If you want better efficiency behind a process-like interface, go with a port driver.
If you want better efficiency behind a module-like interface, go with NIFs.
I'm working on a small C videogames library for the Raspberry Pi. I'm coding the input system from scratch and after reading and seeing some examples about raw input reading, I got some doubts.
For mouse reading, I just use /dev/input/event1, I open() it as O_NONBLOCK, I read() input_event(s) and I also put the mouse reading in a separate pthread. Easy.
For keyboard reading, I saw some examples that reconfigure stdin to O_NONBLOCK (using fcntl()), then save and reconfigure keyboard termios attibutes (ICANON, ECHO), and some example also save and reconfigure keyboard mode with ioctl(). What's the point of doing all that stuff instead of just reading /dev/input/event0 input_event(s) (same way as mouse)?
Note that I undestand what those functions do, I just don't undestand why should be better to do all that stuff instead of just reading input_event(s).
Reading stdin is not limited to reading locally connected keyboards (but has other limitation making it mostly unsuitable for games). Then reading stdin you could be reading keystrokes from a user logged in remotely, using a locally connected serial terminal or a terminal emulator (possibly operated from a remote X server).
For terminal based games it might make sense to use stdin. But then it would probably be better to use GPM instead of reading /dev/input/event1 for the mouse. And possibly even better to use ncurses for everything.
Otherwise you might want to look at SDL, if not for using it directly, at least for learning about different ways to read input. For example, SDL has full support for network transparency using X. Which means a game can execute on one computer but be played on another.
Expanding on Fabel answer - standard input and event1 are entirely different things. Starting from that the event1 does not have to be mouse but can be an other device depending on udev, kernel version, phase of moon etc. - on my (non Raspberry Pi) system it's input device Sleep Button - which has a keyboard interface. In short you cannot and should not assume it's keyboard - or the only keyboard for that matter (for example also YubiKey emulates the keyboard for it's function but it's rather useless as gaming device, and while 2 keyboards are rarely connected to same Raspberry Pi I don't think it's good idea to assume such setup never happens).
Furthermore typically input devices can be read only by privileged user (on older/current systems) or by user holding a 'seat' (on rootless X systems) - assuming you're not using bleeding edge system it means your game can only by used by root user which is usually considered a bad idea.
Finally it only allows for user to play using a evdev subsystem, which probably should be considered Linux/X11 implementation detail. If you try to connect via network (X11, vnc or whaterver), try to use on-screen keyboard or any accessible input program - you might run into problems.
On the other hand what you can do is either use standard input directly, use some more portable libraries like readline (which should be sufficient for rougulike) or use graphics server (probably indirectly via library like QT or SDL as X11 is not the nicest protocol to program against).
Reading from /dev/input/eventN works only on GNU/Linux.
Configuring and using stdin works on any system implementing POSIX.1-2008, specifically chapter 11: General Terminal Interface. So if you want portable code, like say to work on Linux and OS X without rewriting the input system, you'd do it this way.
I just finished a small project written in C, where I read a data stream from a serial port and parse the incoming data.
The software is written for POSIX systems (using termios) and follows the standard steps to working with serial i/o
Opening the serial device using open()
Configuring communication parameters (termios)
Set blocking mode on file handle (fcntl)
Perform read() on serial interface.
Perform close() on serial interface when done.
Other than the socket parts, the code is straight ANSI C.
My question is, how involved would it be to make the code work on a windows platform.
The port would not be written by me, I'd only like to give an indication to others who might be interested in porting it (i.e. trivial, not so trivial, rip your eyes out insanity inducing).
Also if someone has Windows with "Windows Services for UNIX", would they be able to use the code without modifying it?
So, if anyone has experience with this could you please share.
It should be pretty easy to do. The names are very different, but the sequence of calls and concepts are very similar.
What you are looking for is the DCB structure which should be used with the SetComState() function to set baudrate, stopbits etc. Then use SetCommTimeouts() and set the timeout values in the COMMTIMEOUTS structure to make subsequent read calls blocking.
Here is a short introduction as a pretty PDF. (Backup.)
In ANSI C on Windows what is the best/easiest way to transfer data between two programs running locally without needing to write/read from a file? Data will be basic text and only one program will be sending and the other receiving. Thanks.
Inter-process communication is inherently platform-dependent; "ANSI C" doesn't have anything to say about this, but you should start here for Windows:
http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx
Much depends on the kinds of applications you're talking about, and the volume of data, and how tightly coupled the processes are.
I am working on a robot automation project and I have run into a road block. To control the robot, one needs to connect with it wirelessly via telnet and send commands through the tcp/ip protocol. (ex. The 'Mabc' command moves it forward based on the left wheel speed (a), the right wheel speed (b) and time (c)). What I am trying to do is do some calculations in a C program and then send a message to the robot based on the value of the calculation.
How can send commands via tcp/ip protocol in a C program?
Thanks!
Erik
You are looking for sockets. This is a comprehensive guide to socket programming in C. Telnet is also a well defined protocol, although I don't know if this robot would use telnet or not (it's extra processing overhead for a protocol that wouldn't have much added benefit for a robot control program). Telnet is covered in detail by RFC 854
Expect would allow you to interact with external programs, but I am not aware of a C port of expect. Otherwise you would find a telnet library in C or write your own using socket programming.
I would use libcurl: http://curl.haxx.se/libcurl/. It'll do what you want, and handle all the telnet goo that you really don't want to handle.
Expect was designed to do exactly this - hold conversations with interactive programs. It's written in Tcl, extending the Tcl interpreter with various commands. Tcl is very easy to extend; it was designed to be an embedded scripting language right from the word go. The main C API uses argv-style constructs to pass parameters to Tcl commands and is very easy to use. The best guide to the C API is Ousterhout's original book and it took me one two-hour lab session to get my first embedded Tcl interpreter up and running.
As a bonus you also get a built-in Tcl interpereter, which you can use to add a scripting capability to your application. You'll probably find that quite a bit of it can be implemented in Tcl if you feel so inclined, so it will probably save you time overall.
I would be:
writing some simple shell scripts containing the telnet interractions written as here documents.
using a .telnetrc file in your home directory to control aspects of your telnet session, e.g. crmod
calling the script using system calls.
This way your turnaround time to change your interractions with the robot won't involve having to recompile your programm all the time.
BTW This sounds like fun.
HTH.
cheers,
Rob