Sorry your browser is not supported!

I am using DBP to control output from a micro-controller and everything works as it should. The only problem is that I’m using software control to generate pulse width modulation (pwm) signals to control motors. During the actual generation of the pulse the graphics in DBP cannot be updated. This causes a very noticeable glitch in the graphics display. I want to use DBP, because of the graphics capabilities. (I have tried this in VB 2005 also and it does the same thing.)

This is a known problem with software generated pwm. To counter this many people use a coprocessor to handle pwm signals.

I am not a programming guru and it took a lot of persistence to get the program working up to this point. So I would like to try a work around. Here are a couple of ideas.

1. Run two executables at the same time. Kind of like a coprocessor. One would handle the main program/graphics and the other would handle the IO for the micro-controller. I was thinking that the motor speed could be generated in the graphics program with a joystick and then write the value to a file. The micro-controller program could then look up the speed value in the file and set the motors to that speed. This would be in a hidden window, so any graphics glitches would not be seen. I’m just not sure how fast this would respond or if it would even work.
2. I have looked at IanM’s most excellent Matrix Utilities stuff and thought the co routines might work, but alas no. Once the pwm generation routine starts, there is no break. I am using a DLL and do not have access to the actual pwm generation function. That is not to say that I’m using Matrix Utilities right. I might not be. So if someone (IanM) has something on this please let me know.

Any help would be greatly appreciated. Even a little outside the box thinking would be useful.

@wildbill
There is a multithreading plugin here somewhere, if you call the command in another thread, the main thread should keep going as usual

Maybe I'm missing something but don't you want to use the microcontroller to generate the pulse width? I mean, time specific tasks like that is exactly what its for. You should just be using DBPro to send commands to the microcontroller when you want changes like "faster", "slower" or "stop". If you did it that way, it should take no appreciable time away from your DBPro program. Speaking of a co-prosessor, think of the microcontroller is like a sub-processor.

I would have to agree with Diggsey with the information we have been given. Also what type of micro-controller are you using?

This seems like something that *might* be solved by using multithreading or multiprocessing, but it really depends on how the timings for the signals are generated.

If the timings generated are highly accurate (ie, realtime) then nothing short of a subprocessor is going to help because the timings process will literally take over the processor until it's done it's thing.

If they are not, then two programs can be written - one to do the microcontroller stuff and one to display, using a shared memory bank to communicate between them.

Before you dismiss that out of hand, DarkShader works in precisely this way and it works well.

Actually I tried the two programs at the same time routine and have determined that its the micro-controller. It works fine generating all the digital signals, but since it uses software generated pwm it actually has to wait till the pulse is done to process any further info. I have started programming a coprocessor unit with hardware generated pwm and am confident it will work.

Just to let everyone know using two executables at the same time has a lot of potential. I was able to generate my commands in one program and store them to memory. The other executable used these stored variables without any noticeable problems. Each program was displaying 100 sprites and moving them at the same time.