Objective Development Forums

Thanks for the clarification.

16MHz may be too much of an overclock for the V version. I know of one user who sucessfully used a 12MHz crystal w/ the 461V tho.

Oh, true. It does go up to 14MHz (somehow I thought it's only +/- 1MHz or so). Edit: ah, table 7-6 says 7.3-8.1MHz. Clashes w/ figure 24-35.

Quick question for Christian -- why 12.8MHz ? According to the 461 data sheet the oscillator could be calibrated to 12MHz as well.

Good catch, I did not pay attention to the "V". Not sure the PLL is absent in the V version but the 10MHz speed grading alone makes this idea useless

Almost I was redesigning my mega8 based project and actually got a mega88. Ended up using a tiny461 instead, since it has exactly the right size for what I need. I did look at the 88 specs in detail tho and I also ran into similar problems w/ the 461 (the 461 uses a newer chip design, similar to the...

W/ a tiny461/861 I have sucessfully used the following values:

- 3V6 500mW 1N5227 to ground on D-/D+
- R 68 in series betw. diodes and MCU
- R 2k2 to Vcc on D- (at the USB connector, not after 68 !)

Link above is broken. - make sure the fuses are correct, they are different for m8 and m88 - make sure you recompile the project w/ MCU=atmega88 - are you using 3V3 Z-diodes on D+/D- ? If so, replace them w/ 500mW 3V6 diodes. - if you run the m88 at 3.3V, change it to 5V @ 16MHz. Use Z-diodes. - Atm...

And does the internal PPL oscillator of the 461 work with easylogger? You could try to configure the 461 using the PLL clock in high speed mode (16MHz CPU clock). Since the PLL is locked into the 8MHz RC oscillator it can by calibrated via OSCCAL. You will have to run the CPU at 5V for this tho, so...

Hm, w/ gcc this could be modified to #if FLASHEND > 0xFFFF #define USB_READ_FLASH(addr) pgm_read_byte_far(addr) #else #define USB_READ_FLASH(addr) pgm_read_byte(addr) #endif to generally allow for devices w/ more than 64k flash. avr/io.h defines FLASHEND based on the ...

I assume SREG has to be saved in case that some instructions were aborted before entering the interrupt which have some results in the flags in SREG like signbit or half carry ... But why does avr-gcc save r0 itself before that? The AVR interrupt mechanism just sets the I flag, pushes the return ad...

There are quite some changes to the I/O registers of the 88, chance is that the software needs to be modified as well. Atmel has a migration guide available here. I use the combination 3V6, 68R w/ a 2.2k pullup sucessfully w/ a tiny461 (same electrical specs as the 88 AFAICS).

Looks ok.

I used this crystal and these diodes in the past w/o problems.

In my experience Windows uses the product string from the device descriptor as the name for an otherwise unknown device. Since there's only one device descriptor it's the same name for both entries.

A plain 1N4729A seems to be a 1W diode, these have proven in the past to cause problems. Try using a 1N5227B-T or any 3.6V Z diode w/ 500mW max. power spec.

Sounds good to me

Worked for me using a Mega8, didn't work w/ a Tiny461. Turned out the I/O pin threshold voltages are different and I had to use 3.6V w/ the Tiny (3.6 worked w/ the Mega as well). If you want to play it save use 3.6V, <= 500mW.