Objective Development Forums

Hello All,

In my design I want to use without crystall configuration. I am a little sceptic if no crystal can cause additional instability.

Could you share your experience on this isue. Without crystall do you see any additional risk.

By the way, I am using AvrTiny45 . I am lack of ports. With crystall version I have a port problem at PB1 , I wrote a seperate thread for this but no one returned.

Best regards.

Actually it seems as if the attiny45 isn't suited for V-USB as it is specified for a maximum frequency of 10Mhz (look up the datasheet) which is not supported by V-USB. The minumum is 12 Mhz.

K-Duke wrote:Actually it seems as if the attiny45 isn't suited for V-USB as it is specified for a maximum frequency of 10Mhz

I think you may be reffering to the ATtiny45V. I am running the ATtiny45 @ 16.5Mhz without problems.

Form my datasheet:

Speed Grade
– ATtiny25/45/85V: 0 - 4 MHz @ 1.8 - 5.5V, 0 - 10 MHz @ 2.7 - 5.5V
– ATtiny25/45/85: 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V

Hm ... you're right. I've been to hush looking up the values... most probably I've been too tired.

Well to come back to saltuka's problem. That's pretty strange! If you'd said it doesn't work on PB5 my first guess would have been you forgot the disable reset fuse. Though even if it had been this pin, you have set the appropriate fuse for disabling reset.

Well the only reason i can see is that PB5 is supposed to be used only as "weak" I/O-pin. Unfornately you don't mention what you have connected to this specific pin (may it be PB5 or PB1 now). Maybe PB1 is just letting through a too high current, the power supply fades and the attiny is not working correctly anymore.

Though this is just a guess as you don't mention what you are switching with your tiny.

K-Duke wrote:Hm ... you're right. I've been to hush looking up the values... most probably I've been too tired.

Well to come back to saltuka's problem. That's pretty strange! If you'd said it doesn't work on PB5 my first guess would have been you forgot the disable reset fuse. Though even if it had been this pin, you have set the appropriate fuse for disabling reset.

Well the only reason i can see is that PB5 is supposed to be used only as "weak" I/O-pin. Unfornately you don't mention what you have connected to this specific pin (may it be PB5 or PB1 now). Maybe PB1 is just letting through a too high current, the power supply fades and the attiny is not working correctly anymore.

Though this is just a guess as you don't mention what you are switching with your tiny.

I use the PB1 pin as input. Problem is with the PB1 pin. To be sure, if I make something wront for initialization of this pin, I removed all USB related code and tested PB1 as input. It is OK no problem is seen. However when I add the USB code, problem happens. USB comminication stops when apply ground to PB1. Currently I decided not to use this pin so disable crystal and use these pins as input. This worked well but I am a little hesitating if without crystal configuration there may be some performance problems with USB firmware.

Well it might be that you can't use the device in some circumstances like EMI (electromagnetic interference) or if the temperature changes a lot ( like 10°C ). Though I don't know exactly how exact the attiny45's internal rc oscilator is. Though I just got another idea. You can use an external crystal oscillator (not just a crystal). The ones I'm talking about are those like in this wiki article. http://de.wikipedia.org/wiki/Quarzoszillator Look at the very bottom of the article. As it generates a clock signal itself you only need 1! pin (XTAL1) for the attiny45. So you got the other xtal free for your input pin

The 16.5 MHz module is more stable than the 12.8 MHz module because everything is within the specs of the RC oscillator. The big issue is calibration and V-USB contains only suggestions how this can be solved. If you have a good calibration method, the RC version should be similarly stable as a crystal version.

We suggest two methods of calibration:
(1) Calibration at startup. This method is good, except that it does not compensate for drift.
(2) Synchronization to the SOF pulses (1 kHz). The disadvantage of this method is that USB frames following the SOF pulse can't be read and we have to rely on the host controller to retry the frame. This error may also cause false SOF detections which de-calibrate the oscillator. This method may therefore be unstable for higher data volumes.

You may come up with something better, though...