ATtiny13A 4.8MHz

Go To Last Post
54 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, the datasheet says that "the calibrated internal oscillator provides a 4.8 or 9.6 MHz clock source". On the real thing, I see that 9.6 is approximately 9.6. Great. But 4.8 is more like 3.8, on several units. What am I missing?

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

The tiny13a uses a different value to calibrate the 4.8MHz oscillator. 

You need to read this value (somehow, as it's in the signature area), store it somewhere (probably into Tiny13 EEPROM), and load it into OSCCAL at reset.

 

 

17.3 Calibration Bytes

The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscillator.

The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6 MHz operation.

During reset, this byte is automatically written into the OSCCAL register to ensure correct frequency of the oscillator.

 

There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but

this data is not loaded automatically. The hardware always loads the 9.6 MHz calibration data

during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL

register must be updated by firmware. The calibration data for 4.8 MHz operation is located in

the high byte at address 0x01 of the signature area.

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

That must be it. Thanks! I should have remembered that from my mega16 days. Although I never used anything other than 8MHz back then, I knew that it had different values for other frequencies and that they had to be loaded manually.

I'm probably not going to bother with 4.8MHz then. I didn't really want it that much anyway.

But now I'm just curious. I'm a software guy, so please excuse my ignorance. Is that really hard to divide by 2? Why do we need separate values?

Let's see. The tiny13 datasheet says: "There are separate calibration bytes for 4.8 and 9.6 MHz operation but only one is automatically loaded during reset ... This is because the only difference between 4.8 MHz and 9.6 MHz mode is an internal clock divider." What is that they are trying to say, exactly? I read it as "since the only difference is an internal divider, there is no need for a second value". No?

Eugene

Last Edited: Thu. Jun 25, 2015 - 11:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think what they're saying is it's impossible to load both calibration values since they're different settings for the same oscillator, so it can only load one by default.

 

As for why one isn't enough, my best guess would be that changing the clock divider loads the oscillator slightly differently resulting in a different oscillation frequency, but I'm just shooting in the dark here.

Last Edited: Fri. Jun 26, 2015 - 12:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks as if it is like the old mega8/16/32/64/128 with separate RC for each frequency (and calibration).
Modern chips have a single 8MHz RC and simply prescale in software for 1/2/4/8MHz. Hence a single calibration.
If you want to use 4.8MHz for your tiny13, you need to read the factory 4.8 calibration via your programmer. Then load this value into OSCCAL in software.
David.

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

But now I'm just curious. I'm a software guy, so please excuse my ignorance. Is that really hard to divide by 2? Why do we need separate values?

As others have said, the early AVRs didn't use prescaling to generate various clocks (like CLKPR now offers in modern AVR) but actually used different oscillators. Like you this has always puzzled. The majority had four oscillators at 1, 2, 4 and 8MHz but only ever loaded the calibration byte for the 1MHz choice - so the programmer had to load it for the other three. You would wonder why on earth they didn't just have one 8MHz and divide it? But that's exactly what they did from about 2005 onwards when the 48/88/168 first came out as I think they were the first with a single 8MHz and CLKPR.

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

Except the attiny13 *does* have a clock prescaler, so the previous explanations fall a bit short, and definitely don't explain the verbiage used in the datasheet.  If it's two separate oscillators then why say "This is because the only difference between 4.8 MHz and 9.6 MHz mode is an internal clock divider" in the datasheet?

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

The 4.8 mhz internal oscillator appears to really be that, and not the 9.6 mhz divided by two, as you might conclude from reading that section of the datasheet. Using the 4.8 mhz oscillator will lower the current consumption in active and idle modes, compared to using 9.6 mhz and dividing by two. That can be helpful if, at most, you can idle the CPU, and can not put it into a deeper "sleep".

 

For one ATtiny13A at 4.8mhz and 3.2V, I measured 1200 and 300 µA in active and idle modes; at 9.6 mhz ÷ 2, I measured 1700 and 400.

 

 

- John

Last Edited: Fri. Jun 26, 2015 - 11:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately that would be expected even if it was just a clock divider.  The difference in power consumption between a 4.8mhz and 9.6mhz oscillator, and just the oscillator, is minimal.  The savings you're seeing are the cpu itself running at a lower clock, which it does whether or not the 4.8mhz oscillator is based on a clock divider or a separate oscillator, and you can't use that information to say definitively how the oscillator is implemented within the chip.

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

 

For one ATtiny13A at 4.8mhz and 3.2V, I measured 1200 and 300 µA in active and idle modes; at 9.6 mhz ÷ 2, I measured 1700 and 400.

 

That is intriguing, as the datasheet chart indicates about 1700uA active with the 4.8MHz oscillator.

 

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

jfiresto wrote:

The 4.8 mhz internal oscillator appears to really be that, and not the 9.6 mhz divided by two, as you might conclude from reading that section of the datasheet. Using the 4.8 mhz oscillator will lower the current consumption in active and idle modes, compared to using 9.6 mhz and dividing by two. That can be helpful if, at most, you can idle the CPU, and can not put it into a deeper "sleep".

 

For one ATtiny13A at 4.8mhz and 3.2V, I measured 1200 and 300 µA in active and idle modes; at 9.6 mhz ÷ 2, I measured 1700 and 400.

 

I hadn't had my coffee before making my previous comment, somehow missed the part about dividing the 9.6mhz clock by two.  Still, there's no way the oscillator itself draws an extra 500uA between the two modes.  The first thing I'd ask of your results is whether you verified the chip was actually running at 4.8mhz when using the 4.8mhz oscillator setting, or was it running significantly slower since it was still using the 9.6mhz calibration values.  The fact that the datasheet specifies 1700uA draw at that speed and voltage is rather telling.

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

Rezurok wrote:

I hadn't had my coffee before making my previous comment, somehow missed the part about dividing the 9.6mhz clock by two.  Still, there's no way the oscillator itself draws an extra 500uA between the two modes.  The first thing I'd ask of your results is whether you verified the chip was actually running at 4.8mhz when using the 4.8mhz oscillator setting, or was it running significantly slower since it was still using the 9.6mhz calibration values.  The fact that the datasheet specifies 1700uA draw at that speed and voltage is rather telling.

That is an excellent suggestion. At that point, I hadn't considered how the ATtiny13A loads the wrong clock calibration value. When I eventually did read out the two calibration values, they differed by 32. Another arbitrary design deficiency, one that I could not work around, disqualified the part before I could more carefully and accurately parameterize its current draw.

 

It is possible, but perhaps not probable, that I got a golden ATtiny13A that really does draw 1200 uA at 4.8 mhz -- given the 1:1.5, published typical and maximum values at 3 volts with a 4 mhz external clock. The 9.6 mhz oscillator current consumption is also less than typical. Still, I would want to test your suggestion and a couple other ideas before believing in luck.

 

Thank you for the suggestion!

 

- John

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

I do not own a tiny13. You can do everything and more with a tiny25 or tiny45.
It should be pretty simple to measure your active current with the 4.8MHz RC versus 9.6MHz div2.
You might also compare it with the tiny25 typical figures.
Obviously you should always do your tests with the correct factory calibration values loaded into OSCCAL.

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

I did consider and test the ATtiny25, but it had another design issue that disqualified it. The ATtiny24A, however, proved sufficiently accommodating. It is a bit silly to only use 3 of its 12 i/o pins and less than half its flash, but that is marketing for you.

- John

Last Edited: Tue. Jun 30, 2015 - 06:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on. What can the tiny13 do that the tiny25 does not?

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

According to the datasheet, the 'tiny25 has a considerably higher idle current when using the 8 mhz, RC oscillator. Further, table 22-2 on page 177 shows the idle current nearly doubles(!) when you use both timers – when using an external clock, what about the internal 8 mhz oscillator?

 

For my application, I can also run a 'tiny13 at 1.2 mhz rather than  2 mhz for the 'tiny25 which increases the multiple.

 

Sorry about all the edits. I got up a bit early this morning.

- John

Last Edited: Tue. Jun 30, 2015 - 07:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you need idle, or can you go with powerdown?

 

If it't low power go for a newer design like 441/841, but if you need low pin count the only new design are the tiny10 (4/5/9), they use even less.

but no eeprom etc!

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

Alas, I can't power down the MCU because I need continuously running timer(s) for pulse generation and accurate event timing.

 

Looking into it further, an ATtiny9 might very well do the job. The present avr-gcc 3.4.6 compiled, ATtiny24A code allocates 17 registers and uses 932 bytes of flash. I would have to do some more in software, but I expect that will be manageable space-, time- and energy-wise.

 

Switching to a later version of avr-gcc may burn too much more of the remaining flash. If worst comes to worst, I could probably guide 3.4.6 to allocate one fewer register, and then attack the assembler output with Python and  remap the registers to R16+.

 

The 441 looks very nice.

- John

Last Edited: Tue. Jun 30, 2015 - 12:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the key for low power when you can't power down, are low voltages.

But I would use a tiny85 (because I know it well and have it), and get it to work first, and then care about low "sleep" current later, (perhaps use ISR form watchdog can do your job)

 

For a simple job like this I would use ASM.

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

Go on. What can the tiny13 do that the tiny25 does not?

In general in our apps we lean toward the Tiny25 family.  Sometimes the "family" part is important to get a bit more flash, as well as corresponding multiples of EEPROM and SRAM.  (An app might be small overall, but might still need bigger-than-trivial tables or buffers or history or the like.)

 

That said, there are many fans over the years of the '13.  Rez has pointed out at least one combination where it might well be "better".  Not to mention cheaper, especially vs. the '25V.

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

sparrow2 wrote:

the key for low power when you can't power down, are low voltages.

I run the tiny24A at a closely-regulated 3.3V. I haven't tried lower voltages because it directly drives an analog meter.

 

Quote:
But I would use a tiny85 (because I know it well and have it), and get it to work first, and then care about low "sleep" current later, (perhaps use ISR form watchdog can do your job)

For a simple job like this I would use ASM.

The project has a pretty high timing to i/o pin ratio. I don't think I would have had the patience to get everything right if it were all in assembler.

Instead, I do all the higher-level processing in C and have it talk with a portability layer, largely in C with a bit of assembler, that deals with the hardware. I tried to make the portability layer dead-simple to reduce the time spent debugging and testing it.

 

I first debugged and tested the higher-level code on a MacBook under OSX's Xcode. I wrote and ran a Python sub-process in place of the hardware, to supply stimulus, and to take and record output.

 

Once everything checked out, I substituted the portability layer for an tiny13A, and re-compiled with avr-gcc. I spent a couple hours discovering another design gotcha with the AVR counter/timers, and the first I could not workaround (on a tiny13, at least). After modifying the code to support a tiny24, I spent another day debugging the revised portability layer – but mostly a few simple bits of new or changed higher level code I thought did not warrant re-testing. I will not repeat that mistake.

 

I am pretty sure I could modify the code for an ATtiny9. I am going to wait on that, and see how some test rabbits / guinea pigs react to the present design.

 

Thank you everyone for the suggestions!

 

- John

Last Edited: Wed. Jul 1, 2015 - 09:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 rabbits / guinea pigs

 

I don't know if that's for real but it reminded me of this (working but NOT follow any spec!)  :

 

http://hackaday.com/2009/06/27/a...

 

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

Looking at the subversion code, that RFID tag design is a hoot.

- John

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

We keep hearing about these 'gotchas' and 'design deficiencies'. Perhaps you could elaborate.

"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

Well, the one I could not workaround on the tiny13 is that I could find no way to immediately update an output compare register when the timer was in PWM mode.

 

Imagine putting the counter in fast PWM mode and using OCR0A to set the output pulse width. Now try to progressively program OCR0B to wake the MCU every 200 cycles. As far as I can tell, you can not, because the timer has to roll over first before the next wake up time you program takes effect. If you know a way, I am all ears.

- John

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

jfiresto wrote:
Well, the one I could not workaround on the tiny13 is that I could find no way to immediately update an output compare register when the timer was in PWM mode.

 

Imagine putting the counter in fast PWM mode and using OCR0A to set the output pulse width. Now try to progressively program OCR0B to wake the MCU every 200 cycles. As far as I can tell, you can not, because the timer has to roll over first before the next wake up time you program takes effect. If you know a way, I am all ears.

That is hardly an 'arbitrary design deficiency'.

 

AVR timer PWM modes are specifically designed to generate glitch-free PWM outputs.  Allowing a change to a compare register to take immediate effect would break that design.  When you place a timer into a given mode (i.e. fast pwm), the >>whole<< timer is placed into that mode, not just one of the compare registers.

 

If you require that a timer express two contradictory functions (glitch-free pwm >>and<< instant compare register update) at the same time, then you're out of luck.  There is no such beast in the AVR line (AFAIK).  Choose a device which has an extra timer (as you have done).

 

Going out of your way to buy a bottom-of-the line component the purpose of which is to satisfy a market for an inexpensive-and-not-overly-feature-packed mcu, and then suggesting it suffers from 'arbitrary design deficiencies' is, I think, missing the point.  Rather like buying a Trabant and then complaining that it doesn't have a turbocharger.  Or power windows.  Or a fuel gauge.

"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

jfiresto wrote:

Well, the one I could not workaround on the tiny13 is that I could find no way to immediately update an output compare register when the timer was in PWM mode.

 

Imagine putting the counter in fast PWM mode and using OCR0A to set the output pulse width. Now try to progressively program OCR0B to wake the MCU every 200 cycles. As far as I can tell, you can not, because the timer has to roll over first before the next wake up time you program takes effect. If you know a way, I am all ears.

 

How accurate do you need your PWM/wake from standby to be?  You could always run the timer in normal mode and toggle the pin in ISRs and deal with the small amount of jitter, or just use the WDT ISR if it has enough granularity.

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

It is unfortunate that you need exactly 200 cycles, as the timer overflow would be very convenient if 256 cycles would be OK.

 

AFAIK all AVR8 timers have your described "double buffered in PWM" behaviour, not just the '13(A).

 

As the discussion started with the internal RC clock, one could use OSCCAL to "tune up" the internal oscillator so that 200 becomes 256?

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. Jul 1, 2015 - 05:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could also use normal mode on the timer, and use OCR0A to toggle OC0A on a compare match.  Use TIM0_COMPA to 'reschedue' OCR0A for the next edge.  In other words, use the ISR to write OCR0A to 0 for the next leading edge on OC0A.  When the ISR fires again, write OCR0A to the correct value for the next trailing edge on OC0A.  Rinse and repeat.

 

In normal mode you would be free to schedule a wakeup with OCR0B/TIM0_COMPB in the 'leap-frog' manner you were looking for.

 

The one caveat would be that the duty cycle available on OC0A would be limited by the interrupt response time for your TIM0_COMPA ISR, as well as that for the wakeup ISR TIM0_COMPB.  You could probably keep that under 30 cycles total (possibly less), so you should be able to maintain glitch-free PWM for any duty cycle between 30/256 and 226/256.

"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

...so you should be able to maintain glitch-free PWM for any duty cycle between 30/256 and 226/256.

Might be somewhat limiting, not being able to go "slow"?

 

I like my idea better.  Given the vagaries of the internal oscillator I'd guess that the 200 is somewhat arbitrary.  200 cycles at 4.8MHz is 41 2/3 microseconds.  208ns per clock tick, nominal.

 

To get the same period with 256 ticks, the tick must be about 163ns or a system clock of 6.144MHz.  The chart in the datasheet indicates that that can be reached:

Now we have no glitches in the PWM and no problems with low and high duty cycles.  The 256 cycles will not jitter, though the servicing might a bit it will "catch up" sometime with reasonable interrupt latency.

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

joeymorin wrote:

That is hardly an 'arbitrary design deficiency'.
I had a hard time finding a short phrase that conveyed the issue with the buffered output compare registers. I decided the least worst was "arbitrary design deficiency", because if you take each word literarly, the issue was exactly that. Unfortunately, someone can read in and add their own meaning to that phrase and every other one I could think of – meaning that was neither the words' nor mine. I could have written a "chance design deficiency", for example, or a "ruinous feature" but I think those are even worse for provoking thoughts that are not on the page.

 

Let me try the long version. On every project, a designer is faced with requirements and constraints; his job is to come up with a design that satisfies them all. The product has requirements that it must satisfy, and the materials a designer chooses to complete his project have constraints the design can not violate. In this case, I discovered a generally helpful constraint of the ATtiny13A's PWM modes, that was not, and that I could not work around. With almost ridiculously simple additions to its design, the ATtiny13 could have let a customer eliminate the constraint, should he need to, so that he can focus on and finish the rest of his design. In my case, the  one and only thing that sunk my use of the part I had chosen, was the decision to always delay output compare register updates while in PMW mode. Had the ATtiny13's designer(s) added a couple timer control register bits to never delay the corresponding OCR0A / OCR0B register update, I would have likely finished the product's development
within a day.

 

The ATtiny13 is missing those two bits: it is deficient with regards to a behavior I needed to use the part. The bits were missing from the part's design.  That is what I meant when I wrote a "design deficiency", a deficiency of the design, something that makes it deficient for a use, and in my case, disqualified the part.

 

As to writing "arbitrary design decision", ooooooooh, I fear this reply is growing too long and becoming metaphysical. Well, from what I have seen, that there seem to be two basic types of engineers, or rather  two ways of doing engineering, and an engineer tends to favor one way or the other. You wrote:

 

Quote:
AVR timer PWM modes are specifically designed to generate glitch-free PWM outputs.  Allowing a change to a compare register to take immediate effect would break that design.  When you place a timer into a given mode (i.e. fast pwm), the >>whole<< timer is placed into that mode, not just one of the compare registers.

 

If you require that a timer express two contradictory functions (glitch-free pwm >>and<< instant compare register update) at the same time, then you're out of luck.  There is no such beast in the AVR line (AFAIK).  Choose a device which has an extra timer (as you have done).

 

Going out of your way to buy a bottom-of-the line component the purpose of which is to satisfy a market for an inexpensive-and-not-overly-feature-packed mcu, and then suggesting it suffers from 'arbitrary design deficiencies' is, I think, missing the point.  Rather like buying a Trabant and then complaining that it doesn't have a turbocharger.  Or power windows.  Or a fuel gauge.

 

When I read that, I think you must be that one type of engineer. I tend to be the other. I understand your points, and often I would agree with them and follow them all. In this case, however, I would not. In fact, were I designing chips for Atmel, I would now find it unconscionable to promote an revised ATtiny13B, or an ATtiny10A, without two more timer control register bits. I believe if you look at the issue as the other type of engineer, you will or would agree. If you presently can not and wish you could, I just wish I were good at explaining and discussing such things.

 

Or posting with this inscrutable forum editor. What is with its paragraph breaks? Sometimes they take and sometimes they don't.

 

- John

Last Edited: Thu. Jul 2, 2015 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rezer wrote:
How accurate do you need your PWM/wake from standby to be?  You could always run the timer in normal mode and toggle the pin in ISRs and deal with the small amount of jitter, or just use the WDT ISR if it has enough granularity.

Oh, I wish that would work. I am also capturing the times a signal's edges wake the MCU, and differencing them to get the signal's transmission rate. The measured rates have to be fairly accurate. The added interrupts would delay the wake-ups and wreck the  measurements.

- John

Last Edited: Thu. Jul 2, 2015 - 02:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
It is unfortunate that you need exactly 200 cycles, as the timer overflow would be very convenient if 256 cycles would be OK.

 

AFAIK all AVR8 timers have your described "double buffered in PWM" behaviour, not just the '13(A).

 

As the discussion started with the internal RC clock, one could use OSCCAL to "tune up" the internal oscillator so that 200 becomes 256?

Now, that is an interesting idea.  Unfortunately, I have two mix at least two different wake up delays. I am not sure how the RC clock would react to jerking the OSCCAL value to produce, say, first a 160 cycle delay then a 200. Can you even model the RC oscillator accurately enough to do that?

- John

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

Now, that is an interesting idea.  Unfortunately, I have two mix at least two different wake up delays. I am not sure how the RC clock would react to jerking the OSCCAL value to produce, say, first a 160 cycle delay then a 200. Can you even model the RC oscillator accurately enough to do that?

You aren't getting it. You don't jerk anything.  You just run the AVR clock at a different frequency.  You calculate the number of cycles or timer ticks or whatever at that frequency.

 

In this particular case, 200 is fairly close to 256 so your design deficiency/decision (no live update of OCR0B) can be side-stepped by not having to do the leapfrog of +200 counts and instead using the overflow interrupt of 256 counts.  I showed the timing arithmetic.

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

joeymorin wrote:

You could also use normal mode on the timer, and use OCR0A to toggle OC0A on a compare match....

 

The one caveat would be that the duty cycle available on OC0A would be limited by the interrupt response time for your TIM0_COMPA ISR, as well as that for the wakeup ISR TIM0_COMPB.  You could probably keep that under 30 cycles total (possibly less), so you should be able to maintain glitch-free PWM for any duty cycle between 30/256 and 226/256.

Another good idea. I also need to output pulse widths starting from 0/256 or 1/256. Using a tiny13 sure imposes a lot of constraints. If it were not for the one with the fast PWM mode, it would have been enough to nail the design. Oh well, it is perfectly acceptable these days to throw ridiculous amounts of hardware at a problem. A tiny24 with a second 16-bit counter was easily enough.

- John

Last Edited: Thu. Jul 2, 2015 - 02:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Now, that is an interesting idea.  Unfortunately, I have two mix at least two different wake up delays. I am not sure how the RC clock would react to jerking the OSCCAL value to produce, say, first a 160 cycle delay then a 200. Can you even model the RC oscillator accurately enough to do that?tho

You aren't getting it. You don't jerk anything.  You just run the AVR clock at a different frequency.  You calculate the number of cycles or timer ticks or whatever at that frequency.

 

In this particular case, 200 is fairly close to 256 so your design deficiency/decision (no live update of OCR0B) can be side-stepped by not having to do the leapfrog of +200 counts and instead using the overflow interrupt of 256 counts.  I showed the timing arithmetic.

Oh, I made that confusing. When I was working on the software, I was calculating everything in terms of a nominal, 4.8 mhz CPU frequency. So, if I wanted, say, a 50 us delay, I did the math with a nominal 240 cycle delay count. I then scaled the nominal number of cycles to whatever frequency the CPU was actually ticking at, and used the actual number of clocks that delayed the MCU for 50 us.

 

If I understand correctly, you propose I set up the 8-bit timer to produce an interrupt every 256 MCU clocks, and then adjust the MCU frequency to achieve close to the desired delay. So, I set OSCCAL to 107, to clock the timer at 6 mhz and wrap around every 43 µs. When the interrupt goes off, I then set OSCCAL to 48, to clock the timer at 3 mhz and wrap around every 85 µs. How will the RC oscillator respond to jerking OSCCAL from 107 to 48 to 107? IIRC, various tiny datasheet say that you should change the RC oscillator frequency by no more than 2% per oscillator cycle. How will the oscillator respond to a 50 or 100% frequency step change?

- John

Last Edited: Thu. Jul 2, 2015 - 03:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see now that in essence you want a "variable delay".  That wasn't stated/clear in the original "problem statement" with the 200 in it...

 

If the two values are indeed 2x, then just count two "ticks" of 43us or whatever to get multiples.

 

Depending on the app, it might be much more efficient to just test/clear/act on the overflow flag (maybe 10 cycles?) instead of ISR servicing of perhaps twice that.

 

 

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

You got me thinking. The MCU doesn't always have to sleep for part or all of a delay. I could you use your scheme to create a fixed, sleeping, timer-woken delay, then extend or intersperse those delays with software spin-loop delays to get the ultimate delays or delays that I need.

 

I had to do some slightly twisted things to get everything to nearly work on a tiny13. If I manage to shovel everyone's suggestions into the code, it is going to look semi-insane.

- John

Last Edited: Thu. Jul 2, 2015 - 03:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well, from what I have seen, that there seem to be two basic types of engineers.
What two types?  You never mentioned it.

 

Apart from the many different things which engineering can be said to be, it is also the art/science/process of accomplishing a task with the resources available ("We need to get this, to fit into the hole for this, using nothing but that.")  If, as a project lead, you conclude that this is impossible, you have two choices.  Acquire better resources, or acquire better engineers.  Ultimately engineering is a process of compromise.

 

I'd imagine the same conversations took place in the planning meetings at Atmel.  While to you, it's just a couple of bits in an I/O register, to a chip designer it translates to silicon real-estate.  "We have X amount of silicon.  The feature set on the table will consume X+Y amount of silicon.  Which features stay in this room, and which ones come off the production line?"  At some point a decision was made that the resources required to implement individual control of compare register buffering was less important than some other feature.  And certainly not all of the reasons behind that decision are likely to have been engineering decisions.  Since Atmel is a business, there will be in addition to the engineering rational behind a decision, many business-related reasons behind every decision (does our customer base, on the whole, want this feature... does the feature overlap with another product line... is there a patent or licence barrier...).  Although the engineering rationale and non-engineering rationale will not always agree, it is unlikely that there were many 'design deficiencies' arbitrarily introduced.

 

If you were in the room during the AVR planning meetings at Atmel, you could have made an argument for separate control bits.  Perhaps someone made that argument and it didn't make the cut.  Perhaps no-one foresaw the need.   You could make that argument now if you wish.  If you place an order for 5 million units, I suspect Atmel will be happy to deliver whatever custom feature set you want.  If, however, like most of us you must work with what you have, the question is moot.

 

Quote:
When I read that, I think you must be that one type of engineer. I tend to be the other.
Again, still don't know what two types of engineer you're getting at.  I'm the type that very much enjoys a challenge ("We need to get this..."  "I had no idea you could do such a thing!"), but who won't bang his head against a wall when a job needs to be done and it's clear that the wall won't come down.  I go around the wall.

 

I'm also the type of engineer who tries not to get trapped by my own perceptions of a problem.  It is always... always... better to return to first principles.  State the objective, not the obstacle to an implementation of that objective.  It should be clear to you after reading many of the posts in this thread that there are other approaches which you hadn't considered.  You wrote:

Quote:
If I manage to shovel everyone's suggestions into the code, it is going to look semi-insane.
I wonder why that matters?

 

When faced with a 'design deficiency' in your available resources, the conventional approach is to supplement your resources with those which do not suffer from that 'design deficiency'.  The unconventional approach is to make that deficiency irrelevant.  To me that is the most rewarding kind of process, because it satisfies both of the above engineering 'types' to which you alluded.  You get to stretch and grow by tackling a challenge and crafting an unusual solution to problem, and you 'go around the wall'.

 

Quote:
Or posting with this inscrutable forum editor. What is with its paragraph breaks? Sometimes they take and sometimes they don't.
Yeah.  Now this new website is not a good example of Atmel's ability to make sound engineering decisions sad... I feel your pain...

 

 

"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 guess that we are at point where you need to tell what you are doing, or at least a logic flow of the control of the delays, and accepted jitter on time and IO's. and what needs to happen at idle :)

 

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

joeymorin wrote:

 

Quote:

Well, from what I have seen, that there seem to be two basic types of engineers.

What two types?  You never mentioned it.

I didn't go there, because, as I wrote, my post was getting too long. It would have gotten much longer, and I was and am not sure if I can clearly explain the two.

 

Quote:
Although the engineering rationale and non-engineering rationale will not always agree, it is unlikely that there were many 'design deficiencies' arbitrarily introduced.
The decision was arbitrary in the sense that had a different engineer or engineering group down the design, they might have included two more bits that would have made the design sufficient for my purposes. The design depends on the designer(s) and their circumstances and temperament – I don't think it says anything about their competence, if that was a concern.

 

Quote:
You could make that argument now if you wish.  If you place an order for 5 million units, I suspect Atmel will be happy to deliver whatever custom feature set you want.  If, however, like most of us you must work with what you have, the question is moot.
I could, but it is easier to work with what is available. Isn't that the point of writing portable code?

 

Quote:
Quote:

When I read that, I think you must be that one type of engineer. I tend to be the other.

Again, still don't know what two types of engineer you're getting at.  I'm the type that very much enjoys a challenge ("We need to get this..."  "I had no idea you could do such a thing!"), but who won't bang his head against a wall when a job needs to be done and it's clear that the wall won't come down.  I go around the wall.

 

It really does not matter and it probably not worthwhile explaining, assuming I am able to. I expect you are a fine engineer; I have my doubts that I am a competent explainer.

 

Quote:

Quote:

If I manage to shovel everyone's suggestions into the code, it is going to look semi-insane.

I wonder why that matters?

Because at some point, contorting a design, to work with what you have before you, becomes counterproductive.

- John

Last Edited: Fri. Jul 3, 2015 - 02:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

I guess that we are at point where you need to tell what you are doing, or at least a logic flow of the control of the delays, and accepted jitter on time and IO's. and what needs to happen at idle :)

That could take a while. The design came together and is working fine after I moved to an ATtiny24.

 

This is a hobby project to learn about things I could not be paid for. If you guys have more important threads to answer, please do.

 

In case you are curious, the project is an RS-232 powered, analog, CPU load meter. I created one about 30 years ago for my then personal computer, a PDP-11. I am revisiting the project to learn how things have changed. It was an amusing hack back then, and it still an amusing hack today.

 

There was a bit of a craze a few years ago, where people used Arduino boards to show CPU, memory and network load on analog panel meters. I could have simply bought a board and downloaded one those designs. Or, I could have thrown together a similar USB powered design with a USB MCU and standard library.  I thought using RS-232 and a bottom of the barrel MCU would be much more challenging, instructive and fun, and it was.

 

If you guys are interested, I could try to write up the project. I could post it in installments and you guys can take it to pieces. :) Assuming I can find time, and can make my peace with the forum software.

- John

Last Edited: Fri. Jul 3, 2015 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jfiresto wrote:
I could, but it is easier to work with what is available.
It feels like we're going in circles smiley:

joeymorin wrote:
Apart from the many different things which engineering can be said to be, it is also the art/science/process of accomplishing a task with the resources available

 

 

jfiresto wrote:
I have my doubts that I am a competent explainer.
I don't know, you're doing fine so far.  It'd be a shame if we let misunderstood intentions to get in the way.

 

jfiresto wrote:
Because at some point, contorting a design, to work with what you have before you, becomes counterproductive.
Agreed.  At some point.  We each decide where that point is.  However, since:
jfiresto wrote:
I thought using RS-232 and a bottom of the barrel MCU would be much more challenging, instructive and fun, and it was.
... well, I guess "We each decide where that point is".  For a hobby project certainly there is no 'best' approach.  Do what makes you happy.  But in the end, if the requirements are met, what does it matter?  This site and indeed the web in general is filled with may excellent (and, I concede, many not-so-excellent) examples of someone trying to fit a square peg into a round hole.  Just to see if it can be done.  For the challenge of it.  Search for >>anything<< by AtomicZombie, for example.  The thrill he gets from generating full-frame colour VGA video and stereo audio from an ATtiny85 must surely overrule any notion that "at some point, contorting a design, to work with what you have before you, becomes counterproductive."

jfiresto wrote:
If you guys are interested, I could try to write up the project. I could post it in installments and you guys can take it to pieces. :)
That's your call.  I suspect that, on the whole, it would be well-received.  You will get positive feedback, questions, helpful suggestions, some thoughtful input, and some thoughtless input.  Try not to take any of it personally smiley
jfiresto wrote:
Assuming I can find time, and can make my peace with the forum software.
There, we can only commiserate!

"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]

 

Last Edited: Fri. Jul 3, 2015 - 05:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to use 4.8MHz for your tiny13, you need to read the factory 4.8 calibration via your programmer. Then load this value into OSCCAL in software.

 

Can the factory cal value for 4.8MHz setting be read in software? If not, why not--that would be ridiculous. I want to read & send that value into OSCCAL sometime during powerup.  This can't be done with the programmer, since the same program is being "burned" into hundreds of boards.   (The fuse is already set for 4.8MHz operation, during the flashing of the program). 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Modern AVRs can read the Signature Row at runtime via the SPMCSR register.   Normally by setting bit#5.

The ATtiny13A datasheet does not document bit#5.   Try it and see.

 

For example,  the ATtiny2313 can not read the Signature but the ATtiny2313A can.

 

Is it really too difficult to read the Signature Row with an extrnal programmer and store the values in EEPROM?

 

David.

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

RTFM

 

It's clear that it don't 

 

But who care the chip is +-10% (fixed 3V 25C) so if you need anything better you need to calibrate.

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

Is it really too difficult to read the Signature Row with an extrnal programmer and store the values in EEPROM?

 

Yes, it is an issue, since they use a one button programmer (PROG) to flash in the code.

There is no way to read anything (I think there is an led to show if the programmer aborted), and any manual process would certainly be error prone.  Their folks want to press the button & spread solder paste.

 

Why, when 4.8Mhz is selected, is the corresponding factory cal value not used by the micro (why would it keep using the 9.6 factory cal value??)...this makes such little sense I wonder if that is what is actually happening.

 

Thanks for the tip on the SPMCSR register...also, now I see from other posted threads that the signature area has some hidden gems (seems like area 51)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
... There is no way to read anything (I think there is an led to show if the programmer aborted), and any manual process would certainly be error prone.  Their folks want to press the button & spread solder paste....
By any chance, could they program the device twice, first at 9.6 and then at 4.8 mhz?

- John

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

It costs you nothing to see if bit#5 of SPMCSR works but is just undocumented.

 

Since the Factory default is the calibrated 9.6MHz RC,  why not just use the prescaler to get 4.8MHz?

In practice,  the Factory Calibration is fairly accurate.   It is just that the accuracy is only specified for +-10% (or whatever)

 

If you need / want better accuracy,  you would have to calibrate the 9.6MHz RC or the 4.8MHz RC anyway.

 

The real mystery is: Why use a Tiny13A when the Tiny25 is superior in every way?

 

David.

 

 

Last Edited: Sat. Dec 24, 2016 - 09:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A tiny25 use about 50% more power for the same job!

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

Go on.   The tiny13A and tiny25 seem to have similar Active, Idle and Power-Down currents.

 

The tiny25 has certainly got better peripherals and you can read the Signature Row at runtime.   Which seems to be the feature that the OP finds important.

 

David.

Pages