Objective Development Forums

The currently shipping firmware works with 12 MHz only, it's required that one USB bit is exactly 8 CPU cycles. In principle, it's possible to insert NOPs in the assembler module to accommodate higher clock rates. However, the clock rate must be divisible by 3 (i.e. 15, 18, 21, ... MHz). The assembl...

The Tiny25 is almost the same as the Tiny45, except memory sizes. Since we have tested with the Tiny45, I would expect that it works.

Since you say that it also fails with the Tiny25, it's likely that something is wrong with the wiring.

Yes, you need a CMOS buffer chip. The HCT126 is preferred. The buffer allows for differences in supply voltage between programmer and target. If you don't need this feature, a version without buffer chip is (in principle) possible. Any volunteers who design a version and firmware patch to work witho...

First of all: The base resistor of T4 is the internal pull-up resistor of the port pin. I must admit that we have not tested HV programming with too many chips, I only have the ATTiny45 and an AT90S2343 available. If I remember correctly, somebody here in the forum has reported problems with the ATT...

You should call usbPoll() at least every 50 ms (see documentation in usbdrv.h). You may get away with longer intervals after the device enumeration is completed, though. If you call usbPoll() from other places than the main loop, you should be aware that usbFunctionSetup(), usbFunctionRead() and usb...

I doubt that it's the cable -- this is low speed USB anyway. You must be violating the USB standard somehow. USB 2.0 controllers are more modern and may therefore enforce better standards compliance. I can assure you that the driver itself is good enough for compatibility with all host controllers a...

I can confirm that the driver itself works well with USB 2.0 hosts as well with USB 1.0 / 1.1 hosts. I would suspect either a hardware problem or something in the firmware which interfers with the driver, e.g. by modifying the status of D+ and D-.

That's an error in the checksize script, probably because you don't have awk or another Unix tool installed. You can safely ignore this error or remove the checksize call altogether. It's only a check to see how much memory is used by the code.

Are you sure that this is a USB 2.0 specific problem and not a problem with this particular host? The USB port of this host might be damaged, at least the low speed / full speed circuit.

That's a point Libusb-win32 is a generic, ready-made kernel level driver. It's built to attach to any device and send/receive messages to/from it. The problem with an HID is that the operating system's driver already matches the device. You can probably override that matching if libusb-win32 matches...

I don't know Atmel's HID example and therefore don't know what the DLL is supposed to do. However, I do know that a kernel DLL is not required to communicated with an HID. The DLL might just be a user space library which builds an abstraction around the operating system's USB calls, similar to the l...

Do you have a scope (storage scope would be ideal) to check the wave forms and levels on D+ and D-?

If you power your AVR from 3.3V, there should be no common mode range problem. But a scope often reveals trivial problems which would otherwise be hard to find.

Are you referring to the HIDKeys example? The makefile in that example DOES have a default target named "all". If it is not found, something is seriously broken in your development environment.

Can you post the exact error messages?

The HID spec suggests that key repitition can be implemented by sending the keyboard status in an interrupt transfer in regular intervals. Most operating system interpret the key status as status, measure the time how long a particular key is pressed and start repeating (with their own internal time...

Interesting... Do you have any debug tools available such as a digital storage scope, a logic analyzer or at least a simple analog scope? With a DSO, you should see a query/response dialog on D+, query and response being distinguished by slightly different voltage levels. Simple errors can usually b...