Fast Switching Circut On/Off

[epicfatigue]

Yeah sorry my bad on that one!,
I think its because alot of KVM's change the vert frequency, and in the user manual this one mentions it leave it intact and only passes through the signal.

I dont have Parallel or Serial ports, i have a PS2 and USB.

So i think PIC might have to be the way to go.
Im going to do some hunting on the net to see if i can learn alittle about pics.

I know the Clock and Hex codes i need to send.
Just need to work out how i can get a PIC to send this

 

[()blivion]

I dont have Parallel or Serial ports, i have a PS2 and USB.

That's unfortunate. PS2 ports on the motherboard are bi-directional, but I don't think you can emulate a PS2 device with it, as it seems that the PC host can't actually clock the PS2 clock wire without some kind of hack.

USB can work fine, but it's actually fairly complex for supposedly being "universal". There are no "wires only" solutions, or even a "junk box parts" solutions. You really need to get integrated task specific parts to do USB.

So i think PIC might have to be the way to go.
Im going to do some hunting on the net to see if i can learn alittle about pics.

I know the Clock and Hex codes i need to send.
Just need to work out how i can get a PIC to send this

The way I see it, if the switching system for the KVM is going to be controlled by software, then no matter what, you have to have your PC software be able to talk to some electronic device that can flip bits/pins. In your case, the most straight forward option seems to be USB. Which you could easily do with a USB PIC and software stack. This will let you flip bits/pins directly in the micro from the PC. The other possibility is the infamous FTDI's USB UART chip. You can even buy a ready made cable for under $10 that already contains one of the FT232 chips. This brings us back to a serial port, which we *may* be able to use as is. It really depends on whether or not we can manipulate the RS232 side on a bit/pin level. If not, then you can always attach it to a non USB PIC USART, and use that to flip PIC pins via software -> USB -> RS232 -> PIC.

I have little knowledge of USB microcontrollers and their associated USB software stack. If you go that route, you are basically on your own. Unless of course some one else happens to jump in and want to help with that. Be aware, you will also need to either buy a compiler, or finish the job within a trial period, or deal with some other kind of nuisance. The PIC USB software stack is in C, so you're obviously going to need a PIC specific C tool chain of some kind to work with it.

If you decide to go with the FT232 plan though, I can easily help you out with getting a raw PIC to send the signals you need. So if you can decide on a PIC, and can tell me the exact bit pattern/hex you need, I can probably give you working code in ASM, no problem.

If you have another way of getting software controlled bits/bytes out of your base computer, let me know.

 

[epicfatigue]

Hrm what i was thinking of doing was something like this.

Program a Pic to send clock and hex to KVM when a pin receives 5v or Gnd or whatever

And when the computer starts up i would trigger my USB relay to feed the chip either 5v or GND whatever it needs to trigger the PIC to send the keystroke commands that would trigger the KVM.


I just cant seem to find any decent information on it, been going through the yellow pages trying to find someone that i could pay to do this because i just can not find anything on it.
Need to step back and have a beer my head is about to explode been reading for 15 hours and have not come up with anything that i can understand.

This seems to be the best thing i have found so far
https://www.picbasic.co.uk/forum/showthread.php?t=7962

 

[()blivion]

I can handle the PIC programming aspect for you no problem, and no charge. I just need to know what exactly needs to be done. But I think I may have a good idea. Just need to square away a few more things and come to some kind of an agreement.

First, do you have a programmer? Do you have any PICs?

Second, what is this "USB relay" exactly ??? (Model numbers and so forth). Do you need it? Are you only using it for this one thing? There is room for optimization in the design if you are only doing the one thing with it. If so, we can remove it and make up our own USB device. It could do the relay thing if you still need it, and also happen to do whatever else we want it to do, including the PS2 stuff. And it will all be in one package/PCB.

Third, what are hex commands that need to be sent to the KVM? I could look it up, but I'm kinda lazy right now.

 

[epicfatigue]

that sounds awesome,
Yes i have a programer a USB Williem GQ-4x

I have the following.

PIC16F630
PIC12C508A

Lots of EEproms and UV box
and 29f032 chips.


My usb Relay is just a standard relay i made, its on a circuit board and has a RSchip on it (serial to USB)
Basically when the driver installs it send 5v out the TX line and triggers the relay.
I was planning on using this to know exactly when the computer was loaded to switch Video outs.
it has no other purpose and as start up time would vary i didnt know any other way of knowing when to switch

Thanks for your help mate.
As for the code i can provide you with that i found this nifty table!.

**broken link removed**

 

[()blivion]

Excellent, I have some PIC12F509's which are virtually identical to the PIC12C508, so we could probably work with that. This way, I would be able to test my code, to make sure it works, then just send you the hex so you can burn it. Problem is neither of the PICs you have are equipped with USART hardware, so I would have to "bit bang" something together. That makes it somewhat harder, but I could probably manage. Can also copy paste some free bit bang USART code from somewhere probably.

So, based on the scan code table you provided. I should just need to make this command sequence for selecting port 1...

|------- Left control 1 -------|    |------- Left control 2 -------|    |-------- Press key 1 --------|
0x14, <wait>, 0x0F 0x14, <wait>     0x14, <wait>, 0x0F 0x14, <wait>     0x16, <wait>, 0x0F 0x16, <wait>

Then this command sequence should switch back to port 2...

|------- Left control 1 -------|    |------- Left control 2 -------|    |-------- Press key 2 --------|
0x14, <wait>, 0x0F 0x14, <wait>     0x14, <wait>, 0x0F 0x14, <wait>     0x1E, <wait>, 0x0F 0x1E, <wait>

That look right to you as far as you know?


PC side of things.
Now correct me if I'm wrong, but you ARE able to write programs for the computer your using right? Like, you can handle the software in the computer that is going to do the serial coms? You wont need me to do that for you too?

I may have mistakenly assumed you are a software type of guy having problems with the hardware aspects of the project. If not, then that hurdle is probably going to be a show stopper. I only program MCU's really, not PC's. I could try and look into making a little C app that does it, or a batch script, or something. But I can't make any promises, I have never done that kind of thing before.


Edit: I have NO idea if the "USB Williem GQ-4x" can actually program PICs or not.
Edit2: Found it https://www.mcumall.com/comersus/store/mcumall_TrueUSBWillemsupportICs.asp

 

[epicfatigue]

That is awesome,

I can program no worries, i have to check but i think we only need to "bit bang" once Left Ctrl left Ctrl 2.

As it will be defaulted to display 1 on start-up.

I am not familiar with pics but if we can trigger our "bit bang" By applying voltage or Gnd ("Hi or Low") to a pin i can take care of that software wise no worries.

Just need to know how we would trigger the "bit bang"

Thanks for your help

 

[()blivion]

PM sent.

As for the project, we can trigger the bit KVM switch algo two basic ways.

One would be the simple way of the RSchip install -> TX goes 5v. This is easy to do, but that only gives us the one thing we can do with it. Switch the KVM to the other channel, when the TX pin goes high. I can also add a simple delay so it switches at some point after it gets it's signal. I can't make it trip faster than the signal though, of course. That would require precognition or something.

The other way would be to send actual full byte "commands" to the PIC through a port on the computer. FT232 USB to serial, or some such thing. This opens the option of being able to send full commands, not just switching the KVM to the other channel at some fixed moment in time. Anything you attach to the PIC can be under software control. It's more complex though, so if we don't actually need it, we can make less work for ourselves.

 

[()blivion]

By the way, whenever you get a chance, use that programmer of yours to READ THE BLANK CHIP, and give me the hex. Microchip stores a special internal clock calibration value at the last memory address. This value is critical if we want the chips internal clock to be accurate, and if we burn the chip without having it... *POOF* it's gone forever. This value is also part specific, so we can't just make something up or use some other one, won't work like that.

Remember which chip you read, each value goes with each specific chip after all. I scratch mine into the plastic after I get it. Keeps it safe.

 

[()blivion]

Triple post.

I worked on method one a bit. I have the REALLY easy part done. The PIC program now jumps from one part of the code to another when a pin goes 5v. It is also fully "debounced" as it checks the pin 50 or so times, once every 100us, and will reject the signal as not being fully asserted if it goes low at any time during these checks. This means that the 5v that goes to this chip needs to be stable for longer than ~5ms, or it will not trip the KVM part of the code. But this shouldn't be a problem as the signal is probably solid, and I can easily change the code to do some other lower number of checks. That or go entirely overboard and make it sample the pin and average the results statistically, or use some kind of fuzzy logic or something.

I'll be back on the ball later though, tired right now.

 

[epicfatigue]

Thats Awesome work mate!
I am going to test the KVM today have not had a PS2 keybaord any where and now the shops are open (Monday) i am going to go buy one and double check it resets to display 1 on shutdown.

 

[epicfatigue]

Okay so i have tested the KVM,

Works as expected it will default back to what ever port feeds it its 5volts, so i will send the 5v line from the arcade machines PSU (not the computers one) to port 1.
That way when the arcade machines Screen is turned off it will also shutdown the Arcade PSU, which Inturn will turn off the kVM and it will be defaulted back to display 1.

So with your "bit bang" code it will function correctly!

I have a quick question will it only send the "Bit bang" Once when it receives a 5v line? or will it send it every 10 seconds or so?
If we could make it loop sending the "bit bang" every 10 seconds until the 5v line is lost that would be ideal.

As i have tested repetitively sending the same command to the KVM does not affect it what so ever.
That way if the monitor had to be turned off then started again (the KVM would reset back to display 1)
And if the computer was running it would send the 5v line back to the chip and it would set it back to display 2.

That way if this ever unexpectedly happened the user would not notice an interruption.

 

[()blivion]

I have a quick question will it only send the "Bit bang" Once when it receives a 5v line? or will it send it every 10 seconds or so?
If we could make it loop sending the "bit bang" every 10 seconds until the 5v line is lost that would be ideal.

I can loop it with an arbitrary delay, not a problem.



Also, came up with an interesting idea for doing two way communication if that ever becomes wanted.

If I make the chip have PS2 on *both sides*, you could plug it into the computer, and use PC software to control what it does. The PS2 port *IS* bi-directional, only the clock is controlled by our device, not the computer. That was a problem for simple circuits, as we needed some handshaking and "protocol" and so forth. But this is not a problem for our PIC because in our PIC, we have a full computer.

You just need to be able to program the computer to do things with the PS2 port...

On that note, I found the below VBS script, tried it, and it worked PERFECTLY on my PS2 keyboard and windows 7. If you understand what the heck it does, and can repurpose it to send any key stroke to the PS2 port. I could probably use that key stroke as a command to make the PIC do anything. Otherwise, we have at least three commands(keys) to work with.

Set wshShell =wscript.CreateObject("WScript.Shell")
do
wscript.sleep 100
wshshell.sendkeys "{CAPSLOCK}"
wshshell.sendkeys "{NUMLOCK}"
wshshell.sendkeys "{SCROLLLOCK}"
loop

Here is a link to the most important function/method for doing this. I have NO IDEA if it works for all keys though.
https://msdn.microsoft.com/en-us/library/8c6yea83(v=vs.84).aspx

You can think about this while I work on getting the PS2 protocol and KVM commands out of the chip.

 

[epicfatigue]

Ah that is very cool, the only issue with that is you can not specify a left ctrl from a right but im sure we could devise some kind of plan for it.
I am just heading down now to buy a few things for the bread board to test this all out on once we create it.

be back shortly.

 

[()blivion]

Ah that is very cool, the only issue with that is you can not specify a left ctrl from a right but im sure we could devise some kind of plan for it.

We actually don't need the PC to be able to send any particular keys, as it's just talking with the PIC. This is just a possible way for us to be able to tell the PIC to do arbitrary things from your software. The PIC would still be doing all the KVM stuff. For example, we could send the PIC a random string like "FJHAHDYG" or whatever and make the other end of the PIC do "<L-CTL> <L-CTL> <2>" if we want. It's confusing because it would be PS2 on both sides. But one side is for the PC <-> PIC coms, the other is PIC <-> KVM, and they are entirely separate. I have absolute control over what happens in between the two.

But I guess I should slow down and take this one step at a time, as the above hinges on my ability to make the PIC talk with the KVM. I will get the 5V version to work first. This way, we can be sure to be able to control the KVM with a PIC. We can add more functionality later by making code revisions if and when the need arises.

 

[epicfatigue]

Sounds good may aswell get the basics running and we can take it further, ill do a video for you at some stage once we finish this part and show you the overall operation and we can work out together some improvements.

 

[()blivion]

Making progress.

Got the beginnings of PS/2 protocol based communications working. Still need to work on parity, open drain, weak pull-ups, and some other little odds and ends before it's even close to finished. We can probably do some hardware tests tomorrow or the next day if things go REALLY smoothly. Here is a screen shot of sending the start condition, followed by 0xD4 (b'11010100' LSb first.)

 

[epicfatigue]

Nice mate thats awesome!

What ahs taken you a day or so would have taken me 3 weeks!

 

[()blivion]

OK, another update.

Things have been going kinda slow. It's really hard to use sink-source-float capable PICs to make buses and protocols that are open drain/collector, do only to the fact that MPLAB doesn't have support for simulating pull-up resistors. Thanks to this, what should be 200~300 lines of code, is at about 500, do to all the if-then statements I had to add, just so I can make the waveforms show up in the dang logic analyzer and let me... analyze them. I have basically had to write all my code twice, one set of algos for the sim, and another that SHOULD approximate that exact behavior when in the chip.

And therein lies the crux...

We can't be sure, when we run into problems with the test circuit and chip, that it isn't a bug in my code, caused by the two different algos not matching in functionality, as I intended.

But we will deal with that bridge when we come to it...
===========================================================================

In any case, I *DO* actually have what appears to be fully working PS/2 transmitting capability in simulation as of right now. Does starts and stops, parity, LSb first order, checking for bus idle state... pretty much everything. Here is a screen shot of what the sim claims I'm sending out of the chip. The byte being sent is "Q" or 0x15 exactly as in the PS/2 article from before...

(I even duplicated the last low clock pulse lagging a bit, for kicks.)


And here again, is what the waveform for the same code/sequence/protocol looks like with a real device, from the same PS/2 article...


This should work, as is, provided that...
(A) My alternate code works exactly the same as my sim friendly code.
(B) We can get the calibration value for your PICs easily.
(C) The KVM works with just receiving the code for L-CTL L-CTL 2.
(E) The KVM *DOESN'T* need any other coms, or to be connected to a PC.
(F) You have all the parts, and can actually build the circuit. (it's simple.)

However, I highly suspect bugs at this point. I almost never have code work the very first time. So, I want to try and come up with some hardware tests and experiment on my end still. What I really need to do is try and emulate a key board and then just plug it into one of my spare PCs. If it works, then it should be able to send a bunch of key strokes or something.

The better option would be to scope/logic analyze the pins when they are not attached to anything. This would show me a real waveform, and would let me use the real part. then I could also do away with all the if-then statements all over the place.

EDIT:
By the way, this is what it looks like with the full command...

 

[epicfatigue]

Awesome work mate,

Look i am happy to build the circut and i will just put in a IC socket and program a chip to test if it doesnt work ill toss it in the bin and get another happy to do it.

I have been writing drivers for a Xbox 360 wireless receiver.
Seeing as Windows decided not to make one for XP 64bit. I believe i just completed this.

This is for emulators where someone would rather use a console controller.

I have this really cool concept my wife and i tested last night and it was all to much fun!.

Counterstrike Source

Player 1 Uses the Xbox360 controller to run around duck etc etc.

Player 2 uses a Namco Recoil gun for head moments and two foot pedals, one for reload one for aim.

It was a stupid amount of fun it took the meaning of BOOM headshot to a whole new level and your Aim is almost aimbot like because your gun has a sight and since the res is at 640x480 and your aiming at a screen with a scope you can unscope people.

With the recoil in the gun it was absolutely awesome!

However we had issues with the driver, however i have been refining it and it is absolutely awesome!