Author Topic: driver development / testing  (Read 1117 times)


  • Jr. Member
  • **
  • Posts: 41
    • View Profile
driver development / testing
« on: April 22, 2013, 06:12:34 pm »
hey, how do you folks (hobby types) go about testing / developing drivers. My elve computer isn't connected to a monitor or keyboard (normally).

Do you work on your system "live" or have a separate development system. I suppose that's not really practical with an enthusiast license right?


  • Sr. Member
  • ****
  • Posts: 460
    • View Profile
Re: driver development / testing
« Reply #1 on: April 22, 2013, 07:25:28 pm »
What I do (I have the same setup as you with a headless server)
1) Headless server is running the Master Service
*You can install and run the Elve components on as many machines as your license allows, but you can only run one instance of the master service per license*
2.) I have all the components running on my office (development) machine
*EMS, builder, and viewer*
3.) I do the coding on the development machine and drop the build into the server
*To do the above I setup some .BAT files on the desktop of the server to quickly shut down and restart services as follows:
Code: [Select]
net start ElveMasterService
net start ElveDriverService
net start ElveTouchService
Code: [Select]
net stop ElveDriverService
net stop ElveTouchService
net stop ElveMasterService
4.) After the driver is dropped restart the Elve services

Some things that you may or may not be aware of:
You can debug in realtime with visual studio, but that will require you to do your development debugging on the machine running the driver service. I am not sure if that means you can debug on your development machine if you are running the driver service and not the master service, definitely something to test if that setup is better for you. I am not running the driver service on my development machine so I am unsure.  I chose against that route for debugging and use the logging feature in Elve heavily instead. That way I rdp into my server, stop the services, drop the build, restart the services, go back to my development machine and watch the EMS logs for driver feedback. Sounds like a lot but really is pretty quick to do the above, especially if you use .BAT files and create a shortcut to the compiled driver folder. Working with a live system is nothing I am too worried about, despite the frequent starting and stopping of services. The system will not be effected by a buggy driver. It will not load the driver if it detects a bug, and usually has a very nice error message letting you know exactly where the bug occurred.
« Last Edit: April 22, 2013, 07:28:50 pm by iostream212 »
I always wanted to be somebody. In retrospect, I think I should have been more specific.