Searching \ for '[PIC]: BCD time-of-day addition' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=time
Search entire site for: 'BCD time-of-day addition'.

Exact match. Not showing close matches.
2002\10\06@034055 by

Before I go and reinvent the wheel I was wondering if there where any
routines out there for adding together Binary Coded Decimal (BCD) times?

Eg I have the time of day stored in two bytes coded in BCD, named hour (in
24 hour time) and minute, and I want to know that the time will be in 40
minutes (or some other fixed interval of minutes).

I've had a bit of a surf our the web but couldn't locate a routine to do this.

John

_______________________________________________________________________
John Brown
PhD (Clinical Psychology) candidate
Email:  john.brownanu.edu.au
School of Psychology                  Phone:  (02) 6125-3827
Room 124, Building 39, Psychology     Fax:    (02) 6125-0499
The Australian National University    Mobile: 0429 455 504
ACTON ACT 0200   Web: http://www.anu.edu.au/psychology/staff/BrownJ.htm

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

This is not a direct solution to your problem but an attempt to rethink it.

Why add in BCD? It seems unnatural on a PIC. If you are using a PIC, then
the natural method would be binary addition.

I prefer to work in binary and only convert to BCD (or ASCII) when
necessary, which is usually for output on a device.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

At 05:33 PM 10/6/02 +1000, you wrote:
>Before I go and reinvent the wheel I was wondering if there where any
>routines out there for adding together Binary Coded Decimal (BCD) times?
>
>Eg I have the time of day stored in two bytes coded in BCD, named hour (in
>24 hour time) and minute, and I want to know that the time will be in 40
>minutes (or some other fixed interval of minutes).

24, with any resulting carry from that operation representing a time
in the next day. Here's some (untested) C code that represents what
should be done:

c= 0; d=0;
min += m; if (min >= 60) {min -= 60; c++;};
hrs += h + c; if (hrs >= 24) {hrs -=24; d++;};

(you can make comparisons on packed BCD numbers as if they were
binary numbers).

The PIC provides support for BCD operations in the form of the DAW
instruction, but that's only on the high end parts, so I don't think
AN544 will help you directly unless you're using one of those. On the low/mid
parts you'll have to make do with the half-carry bit DC in the
status register (hey, at least they put that in!).

Here's an example from Scott Dattalo on (packed) BCD addition:

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

Spehro Pefhany wrote:
> it modulo 24, with any resulting carry from that operation
> representing a time in the next day. Here's some (untested) C code
> that represents what should be done:
>
>    c= 0; d=0;
>    min += m; if (min >= 60) {min -= 60; c++;};

min = 59h
m   =  2h

min + m = 5Bh

[snip]

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Wagner Lipnharski - UST Research Inc
Orlando FLorida - USA - http://www.ustr.net
/_/_/_/ Atmel AVR Consultant /_/_/_/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

At 12:57 PM 10/6/02 -0400, you wrote:
>Spehro Pefhany wrote:
> > modulo 60 and add any carry to the hours, add on the delta and adjust
> > it modulo 24, with any resulting carry from that operation
> > representing a time in the next day. Here's some (untested) C code
> > that represents what should be done:
> >
> >    c= 0; d=0;
> >    min += m; if (min >= 60) {min -= 60; c++;};
>
>
>min = 59h
>m   =  2h
>
>min + m = 5Bh

You seem to be making some assumptions about the internal representation
used for my untyped variables. ;-)

Yes, the addition has to be done in packed BCD if the numbers are in packed
BCD (or conversions must be done before and after), hence the latter part of
my message that you snipped.

The first part addresses the overall logic of the problem, the second is
a pointer to help the OP solve the specific problem, which he probably
will use assembly for.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

I was joking, of course BCD math requires decimal adjust.
But still a problem for the novice that without further warning, will think
that 59h + 2h = 61h.
Having students in this area, you can't imagine things I see.
It took me almost 3 whole days to put the idea of a pointer into someone's
concrete brain.  A memory position containing the address of another memory
position, when "data" is in true "address"... for this guy, it simple
doesn't fit. It took me all that time to make him understand that address
is not only what goes to the address lines of the chip, at some instance it
is also data. Difficult concepts for the Hard Head.

Wagner Lipnharski - email:  wagnerustr.net
UST Research Inc. - Development Director
http://www.ustr.net - Orlando Florida 32837

Spehro Pefhany wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

> It took me almost 3 whole days to put the idea of a pointer into someone's
> concrete brain.

Next time just teach him to say "would you like fries with that?" instead.
Sounds like he'll need that sooner or later anyway.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

10/6/02 12:46:31 PM, Olin Lathrop <olin_piclistEMBEDINC.COM> wrote:

>> It took me almost 3 whole days to put the idea of a pointer into someone's
>> concrete brain.
>
>Next time just teach him to say "would you like fries with that?" instead.
>Sounds like he'll need that sooner or later anyway.

You know, I think the two of you are being a little harsh here.  In my experience, the concept of
pointers has a learning curve that's practically a step function; there's a "moment of truth" in
which the idea suddenly goes from incomprehensible to blindingly obvious.  Most people simply
don't start out with a mental model that encompasses the notion; they have to build one.  We sort
of sloppily say that the concept is "unintuitive"; most of the time when we say something is
"intuitive" what we really mean is that it fits into a mental model that we already have.

There's a *big* difference between not initially having a mental model that fits some concept, not
having the intellectual ability to build one, and, worst of all, being capable of building one but
being too lazy, stubborn or rigid to do so.  We often forget that things that seem to come
"naturally" to us now only do so because we *worked hard* at understanding them some time in the
distant past.  Sure, intelligence was necessary to do so, but it was only a necessary condition,
not a sufficient one.

IMHO, this geekish tendency to assume that failure to understand an "advanced" concept on one's
very first exposure to it indicates mental retardation or something close to it is nothing more
than the equivalent of taunting a 13-year-old for being a virgin.

Anyone remember the discussion of addressing modes in Lewis Caroll's _Through the Looking Glass_?
The distinctions between what the poem was, what the poem was called, what the name of the poem
was, and what the name of the poem was called?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

Eric Bohlman wrote:
> >> It took me almost 3 whole days to put the idea of a pointer into
someone's
> >> concrete brain.
> >
> >Next time just teach him to say "would you like fries with that?"
> >Sounds like he'll need that sooner or later anyway.
>
> You know, I think the two of you are being a little harsh here.
> In my experience, the concept of pointers has a learning
> curve that's practically a step function; there's a "moment of
> truth" in which the idea suddenly goes from incomprehensible
> to blindingly obvious.

Some guys need to be treated with harsh. Otherwise
a "moment of truth" will never come to them.

Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

Olin Lathrop wrote:
>
> > It took me almost 3 whole days to put the idea of a pointer into someone's
> > concrete brain.
>
> Next time just teach him to say "would you like fries with that?" instead.
> Sounds like he'll need that sooner or later anyway.

Welcome guys and gals to the Piclist comedy hour.
Tonight we have a great line up for you! First up
we have one of the greats of stand-up comedy, famous
as much for his jovial humour as he is for his easy-
going attitude towards lazy students who didn't read
the manual. Let's give a big round of applause for...
Olin Seinfeld!
;o)
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

>> It took me almost 3 whole days to put the idea of a pointer
>> into someone's concrete brain.
>
> Next time just teach him to say "would you like fries with that?"
> instead.  Sounds like he'll need that sooner or later anyway.

You know, I think the two of you are being a little harsh here.  In my
experience, the concept of pointers has a learning curve that's
practically a step function; there's a "moment of truth" in which the
idea suddenly goes from incomprehensible to blindingly obvious.

I agree.  It took me years of fiddling with assembly language (on a
before it clicked that those addresses WERE these "pointer" things that
HL Languages kept mentioning (they never mentioned them that way in the
HLL classes that I remember; after all, the point of a HLL is NOT having
to understand computer architecture concepts, right?  A case where
having some asssembly background helps a lot, IMO, but only if you
connect the two...  You can also teach pointers in terms of the
basic/fortran array indicies sometimes used to provide similar
functionality in those languages, but that's usually not done either,
since that would be the BAD way to do it...)

Moreover, even after UNDERSTANDING "pointers", it took be a long time to
figure out just what they were good for in a HLL program.  After all,
the average computer class assignment just isn't BIG enough for dynamic
assignment to become all that important...

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

10/6/02 2:40:20 PM, Mike Singer <mikePOLUOSTROV.NET> wrote:

>> You know, I think the two of you are being a little harsh here.
>> In my experience, the concept of pointers has a learning
>> curve that's practically a step function; there's a "moment of
>> truth" in which the idea suddenly goes from incomprehensible
>> to blindingly obvious.
>
>Some guys need to be treated with harsh. Otherwise
>a "moment of truth" will never come to them.

But *that* particular form of harshness (implying that the person is incapable of learning the
subject) will only work for people with certain personality types and from certain cultures.  Yes,
someone with a general "fuck authority and fuck what others think of me" attitude might take it as
a challenge to prove the other guy wrong.  But someone who's been raised to respect authority or
who has more feelings than Mr. Spock would find it *harder* to push on after receiving such
discouragement.  I think this sort of attitude, when applied to the teaching of science and
technology, is a major part of what leads people to actively reject science and math (plenty of
educated people are actually proud of not understanding science or math concepts, people who would
never be proud of, say, not knowing who Shakespeare was) and turn to superstition and
pseudoscience.  Their lack of aspiration to the lonergeek lifestyle shouldn't be confused with
incapability.

Although many people loudly poo-poo it, there have been *plenty* of studies that show that
students' performance is greatly influenced by the expectations their teachers communicate to
them, and that communicating low expectations lowers their performance whereas communicating high
expectations raises it.  The key is an appropriate level of challenge: if they don't have to
stretch themselves, students will feel bored, patronized and may lower their horizons, but if
they're expected to jump ten feet in the air and ridiculed for not being able to do so, they'll
also get discouraged and lower their horizons.

In the case of pointers, the appropriate response is along the lines of "yes, it's a hard subject.
No, there's no real way to make it easy, but if you want to succeed in this field you've got to
learn it.  Keep trying.  You can do it.  It's going to be a lot of work, but it will be worth it."

To use a Harry Potter analogy, teachers don't have to be either Snapes (puts down non-prodigies)
or Trelawneys (dumbs down the content); they can be McGonnagals (strict, tolerates no nonsense,
treats students with respect, assumes they're capable of learning and expects them to) or
Flitwicks (both of whom teach "hard science" subjects).

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> -----Original Message-----
> From: William Chops Westfield [SMTP:billwcisco.com]
> Sent: Monday, October 07, 2002 2:18 AM
> To:   PICLISTMITVMA.MIT.EDU
> Subject:      Re: [PIC]: BCD time-of-day addition
>
> Moreover, even after UNDERSTANDING "pointers", it took be a long time to
> figure out just what they were good for in a HLL program.  After all,
> the average computer class assignment just isn't BIG enough for dynamic
> assignment to become all that important...
>
Pointers have considerable use outside of dynamicaly allocated memory, e.g.
passing a large data structure to a function is almost always done using a
pointer.  String handling and arrays would be impossible to use without
pointers.

Regards

Mike

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Oop's meant to send this to the list, sorry about that.

{Quote hidden}

But passing an address IS passing a pointer. Ok, some languages pass by
reference without it being obvious to the programmer, but a pointer is still
used and can be taken advantage of by someone who understand what's
happening.

{Quote hidden}

I take your point about 'C' bias, but to be pedantic, arrays and string
handling is impossible without pointers, it's just that some langauages hide
it better than others :o)

Cheers

Mike

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> String handling and arrays would be impossible to use without
> pointers.

FORTRAN did both these things without pointers.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> -----Original Message-----
> From: pic microcontroller discussion list
> [PICLISTMITVMA.MIT.EDU]On Behalf Of Michael Rigby-Jones
> Sent: Monday, October 07, 2002 04:45
> To: PICLISTMITVMA.MIT.EDU
> Subject: Re: [PIC]: BCD time-of-day addition
>
> Pointers have considerable use outside of dynamicaly allocated
> memory, e.g.
> passing a large data structure to a function is almost always done using a
> pointer.  String handling and arrays would be impossible to use without
> pointers.

I don't know why you'd say impossible, other earlier HLL's were doing that
sort of thing without even the mention of a pointer. Pointers may make
things easier to do (at least in some people's eyes), but not having them
doesn't preclude having certain features. TTYL

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> -----Original Message-----
> From: Olin Lathrop [SMTP:olin_piclistEMBEDINC.COM]
> Sent: Monday, October 07, 2002 2:06 PM
> To:   PICLISTMITVMA.MIT.EDU
> Subject:      Re: [PIC]: BCD time-of-day addition
>
> > String handling and arrays would be impossible to use without
> > pointers.
>
> FORTRAN did both these things without pointers.
>
Perhaps from the programmers perspective but surely pointers were used
"under the hood".  There is simply no way that I can thik of to perform
array and string operations without pointers.

Regards

Mike

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> > -----Original Message-----
> > From: Olin Lathrop [SMTP:olin_piclistEMBEDINC.COM]
> > Sent: Monday, October 07, 2002 2:06 PM
> > To:   PICLISTMITVMA.MIT.EDU
> > Subject:      Re: [PIC]: BCD time-of-day addition
> >
> > > String handling and arrays would be impossible to use without
> > > pointers.
> >
> > FORTRAN did both these things without pointers.
> >
> Perhaps from the programmers perspective but surely pointers were used
> "under the hood".  There is simply no way that I can thik of to perform
> array and string operations without pointers.

Perhaps FORTRAN did use references, I don't know, but it's certainly
possible to do this sort of stuff without references. References (pointers)
simply makes things easier, as long as you understand them of course. TTYL

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Perhaps from the programmers perspective but surely pointers were used
"under the hood".  There is simply no way that I can thik of to perform
array and string operations without pointers.

No, no.  Those things used "under the hood" are ADDRESSES, without which you
can't do much of anything (no jumps or calls, for instance.)  A "pointer" is
a particular implementation of an address-like capability in a high level
language, and that's quite different.  When you talk about "Joe the Dense"
not understaning "pointers", you're almost certainly talking about the HLL
definition - he may or may not understand "addresses."  (I did mention being
comfortable with assembly language pointers for quite some time before
connecting them with HLL pointers, right?  Perhaps the difficulties some
people have with pointers is BECAUSE many HLLs do such a good job hiding any
need for them...)

Pointers in C, of course, have semantics, capabilities, and quirks that
extend their incomprehensibility far beyond those of other languages, not to
mention the fact that they're NECESSARY so often.  Fortunately, there are
tools you can use if you have to define a pointer to a function that returns
a pointer to a function or similar :-)`

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

{Quote hidden}

The pointers may not have been mentioned per se, but they are being used.  I
challenge anyone to write string handling routines that do not use pointers,
either explicitly or implicitly.  Even a PIC accessing program memory using
RETLW is a form of pointer operation.

Regards

Mike

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

That which the C-world dubbed 'pointers' existed
long before as "indirect addressing" (as opposed to
direct) in the world of assembler ...

The three addressing modes (in a nut shell) are:

1) Immediate - simply loads a data value into a reg
2) Direct - loads a value from/to a register into
to/from a memory location and
3) Indirect - uses a value in a reg as an *address* into
memory. *This* is your pointer functionality ...

Reference: http://www.csee.umbc.edu/~plusquel/310/slides/assem1.html

RF Jim

{Original Message removed}
On Sun, 6 Oct 2002, William Chops Westfield wrote:

*>    You know, I think the two of you are being a little harsh here.  In my
*>    experience, the concept of pointers has a learning curve that's
*>    practically a step function; there's a "moment of truth" in which the
*>    idea suddenly goes from incomprehensible to blindingly obvious.
*>
*>I agree.  It took me years of fiddling with assembly language (on a
*>before it clicked that those addresses WERE these "pointer" things that
*>HL Languages kept mentioning (they never mentioned them that way in the

Grin. There is also that second threshold when function pointers are
introduced. Wrapping one's mind around that (especially in the context of
variable arity) is a much steeper step than pointers imho. At least for me
it was. I had exposure to pointers and computed jumps/calls in assembly
before learning C but I know CS people who hit a sort of wall at the time.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

On Sun, 6 Oct 2002, Joaquim J. Peixoto wrote:

*>This is not a direct solution to your problem but an attempt to rethink it.
*>
*>Why add in BCD? It seems unnatural on a PIC. If you are using a PIC, then
*>the natural method would be binary addition.

The natural way to store data in a micro with limited space and limited
maths is packed BCD. Then you need half the storage space of unpacked BCD,
and no base conversions.

In C the code is like:

uchar pbcd;     // packed bcd accumulator
bit   carry;    // carry in and out, normally LSB in some register, or
// use the one in STATUS

// add one packed BCD byte to another, returns carry out

pbcd += addend;            // this is clear
if(carry)                  // so is this
++pbcd;

if((pbcd & 0x0F) > 0x09)   // need daa lsbyte
pbcd += 0x06;

carry = 0;                 // assume no carry out
if((pbcd & 0xF0) > 0x90) { // need daa msbyte
carry = 1;
pbcd += 0x60;
return(1);               // carry
}
return(0);
}

// substract a packed BCD number from another
void pbcd_sub( uchar subtrahend ) {

pbcd -= subtrahend;
if(carry)
--pbcd;

if((pbcd & 0x0F) > 0x09)    // need to saa lsbyte
pbcd -= 0x04;

carry = 0;
if((pbcd & 0x0F) > 0x90) {
carry = 1;
pbcd -= 0x40;
return(1);
}
return(0);
}

In assembly it is shorter and I am sure someone will point out the DC flag
and its use. The code above can be cascaded for several digits, and it has
the advantage that it works on any compiler (perhaps change bit to
something else).

*>I prefer to work in binary and only convert to BCD (or ASCII) when
*>necessary, which is usually for output on a device.

Me too, but not on a PIC that has no multiply and divide and no
reasonably sized printf().

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Oh.  Yeah, my mail agent insists on adding the "reply-to" field if I
customize the From: line at all.  I guess I'll have to fix it :-(

The three addressing modes (in a nut shell) are:

1) Immediate - simply loads a data value into a reg
2) Direct - loads a value from/to a register into
to/from a memory location and
3) Indirect - uses a value in a reg as an *address* into
memory. *This* is your pointer functionality ...

Hmmph.  The processor I grew up on had immediate, direct, and INDEXED, the
last where the "address" field was used as a constant and added to the value
of a register to get a final memory address.  There was also an "indirect"
bit that meant "once you get a memory address, look in that memory location
for ANOTHER set of index/offset/indirect bits and do the "effective address
calculation" AGAIN to find the next memory address to look at.  Repeat as
Infinite loops in less than one instruction.  Doubly indexed arrays (perhaps
sparse) implemented in hardware.  I think I actually used one-level
indirection with index registers on both calculations once.  Shudder.
(single indirect addressing without multiple indexing was pretty common.  It

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

The substract code I posted is bad, I don't know what happened. Here is
the fixed version:

On Mon, 7 Oct 2002, Peter L. Peres wrote:

*>On Sun, 6 Oct 2002, Joaquim J. Peixoto wrote:
*>
*>*>This is not a direct solution to your problem but an attempt to rethink it.
*>*>
*>*>Why add in BCD? It seems unnatural on a PIC. If you are using a PIC, then
*>*>the natural method would be binary addition.
*>
*>The natural way to store data in a micro with limited space and limited
*>maths is packed BCD. Then you need half the storage space of unpacked BCD,
*>and no base conversions.
*>
*>In C the code is like:
*>
*>uchar pbcd;     // packed bcd accumulator
*>bit   carry;    // carry in and out, normally LSB in some register, or
*>                // use the one in STATUS
*>
*>// add one packed BCD byte to another, returns carry out
*>
*>  pbcd += addend;            // this is clear
*>  if(carry)                  // so is this
*>    ++pbcd;
*>
*>  if((pbcd & 0x0F) > 0x09)   // need daa lsbyte
*>    pbcd += 0x06;
*>
*>  carry = 0;                 // assume no carry out
*>  if((pbcd & 0xF0) > 0x90) { // need daa msbyte
*>    carry = 1;
*>    pbcd += 0x60;
*>    return(1);               // carry
*>  }
*>  return(0);
*>}
*>
*>// substract a packed BCD number from another
*>void pbcd_sub( uchar subtrahend ) {
*>
*>  pbcd -= subtrahend;
*>  if(carry)
*>    --pbcd;
*>
*>  if((pbcd & 0x0F) > 0x09)    // need to saa lsbyte
*>    pbcd -= 0x06;     // fixed
*>
*>  carry = 0;
*>  if((pbcd & 0xF0) > 0x90) { // fixed
*>    carry = 1;
*>    pbcd -= 0x60;     // fixed
*>    return(1);
*>  }
*>  return(0);
*>}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> >         I don't know why you'd say impossible, other earlier HLL's were
> > doing that
> > sort of thing without even the mention of a pointer. Pointers may make
> > things easier to do (at least in some people's eyes), but not
> having them
> > doesn't preclude having certain features. TTYL
> >
> The pointers may not have been mentioned per se, but they are
> being used.  I
> challenge anyone to write string handling routines that do not
> use pointers,
> either explicitly or implicitly.  Even a PIC accessing program
> memory using
> RETLW is a form of pointer operation.

Ahh, you are broadening what "pointer" refers to. Even a stack can be
considered a pointer in your case. TTYL

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Peter L. Peres wrote:
[snip]

> The natural way to store data in a micro with limited space and
> limited maths is packed BCD. Then you need half the storage space of
> unpacked BCD, and no base conversions.

[snip]

With all due respect please, "limited space" is something that we used to
deal strongly in the 70ish or 80ish decades.  4004, 8008 and Z80 chips with
SRAM memories (external of course) were expensive and short, you really
needed to catch all the possible black magic you could hold, and thanks to
that dark age, we did learn how to do magical things.  Microsoft and Intel
show us that we shouldn't think that way anymore.

Bill Gates and Intel (+AMD) wizards just made a pact with the horny one,
memory and processor power should never be a problem, what do you want?
50GHz processing speed and 1TeraByte of DDRAM? No problem, can you wait 10

It is amazing how I can still producing a nice program in DOS assembly in
less than 2kBytes, and ANY windows something slower similar thing with
bells and whistles (that you don't need), with at least 3 or 4 DLLs and
more 2 or 3 INI files along with registry messup, will require at least 4MB
(if you are lucky) to do the same thing (of course with illegal operations,
blue screens, and all sort of nasty smell and smoke that you deserve by
using such commercial fries and catchup messy things) [UnixSoapBox Off].

At this moment, a customer is asking a solution to store at least 1MBytes
of data into non volatile SRAM.  I just gave him a solution using (AVR uC)
and Compact Flash 16MB memory that you can buy for less than \$12, something
that can allow him to remove and transport the data, without needing a
saltinbank operator to squeeze the devices into a huge data collector.  Of
course that using BCD (for the apropriate data) could double this \$12
memory, but this is another story.

Wagner Lipnharski - email:  wagnerustr.net
UST Research Inc. - Development Director
http://www.ustr.net - Orlando Florida 32837

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Wagner Lipnharski - UST Research Inc
Orlando FLorida - USA - http://www.ustr.net
/_/_/_/ Atmel AVR Consultant /_/_/_/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...