DIY USB password generator

Having done half a dozen V-USB tutorials I decided it’s time to whip up something cool. As USB keyboards were an area untouched, I decided to make a small USB HID keyboard device that types a password stored in EEPROM every time it’s attached. A new password can be generated just by tabbing CAPS LOCK a few times (4 times to start password regeneration and one tab for each password character generated, 10 is the default password length). Below you can see the device in action:

The place I work at requires me to change my password every few months so this would be one way to skip remembering a new password altogether (as long as I remember to write it down before regenerating a new one so password can be changed :).

What is inside?

The device is powered with a simplified version of the hardware I used in my ATtiny85 USB tutorial – I stripped away the LCD, reset pullup and both capacitors. If you’re better in cramming components inside enclosures I suggest adding at least a 0.1 uF capacitor between VCC and GND, but it seems to work fine even without it:

The enclosure was graciously donated by an old 512 MB flash drive. I couldn’t make myself to break the USB connector from the circuit board inside, so I stripped appart a short USB cable instead (shown on left):

After some thinking and iterative soldering, I managed to cram everything on a tripad veroboard with 2×8 pads with the following initial setup:

I soldered the connector first, then the zener diodes, then resistors and jumpers, and finally VCC, GND and the ATtiny itself. I used the following tricks to make all ends meet:

  • D+ zener diode goes to the pad under ATtiny that is connected to GND pin
  • After the D- zener diode, only 1 pad is left for 2k2 pullup and 68 ohm resistor, so I used a jumper wire to the next pad
  • 2k2 pullup goes to a pad connected to ATtiny VCC
  • VCC goes to the pad under the ATtiny using a black jumper wire
  • I soldered the D+ 68 ohm resistor to a wrong tripad, so I used another jumper wire just barely visible behind the top left black jumper wire for GND

I was pretty satisfied the result and the fact that it actually worked! The board did not initially fit into the very snug space in the plastic enclosure, so I had to use a Dremel to trim its insides a bit, but after that, everything snapped right back (click for larger versions):

Update: For those who are building this project – I recommend you first build it on a breadboard, and only when you have it working, solder it to a veroboard. Here are two additional, extra-large pictures of the configuration I used to help you in the component layout:


The device presents itself to the computer as a USB HID keyboard. To enable communication to the device, it is a boot-compliant keyboard that can receive LED status changes from the computer. HID descriptor is from Frank Zhao’s USB business card example and I also looked at Frank’s code to understand how LED state is sent to the device (in short, PC sends a control message with 1 byte of data, the LED state bit mask).

The code is mostly based on my USB HID mouse example except for the usbsconfig.h and HID descriptor changes required to implement a boot keyboard. I’ve documented the code but here are some highlights if you want to understand it better:

  • PASS_LENGTH defined in the beginning controls the length of generated passwords
  • SEND_ENTER can be defined to 1 if you want the device also to send ENTER after typing the keyboard
  • measuring_message and finish_message contain the messages that are displayed when generating / saving a new password
  • buildReport() is called by the program main loop to send keypresses to PC one by one – it translates characters in messageBuffer to USB key codes on the fly
  • usbFunctionWrite() is implemented to receive the 1-byte LED state from PC – it calls caps_toggle() function every time the LED state changes
  • generate_character() is used to return random keypresses – it is currently written to return alphanumerics, hyphen and underscore (64 symbols make it simple to select one so each has equal chance of being selected without additional logic)
  • caps_toggle() does the caps-lock counting and password generation/saving

I’ve packed the source files with the schematic, critical pictures and a Makefile. In addition to “make flash” you of course need to update the fuse bits to use the PLL clock source – see details from my previous tutorial for that. I also very strongly recommend testing the device using a breadboard before soldering it, because otherwise reflashing will be a major pain.

And of course, if you build it, try it at your own risk – and remember that once you reprogram the password, nothing will be able to restore it. I recommend storing passwords generated with the device to a safe place just to be sure.

Update: Getting it from SparkFun

I found out yesterday that SparkFun is carrying an almost identical piece of hardware, the AVR Stick. So if you order one and reprogram it with this firmware (pin configuration in usbconfig.h needs to be updated in that case), you can avoid some soldering (although not all, you’ll likely need to solder in the programming header).

I asked SparkFun if they’d be interested to make a “2.0” model of their AVR Stick with actual USB connector and enclosure to go with the package, and my password generation firmware preloaded. If you think that’s a good idea, now would be a great time to send them feedback. I’d also be interested in covering additional hacks and tutorials with such a device. :)

Update 2: Indiegogo project

Alvin Chang is currently (December 1st 2012) running a Indiegogo project to build a device very similar (and inspired by) my DIY version. In case you’re interested in getting a ready-made version, be sure to check Mr. Chang’s project out: Aladdin: The Key to Your Computer.

242 Comments or trackbacks to DIY USB password generator

March 5, 2012 at 21:01

Excellent work there.
I’m really interested in making one of these for myself with your bits and pieces, many thanks!
Just one thought, you could also include a special operation on a keypress to make it change your password (for Windows 7) by getting it to do the Ctrl-Alt-Del shortcut, down arrow, down arrow, down arrow, then enter. It can then put in the known old password, and update the new password for you automatically!
This method has the obvious advantage of having NEVER been displayed on the screen in Notepad, etc.


March 5, 2012 at 21:25

Great idea for the Windows 7 -specific key combo, I’ll see if I time to do that at some point!

Meanwhile, it’s pretty easy to add on your own, especially if ctrl-alt-del can be sent in a single HID report – you could just invent special characters for that and the arrow keys (like ^ and _) and concatenate everything into the messageBuffer while regenerating password (first the old password, then the key sequences, and finally the new password two times) – of course messageBuffer needs to be at least 64 bytes then. :)


March 5, 2012 at 22:16

Hi jokkebk (Sorry, I don’t know your name!)
I would have a go myself, but I’ve been over your code, and some USB coding in the past, I’m still somewhat mystified as to why USB has to be so darned difficult to use, even with libraries like v-usb!
I only write simple code for my PIC chips (PIC16F88 so far), so I’m not grounded in AVR at all, I’m reading more about it now though.
But I’m perfectly content to shell out £2 for a USB serial to TTL chip off ebay and interface to my PIC chips directly on my PC via a USB virtual COM port. Good olde RS232 still serves me well.
Of course making HID keyboards requires USB, so I’m prepared to put the effort in, but for now, I’ve got an AWFUL lot of reading to do. For starters I’ll be compiling your code or just trying out the provided HEX file, thanks! Its important to know as much as possible when diving into all this, even if your code does it all for me…
You’re definitely a credit to the hardware hacking community! Thanks!


March 5, 2012 at 22:49

Hi Stu,

Yeah I have to admit USB is a hard nut to crack, and the only way I was able to do it was to start from ground up, first building the simplest possible circuit with V-USB, and then adding layer after layer: first a easy circuit, then lighting a LED, then reading and writing data, then simplyfying the circuit and getting rid of the oscillator, then HID devices, and finally the HID boot keyboard. Even understanding the keyboard reports takes some thinking and because one has to emulate key presses instead of just sending characters, another layer of complexity is added.

I recommend you to check my V-USB tutorial from the beginning, by starting from something less complex the amount of learning in each new iteration stays small enough to absorb. You are absolutely right that USB to serial TTL is a good option well worth the cost, I myself tackled USB more because it seemed challenging than absolutely useful.

Joonas a.k.a. JokkeBK (my home page is well hidden on the right hand navigation pane ;)


March 6, 2012 at 5:58

nice work!!
just a simple question..what happen if u lost this dongle..ha ha


March 6, 2012 at 7:28

Any chance you’d be willing to make me one if I paypal’d you some money?


Adam Miner:
March 6, 2012 at 8:32

Would you be willing to make/sell/ship these?


March 6, 2012 at 10:13

Hi Adam & Trev,

My soldering skills probably wouldn’t cut it for commercial production, and I’d also price myself out of business in any case. :) Those who want a ready solution might want to check out YubiKey. If there’s enough interest, a provider like SparkFun might be able to do a DIY/preassembled kit based on this project, I might just ask them about it.



March 6, 2012 at 11:00

nice job…
is it possible to have the file to program the chip?
thank you


March 6, 2012 at 11:35


The source package contains the .hex file you can use to program the chip. If I recall correctly it is a version that does not send ENTER, so you need to recompile using WinAVR or AVR Studio if you want to enable that functionality.


March 6, 2012 at 12:29

Great job! Another question here, does the USB need any driver to work in Win7? Or the driver is already included inside the ATtiny chip? Likewise the USB can use it at any computer, plug-and-play?


March 6, 2012 at 12:36

kenny, from computer’s perspective the device is a USB keyboard, so no driver at all is needed for PCs.

However, OS X does things differently and it does not work for Macs (it seems Macs don’t send caps lock status accross keyboards, so communicating with stick using status LEDs do not work – also, OS X has “intelligent” keyboard recognition that does not work very well with non-interactive devices). I haven’t tried Linux yet.


jan says:
April 5, 2012 at 12:31

Hi jokkebk

Thx for the passgen.
Mine works like a charm with win7.

Some remarks
– win7 – mine did load a driver at first startup from microsoft
– never did it again :D and is working since then

– linux – does not work.

– kernel message is :

[ 3144.219114] usb 3-3: default language 0x0409
[ 3144.228145] usb 3-3: udev 9, busnum 3, minor = 264
[ 3144.228154] usb 3-3: New USB device found, idVendor=4242, idProduct=e131
[ 3144.228160] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3144.228166] usb 3-3: Product: Passgen
[ 3144.228171] usb 3-3: Manufacturer:
[ 3144.228417] usb 3-3: usb_probe_device
[ 3144.228429] usb 3-3: configuration #1 chosen from 1 choice
[ 3144.231139] usb 3-3: adding 3-3:1.0 (config #1, interface 0)
[ 3144.231296] usbserial_generic 3-3:1.0: usb_probe_interface
[ 3144.231307] usbserial_generic 3-3:1.0: usb_probe_interface – got id
[ 3144.231369] usbhid 3-3:1.0: usb_probe_interface
[ 3144.231377] usbhid 3-3:1.0: usb_probe_interface – got id
[ 3144.241875] input: Passgen as /devices/pci0000:00/0000:00:04.0/usb3/3-3/3-3:1.0/input/input11
[ 3144.242434] generic-usb 0003:4242:E131.000A: input,hidraw3: USB HID v1.01 Keyboard [ Passgen] on usb-0000:00:04.0-3/input0
[ 3144.242513] drivers/usb/core/inode.c: creating file ‘009’
[ 3144.242598] hub 3-0:1.0: state 7 ports 6 chg 0000 evt 0008

-> so it is recognized ok.

what it does on linux :

it spits out the last 7 bytes (characters) of the password at first plugin and the last 8 chars of the password at every plugin afterwards. The first 3 (2) characters are always missing.
I compiled your code on linux and flashed the chip with linux avrdude and an arduiono isp programmer. Works great.

what it does not on linux : it does not recognize tabslock / led status change
-> it does not generate new passwords

At the current state of code it is not usable with linux.

Any hint is welcome.

THX again for this great idea and support with schematics, parts, code … blog …



jokkebk says:
April 5, 2012 at 12:51

USB HID devices seem to take a while (two seconds or so) to initialize themselves, so any characters sent before that are lost. With first attempts, I had a delay timer to wait a few seconds before sending the characters.

But after I added the support for receiving LED state changes, I assumed that the device is initialized when the first LED state is received – obviously this is not the case in Linux. You’d need to add a initial delay – for example increment some counters and only start sending after counter reaches a given value.


jan says:
April 6, 2012 at 12:28

OK, there seems to be a timing problem with usb on linux. So far i was not able to set a reasonable waiting time in the main loop. I tried up to 3 seconds waiting time before sending the password.
And i found another obstacle on my way. Keycodes are different for win7 and linux. What a surprise LOL Special characters are interpreted in a different way:
win7 linux
” 2
= 0
$ 4
( 8
…and so on ..

If you set your password on win7 to use it on linux you r screwed if you rely on your notes in case of trouble. You have to translate your password to your linux keycodes (just look at your keyboard …). Or you you have to stick to your operating system …

And there are more problems on linux as no keypress or LED-change seems to be recognized by your current code on linux.Probably linux doesnt send it in a way your soft can recognize it? There seems to be no way to generate a new password. Probably we are stuck like in OSX. I wouldnt mind to set a new password in win7 if i can use it on any OS afterwards.

Seems to me i have to go through your usb tutorial
… and understand it before i can contribute anything useful
this might take a while …
Keep in mind : N E V E R change a running system!
Your system works perfectly for the OS you created it for!

THX for your advice and help.
Happy Easter :D



March 6, 2012 at 15:38

Nice project. Ive made something similar with my Teensy 2.0. However, from what I understand, if I stole your usb device, plugged it into my computer and opened notepad, I would get the password out in clear text, correct?

So while the device is a cool way to not having to remember a given password, the security of it all completely relies on you having control over the device at any given time.

If you have somehow taken measures to mitigate this that I somehow missed, please enlighten me :)


c4d says:
April 29, 2012 at 16:02

Take a simple step… password combinations on windows login type “win” or something simple then plugin key. Therefore your password for login would be “win” and your keys password…

For a or a login to a website such as Facebook… type “fb” then insert your key


March 6, 2012 at 16:11

Untouchab1e: Yes, it’s much like a key in a keychain – if it’s stolen, there’s nothing to stop the user from taking advantage of it, as long as he/she knows where the key fits.

Unfortunately there’s very limited space on USB stick to add any kind of keypad for pin code – the best option probably would be to implement a “secret knock” using the caps lock key – e.g. three short taps followed by three long ones would trigger the device to to output its password. However, you’d either need to hard-code it or whip up a very elaborate setup on how to program the device.

Implementing a special software to program the device using caps lock is one option but you’d quickly lose any “simplicity benefits” against an encrypted USB memory stick.


March 6, 2012 at 16:13

Very cool Joonas.


March 6, 2012 at 19:07



Roman Smetanin:
March 7, 2012 at 6:33

Tell please you can make and send by mail this device? And how many it will cost with delivery?


March 7, 2012 at 8:23

Hi Roman,
As I said earlier in the comments, I won’t be making these – I doubt people would be willing to pay me 30€/hr for soldering such a simple circuit. However, I think I’ll check if some electronics supplier would be willing to offer this is a kit, either in finished or solder-it-yourself form.


March 7, 2012 at 10:25

That great man now I wanna make one but I need the flash to submit a username and pass would, should I go the same route? and do you have any other suggestions?


jokkebk says:
March 7, 2012 at 10:39

@thata: The hardware is identical and software (or firmware, if you like) would not need much tweaking to achieve what you want – just send username first (you’d need to hardcode that into flash), then a TAB, then the saved password and ENTER and you’d be good to go.


March 7, 2012 at 13:38

fantastic,superb,awesome buddy lookin ahead eagerly for more such innovations…


March 8, 2012 at 8:57

For everyone who wants to buy a pre-made one, there is nothing that I can see that would prevent the Sparkfun AVR Stick from working. It has the same ATtiny, and comes pre-programmed using the same USB library, so its compatible.


March 8, 2012 at 9:42

@mck: Yes, I realized that yesterday. The hardware is all there, but an enclosure would be nice, as would an actual connector instead of “on the board USB traces” (some people complained that it doesn’t get contact in all cases).

I suggested a “2.0 model” to SparkFun with enclosure and this firmware preloaded and some additional improvements. If you’d like to see this happen, now would be a good time to tell SparkFun that!

I also promised to cover additional hacks and tutorials for the 2.0 version if they decide to make one. :)


March 8, 2012 at 20:05

What a great use of the vusb library.
I got the tools and time to assemble some kits, if enough people are interested and you dont mind jokkebk. Cost of parts + shipping. Maybe a custom pcb down the line (theyr cheap anyways)


March 8, 2012 at 22:46

@Nicolas: I don’t mind at all, I think it’s great if someone wants to build them!


March 10, 2012 at 17:15

Fantastic project, have just ordered some attiny85 so I can have a go.



March 12, 2012 at 0:54

Super Cool idea..

How would you address this?

Good Security Practices include disabling auto mount of anything..

As I read the piece auto mount is essential to the function of your device.

Again.. Fantastic piece of creativity and Thank you so much for sharing it.


March 12, 2012 at 3:21

When I try to compile main.c I receive an error indicating that LED_PIN is not defined. What value did you use for LED_PIN. I couldn’t find where it was defined in anywhere in your source.

main.c: In function ‘main':
main.c:293:13: error: ‘LED_PIN’ undeclared (first use in this function)

Thanks for sharing this project.


March 12, 2012 at 9:34

Philip: Oh no, I forgot to remove that last reference to LED_PIN. You can either remove the offending line or define LED_PIN to PB3 or PB4 (or straight numerical values of 8 or 16).

I have fixed the source code now, so alternatively you can just re-download the zip.


March 12, 2012 at 9:48

wm: In many cases, attaching a USB keyboard might not be considered “auto-mounting” (I believe the term mounting is mostly used for storage devices), so the device might still work even if certain USB devices are not automatically mounted.

One way to check before building the device would be to plug a normal USB keyboard in when the machine is waiting for password, and see if it gets recognized and you can type in your password using that.

Of course, if your employer or similar directly prohibits the use of any devices to input password, I do not recommend you to use this project…


March 14, 2012 at 16:26

I flashed the chip, build the circuit on a breadboard, but my computer doesn’t know what to do with it. It tells me, that it’s an “Unknown device”. Any ideas why this is happening?


March 14, 2012 at 16:51

@Brillow: Good thing that you built it on a breadboard so you can debug! On my experience, Windows plays a “message sound” that a USB device is connected even if the firmware wouldn’t work, so if you do not get that, I suggest you double-check the connections (you can see an example layout for breadboard on my ATtiny85 USB tutorial page).

Also, you can check with a multimeter that voltages are OK – for example, D- should be about 2.9-3.3V because of the pullup + zener. I recommend <1W zener diodes, one person had issues with too “heavy” zeners. Double-check also that zeners are connected the right way (black line away from GND).

And of course, if you’re using a breadboard you could attach a LED to a free pin and use some debug programs to check that the program does not hang before getting into main loop…


March 14, 2012 at 18:43

Same problem als Brillow… The computer tell’s me “unknow device”. I checked the connections and D- Voltage and it’s ok. Any ideas? Shouldn’t PB5 be connected to a pull-up to avoid the reset? (I tried but it did the same thing :-/) Please help! :-P


March 14, 2012 at 20:49

Hmm, Voltages seem ok and I’m using 0,5W Zeners (inserted the correct way ;) ). The search continues…


March 14, 2012 at 20:54

@Daniel: Hmm, weird problem! Unfortunately I soldered my last ATtiny85 into this project and would like to avoid prying it out of there to retest the circuit with a breadboard.

First suggestions would be to try if adding a 1 uF capacitor or so between GND and VCC to see if that would help, and testing the USB cable that there isn’t cold solder joints that conduct poorly (mine shows 0.0-0.6 ohms for each of the four wires).

I think reset has a small internal pullup but if you attach an additional LED and light it once you get the circuit running and turn it off when you reach the main loop, you can check that the device does not reset before its time.

Also, double-checking the fuses is always a good idea.

I think I’ll order a few additional MCUs soon and try the configuration out myself once more, will get back to this when I get the parts.


March 14, 2012 at 21:40

@jokkebk: Thank you for your fast answer! I already try to pull up the reset line and to solder a capacitor between vcc and gnd. I directly solder the usb connector to my pcb and there’s no poorly conduction. :-/
Did you use the 20Mhz version or the 10Mhz one of the Attiny85?(I got the 20Mhz one)
And are you sure of your hex file? (I read upper that there were a mistake in the source code with LED_PIN)


March 14, 2012 at 21:45

@Daniel: I used the 20 MHz version with fuses set to 0xE1 (low) and 0xDD (high). The .hex file should work as the compile problem only related to source code I had edited after compiling. Unfortunately I cannot check the .hex file as I have only 10 MHz ATtiny45 at my disposal and it probably won’t support 16.5 MHz from PLL.

If you upload a picture of your PCB I can take a look at it if I can spot any problems there.


March 15, 2012 at 6:34

I finally got it too work, it seems I forgot to set the fuse bits. This way it seems that I destroyed 2 of my chips, at least I can’t see to connect to them anymore.


March 15, 2012 at 7:47

Is there anything special I’m supposed to be doing for the SFE board? I changed the pin definitions to PB0/PB2 for D-/D+, respectively, and it doesn’t cooperate. Is there something I’m missing?


jokkebk says:
March 26, 2012 at 13:11

@mck: Hmm, I don’t have the SparkFun board myself, but the first thing I’d check is that did the original firmware work, reporting temperatures via text input (or any other voltage measurement, it would probably report something like zero if there’s no temp resistor attached)?

Once you get the “original plan” working, you can be sure that the card gets proper contact to USB port, and can then just double-check the differences in EasyLogger usbconfig.h and my USB password generator’s usbconfig.h. I can’t think of much else than the pin definitions, though. Some people had issues with the LED voltage regulation used in SparkFun’s version, and needed to use a USB HUB to get it working.

Also, as noted in my other comments, the USB password generator does not work on Macs due to the way OS X handles these kinds of devices.


March 24, 2012 at 12:09

Well, first of all many compliments for the nice development.
I have some problems though and I am wondering if somebody working with OSX Lion can assist me.
The hardware assembly looks fine and the voltages are 2.47 V on PIN no 6 and ~0 on PIN no 7 of the ATTiny85.

I installed the needed software as described here:

Plus I installed the precompiled version of libusb.

Than I downloaded the usb_passgen package and run: “make” and “make flash” and this is the message that I get:

make flashavrdude -p attiny85 -c usbtiny -v -U flash:w:main.hex

avrdude: Version 5.11, compiled on Mar 24 2012 at 00:34:11
Copyright (c) 2000-2005 Brian Dean,
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is “/usr/local/etc/avrdude.conf”
User configuration file is “/Users/rik/.avrduderc”
User configuration file does not exist or is not a regular file, skipping

Using Port : unknown
Using Programmer : usbtiny
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

avrdude done. Thank you.

I don’t know what is wrong there… Any idea???

Thank you in advance.


March 24, 2012 at 13:14

@Rik: I checked out Lady Ada’s instructions and tried out “easy method”, i.e. CrossPack for Mac from Obdev (by the way, amazingly useful thing to have). After installing and plugging in my usbtiny, I could flash with avrdude just like in Windows.

So as the error says, it seems there are communication problems with your USBtiny. I assume the USBtiny is the programmer you are using, so unless you have a faulty programmer, double-check the USB connection (you should get a completely different error if USBtiny fails to communicate with the ATtiny85).

Also, if you are powering the circuit from USB, check that you have not accidentally left the USBtiny “power jumper” on, which might cause malfunction when the MCU is getting 5V from USB. As last idea, triple-check the 6-pin header connections that you have not mistakenly wired ground, VCC or anything else to wrong places (in worst case it’s a good way to brick your programmer).

Hope you get it working!


March 24, 2012 at 14:33

@jokkebk Sorry for the dumb question… but how can I check if I didn’t “have accidentally left the USBtiny “power jumper” on”???

I don’t know what you mean with USBTiny. I only have the ATtiny85 wired with resistors and diodes of the right value and a usb cable going to the breadboard in a way similar to what you show in the other tutorial (a 4 pins plug inserted in the breadboard to allow connecting the usb cable) and that is it…

Thanks in advance!


March 24, 2012 at 14:41

@Rik: Ah now I understand! You need a programmer like this USBtiny to flash the chip, it doesn’t work with just the project circuit plugged into a computer:

I thought you had it because you were referring to the guide from Lady Ada on how to use this on a Mac. There are also a dozen other ISP programmers available with various designs, but the USBtiny is probably the most commonly used.

Alternatively, you can use an Arduino to do the programming, I just did on blog post on that. It also shows how I have detached the USB cable when programming, with USBtiny you can just set the jumper as I said and avoid that:

Also a word of warning: Even if you program the device with a Mac, OS X handles USB keyboards in a different way, causing the USB password generator not to work on a Mac (in a nutshell, Macs don’t send LED status changes to keyboard when you toggle caps lock on the native keyboard, and my device waits for this status change message before it sends anything…). So it’ll only work on PCs.

However, if you add a button and use that to trigger the sending of keypresses, you might have success. I haven’t tried that myself yet.


March 24, 2012 at 15:52

@jokkebk Well, well… this make now a lot of sense… I will try to get one of this usbtiny from Adafruit or Sparkfun and then try again…

Clearly there was some big piece of equipment missing!!!

Thanks indeed, I’ll tell you if I manage!



March 27, 2012 at 19:22

Люди помогите мне сделать такую вещь и я вам заплочу денег !!!!!вот скайп dima_2207


April 1, 2012 at 22:51

Hello, I have managed to finally program the attiny (after loosing alot of hair and many different methods) however i am a complete noob at reading circuits even simple ones is there any chance anyone could provide a diagram on veroboard for the component layout. I am getting the same issue as others when I plug it in that the device is unknown but i think this is becaus I have not put it toghether as it should be.



jokkebk says:
April 3, 2012 at 0:03

You _should_ be able to see all the components in this picture on the veroboard, just look at my veroboard sketch first so you can visualize in you mind which groups holes are connected.

I added two new pictures in large resolution to help you even more. If I had the knowledge, I would’ve created a gif animation of the build process, but alas it’s too late now.


April 17, 2012 at 11:16

I use the V-USB, when i plug the usb, the program is running.
When the pc loaded the drivers completly, the program had run a half,
how can the avr know if the drivers is loaded completly on PC,

which can i use, and how?

is there any sample?

sorry for my pool english.


jokkebk says:
April 17, 2012 at 11:21

Yes that’s the hard part. A simple way is to add a delay loop of a few seconds after initialization before the main loop (you’d likely need to call USB polling function also in there), but that will not work the first time when Windows looks for drivers and installs them.

If you have a custom software on PC side, you could implement a “activate” command that you send over USB to tell the device to start doing its job.

For HID devices that have no PC side component telling them to start, the only choice is the delay loop. On Windows, the HID keyboards implementing boot protocol can also wait for first LED state change message (which is sent after initialization to tell the “initial” LED state) and then start doing things. But that won’t work on Linux or Mac, I think.


April 19, 2012 at 5:10

Have you used these functions yet? USB_SET_ADDRESS_HOOK、USB_RX_USER_HOOK and USB_RESET_HOOK.

I have searched everywhere, and can’t find any example.


jokkebk says:
April 19, 2012 at 10:21

My password generator uses USB_RESET_HOOK, check out usbdrv/usbconfig.h – it calls a function that is then defined in main.c. I would guess the other two hooks would be similar.


April 19, 2012 at 17:58

sorry for disturb you again and again.
i have unzip the and can’t find any code about hook in main.c but only usbconfig.h
#define USB_RESET_HOOK(resetStarts) if(!resetStarts){hadUsbReset();}

does this hook can resolve my problem that program had run a half when pc had loaded the drive completly ?


jokkebk says:
April 20, 2012 at 0:38

The #define in usbconfig.h means that the code after it is executed when USB device is reset:


Basically, the if clause will call hadUsbReset() when resetStarts is false (zero). The V-USB library basically has this kind of code somewhere in usbdrv.c:

USB_RESET_HOOK(1); // reset starts
// do reset stuff
USB_RESET_HOOK(0); // reset ends

So only thing needed in main.c is to define hadUsbReset() function which the above lines will call, thanks to that #define in usbconfig.h.

Reset hook is called some time before PC accepts any data from your USB device, so it probably does not solve the issue. You need to start a timer before the main loop, and only start sending anything after certain period has passed. You can find many AVR timer tutorials by googling – just don’t use interrupt versions (unless you understand the requirements V-USB has for interrupts and can accomodate for them).


April 20, 2012 at 5:12

Thanks a lot,
now i have used a witless way to detect if the driver is loaded completly.
i emulate to press the CapsLock key in the loop, and checked the CapsLock counts, if the counts > 2 , it means the drivers is loaded completly.

it seems to work fine ^_^


April 22, 2012 at 15:38

Hello jokkebk,

how can switch form CAPS LOCK to a other button for new Key?
the usbFunctionWrite is only start to klick CAPS LOCK and I find not the call.

thanks for help,


jokkebk says:
April 23, 2012 at 12:50


Unfortunately the only thing that a USB keyboard will receive from PC is the LED status for CAPS LOCK, NUM LOCK and SCROLL LOCK. The password generation counts LED state changes and starts generating after three of them (currently any of the three will work) are received.

So it is not possible to change the key, sorry.


Newer Comments arrow

Leave a Reply

Your e-mail address will not be published.

1 × = six

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>