Hello ! Anyone have any ideea where I can fiind such a project ? Or any ideea how it works ? Thank you !
Printable View
Hello ! Anyone have any ideea where I can fiind such a project ? Or any ideea how it works ? Thank you !
In the interests of helping you to develop your own code.
This is an example of how such a device works:
When the “DATA LOGGER” is powered up it searches the EEPROM for the first empty memory cell. This will be the new write position and older recording sessions will not be deleted. If this position is found, the “DATA LOGGER” will write '***RESET***' to the memory. That means a user can later see when the PC (and the “DATA LOGGER”) was powered up.
In normal operation the “DATA LOGGER” will only listen to the DATA and CLK line of your PS/2 keyboard. The scancodes that come across these lines (e.g. a certain key is pressed or is released) are filtered, because not all keystrokes can be stored (will be explained later). If a scancode passes the filter, it is written into the external EEPROM (e.g. 24C64). The value 0xFF will never be written to the EEPROM as a recorded keystroke, beacuse this is the mark for an emty memory cell. If the EEPROM is cleared ba the “DATA LOGGER”, the value 0xFF is written to all memory cells.
In the normal operation, the “DATA LOGGER” will listen to the scancodes and will recognize if the supervisor password is entered. With this password entered one has the possibility to get access to the “DATA LOGGER” menu that will appear on the screen. If the password is entered, the “DATA LOGGER” will leave its listen-state, will disconnect the keyboard from the PC and will speak to the PC itself like a 'real' keyboard. Before that, a n editor (like NOTEPAD.EXE) has to be opened. The following menu will appear on the screen:
***”DATA LOGGER” V2.0
-o-utput EEPROM
-e-rase EEPROM
-c-hange password
-u-sed memory
By pressing 'o' the supervisor can display all the recorded keystrokes on the screen. The PIC will go into output mode and send all recorded key scancodes to the PC and return to receive mode. The recorded keystrokes remain in memory and the next recording session can begin. Now you will understand that not all the keystrokes that someone has entered before can be played back to the PC. Think, if the “DATA LOGGER” would send Alt-Tab to the PC... the focus would jump out of your editor window and all the recorded keystrokes could do anythink to your machine, that you don't really want...!
If 'e' is pressed, the “Data Logger” will start clearing the EEPROM completely by writing 0xFF to all memory locations. As soon as finished (it will take only a few seconds) the screen displays:
Wait...done.
By pressing 'c' in the menu, the supervisor will be prompted to enter an new password that will be the new supervisor password. This password will be stored in the internal EEPROM of the PIC16C84. If you don't remeber that password, you don't have to reprogram the PIC, but you can reset the password to the default password by connecting the RB4 pin to ground in the power up state.
The option 'used memory' will display the used size and the total size of the connected external EEPROM in hexadecimal.
Limitations:
The “DATA LOGGER” Software will record all keys on the alphanumeric keypad except the TAB-key, the '^'-key, caps-lock, delete, Ctrl, Alt, and Alt-Gr. The left and the right shift key and the return key will be recorded. These limitations are necessary, because otherwise the “DATA LOGGER” output may let the focus 'jump' out of the editor window while playing back recorded keystrokes.
The “DATA LOGGER” can only record one scancode set. There are a few keyboards that use a different scancode set. If a PS/2 keyboard is used in combination with a PS/2 mouse, the mouse must not be moved during “DATA LOGGER” playback, because the mouse will affect the CLOCK line of the keyboard.
The "DATA LOGGER" consists of the following devices:
* Microcontroller PIC16C84
* CMOS analog switch 4053
* serial I˛C EEPROM 24C32, 24C64, 24C128, 24C256 or 24C512
In normal operation mode the CMOS analog switch connects the data and clock line from PC to keyboard. The keyboard is always powered with the 5V from the PC. If any key is pressed the PIC receives the keystrokes on the clock and data line, decodes them and stores them in the EEPROM. If the user enters a specific password, the PIC will disconnect the keyboard from the PC and talks to the PC itself.
Thanks. This is avery usefull start for me !
While I am not looking to log keystrokes, I do want to position the USB PIC between a keyboard and host and 'listen' for a certain keyboard input before sending a remote command to a motor controller. How can a USB device be created to listen for input? Should it be a Keyboard HID, some generic HID?
I have made such a device with an 18F4550, however since the PIC is a USB slave device only, it cannot accept input from a USB keyboard. The one I made accepted input from a PS2 keyboard, logged the data, and passed it on to the PC via USB. I configured the USB as a Keyboard HID.Quote:
Originally Posted by kirtcathey
Thanks to Kamikaze and Les for the great info.... now let's take this puppy to USB keyboards. More than a keylogger, I just want to trigger something across a factory floor when a certain string of characters are entered into a database, but the task is the same.
I have done the necessary research and have all the nitty gritty voltage signal requirements for USB communication that has led me to the onboard comparators in many PICs. How do I setup a comparator to take the differential signaling from D-/D+ on the USB data lines and convert that into 0 and 1 in the PIC for further processing? Here is an excerpt that provides most of the details that I need to setup the comparator.
----------------------------------
USB signals are transmitted on a twisted pair data cable with 90Ω ±15% impedance,[9] labeled D+ and D−. These collectively use half-duplex differential signaling to combat the effects of electromagnetic noise on longer lines. Transmitted signal levels are 0.0–0.3 volts for low and 2.8–3.6 volts for high in Full Speed (FS) and Low Speed (LS) modes, and -10–10 mV for low and 360–440 mV for high in High Speed (HS) mode.
---------------------------------
Most of the comparator examples that I have seen only handle one input. I have determined, given the details above, that the reference voltage should probably be about 1.25 volts, so do I use two comparators against the same reference voltage? Or,..... I'm kinda lost on this one, but really want to figure it out.
Cheers, i'm just trying to do the exact same thing with a PIC18F4550 and a USB keyboard. Just starting, no clue yet how to do that. I'll keep an eye on this post ;)Quote:
Originally Posted by kirtcathey
Don't jump into this too far without purchasing a USB node controller chip such as the USBN9604, or even better, the Viniculum chip. Putting the code together to interface an 18F2550 and a USBN9604, and will post later.
I've found this schematic that helped with the wire-up between an 18F2550 and a USBN9604.
<a href="http://www.massmind.org/images/www/hobby_elec/e_pic6_f1.htm">http://www.massmind.org/images/www/hobby_elec/e_pic6_f1.htm</a>
The way all is hooked up, I had assumed that communication would be via SPI, but now do not think so. I have read the USBN9604 data sheet (a couple times) and it appears that I need to send commands in order to receive data via microwire... versus just wait for SSPBUF to fill.
Does anybody have sample code for a PIC and USBN9604? Any language will be fine, but PBP would be even nicer.
Or, even a pointer as to what to use. Such as, would SPI work fine? Or, should I do a byte level shiftin and shiftout, with commands on the first two bits as described in the microwire section of the USBN9604 data sheet?
Any help is appreciated. The finalized USB key logger code with schematic will be posted back into this forum.
I can already tell you that any FTDI chip (Viniculum uses FTDI chips) are designed so that they are recognized as a USB device, it is their non reprogrammable firmware, so you won't be able to put this between a keyboard and a host, it will interfere and thus make the keyboard not working. I just bought a couple to try and use it, and contacted their tech support, which confirmed this :(
As for the other chip, USBN9604, i didn't look at it yet, but there is a good chance it works the same, therefore unusable for such applications.
Well... the USBN9604 is working as expected - hosting a keyboard and passing on the signals. More details with a drawing within the next couple days. I am fairly certain that this (http://www.vinculum.com/prd_vnc1l.html) Vinculum chip will work as a host as well, since that is what we are using for hot-pluggable components that plug into a 16F877A.
Doh! I just re-read magestik's post above.... you mean that vinculum chip, while hosting USB, will also be recognized as a USB device by Windows? I just realized that the rig with the 877A mentioned above does not plug directly into a PC.
That's right. All FTDI chips contains enumeration functions, so the chip, associated with a controller, will be recognized by windows, i tried it myself, therefore, if you plug it on the USB line of the keyboard, you will disconnect your keyboard, because of the presence of two devices for one line.Quote:
Originally Posted by kirtcathey
You can plug the chip + pic into a computer, as a USB device of its own, but you can't "monitor" an existing USB line with it.
I wonder if with the 18F4550, you can't just take off the enumeration function, and just use functions such as get_usb_packet().
This is great timing. When this came across the forum, I was ready to purchase a couple of those Vinculum chips, thinking they would be easier to deal with than the USBN9604. One more question....
Even if you put the 18F2550/184550 between the vinculum and the PC this happens?
What I am doing with the 9604 is exactly that....
The keyboard plugs in and enumerates with the USBN9604, then as the user inputs keystrokes, this input is sent via microwire signal to the 18f2550, which is then sent to the PC that has enumerated the PIC as a keyboard and handles the PIC as a keyboard. Can you confirm that this is the way that the Vinculum is setup? Don't understand why the PC would be visible to the vinculum at all. Unless, it was in the circuit so that it connected directly to the host.
This is a big help. Thank you for sharing the experience.
--Kirt
Vinculum.... sounds like medicine. Doctor says, "Take two vinculum and call me later today."
The Vinculum contains all the enumeration protocol, whenever wherever you use the chip, it will appear as a USB device, so told me the FTDI support, which a verified unfortunately.
hmmm ok, i see, i'm not doing the exact same thing for the moment, i'm not trying to place the PIC between the line, but on the line, quite like this :
http://img83.imageshack.us/img83/9286/sanstitrewd6.jpg
Could you post a quick schematics of your connections, like mine, so i can see better ?
If i understand well, you have :
http://img133.imageshack.us/img133/1...nstitrewf0.jpg
Is that right ? Did you connect it and this works ?
I don't know if this could work, i don't know if the chip would enumerate with a keyboard, with the computer yes.
Yes, the second drawing is what I am doing. Late last week in a forum exchange with Darrel and after some extensive research, we concluded that since USB is packet-based and such high speed, that filtering information on a tap-wire would be computationally impossible for a PIC. Even if computationally possible, writing the filter in program code would be like trying to write something to filter fiber connections.... possible, but....
Also, through connection analysis, we discovered first-hand that what comes across a tap-wire is just about everything on the bus except information that you're looking for.
I'll post a drawing and some complete code soon, but in the mean time, have a quick question. The USBN9604 has a microwire interface that we are trying to implement, instead of a parallel interface that is available. I have no experience programming for SPI, and am still new to PBP... but have coded quite a bit in MPASM. Attached is some rough code put together for this project. The code does no recording of keystrokes, it just takes one byte in from the USBN9604 and sends that byte out to the PIC USB connection.
The 9604 data sheet is here, which says that I have to send a read/write command before executing such read and writes. Also, it says, "1 cycle = 8 SK clocks. Data is transferred after the 8th SK of 1 cycle."
This is code that has been snipped from all over, then peppered with morsels fixing, then cut, replaced, and interrogated. I will not be able to test it on the PIC until tonight. But before that, can somebody take a look and critique?
What is the difference between hardware SPI and software SPI? I think my code might be a mix of both.... which probably will not work. In other words should I be observing SSPBUF for changes, or should I use an interrupt? Also, how do I tie the SPI interrupt to a particular pin? A solid code example or link to would be appreciated.
USBN9604 Data Sheet:
http://www.national.com/ds/US/USBN9604.pdf
Thanks all.
Crazy question... but is microwire the same thing as SPI? Everything I have read tends to associate the two, but nothing clearly states that they are the same thing. Or, is microwire the same thing as I2C; or neither is related?
I believe SPI and Microwire are related yet not exactly the same, and I2C is different again.
http://www.scienceprog.com/microwire...o-spi-and-i2c/
SPI is a close cousin of the older Microwire.
I2C is quite a bit more complex than SPI and Microwire.
There is a minimum of 3 connections for SPI and Microwire: serial clock, serial data out and serial data in. Therefore you'll see those interfaces sometimes referred to as 3-wire interfaces.
If you want to connect N devices to your microcontroller with Microwire or SPI you need to sacrifice 3+N pins to do the job. This is an area where I2C has an advantage.
Microwire and SPI shine when it comes to speed. I2C was initially specified at a maximum speed of 100kbits/sec. This was later increased to 400kbits/sec and lately some devices started to show up that boast 1Mbits/sec. This still pales in comparison to Microwire and SPI speeds. SPI has the edge over Microwire, due to the availability of higher speed peripheral devices. Today's serial EEPROM for example support up to 3MBits/s for Microwire and up to 10Mbits/sec for SPI. But even the slowest Microwire and SPI peripherals still beat the typical 100 or 400kbit/s I2C speeds.
Here is also a comparision between several serial Protocols, including I˛C, SPI and Microwire.
Hope this help.
Well... I decided to go with an 18F4550, since it gives a little more room for evil expansion. :cool::cool:
Here is a spaghetti schematic, so good luck trying to find the wire routes. Still trying to figure out some things on Eagle. Please take a look and comment. Am walking over to the breadboard in a few minutes to start putting it together.
Disregad X1 and X2. Those are just place holder sockets for extra SPI devices, like an MMC or bluetooth.
Didn't you forget to wire the data/adress bus ?
I just changed the drawing in the attachment above. Moved the connect to clockout on the 9604 to the WR/SK pin. Is that correct? To have the same pin going to both SK and SDI on the PIC?
Data address bus.... can you elaborate? Got it! The eagle device is a bit funky.... confirmed the data sheet and will update the drawing.
Thanks alot.
D0/AD0 to D7/AD7 pins on the 9604, how does the two chip communicate ?
The data sheet and the Eagle symbol confused me. Here is an update.
Do you have this project made! Becouse i'm intresting in it. I want to make a ps/2 data logger with pic but with time stamp too if its possible. Can You help me?
Bert regards,
mama nasol
Quote:
Originally Posted by lester