I'm currently writing a light application that handles IO on the serial port, standard input(keyboard) and output (screen). This allows interaction with software embedded on an external board linked to the PC with serial over USB.
I mainly use the read_nonblock function and it works well on Linux:
$c = $usb_ios.read_nonblock(500)
$in = STDIN.read_nonblock(500)
I tried to use it on Windows, but I had an error using read_nonblock, then I learned that read_nonblock cannot be used on Windows.
After reading lot of posts, FAQs, and blogs, I cannot find a simple way to have some kind of non-blocking read on the serial port. (There might be a dirty way for keyboard input.)
Please note that I don't want to use the 'serialport' gem for several reasons. In fact I want it to work with regular, basic, versions of Ruby.
Related
Is is possible to trap the MIDI signals being sent by my keyboard connected via MIDI-USB in Ruby? If not Ruby, how would I do it in C so I can make a Ruby extension?
Use PortMidi, which is part of the PortMedia project. A little Googling showed several references to existing Ruby bindings to PortMidi, so you may not need to do much/any work to get things running.
What is PortMedia?
PortMedia is a set of APIs and
library implementations for music and
other media.
PortMedia is open-source
and runs on Windows, Macintosh, and
Linux.
Currently, libraries support
Audio I/O and MIDI I/O.
I know this probably is not the easiest thing to do, but I am trying to connect Microcontroller and PC using USB. I dont want to use internal USART of Microcontroller or USB to RS232 converted, its project indended to help me understand various principles.
So, getting the communication done from the Microcontroller side is piece of cake - I mean, when I know he protocol, its relativelly easy to implement it on Micro, becouse I am in direct control of evrything, even precise timing.
But this is not the case of PC. I am not very familiar with concept of Windows handling the devices connected. In one of my previous question I ask about how Windows works with devices thru drivers. I understood that for internal use of Windows, drivers must have some default set of functions available to OS. I mean, when OS wants to access HDD, it calls HDD driver (which is probably internal in OS), with specific "questions" so that means that HDD driver has to be written to cooperate with Windows, to have write function in the proper place to be called by the OS. Something similiar is for GPU, Even DirectX, I mean DirectX must call specific functions from drivers, so drivers must be written to work with DX. I know, many functions from WinAPI works on their own, but even "simple" window must be in the end written into framebuffer, using MMIO to adress specified by drivers. Am I right?
So, I expected that Windows have internal functions, parts of WinAPI designed to work with certain comonly used things. To call manufacturer-designed drivers. But this seems to not be entirely true becouse Windows has no way to communicate thru Paralel port. I mean, there is no function in the WinAPI to work with serial port, but there are funcions to work with HDD,GPU and so.
But now there comes the part I am getting very lost at. So, I think Windows must have some built-in functions to communicate thru USB, becouse for example it handles USB flash memory. So, is there any WinAPI function designed to let user to operate USB thru that function, or when I want to use USB myself, do I have to call desired USB-driver function myself? Becouse all you need to send to USB controller is device adress and the infromation right? I mean, I don´t have to write any new drivers, am I right? Just to call WinAPI function if there is such, or directly call original USB driver. Does any of this make some sense?
To make your life easier, and avoid writing your own driver, try using the HID (Human Interface Device) API on top of USB. Although it says "Human Interface", it doesn't actually have to be for devices that a human controls. The advantage is that modern OSes already come with a HID driver and you can use sample code such as what you can find here to get started. Many microcontroller manufacturers provide suitable code for the embedded of the protocol.
Because OSes already understand HID, if you build a device using the HID interface you'll find that not only can you read from it from any OS, you may also find that many applications can already talk to your device if its communication is restricted to a small enough subset of HID. (For example, I built an input device for a music app, but amazingly I found I could literally plug it straight into a 3D animation app we use at work, running on a different OS, and have it work right away without writing a single additional line of code!)
This answer might aim you in the right direction.
The first answer here might also be helpful.
The answers to this have some actual code and links to yet other resources.
USB includes a set of stock functionality, much like supporting USB flash drives (USB Mass Storage class). The two most interesting for microcontroller interfacing are HID and CDC. CDC is easiest to use as it directly emulates an old fashioned serial port.
If you configure the microcontroller to act as a CDC device, Windows will enumerate it as a serial port, and all the old serial APIs will work on it.
I'm reading <<Understanding Linux Network internals>>,but not sure how much of it will also apply to windows?
I think you will find that they are very similar as both are based on the standard Berkley sockets API. Assuming you are programming in C here, you'll see the same sorts of functions with similar usage in both windows and unix (listen, accept, bind, etc).
There are of course many windows-specific socket functions though, mostly for things like async IO. Here's a list of the Windows socket functions so you can have a look for yourself.
I am into new project, which should use microcontroller. The easiest way to program it is using parallel port. But, there are few things I hope you can help me with. Oh, and the preferred language is C and platform Windows.
So, I studied LPT ports and Windows a bit, and from what I learned the most important is: Since Windows NT based systems, you cannot use instructions for direct port manipulation. This should be, because now programs are run in different privilege mode, which doesn't support the kind of instructions that are used by outport() function.
But at this point, I don´t understand a few things. First, I thought that Windows actually used privilege levels since first protected mode version, but that's the wrong assumption.
But more importantly, I thought that Windows has included functions for just about any hardware communication. I mean, anything you do in Windows these days, you just call windows functions which further call kernel services. I assumed that outport() doesn´t use any Windows function, and just makes the communication itself, which is prohibited now. But I am literally shocked that there is no system function to control parallel ports in modern Windows systems. At least that's what I read.
But even if I could get the control of parallel port, there comes my second problem.
For programming the controller, I need to follow special protocol, especially timing. But since Windows is multitasked, I worry about what if Scheduler switches to another app, and therefore when is the right time to switch signals on LPT, my program just will not be able to run.
Oh, by the way, I know I could use any 3rd-party apps, but I just like to be able to do it myself, or at least before I use some 3rd-party app, I want to know how it works. And yes, you can program some microcontrollers just by parallel port with some resistors, I know this for sure.
Thanks.
For windows you need to install a DLL which contains a driver to run at elevated privileges to get access to the HW ports.
You can find such a library at :
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html
There are also some links to sample code.
I do not know which uController you are using, but I programmed in the past a variety of them and never had issues with timings, well for programming at least. The programming protocols are usually robust enough to deal with the jitter caused by multitasking. Just keep your clock edges and signa edges well separated and it should go fine.
I am working with a peripheral device that needs to be communicated through serial. I can send it commands using HyperTerminal, but now I need to write programs that will let me do it without HyperTerminal. Can somebody point me to a website and/or show me a sample hello world program to get me started? I have searched through many sites which give me uncompilable/ancient VC6 code.
In order to interface with the serial port, you open a file with one of the special filenames "COM1" through "COM9". For serial ports with higher numbers, the special filename begins with \\?\, which in C/C++ code must be escaped as "\\\\?\\COM10", etc.
http://msdn.microsoft.com/en-us/library/ms810467.aspx has a really good tutorial on using the serial port. Note that you should use the Windows file I/O functions such as CreateFile(), ReadFile(), and WriteFile(). I'm not sure if it will work to use standard I/O functions such as fopen(), fread(), and fwrite().
Microsoft provides an article with sample code describing how to do this under Win32.
Boost:asio may be able to help as a serial device was added recently.
Fair warning though; the serial port documentation is light, presumably since it's quite new (it was added in asio 1.1.1 which was included in boost 1.36).
But working your way through asio is, IMHO, a better solution than using the raw Win32 API. Why? It'll be easier to read and maintain (it's a higher level API) and it'll be cross platform (except where you need to specify the OS-specific device name).
The Boost - Users and asio.user mailing lists are quite active and friendly and ought to be able to help you out if you get stuck.
If using .NET 2.0 see System.IO.Ports and this article should be helpful. If direct Win32, then Adam's answer is best.
I believe you will find plenty of sample code for C# as well if you find VC6 too ancient. I think there are also a bunch of "free" serial/COM port wrappers but I just wrote my own when I wrote an RS232 device controller piece of software.
google C# and serial port or rs232
I got these:
http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx
http://msmvps.com/blogs/coad/archive/2005/03/23/SerialPort-_2800_RS_2D00_232-Serial-COM-Port_2900_-in-C_2300_-.NET.aspx
You should have no problem finding suitable code with a google search.