Nabble - PIC - [AVR]

Start-up / Wake-up / Reset timings on ATTiny13A

2009-09-10T06:38:00Z

Hello,

I have hard times to understand what the datasheet is trying to interpret in
timings for reset from different state of the AVR ATTiny13A.

Particularly I am interested when the internal RC oscillator is used for
clocking the chip. As I understood I can set up different delay when comes
up from powered down mode. It ads additional 14 CK to the 6 CK normal
start-up time + can set further 4ms or 64ms.

What is not clear when is this delay added to the normal start-up time? Only
at POR, or also when waking up from power down sleep mode? Also could not
figure out from the datasheet the timing of waking up the MCU from idle
mode?

In addition to this grey cloud I could not find information of this 6 CK
startup time? I guess ones the oscillator is up and stable then it counts to
6 and this is this this 6 CK startup time, but how long does it take to the
oscillator circuit to be started up into a stable condition when this 6 CK
starts counting? Especially regarding this to different thermal and power
supply conditions?

If you could point me to a link or which documentation shall I read on this
subject, it would be much appreciated.

Thanks,
Tamas
--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

problems with division

2009-05-07T09:25:24Z

I have this simple program:

int fb;
int fc;
signed long int Rs;

while (1)
{
fb = 400;
fc = 2;
Rs = fb/fc;
delay (20);
UDR = 0xf0;
while (!(UCSRA & (1<<UDRE)));
UDR = Rs;
while (!(UCSRA & (1<<UDRE)));
Rs <<= 8;
UDR = Rs;
}

and the port receives:
0xf0
240 136 000
240 200 000
240 136 000
240 200 000
240 200 000
240 200 000

I don´t know why 136 appears all the time. The result should be 200. I write this program because I´m not able to understand whats happening with divisions.

Thank you in advance

Re: divide 48bit number by (constant) 125 ?

2009-04-30T11:45:49Z

On Wed, Apr 29, 2009 at 7:06 PM, William "Chops" Westfield
<westfw@...> wrote:

>
> On Apr 29, 2009, at 7:56 AM, M. Adam Davis wrote:
>
>> If you decide you only need 1% accuracy, then you only need the first
>> two factors (128, 8192), and if you want 0.001% accuracy you need 6
>> factors (128, 8192, 16384, 262144, 2097152, 8388608).
>
> To get the accuracy you talk about, do you need to have "perfect"
> fractions (1/128 * input) or does truncation suffice? (Rounding?) I
> think the last time I actually tried to implement one of these "sum of
> power-of-2 fractions" I ended up getting really lousy results, that I
> attributed (rightly or wrongly) to the bits shifted off the right
> side...

That's correct, this is still subject to rounding error.

If you want to include *all* the bits in the calculation, you reverse
the process:
Original right shifts: 7, 13, 14, 18
Reverse left shifts: 11, 5, 4, 0 then shift right by 18

This takes a maximum of 2x the number of bits in the original - in
other words, it could take up to 48+48 bits to process a 48 bit
number, if you wanted to get as much accuracy as possible.

output = (input << 11 + input << 5 + input << 4 + input) >> 18;

I don't know if the code generator mentioned actually computes the
accuracy based on all the rounding errors, or just the error from the
"ideal" equation where the intermediate values are computed using
floating point (ie, takes all bits into account). But it must not,
because the rounding errors can be truly nasty:

Take 12500/125, for instance. The ideal result is 100. The binary
division approximate, using floating point rather than integers, is
99.99275. Using all the bits (as in the left shift then right shift
above) you get 99 - which is the integer equivalent of the floating
point version of the binary division.

This is 1% off.

The left shift version, however, results in 98, with 4 factors (128,
8192, 16384, 262144). The right shift version, by preserving all the
bits, gets at least as close as one digit (and that can be improved by
rounding - look at the 18'th bit before it's shifted off and add 1 to
the result if it's high). The original right shift version can be off
by more than one integer. One integer may be a lot or a little,
depending on your range and usage.

If you use this repeatedly, as in infinite impules response filters,
you're going to have bad problems.

Ideally you'd use all the factors down to the 48th bit:
7, 13, 14, 18, 21, 24, 25, 27, 28, 29, 31, 34, 36, 37, 38, 39, 43, 44,
46 (left shifts)

But even then, you're using integer intemediate values, so you'd still
have rounding errors, just not as significant.

However, it's still faster than 'real' division, and yields good
results for most cases.

-Adam

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

RE: divide 48bit number by (constant) 125 ?

2009-04-30T00:43:41Z

> -----Original Message-----
> From: piclist-bounces@... [mailto:piclist-bounces@...] On
Behalf
> Of Tamas Rudnai
> Sent: 29 April 2009 19:03
> To: Microcontroller discussion list - Public.
> Subject: Re: [AVR] divide 48bit number by (constant) 125 ?
>
> That's a very nice explanation. Exactly these kind of things what a
high
> level language compiler supposed to do, however. It is actually really
sad
> if avr-gcc does not support microcontroller specific optimizations and
> storage classes.
>

It does as much as possible, but it can't arbitrarily convert integer
multiplies/divides to shifts and adds unless the multiplier/divider can
be perfectly expressed in a small, finite number of terms. If not there
will always be some accuracy trade-off against the number of terms used.

Also there is often a danger of impaired accuracy when the operands
magnitudes are small, e.g. in this case an input of 126, 126 or 127 will
give a valid result of 1 when using an integer division. When using
shifts and additions, the result will be (incorrectly) zero for these
inputs. This may well be acceptable, but how would a compiler know
this?

IMO this is exactly the kind of optimisation is where human intervention
should be required since the compiler doesn't have enough information to
make a valid decision.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T16:06:11Z

On Apr 29, 2009, at 7:56 AM, M. Adam Davis wrote:

> If you decide you only need 1% accuracy, then you only need the first
> two factors (128, 8192), and if you want 0.001% accuracy you need 6
> factors (128, 8192, 16384, 262144, 2097152, 8388608).

To get the accuracy you talk about, do you need to have "perfect"
fractions (1/128 * input) or does truncation suffice? (Rounding?) I
think the last time I actually tried to implement one of these "sum of
power-of-2 fractions" I ended up getting really lousy results, that I
attributed (rightly or wrongly) to the bits shifted off the right
side...

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T15:07:14Z

On Apr 29, 2009, at 7:56 AM, M. Adam Davis wrote:

> Slightly faster (since a one bit shift takes a full instruction
> cycle):
> temp = input;
> temp = temp >> 7;
> result += temp;
> temp = temp >> 6; // temp = input >> 13
> result += temp;
> temp = temp >> 1; // temp = input >> 14
> result += temp;
> temp = temp >> 4; // temp = input >> 18
> result += temp;

This is especially interesting, because after all the original "ticks"
input BEFORE the multiply is already "input>>7" (it becomes a
multiply by "128/125", which is just fine...)

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T13:34:01Z

----- Original Message -----
From: "Dave Tweed" <pic@...>
To: <piclist@...>
Sent: Wednesday, April 29, 2009 7:19 AM
Subject: Re: [AVR] divide 48bit number by (constant) 125 ?

> William "Chops" Westfield wrote:
>> I want to calculate:
>>
>> (ticks * <microsecondsPerTick>) / 1000
>>
>> to return the number of milliseconds elapsed based on a count
>> maintained by a timer ISR. microsecondsPerTick is a nice constant
>> number like 1024 or 2048, so the multiplication becomes a shift, and
>> factoring out twos I get:
>>
>> (ticks * (microsecondsPerTick/8)) / 125
>>
>> "ticks" is at least 40 bits, however, and the multiplication MUST NOT
>> OVERFLOW (been there, trying to fix that!), so I'm looking at at at
>> least a 48bit intermediate value.
>
> Do you have access to the ISR? I would be inclined to do the following,
> rather than (or in addition to) simply counting the raw ticks:
>
> /* microseconds can be a 16-bit integer */
> microseconds += microsecondsPerTick;
> while (microseconds >= 1000) {
> microseconds -= 1000;
> ++milliseconds;
> }
>
> -- Dave Tweed
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

You can use a trick similar to a binary to decimal
conversion algorithm to convert your value.

A short description of the algorithm:

1: compute ticks * microseconds per tick
2: convert to a mixed radix representation where the low-order 3 (decimal)
digits of the number are kept in a separate variable from the rest of the
number.
3: toss out the low-order 3 digits, keeping the number containing the rest
of the value.

A longer description in pseudo-C

uint16 in_hi;
uint16 in_mid;
uint16 in_low;

uint16 out_hi
uint16 out_mid
uint16 out_low
uint16 out_toss;

out_hi = out_mid = out_low = out_toss = 0;
for (i=0; i < 48; ++i)
{
// double the output value, taking
// ...into account its mixed radix
// ...representation
out_toss <<= 1;
carry = 0
if (out_toss > 1000)
{
out_toss -= 1000;
carry = 1;
}
shift [out_hi:out_mid:out_low] left one bit
shifting 'carry' into lsbit

// add in the next bit of the input value
// to the accumulated value. this is
// simplified by the fact that we know
// the low-order bit is a zero (after
// the doubling above)
shift [in_hi:in_mid:in_low] left one bit;
if (the bit shifted out is 1)
out_toss |= 1;
}

// the resulting millisecond count is in
// [out_hi:out_mid:out_low]

This could be very efficiently implemented in PIC assembly code, and I
imagine it wouldn't be too much different for an AVR. It is a little ugly in
true C because of the multiword shifts.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T11:02:50Z

That's a very nice explanation. Exactly these kind of things what a high
level language compiler supposed to do, however. It is actually really sad
if avr-gcc does not support microcontroller specific optimizations and
storage classes.

Tamas

On Wed, Apr 29, 2009 at 3:56 PM, M. Adam Davis <stienman@...> wrote:

> Just in case the below wasn't explicit enough, the info below would be
> converted into C as follows:
>
> result = input / 125; // Original
> result = input / 128 + input / 8192 + input / 16384 + input / 262144;
> // To binary equivalant ( with 0.007% error)
> result = input >> 7 + input >> 13 + input >> 14 + input >> 18; //
> Using shifts rather than division (faster, same result)
>
> Slightly faster (since a one bit shift takes a full instruction cycle):
> temp = input;
> temp = temp >> 7;
> result += temp;
> temp = temp >> 6; // temp = input >> 13
> result += temp;
> temp = temp >> 1; // temp = input >> 14
> result += temp;
> temp = temp >> 4; // temp = input >> 18
> result += temp;
>
> This can be optimized further, but it only requires a total of 18
> shifts (whereas the previous version might have actually generated 52
> shifts) and a similar number of additions. Across a 48 bit number on
> an 8 bit processor this adds up...
>
> If you decide you only need 1% accuracy, then you only need the first
> two factors (128, 8192), and if you want 0.001% accuracy you need 6
> factors (128, 8192, 16384, 262144, 2097152, 8388608).
>
> -Adam
>
> On Wed, Apr 29, 2009 at 10:38 AM, M. Adam Davis <stienman@...>
> wrote:
> > This should give you what you need - you can turn a division into a
> > sum of several binary divisions:
> >
> > http://piclist.com/techref/method/math/divconst.htm
> >
> > There is an online code generator here, though it only goes up to 32
> > bits, but you probably don't care about the code generated, just the
> > binary division factors:
> > http://www.piclist.com/techref/piclist/codegen/constdivmul.htm
> >
> > 1/125 = 0.008, which happens to be very close to:
> >
> > ; ALGORITHM:
> > ; Clear accumulator
> > ; Add input / 128 to accumulator
> > ; Add input / 8192 to accumulator
> > ; Add input / 16384 to accumulator
> > ; Add input / 262144 to accumulator
> > ; Move accumulator to result
> > ;
> > ; Approximated constant: 0.00799942, Error: 0.00724792 %
> >
> >
> http://www.piclist.com/cgi-bin/constdivmul.exe?Acc=ACC&Bits=32&endian=little&Const=.008&ConstErr=0.05&Temp=TEMP&cpu=pic16
> >
> > You can change the "ConstErr=0.05" to a finer value to reduce the error
> further.
> >
> > -Adam
> >
> > On Wed, Apr 29, 2009 at 3:14 AM, William "Chops" Westfield
> > <westfw@...> wrote:
> >> I want to calculate:
> >>
> >> (ticks * <microsecondsPerTick>) / 1000
> >>
> >> to return the number of milliseconds elapsed based on a count
> >> maintained by a timer ISR. microsecondsPerTick is a nice constant
> >> number like 1024 or 2048, so the multiplication becomes a shift, and
> >> factoring out twos I get:
> >>
> >> (ticks * (microsecondsPerTick/8)) / 125
> >>
> >> "ticks" is at least 40 bits, however, and the multiplication MUST NOT
> >> OVERFLOW (been there, trying to fix that!), so I'm looking at at at
> >> least a 48bit intermediate value.
> >>
> >> It would be nice if the code were in C. Avr gcc, in particular.
> >> There are 8, 16, 32, and even 64 bit math functions available, but of
> >> course they're *C*, so they don't let you actually do mixed-sized
> >> math, nor are they likely to optimized
> >>
> >> The code is not particularly time critical, but it would be nice if it
> >> were as small and fast as possible (using 64bit long longs seems
> >> excessive.)
> >>
> >> Thoughts? Any pointers to mixed-size C math functions in general? In
> >> principle, I think I understand how to do this, but ... Is there a
> >> way to take advantage of the constant? Of 125 in particular? (lots
> >> of one bits there...)
> >>
> >> Thanks
> >> Bill W
> >>
> >> --
> >> http://www.piclist.com PIC/SX FAQ & list archive
> >> View/change your membership options at
> >> http://mailman.mit.edu/mailman/listinfo/piclist
> >>
> >
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T10:35:07Z

On Apr 29, 2009, at 4:19 AM, Dave Tweed wrote:

> Do you have access to the ISR? I would be inclined to do the
> following,
> rather than (or in addition to) simply counting the raw ticks:
>
> /* microseconds can be a 16-bit integer */
> microseconds += microsecondsPerTick;
> while (microseconds >= 1000) {
> microseconds -= 1000;
> ++milliseconds;
> }

This is in fact the currently proposed solution (plus or minus
optimization), although some would rather the ISR were shorter.

(avr-gcc will "optimize" that while loop to a divide, BTW. ouch! (and
Grr!)
http://www.avrfreaks.net/index.php?
name=PNphpBB2&file=viewtopic&t=78209 )

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T08:32:23Z

why not find out where ticks is incremented, and add another variable
that increments every 1K times ticks gets incremented, and use that
instead of ticks? Or depending on the accuracy you want, change the
formula to msecs = (ticks>>17)*<microsecondsPerTick>*131;

Tony

Marechiare wrote:

>> I want to calculate:
>>
>> (ticks * <microsecondsPerTick>) / 1000
>>
>> to return the number of milliseconds elapsed based on a
>> count maintained by a timer ISR. microsecondsPerTick
>> is a nice constant number like 1024 or 2048, so the
>> multiplication becomes a shift
>>
>
> So, what you need is just to divide by 1000 after the shifting.
> Why not convert it to decimal, discard last 3 digits, and then convert
> it back to binary?
>
>
>
>> The code is not particularly time critical
>>
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T08:06:47Z

> I want to calculate:
>
> (ticks * <microsecondsPerTick>) / 1000
>
> to return the number of milliseconds elapsed based on a
> count maintained by a timer ISR. microsecondsPerTick
> is a nice constant number like 1024 or 2048, so the
> multiplication becomes a shift

So, what you need is just to divide by 1000 after the shifting.
Why not convert it to decimal, discard last 3 digits, and then convert
it back to binary?

> The code is not particularly time critical

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T07:56:10Z

Just in case the below wasn't explicit enough, the info below would be
converted into C as follows:

result = input / 125; // Original
result = input / 128 + input / 8192 + input / 16384 + input / 262144;
// To binary equivalant ( with 0.007% error)
result = input >> 7 + input >> 13 + input >> 14 + input >> 18; //
Using shifts rather than division (faster, same result)

Slightly faster (since a one bit shift takes a full instruction cycle):
temp = input;
temp = temp >> 7;
result += temp;
temp = temp >> 6; // temp = input >> 13
result += temp;
temp = temp >> 1; // temp = input >> 14
result += temp;
temp = temp >> 4; // temp = input >> 18
result += temp;

This can be optimized further, but it only requires a total of 18
shifts (whereas the previous version might have actually generated 52
shifts) and a similar number of additions. Across a 48 bit number on
an 8 bit processor this adds up...

If you decide you only need 1% accuracy, then you only need the first
two factors (128, 8192), and if you want 0.001% accuracy you need 6
factors (128, 8192, 16384, 262144, 2097152, 8388608).

-Adam

On Wed, Apr 29, 2009 at 10:38 AM, M. Adam Davis <stienman@...> wrote:

> This should give you what you need - you can turn a division into a
> sum of several binary divisions:
>
> http://piclist.com/techref/method/math/divconst.htm
>
> There is an online code generator here, though it only goes up to 32
> bits, but you probably don't care about the code generated, just the
> binary division factors:
> http://www.piclist.com/techref/piclist/codegen/constdivmul.htm
>
> 1/125 = 0.008, which happens to be very close to:
>
> ; ALGORITHM:
> ; Clear accumulator
> ; Add input / 128 to accumulator
> ; Add input / 8192 to accumulator
> ; Add input / 16384 to accumulator
> ; Add input / 262144 to accumulator
> ; Move accumulator to result
> ;
> ; Approximated constant: 0.00799942, Error: 0.00724792 %
>
> http://www.piclist.com/cgi-bin/constdivmul.exe?Acc=ACC&Bits=32&endian=little&Const=.008&ConstErr=0.05&Temp=TEMP&cpu=pic16
>
> You can change the "ConstErr=0.05" to a finer value to reduce the error further.
>
> -Adam
>
> On Wed, Apr 29, 2009 at 3:14 AM, William "Chops" Westfield
> <westfw@...> wrote:
>> I want to calculate:
>>
>> (ticks * <microsecondsPerTick>) / 1000
>>
>> to return the number of milliseconds elapsed based on a count
>> maintained by a timer ISR. microsecondsPerTick is a nice constant
>> number like 1024 or 2048, so the multiplication becomes a shift, and
>> factoring out twos I get:
>>
>> (ticks * (microsecondsPerTick/8)) / 125
>>
>> "ticks" is at least 40 bits, however, and the multiplication MUST NOT
>> OVERFLOW (been there, trying to fix that!), so I'm looking at at at
>> least a 48bit intermediate value.
>>
>> It would be nice if the code were in C. Avr gcc, in particular.
>> There are 8, 16, 32, and even 64 bit math functions available, but of
>> course they're *C*, so they don't let you actually do mixed-sized
>> math, nor are they likely to optimized
>>
>> The code is not particularly time critical, but it would be nice if it
>> were as small and fast as possible (using 64bit long longs seems
>> excessive.)
>>
>> Thoughts? Any pointers to mixed-size C math functions in general? In
>> principle, I think I understand how to do this, but ... Is there a
>> way to take advantage of the constant? Of 125 in particular? (lots
>> of one bits there...)
>>
>> Thanks
>> Bill W
>>
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T07:38:06Z

This should give you what you need - you can turn a division into a
sum of several binary divisions:

http://piclist.com/techref/method/math/divconst.htm

There is an online code generator here, though it only goes up to 32
bits, but you probably don't care about the code generated, just the
binary division factors:
http://www.piclist.com/techref/piclist/codegen/constdivmul.htm

1/125 = 0.008, which happens to be very close to:

; ALGORITHM:
; Clear accumulator
; Add input / 128 to accumulator
; Add input / 8192 to accumulator
; Add input / 16384 to accumulator
; Add input / 262144 to accumulator
; Move accumulator to result
;
; Approximated constant: 0.00799942, Error: 0.00724792 %

http://www.piclist.com/cgi-bin/constdivmul.exe?Acc=ACC&Bits=32&endian=little&Const=.008&ConstErr=0.05&Temp=TEMP&cpu=pic16

You can change the "ConstErr=0.05" to a finer value to reduce the error further.

-Adam

On Wed, Apr 29, 2009 at 3:14 AM, William "Chops" Westfield
<westfw@...> wrote:

> I want to calculate:
>
> (ticks * <microsecondsPerTick>) / 1000
>
> to return the number of milliseconds elapsed based on a count
> maintained by a timer ISR. microsecondsPerTick is a nice constant
> number like 1024 or 2048, so the multiplication becomes a shift, and
> factoring out twos I get:
>
> (ticks * (microsecondsPerTick/8)) / 125
>
> "ticks" is at least 40 bits, however, and the multiplication MUST NOT
> OVERFLOW (been there, trying to fix that!), so I'm looking at at at
> least a 48bit intermediate value.
>
> It would be nice if the code were in C. Avr gcc, in particular.
> There are 8, 16, 32, and even 64 bit math functions available, but of
> course they're *C*, so they don't let you actually do mixed-sized
> math, nor are they likely to optimized
>
> The code is not particularly time critical, but it would be nice if it
> were as small and fast as possible (using 64bit long longs seems
> excessive.)
>
> Thoughts? Any pointers to mixed-size C math functions in general? In
> principle, I think I understand how to do this, but ... Is there a
> way to take advantage of the constant? Of 125 in particular? (lots
> of one bits there...)
>
> Thanks
> Bill W
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T04:19:50Z

William "Chops" Westfield wrote:

Do you have access to the ISR? I would be inclined to do the following,
rather than (or in addition to) simply counting the raw ticks:

/* microseconds can be a 16-bit integer */
microseconds += microsecondsPerTick;
while (microseconds >= 1000) {
microseconds -= 1000;
++milliseconds;
}

-- Dave Tweed
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T04:07:49Z

48 bits by 125

I would use a grade school divide and nybble away at the 48 bit number
something like

unsigned char i48[5]; // 48 bit number
unsigned char r48[5]; // Result

unsigned char m,r; // most , least and result
signed char l; // signed so some compilers can check better for
negative than > 128

// init the most and least significant numbers
m = i48[0];
l = i48[1];

for (char i = 2; i != 5; i++)
{

for (char j = 8; i != 0; i--) // should be optimizede to a repeat .. until
{
r <<= 1; // No need to init all the bits will be shifted out
if (m > 250) // 125 shifted up by 1
{
m -= 250;
r += 1;
}

// shift m:l left
m <<= 1;
if (l < 0) m += 1;
l <<= 1;
}

r48[i-2] = r;
l = i48[i+1];
}

// Run out the last byte

for (char j = 8; i != 0; i--) // should be optimizede to a repeat .. until
{
r48[4] <<= 1; // No need to init all the bits will be shifted out
if (m > 250) // 125 shifted up by 1
{
m -= 250;
r48[4] += 1;
}
m <<= 1;
}

This shouldn't generate much code all of the operations are byte sized.
Using 18037 support the shifts and tests should be able to be optimized to
a single 8 bit subtract and three shifts.

The over all result probably is out by a factor of two for the 125 to 250
doubling.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T02:48:09Z

Is the 'microsecondsPerTick' known during the compile time? How long would
it do that with float? (which is 32 bit only so may affects the accuracy).

Tamas

On Wed, Apr 29, 2009 at 8:14 AM, William "Chops" Westfield
<westfw@...>wrote:

--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T01:41:32Z

On Wed, 29 Apr 2009, William "Chops" Westfield wrote:

> Thoughts? Any pointers to mixed-size C math functions in general? In
> principle, I think I understand how to do this, but ... Is there a
> way to take advantage of the constant? Of 125 in particular? (lots
> of one bits there...)

Are you able to do this with 5 16 bit by 8 bit divisons?

Regards
Sergio Masci
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T01:09:00Z

>How much error can you stand?
>125 is pretty close to 128. :-)

Well, from what he is saying, not much error.

But I was wondering - just thinking outside the box here - if it is possible
to change the clock frequency of the micro enough to make the 125 become 128
...

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: divide 48bit number by (constant) 125 ?

2009-04-29T00:44:20Z

How much error can you stand?
125 is pretty close to 128. :-)

-----Original Message-----

>From: "William \"Chops\" Westfield" <westfw@...>
>Sent: Apr 29, 2009 3:14 AM
>To: "Microcontroller discussion list - Public." <piclist@...>
>Subject: [AVR] divide 48bit number by (constant) 125 ?
>
>I want to calculate:
>
> (ticks * <microsecondsPerTick>) / 1000
>
>to return the number of milliseconds elapsed based on a count
>maintained by a timer ISR. microsecondsPerTick is a nice constant
>number like 1024 or 2048, so the multiplication becomes a shift, and
>factoring out twos I get:
>
> (ticks * (microsecondsPerTick/8)) / 125
>
>"ticks" is at least 40 bits, however, and the multiplication MUST NOT
>OVERFLOW (been there, trying to fix that!), so I'm looking at at at
>least a 48bit intermediate value.
>
>It would be nice if the code were in C. Avr gcc, in particular.
>There are 8, 16, 32, and even 64 bit math functions available, but of
>course they're *C*, so they don't let you actually do mixed-sized
>math, nor are they likely to optimized
>
>The code is not particularly time critical, but it would be nice if it
>were as small and fast as possible (using 64bit long longs seems
>excessive.)
>
>Thoughts? Any pointers to mixed-size C math functions in general? In
>principle, I think I understand how to do this, but ... Is there a
>way to take advantage of the constant? Of 125 in particular? (lots
>of one bits there...)
>
>Thanks
>Bill W
>
>--
>http://www.piclist.com PIC/SX FAQ & list archive
>View/change your membership options at
>http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

divide 48bit number by (constant) 125 ?

2009-04-29T00:14:52Z

I want to calculate:

(ticks * <microsecondsPerTick>) / 1000

to return the number of milliseconds elapsed based on a count
maintained by a timer ISR. microsecondsPerTick is a nice constant
number like 1024 or 2048, so the multiplication becomes a shift, and
factoring out twos I get:

(ticks * (microsecondsPerTick/8)) / 125

"ticks" is at least 40 bits, however, and the multiplication MUST NOT
OVERFLOW (been there, trying to fix that!), so I'm looking at at at
least a 48bit intermediate value.

It would be nice if the code were in C. Avr gcc, in particular.
There are 8, 16, 32, and even 64 bit math functions available, but of
course they're *C*, so they don't let you actually do mixed-sized
math, nor are they likely to optimized

The code is not particularly time critical, but it would be nice if it
were as small and fast as possible (using 64bit long longs seems
excessive.)

Thoughts? Any pointers to mixed-size C math functions in general? In
principle, I think I understand how to do this, but ... Is there a
way to take advantage of the constant? Of 125 in particular? (lots
of one bits there...)

Thanks
Bill W

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: Debugging / Simulating

2008-09-13T08:50:12Z

I don't know anything about Linux.

----- Original Message -----
From: "Tamas Rudnai" <tamas.rudnai@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Thursday, September 11, 2008 6:29 AM
Subject: [AVR] Debugging / Simulating

> Hello There,
>
> I am just studying the GNU toolchain on Linux, how could I use it for real
> purposes. My current problem is that there is no symbolic information on
> IO
> registers, like PORTB. So if I say "p/x PORTB" it does not work. I can say
> "x/x 0x800038" but this is so ugly - and of course if I use ddd then it
> looks even worse in the data view window.
>
> Couple of questoins:
>
> 1. Any way to get symbols for these things?
>
> 2. Is there any place where I could download avr-insight compiled for i386
> /
> P4 etc (using ubuntu)
>
> 3. ...If not is there any place which describes for a dummy like me how to
> get that compiled, how to merge insight with avr-gdb etc?
>
> Thanks
> Tamas
>
>
> --
> Rudonix DoubleSaver
> http://www.rudonix.com
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Debugging / Simulating

2008-09-11T03:29:35Z

Hello There,

I am just studying the GNU toolchain on Linux, how could I use it for real
purposes. My current problem is that there is no symbolic information on IO
registers, like PORTB. So if I say "p/x PORTB" it does not work. I can say
"x/x 0x800038" but this is so ugly - and of course if I use ddd then it
looks even worse in the data view window.

Couple of questoins:

1. Any way to get symbols for these things?

2. Is there any place where I could download avr-insight compiled for i386 /
P4 etc (using ubuntu)

3. ...If not is there any place which describes for a dummy like me how to
get that compiled, how to merge insight with avr-gdb etc?

Thanks
Tamas

--
Rudonix DoubleSaver
http://www.rudonix.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: Programming specification, where?

2008-08-14T15:50:41Z

On Aug 7, 2008, at 3:42 AM, Shawn Tan wrote:

>> is there a binary level specification for the opcodes of AVRs? I
>> have the assembly programming specification and I hope to find it
>> there.
>
> Oh, so what you were looking for is the "instruction set" of the AVRs.

See also http://www.geocities.com/westfw/avr-instructionset.html

This is a "decode table" for converting Hex opcodes to actual
instructions, and gives a quick overview of the instruction set, as
well as being "interesting" in its relative randomness. It's clear
(IMMO) that the AVR is a very "top down" digital design...

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Do you need PCB

2008-08-13T18:01:26Z

Hello,all.we are a PCB manufacturer.Material:FR-4,aluminium,FPC.Layer: 1-10,thickness:0.4-4.2mm,min.Line/Space:0.1mm,min.hole:0.1mm,inculding burried/blind hole.Both prototype and mass production are welcome.
Details pls send me email by hanward@szckt.cn or contact me at:
Contacting:Hanward Jiang

Marketing Dept.Manager
Cirket Electronics Company
22A,Block B,Nanhai Bldg,Nanshan Rd,
Shenzhen,P.R.China
Tel:+86-755-8621 5150
Fax:+86-755-8621 5160
MSN:hanwardjiang@hotmail.com
Skype: hanward
Website:www.szckt.cn

Re: Programming specification, where?

2008-08-07T03:42:24Z

On Thursday 07 August 2008 11:04:34 Peter wrote:
> > Atmel places programming information for each chip in that chip's
> > datasheet - it's not a seperate document.
>
> Thanks for that, I found it now. Still, is there a binary level
> specification for the opcodes of AVRs? I have the assembly programming
> specification and I hope to find it there.

Oh, so what you were looking for is the "instruction set" of the AVRs. Google
for "AVR instruction set" and it's the very first document. The binary opcodes
are listed.

--
with metta,
Shawn Tan

Aeste Works (M) Sdn Bhd - Engineering Elegance
http://www.aeste.net
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: Programming specification, where?

2008-08-07T03:04:34Z

> Atmel places programming information for each chip in that chip's
> datasheet - it's not a seperate document.

Thanks for that, I found it now. Still, is there a binary level specification
for the opcodes of AVRs? I have the assembly programming specification and I
hope to find it there.

thanks,
Peter

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: Programming specification, where?

2008-08-04T06:50:33Z

Atmel places programming information for each chip in that chip's
datasheet - it's not a seperate document.

For instance, you can look at section 27 of the atmega168 document for
instructions on both parallel and serial memory programming modes:
http://atmel.com/dyn/resources/prod_documents/doc2545.pdf

Find the full datasheet for the chip you want to program, and check
out the section labeled, "Memory Programming"

-Adam

On 8/4/08, Peter <plpeter2006@...> wrote:

> Could anyone please point me towards the official pdf format memory programming
> specification for AVR micros? I.e. the equivalent of the Microchip Memory
> Programming Specification that shows most pin-out and timing issues needed to
> program a Pic, but for an AVR? And, since on is at that, to the bit level
> instruction encoding specifications for AVRs?
>
> Neither Google nor the peruse of forums and of the Atmel site helped here
> (unlike Microchip's site where such information is linked directly from the
> device home page).
>
> thanks,
> Peter
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
EARTH DAY 2008
Tuesday April 22
Save Money * Save Oil * Save Lives * Save the Planet
http://www.driveslowly.org
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Programming specification, where?

2008-08-04T03:48:36Z

Could anyone please point me towards the official pdf format memory programming
specification for AVR micros? I.e. the equivalent of the Microchip Memory
Programming Specification that shows most pin-out and timing issues needed to
program a Pic, but for an AVR? And, since on is at that, to the bit level
instruction encoding specifications for AVRs?

Neither Google nor the peruse of forums and of the Atmel site helped here
(unlike Microchip's site where such information is linked directly from the
device home page).

thanks,
Peter

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-24T01:34:41Z

On Sat, May 24, 2008 at 12:16 AM, John Samperi
<samperi@...> wrote:
> At 08:13 AM 24/05/2008, you wrote:
>>The original AVRISP from the company that designed the original AVR
>>starter kits, now works from USB.
>
> $59.00?? What do you get for the extra cost than an
> AVRISP?...well apart from the 10W to 6 way adaptor,
> or is that extra? :-)

USB and NO firmware. So it won't update and never work again. Also its
the real price not the subsidised by marketing price. Oh and it has an
avrstudio plugin too, if you don't want to leave studio.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-23T16:49:55Z

At 09:36 AM 24/05/2008, you wrote:
>Are you basing that on actual experience with cheap AVR programmers?

I'm basing it on 7 years helping out people on Avrfreaks that
kill their chips with cheap programmer, especially parallel port
programmer with their confusing hex fuse setting software.

For me, I just do not want to exit Studio, all that I need is in
one IDE which works fairly well...apart from the occasional bug...

Having said that I started off with a PPP with the 4 resistors,
(233 MHz processor win 3.11) but once I started to use AVRs for
real I got an AVRISP, it just works.

I also have a STK500 and a Dragon which can be used as backup
programmers.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495 Fax (02) 9674-8745
Email: john@...
Website http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-23T16:36:30Z

>> DO NOT FALL for cheap programmers!! They cost a LOT more
>> in wasted time and dead chips.

Are you basing that on actual experience with cheap AVR programmers?
My impression has been that due to fewer changes in technology, fewer
chips, and perhaps a more forward-thinking algorithm, the "cheap" AVR
programmers were more reliable than cheap PIC programmers, for example.

For instance, the cheap tiny11 programmer (serial port bit-bang) that
I built works better than my STK-500 (which I never got to work for
tiny11s.)

OTOH, many of the cheap designs use the PC parallel port, which is
likely to have all the same problems of other parallel port
programmers on modern PCs.

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-23T16:16:12Z

At 08:13 AM 24/05/2008, you wrote:
>The original AVRISP from the company that designed the original AVR
>starter kits, now works from USB.

$59.00?? What do you get for the extra cost than an
AVRISP?...well apart from the 10W to 6 way adaptor,
or is that extra? :-)

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495 Fax (02) 9674-8745
Email: john@...
Website http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-23T15:13:36Z

On Fri, May 23, 2008 at 10:34 PM, John Samperi
<samperi@...> wrote:

> At 05:23 AM 24/05/2008, you wrote:
>>Last time I looked into programming an Atmel, I found some low-cost
>>entry-level programmers at sparkfun.
>
> DO NOT FALL for cheap programmers!! They cost a LOT more
> in wasted time and dead chips.
>
> The price of a real AVRISP is nothing even for a hobbiest,
> so for a professional like James it should be a mandatory
> purchase. :-)

The original AVRISP from the company that designed the original AVR
starter kits, now works from USB.
http://www.kanda.com/products/Kanda/AVRISP-U.html

And a note, Our handheld standalone programmer product is programmable
with USB also.
http://www.kanda.com/products/Kanda/HH0010U.html

Contact support or sales @ kanda.com and we will add any device which
may not be at this time supported. We try to keep the device support
up to date, but sometimes Atmel sneaks them past us. :)

BryanW
Software Engineer, Embedded Results ltd, t/a kanda.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-23T14:59:40Z

... amen ... Atmel's AVRISP mkII In System Programmer is Mouser p/n:
556-ATAVRISP2 and sells for $35.91 in qty=1! (plus shipping of course)
It will, among many others, program an 8515.

On May 23, 2008, at 5:34 PM, John Samperi wrote:

> At 05:23 AM 24/05/2008, you wrote:
>> Last time I looked into programming an Atmel, I found some low-cost
>> entry-level programmers at sparkfun.
>
> DO NOT FALL for cheap programmers!! They cost a LOT more
> in wasted time and dead chips.
>
> The price of a real AVRISP is nothing even for a hobbiest,
> so for a professional like James it should be a mandatory
> purchase. :-)
>
> Regards
>
> John Samperi

--
cheers ... 73 de brian riley, n1bq , underhill center, vermont
<http://web.mac.com/brianbr/> Tech Blog
<http://www.wulfden.org/TheShoppe.shtml>
Home of the
K107 Serial LCD Controller Kit FT817 Power Conditioner Kit
Tab Robot Laser Tag Kit MSP430 Chips and Connectors
Propeller Robot Controller SX48 "Tech Board" Kit
PICAXE chips and accessories Freeduino systems

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Re: What does it take to program an ATMEGA 8515?

2008-05-23T14:34:10Z

At 05:23 AM 24/05/2008, you wrote:
>Last time I looked into programming an Atmel, I found some low-cost
>entry-level programmers at sparkfun.

DO NOT FALL for cheap programmers!! They cost a LOT more
in wasted time and dead chips.

The price of a real AVRISP is nothing even for a hobbiest,
so for a professional like James it should be a mandatory
purchase. :-)

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495 Fax (02) 9674-8745
Email: john@...
Website http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist