I'm having some difficulties writing a kernel mode driver on debian wheezy for a custom touch screen, that has driver only for windows. My main problem is, that I have absolutely no experience in driver programming, apart from the tutorial write-to-system-log module I've found on the internet. Also, I have some more specific problems as can be seen below.
Hardware structure:
The touch screen itself is connected to a microcontroller, that connects through serial port to the computer. I've managed to initialize the controller from user-space program connecting through ttyS0, and recieve raw data from the touch screen, but I just couldn't manage to get started from kernel space.
I've looked around in drivers/input/touchscreen/, opened a few .c files, so maybe I could find out, how to start at least, but I'm pretty stuck around here, because I can't substitute some values to match my hardware. In linux/serio.h there is a long list of defines for serio protocols, that for example elo touch screen's driver is using:
#define SERIO_ELO 0x29
Is there any kind of documentation about these values, their meanings, or how they are interpreted?
Are there any books or websites, from which I could learn more about this topic? For now, this is a really dark spot for me.
I don't intend to ask for a full solution, but I'd really appreciate some examples or tutorials regarding serial communicaton and/or touch event gerenation in kernel mode.
Thanks in advance for your help.
Related
I bought a SAMD21G18A (ARM Cortex M0+) from RobotDYN and trying to simply get setup to program it but I can not find much documentation on how these are connected/setup for programming and debugging.
On the website it states "One of its most important features is Atmel’s Embedded Debugger (EDBG), which provides a full debug interface without the need for additional hardware..." so I assumed that the connections would be similar to some of the other MCU Development Boards like the Arduino, PI or Beaglebone meaning that there isn't any need for things like a JTAG Programmer but I don't know if that's the case or maybe I am just confused on how to set this up.
Can anyone point me in the right direction on how to upload the program and get my IDE setup? I can find all sorts of information on the Registers, the newlib library and stuff like that, but I can not find much on the actual connections or other needed components.
I would prefer Visual Studio +VisualGDB if anyone uses that combo but I will take any help so I can just get started. I also have tried Atmel Studio and the Arduino IDE also without success. Just to mention I am not looking for a step by step guide, just some direction and explanation of how I should proceed.
When I installed the Arduino IDE I was able to get the board to show up under COM11 as a Arduino-M0, so possibly I am simply missing some drivers?
Edit:
I have been searching the internet for possible ways of hooking this up and it seems like I need to have some sort of programmer/debugger. I also found there are a couple types of these boards out there, one of them is the XPlained series. I looked at the schematics and they have a ATMega in addition to the ATSAMD21. I have a variety of AVR's, BeagleBone Black and also a FTDI CDM USB cable. Does anyone know if its possible to use any of these to setup for programming/debugging?
Your SAMD21 board from RobotDYN doesn't have the Atmel EDBG interface, so you need an external SWD debugger like the Atmel-ICE you mentioned in your comment.
This debugger comes with the standard 10-pin Cortex Debug Connector, which is also present on the RobotDYN SAMD21 board (labeled "SWD(EDBG)", which is a bit unfortunate since it seems to suggest this is an EDBG interface, which it isn't). So the only connection needed is between these two connectors via the flat cable that is likely included in your Atmel-ICE kit. Pay attention to how you connect the cable to the RobotDYN SAMD21 board: the first pin of the 10-pin header (i.e. the one with a "1" label next to it on the PCB) must correspond to the first pin on the the Atmel-ICE connector, which is the pin at the bottom left. See also http://microchipdeveloper.com/atmelice:connecting-to-avr-and-sam-target-devices.
I want to write something like DaemonTools: a software that presents itself to the system as a real device (a DVD-ROM in the previous example) but it reads the data from a file instead. My requirement is not limited to DVD-ROM. The first goal is a joystick/gamepad for Windows.
I'm a web developer, so I don't know from where I could start such a project. I believe it will have to be written in C/C++, but other than that, I have no clue where to start.
Did anyone tried something like this and can give me some starting tips ?
Most drivers are written in either C or C++, so if you don't know those languages reasonably well, you'll want to get familiar with them before you start. Windows programming uses a lot of interesting shortcuts that might be confusing to a beginner - for example PVOIDs (typedef void* PVOID) and LPVOIDs (typedef void* far LPVOD;). You'll need to be happy with pointers as concepts as well as structures because you'll be using a lot of them. I'd suggest writing a really straightforward win32 app as an exercise in getting to grips with the Windows style of doing C/C++.
Your next port of call then is to navigate the Windows Driver Kit - specifically, you'll need it to build drivers for Windows. At this stage my ability to advise really depends on what you're doing and the hardware you have available etc, or whether or not you're really using hardware. You'll need to know how to drive your hardware and from there you'll need to choose an appropriate way of writing a driver - there are several different types of driver depending on what you need to achieve and it might be you can plug into one of these.
The windows driver kit contains quite a large number of samples, including a driver that implements a virtual toaster. These should provide you with starting points.
I strongly suggest you do the testing of this in a virtual machine. If your driver successfully builds, but causes a runtime error, the result could well crash windows entirely if you're in kernel-mode. You will therefore save yourself some pain by being able to revert the virtual machine if you damage it, as well as not having to wait on your system restarting. It'll also make debugging easier as virtual serial cables can be used.
This is quite a big undertaking, so before you start, I'd research Windows development more thoroughly - check you can't do it using the Windows APIs first, then have a look at the user-mode driver framework, then finally and only if you need to, look at the kernel level stuff.
I need some advice on windows programming, MIDI and WDM. I am trying to write a small application that will sit in the sys tray and be advertised to the system as a MIDI In/Out device so that MIDI programs can send to it and it will convert the messages into a different format. I have been reading Cant's WDM book and scouring for information about writing device drivers, but don't know if I'm going down the right path.
I don't see yet how to:-
a) register my driver as MIDI capable (do I stick a ref to it in the registery and let the OS direct MIDI calls to the functionality in a dll?)
b) direct MIDI data through the my driver to my app, which is probably going to be too large to be a driver itself.
Any advice on where to start would be much appreciated.
thanks,
Pete
Windows MIDI drivers do not need to be implemented in the kernel, they can be implemented entirely in userspace as DLLs.
MSDN has some information about the functions you need to implement -
Audio Device Messages for MIDI - unfortunately it is somewhat lacking.
There used to be sample code for this kind of driver, as part of the NT4 DDK, but more recent releases of the DDK / WDK unfortunately don't include it any more.
Some better (though older) documentation and sample code can still be found after some searching:
Introduction to Multimedia Drivers (From NT4 DDK)
Sample MIDI Wine Driver for Mac OS X
Devices are enumerated (or simulated) by device drivers, not applications. What you see in the sys tray is an application icon. Hence, you will need to have both a driver and an app - you can't have one bit of compiled code acting as both.
On the driver side, you probably want to have a peek at the MSDN docs. This will answer part (a) of yopur question.
Assuming that you still would like to continue, (b) is best don by letting your application pull the data from the driver. That's far easier than the other way around - an application can trivially find a driver, but a driver has big problems finding a specific app (process)
If you are looking for a bit easier way to get started, there is a MIDI loopback driver out there, and the folks that make it also offer (or used to offer) a version of it that allows your program to communicate directly with the driver. This gives you the behavior you are looking for, where a program appears as a MIDI device. The loopback driver is at http://nerds.de/en/loopbe1.html. I don't see the developer page anymore, but if you contact them, you might be able to purchase a license to a driver that you can access directly without the loopback.
My application needs to behave as a virtual joystick (imagine dragging a square with the mouse and translating that to the output of an analog joystick) and send some keystrokes over the network to another computer where the driver would receive that input.
I only need to support XP, Vista and Win7.
Maybe it can be done without writing a driver. I tried sending keystrokes with SendKey() which seemed to work but don't know how to emulate an analog joystick.
I've downloaded the VDK and been reading everything I can find on the subject but there are lots of things I still don't understand. Can you please point me in the right direction?
Should I build a kernel-mode or user-mode driver?
Can my driver act as a server for an app on the network?
Do you know good tutorials / books / samples that can help me with this.
Thanks
First of all you will have to have some kind of interface between your computer (or the network) and the joystick device that is being controlled.
If it involves making custom hardware to control the analog joystick (like it controls pneumatics or hydraulics or something, not just a pc game joystick type thing), then yes, you will almost certainly need a driver to allow a network app to move (the robot arm, or whatever) will move that joystick.
If you are able to remove the physical joystick from the equation, maybe you can write software that emulates the input of wherever the joystick used to plug into (a joystick/serial port?), or emulates it completely (a reasonably simple driver could do this). You could do it completely without writing a driver if the joystick used a standard communication interface (like RS232) because libraries exist that will handle all that and you can set up virtual COM ports that will be indistinguishable to whatever you are trying to communicate with.
The best book you can buy on driver development at the moment is Developing Drivers with the Windows Driver Foundation
Rootkits: Subverting the Windows Kernel is another great book, but doesn't cover a lot of the newer WDF stuff. It has more of a security focus but has a few awesome chapters on device drivers with fully spoonfed examples, breaking it down in a really accessible way.
If it is only over the network, probably simple socket programming should be enough.
I want to create a virtual printer driver for Windows. How and where can I start properly? The WDK has some printing drivers examples that do not seems a good introductory. MSDN also doesn't seems to be very helpful for a novice.
There are a lot of virtual printers for Windows out there (mostly they generate PDFs), I wonder if someone could tell my how can I do the same?
Any links to the elaborating documentations are appreciated in advance.
Thanks.
When I did it (which about 12 years ago) I started with the postscript driver sample, replaced all the postscript-specific stuff (in my case, to write to a bitmap instead of generating postscript commands).
I also wrote a custom print monitor (the driver writes to the spooler, which write to a monitor): my monitor wrote to a file instead of e.g. to the parallel port.
However, printer driver architecture and/or the set of sample drivers may have changed since then.
You can look to the 'minidriver' development in the from Microsoft (Microsoft MDT), that might help depending on your exact needs. If the port you need to deal with (ie: you are going to take the data from an existing printer driver and want to process) you could look to the source code for RedMon. It doesn't support Vista/Win7 but might point you in the right direction.
This book maybe help you Developing Drivers with the Windows® Driver Foundation
A list of my links
http://www.codeproject.com/KB/system/driverdev.aspx
http://www.microsoft.com/whdc/ddk/winddk.mspx
http://jungo.com/wdusb.html
https://web.archive.org/web/20130717135254/https://msdn.microsoft.com/en-us/library/ff554651.aspx
http://channel9.msdn.com/posts/Rory/Driver-Development-and-Much-More-With-Mike-Calligaro/
One of the drivers you mention is open-source (GPL), maybe you could explore its source or adapt it: http://www.pdfforge.org/products/pdfcreator/download
Someone else already mentioned PDFCreator. Here's a more specific link to their code that's creating the printer, port and monitor. Despite being in VB, I can follow it as someone more used to C++, so I guess you can too. modPrinter.bas does the leg work. modMain.bas, from about line 28 onwards, calls into modPrinter.bas.
Create a Print Port Monitor, associate that port with a printer, and you'll get the data the printer driver sends to the port.
working example of how is it done in Cpp and java can be found here:
http://www.mms-computing.co.uk/uk/co/mmscomputing/device/printmonitor/index.php