Objective Development Forums

Hello
I read "products/avrusb/index.html" by an interpreter.
Because I do funny translation, as for the interpreter, I cannot really understand a meaning.
I can interpret it to be able to work even if "12.8MHz" use "atmega168" when I read the sentence that translated "avrusb-20081022/libs-device/osccal.h".
However, I can interpret it if I will read a reading even if, therefore, for example, a device having "PLL" can work "only in Attiny45".
May the right interpretation work in Atmega168?

apollononnno wrote:I read "products/avrusb/index.html" by an interpreter.

I guess this will result in funny (or 大変) translations:-)

apollononnno wrote:I can interpret it to be able to work even if "12.8MHz" use "atmega168" … a device having "PLL" can work "only in Attiny45".

1. Only the ATtiny45 or similar devices have a PLL. This PLL can be tuned to 16 MHz or more, and the 16.5 MHz version of AVRUSB will run.

2. All other ATmega controllers don't have a PLL but an RC oscillator. This oscillator is not as stable as the PLL (over temperature), and only specified by a bit more than 8 MHz. However, in practice, this oscillator can operate up to 14 or 16 MHz. Therefore, the brand-new 12.8 MHz version of AVRUSB will run on all ATmega controllers without crystal. But the 16.5 MHz version will not run.

3. Both versions (12.8 MHz and 16.5 MHz) contain code to re-synchronize USB data, because, in both cases, the clock frequency is not precisely enough to sample USB data from first to last bit of a packet without such correction.

4. Both versions contain optional code to tune the internal oscillator to the right frequency by measuring the time between SOF pulses.

5. It's too hard for me to check whether „Google Translation“ will produce readable Japanese text for this article.

I have used the 12.8 MHz code on an ATMega88. It works great. ATMega168 is from the same family so that should work as well.

With a VCC of about 3.4 volts, I had to load the value 249 into OSCCAL, to reach a frequency of 12.8 MHz.

The frequency is dependent on temperature and voltage. 249 is close to the maximum value 255. I suspect that when the temperature is low, a VCC of 5 volts have to be used, to be able to reach 12.8 MHz.

I take time and try inspection of the movement.

I actually tried to see what happened in different temperatures. The code calibrates the frequency by measuring the intervals between marker pulses. When putting a bag of ice on the IC OSCCAL moved from 249 to 250. When putting the IC under a lamp OSCCAL went down to 248.

Those were not huge differences. 12.8 MHz will probably work in all temperatures humans tolerate (on 3.3 volts).

By the demand of the producer, I deleted URL.
The necessary person please search [hidspx].

Because this device is tn2313, it is lack in "RC12.8MHZ" and memory of "2 kbytes".
Can you change this in mega48,88,168?
What kind of operation is necessary for fuse, proguram to operate this in "RC12.8MHZ?"

For fuse setting - look in the datasheet for the ATtiny2313. CKSEL[3:0] have to be changed as well as SUT[1:0].

The setting of ATtiny2313 is next.
SUT[1:0-10] CKSEL[3:0-0100].
The setting of ATmega168 is next.
SUT[1:0-10] CKSEL[3:0-1100].
Calibration Byte will become 12.8MHz with a value of the neighborhood of 240(F0).
How should I use "libs-device" and "usbdrv?"

apollononnno wrote:ATtiny2313: SUT[1:0-10] CKSEL[3:0-0100].
ATmega168: SUT[1:0-10] CKSEL[3:0-1100].
Calibration Byte = 240 → f = 12.8MHz.
How should I use "libs-device" and "usbdrv?"

ATtiny2313: Selects internal 8 MHz RC oscillator with 65 ms start-up time
ATmega168: Selects low-power crystal oscillator with 1K clock cycles start-up time
That is wrong! For proper 16.8 MHz AVRUSB module, you don't need to change fuse settings, let CKSEL[3:0]=0010 and SUT[1:0]=10.
The calibration byte should be tuned by firmware, either after USB RESET (D- not required to route to an INT pin), or permanently (D- required to be routed to an INT pin, less code size). On ATmega168, every pin is interrupt capable, so, if you decide to use the latter version, no change in hardware is necessary.
You should use “osccal.h”+“osccal.c” to tune calibration byte after USB RESET, or “osctune.h” to tune permanently.
For a working example on ATmega8, see http://www.tu-chemnitz.de/~heha/bastele ... sb2lpt.zip and the directory src/firmware/USB2LPT6 inside.

Note that the 16.8 MHz module does fit into 2 KB program space of ATtiny2313 if you have good knowledge how to do. See same example for a working HID bootloader.

I read it well, but did not come to understand a start.

I made a mistake in choice of fuse.
I am ATmega168: SUT[1:0 -10] You should have chosen CKSEL[3:0-0010].
When I use RC of tn2313 in your sentence and can proofread AVU-USB-HID, I can read, but is the interpretation wrong?
Can you let "16.5MHz" or "12.8MHz" act in tn2313-RC when they are possible?
I can find it in manual of tn2313, Figure 132 "only to 12MHZ".

I can add one pin, a port of 3pin in total by using inside RC oscillator by assigning reset to Port more.
Or I do it whether I connect 16MHz to xtal1 with an outside oscillator and get 2pin.

Seems to be true: the Tiny2313 may not be able to reach 12.8 MHz...

This is not so much of an issue because it's hard to implement something useful in only ~ 300 bytes of code. The 12.8 MHz driver is much bigger than the other modules.

ATTINY2313 OSCCAL length is 7bit.
The initial OSCCAL value is 128 in oeccal.c so ATTINY2313 starts OSCCAL=0 as slow 3.5MHz CPU clock.

Is step=64 in osccal.c better for 7bit OSCCAL products ?

You can't use osccal.c anyway, because to code is too big for the ATTiny2313. The 12.8 MHz module is not suitable for the ATTiny2313.