ATtiny85 Software BOD Disable

Go To Last Post
28 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone had any luck getting this to work?

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try asking the question again, I'm not sure what your problem is. Try posting your code and describe what you want to happen and what is happening. You will get a better response asking specific questions, rather then a generic "why does this not work?"

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fear you may have mistaken Joey for a beginner ;-)

(it's a pretty fair bet he, of all people, knows exactly how to program the BOD so if it doesn't appear to work there's a strong chance there's something wrong with its implementation in the chip).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The BOD is controlled by the fuses. So there usually is no way to change or disable BOD in software - except for having a second µC doing reprogramming the fuse.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So there usually is no way to change or disable BOD in software...

Quote:
• Bit 2 – BODSE: BOD Sleep Enable
BOD disable functionality is available in some devices, only. See “Limitations” on page 37. The BODSE bit enables setting of BODS control bit, as explained on BODS bit description. BOD disable is controlled by a timed sequence.

This bit is unused in devices where software BOD disable has not been implemented and will read as zero in those devices.

Quote:
• Bit 7 – BODS: BOD Sleep
BOD disable functionality is available in some devices, only. See “Limitations” on page 37.

In order to disable BOD during sleep (see Table 7-1 on page 35) the BODS bit must be written to logic one. This is controlled by a timed sequence and the enable bit, BODSE in MCUCR. First, both BODS and BODSE must be set to one. Second, within four clock cycles, BODS must be set to one and BODSE must be set to zero. The BODS bit is active three clock cycles after it is set. A sleep instruction must be executed while BODS is active in order to turn off the BOD for the actual sleep mode. The BODS bit is automatically cleared after three clock cycles.

In devices where Sleeping BOD has not been implemented this bit is unused and will always read zero.


Quote:
7.2.1 Limitations
BOD disable functionality has been implemented in the following devices, only:
• ATtiny25, revision E, and newer
• ATtiny45, revision D, and newer
• ATtiny85, revision C, and newer
Revisions are marked on the device package and can be located as follows:
• Bottom side of packages 8P3 and 8S2
• Top side of package 20M1

So, the first step is to verify the chip revision?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I fear you may have mistaken Joey for a beginner ;)
That's OK, sometimes I feel like one ;)
theusch wrote:
So, the first step is to verify the chip revision?
'E' ... I think... as per this post:
Bottom side:
1F7    415  --> Fab / lot number
B5      1P  --> 
1236    e3  --> Date code(yyww) / revision of the device

As it happens all the ATtiny85 I have on hand have the same back-side labelling.

If the fellow at Atmel who responded was wrong, this may not be an 'E'. Maybe it's a 'B'? Was 'B' still manufactured in September 2012? Does anyone have any '85s on hand to check? I would expect the date codes to increase from revision to revision (within the same fab).

Looking at the above-linked post again, I reference someone else's post within regarding an ATtiny45 containing:

8H7 509
G 1P
0580 e3

... which according to Atmel would be revision 'E' manufactured in the 80th week of '05. Come to think of it, 2005 was an especially long year for me ;)

Anyone have the real skinny on deciphering back-side labelling on these wee beasties?

As for my code:

#include 
#include 

int __attribute__ ((__OS_main__)) main(void) {

  ACSR = (1<<ACD);
  PRR = (1<<PRTIM1) | (1<<PRTIM0) | (1<<PRUSI) | (1<<PRADC);
  DDRB = 0x3F;

  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sleep_bod_disable();
  sleep_cpu();

  while (1);
  
}

This is the recommended sequence.

Assembly:

bods_test.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
   0:	0e c0       	rjmp	.+28     	; 0x1e <__ctors_end>
   2:	15 c0       	rjmp	.+42     	; 0x2e <__bad_interrupt>
   4:	14 c0       	rjmp	.+40     	; 0x2e <__bad_interrupt>
   6:	13 c0       	rjmp	.+38     	; 0x2e <__bad_interrupt>
   8:	12 c0       	rjmp	.+36     	; 0x2e <__bad_interrupt>
   a:	11 c0       	rjmp	.+34     	; 0x2e <__bad_interrupt>
   c:	10 c0       	rjmp	.+32     	; 0x2e <__bad_interrupt>
   e:	0f c0       	rjmp	.+30     	; 0x2e <__bad_interrupt>
  10:	0e c0       	rjmp	.+28     	; 0x2e <__bad_interrupt>
  12:	0d c0       	rjmp	.+26     	; 0x2e <__bad_interrupt>
  14:	0c c0       	rjmp	.+24     	; 0x2e <__bad_interrupt>
  16:	0b c0       	rjmp	.+22     	; 0x2e <__bad_interrupt>
  18:	0a c0       	rjmp	.+20     	; 0x2e <__bad_interrupt>
  1a:	09 c0       	rjmp	.+18     	; 0x2e <__bad_interrupt>
  1c:	08 c0       	rjmp	.+16     	; 0x2e <__bad_interrupt>

0000001e <__ctors_end>:
  1e:	11 24       	eor	r1, r1
  20:	1f be       	out	0x3f, r1	; 63
  22:	cf e5       	ldi	r28, 0x5F	; 95
  24:	d2 e0       	ldi	r29, 0x02	; 2
  26:	de bf       	out	0x3e, r29	; 62
  28:	cd bf       	out	0x3d, r28	; 61
  2a:	02 d0       	rcall	.+4      	; 0x30 
2c: 15 c0 rjmp .+42 ; 0x58 <_exit> 0000002e <__bad_interrupt>: 2e: e8 cf rjmp .-48 ; 0x0 <__vectors> 00000030
: #include int __attribute__ ((__OS_main__)) main(void) { ACSR = (1<<ACD); 30: 80 e8 ldi r24, 0x80 ; 128 32: 88 b9 out 0x08, r24 ; 8 PRR = (1<<PRTIM1) | (1<<PRTIM0) | (1<<PRUSI) | (1<<PRADC); 34: 2f e0 ldi r18, 0x0F ; 15 36: 20 bd out 0x20, r18 ; 32 DDRB = 0x3F; 38: 3f e3 ldi r19, 0x3F ; 63 3a: 37 bb out 0x17, r19 ; 23 set_sleep_mode(SLEEP_MODE_PWR_DOWN); 3c: 45 b7 in r20, 0x35 ; 53 3e: 47 7e andi r20, 0xE7 ; 231 40: 40 61 ori r20, 0x10 ; 16 42: 45 bf out 0x35, r20 ; 53 sleep_enable(); 44: 55 b7 in r21, 0x35 ; 53 46: 50 62 ori r21, 0x20 ; 32 48: 55 bf out 0x35, r21 ; 53 sleep_bod_disable(); 4a: 85 b7 in r24, 0x35 ; 53 4c: 84 68 ori r24, 0x84 ; 132 4e: 85 bf out 0x35, r24 ; 53 50: 8b 7f andi r24, 0xFB ; 251 52: 85 bf out 0x35, r24 ; 53 sleep_cpu(); 54: 88 95 sleep 56: ff cf rjmp .-2 ; 0x56 <__SREG__+0x17> 00000058 <_exit>: 58: f8 94 cli 0000005a <__stop_program>: 5a: ff cf rjmp .-2 ; 0x5a <__stop_program>

All timing requirements appear to be met:

  sleep_bod_disable();
  4a:	85 b7       	in	r24, 0x35	; 53
  4c:	84 68       	ori	r24, 0x84	; 132
  4e:	85 bf       	out	0x35, r24	; 53
  50:	8b 7f       	andi	r24, 0xFB	; 251
  52:	85 bf       	out	0x35, r24	; 53
  sleep_cpu();
  54:	88 95       	sleep

Two cycles between (1<<BODS)|(1<<BODSE) and (1<<BODS) (requires <= 4 cycles). One cycle between (1<<BODS) and SLEEP (requires <= 3).

I tried this code both with and without BOD enabled by fuse, just to be sure I wasn't leaving some other Vbg-dependent feature enabled. DMM confirms that Vbg does not run while asleep when BOD is fuse-disabled, but does run when BOD is fuse-enabled. Ergo software BOD disable isn't working...

... or have I missed something obvious?

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

All timing requirements appear to be met:

I read and re-read the BODS bit description. Each time I come up with a different interpretation.

BODS is set along with BODSE. Does the 3-cycle "clock" start then?

Quote:

The BODS bit is active three clock cycles after it is set.

Also, does "within three clock cycles" mean < 3 or <= 3?

Yes, puzzling. (How are you checking Vbg with a DMM? Indirectly, via current draw?)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only way I can think of to save a cycle would be to use another register (if indeed the timing is that critically tight).

IN reg1, MCUCR
ORI reg1, 0x84
MOV reg2, reg1
ANDI reg2, 0xfb
OUT MCUCR, reg1
OUT MCUCR, reg2
SLEEP

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
BODS is set along with BODSE. Does the 3-cycle "clock" start then?
I don't think so:
Quote:
In order to disable BOD during sleep (see Table 7-1 on page 33) the BODS bit must be written to logic one. This is controlled by a timed sequence and the enable bit, BODSE in MCUCR. First, both BODS and BODSE must be set to one. Second, within four clock cycles, BODS must be set to one and BODSE must be set to zero. The BODS bit is active three clock cycles after it is set. A sleep instruction must be executed while BODS is active in order to turn off the BOD for the actual sleep mode. The BODS bit is automatically cleared after three clock cycles.
I see what you mean though. However, I expect that writing BODS to '1' doesn't equate to 'setting it'. The timed sequence sets it. If this interpretation is correct, then BODS gets set on the second write.

Quote:
Also, does "within three clock cycles" mean < 3 or <= 3?
I interpret it to mean <= 3. In any case, my test code has one cycle between the (assumed) setting of BODS (on the second write of the timed sequence) and the sleep instruction.

In support of this interpretation, I point out that the timed sequence must complete within 4 cycles. If the 3-cycle-before sleep limit began with the first write of the timed sequence, it would technically be possible to succeed in setting BODS with the second write of the timed sequence, but be too late with the sleep. Does that sound likely?

>>If<< I'm wrong and the 3-cycle limit does in fact begin with the first write of the timed sequence, >>and<< 'within 3' means 'less than 3', then this code should work:

ldi r16, (1<<BODS)|(1<<SE)|(1<<SM1)|(1<<BODSE)
ldi r17, (1<<BODS)|(1<<SE)|(1<<SM1)
out MCUCR, r16
out MCUCR, r17
sleep

It does not.

EDIT: I just saw your next post ;)

Quote:
How are you checking Vbg with a DMM? Indirectly, via current draw?
Yes, inserted between the PS and the Vcc pin of the '85. With BOD fuse-disabled I see about 0.5 uA. With BOD fuse-enabled it's 20.9 uA. I expect my DMM isn't especially accurate at these low currents, but it's clear when Vbg is running, and when it isn't.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to resurrect an old thread, but I'm having this same exact problem, and all the searching that I've done, could not find a working solution.

I'm now using the macros define in the sleep.h, sleep_bod_disable(), in this sequence:

 

sleep_enable();

sleep_bod_disable(); // try to disable Brown-Out Detection to reduce parasitic drain

sleep_cpu(); // go to sleepy beddy bye

sleep_disable();

 

It's a recently purchased Tiny85 MCU (from Mouser), so I'd assume it's rev C or higher. The backside revision ID is still a mystery to me - seems no one got any definite way to find it in confidence.

 

Since the 25/45/85 have so much in common, I'd assume this issue is common across them as well. I know the BOD disabling is not working from my measured amps - pretty much the exact delta of uA JJ found above.

 

Anyone ever get the BOD disable working on any these MCU's?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I never resolved either of these issues.  Although I would be happy if they ever do get resolved... ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I really dunno what's going on. I tried with both an 85 and 85V version. I've seen posts where it was working on other ATMEL family MCU's. I can't find any evidence anyone ever got it working on 25/45/85's.

 

I'm using it in a flashlight driver (on BudgetLightForum, thread here: http://budgetlightforum.com/node/41067), so power drain is important. We are hoping to use it in a Group Buy light (http://budgetlightforum.com/node/45915) that has close to 500 sign-ups and get it manufactured in China. Right now I'm measuring 0.016 mA if BOD is disabled via the fuses, 0.037 mA if enabled. It's not a hugh problem - we could live with the 0.037 mA drain, just it's always better to have it as low as possible. People tend to keep flashlights laying around for months. I needed the BOD enabled because without it, I was getting lockups' and other bad behavior if there are power fluctuations cause by intermittent connections when installing batteries, for example, threading on a battery tube that may have intermittent connections while threading it on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting project.

 

I'd say that since you can't predict when a power fluctuation will occur, you need to keep BOD enabled all the time anyway.

 

But it's true, I haven't seen any evidence anyone has ever managed to get software BOD disable working on the t25/45/85.  Doesn't mean there isn't a way, though.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tom E wrote:
sleep_bod_disable(); // try to disable Brown-Out Detection to reduce parasitic drain

I see I participated in this discussion earlier. ;)  I'm out of town so can't play with it, but indeed I have an app where I'll probably use BOD disable (but not on this model).

 

Anyway, have y'all looked at what the infinite-value toolchain generated for this model for that macro?  Does it make sense?  

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Anyway, have y'all looked at what the infinite-value toolchain generated for this model for that macro?  Does it make sense?  


Yes, and yes. I believe it's detailed above (I'm on my mobile and it's a royal pain to read code). I any event, IIRC the macro generates equivalent code for other supported devices, like the 328P, and that code works as expected.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also sorry from me for resurrecting this old thread but I'm actually having the same issue (I cant get the BOD disabled by software) and I was wondering if someone found out something new?

I would greatly appreciate.

 

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still no.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still no.

I'd guess that your troubles in 2014 were caused by a misinterpretation of the chip markings. The datasheet currently on Atmel website (from 2013) lists 'C' as the latest tiny85 revision, so what you had back then probably wasn't an 'E'. And 'B' doesn't have that functionality.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mrono wrote:

Still no.

I'd guess that your troubles in 2014 were caused by a misinterpretation of the chip markings. The datasheet currently on Atmel website (from 2013) lists 'C' as the latest tiny85 revision, so what you had back then probably wasn't an 'E'. And 'B' doesn't have that functionality.

 

 

Where did you find this information in the datasheet (that revision C is the most recent) - the errata? And do you have any information how to interpret the markings?

Last Edited: Wed. Dec 20, 2017 - 08:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where did you find this information in the datasheet (that revision C is the most recent) - the errata?

Yes, I was looking at the errata. And assumed that any newer revision would be listed there. Now that you pointed it out, that assumption might of course be wrong.

And do you have any information how to interpret the markings?

The way I'd interpret the markings in post #6 is that joeymorin's tiny85 is 'B' (as in B5 on the second row), and the example tiny45 markings would be from a rev 'G' part. Again from the second row. Based on the errata section of the datasheet, these would be plausible fairly recent revisions in 2014.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd guess that your troubles in 2014 were caused by a misinterpretation of the chip markings.

No misinterpretation on my part.  Atmel couldn't even answer the question.  I contacted them before even opening this thread  See post #6, and follow the trail of links.  They had this to say:

Bottom side:
1F7    415  --> Fab / lot number
B5      1P  --> 
1236    e3  --> Date code(yyww) / revision of the device

Atmel were never able to tell me (or point me to documentation which would) unequivocally how to determine revision.  It's all just inference and supposition, a terrible way to conduct business.  The likelihood is that it is not E, but by no means is it certain to be B.  What is the '5' for, then?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was in contact with Microchip yesterday asking how to identify the revision.

They told me it's the first letter on the bottom side (PDIP package).

Turned out that he meant the second line, first letter which is a "B" in my case. That would explain why it's not working.

 

Now my problem is where to get a "C" revision of the Attiny85...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ranger81 wrote:
Now my problem is where to get a "C" revision of the Attiny85...

You mean "C or newer"?  With several respondents to this thread, IMO it would be strange for all of you to have early batches.

 

Indeed I never noticed the Limitations note:

7.2.1 Limitations
BOD disable functionality has been implemented in the following devices, only:
• ATtiny25, revision E, and newer
• ATtiny45, revision D, and newer
• ATtiny85, revision C, and newer
 

The datasheets I have downloaded don't put dates on the  chip revisions in e.g. Errata section.  But can we do a bit of "interpolation"?

 

(below refers to datasheet rev letters)-- Datasheet revision history updated that section (or at least subchapter) in datasheet rev. K in early 2008.  That is the last note about BOD in datasheet revision history.  [I lied; "Limitations mentioned rev. N see below]

-- ...and the Software BOD Disable was added rev. G/May 2006

 

-- Indeed rev. C/2006 has no Software BOD Disable section

-- ...nor does rev. F/April 2006

-- Rev. G has the subchapter, but not the Limitations table

-- Rev. K indeed updated the section and added Limitations  Notice that Limitations is now a bit different, although no note of that Tiny45 change in later Dataqsheet Revision History summaries:

7.2.1 Limitations
BOD disable functionality has been implemented in the following devices, only:
• ATtiny25, revision E, and newer
• ATtiny45, all revisions
• ATtiny85, revision C, and newer
 

-- Rev. N /April 2011 has the Limitations table as it is now.  And a note in revision history

28.1 Rev. 2586N-04/11
...
2. Updated:
– Document template.
– Removed “Preliminary” on front page. All devices now final and in production.
– Section “Limitations” on page 37.
...

 

OK, here is the point I'm trying to get at:  I find it hard to believe that the good 'Freaks digging into this are all using Tiny85 chips or others in the model family that are all ~10 years old or older.  I'd speculate that when the Limitations paragraph was added, it was based on some testing results.  Apparently not...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Dec 20, 2017 - 02:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel also told me that 0580 was a date code.  I don't have a lot on confidence in a support team that thinks there are more than 52 weeks in a year, so I don't have much confidence in what revision they think I have.

 

Neither do I have much confidence in the errata, since the 'OC1B' erratum isn't listed as affecting the t85, yet it clearly does.

 

I do wish someone from Microchip would come along and put to rest the question of what each part of the under-side writing means.  Unequivocally

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure I recently linked to a Micromel document which showed how it works. It was in a thread about identifying chips. Were I not on a phone I would try and find it.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I remember about 5 years ago or whenever the new revision came out (and I didn't know about it), I ordered 300 dip tiny85 from farnell.

And was very surprised that I received about 30 tubes with different sizes.

I'm sure that they was clearing the stock of old revision parts.

And I sure that parts you get (at least the big places) are a new revision.     

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just asked at microchipdirect.com which revision they are having in stock.

They replied with "Rev. A".

 

It seems to be impossible getting a Rev. C Attiny85. I gave up and switched to an Attiny84A which works perfectly fine with disabling BOD by software.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They replied with "Rev. A".

Perhaps they've started doing the same thing with revision numbers that they've done with datasheets?:

https://www.avrfreaks.net/forum/whose-stupid-idea-was-it-restart-revision-ids

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]