In article <MPG.25638c561500f651989694@news.giganews.com>, 
uniden@nospam.net says...
> In article <MPG.2562bd87152ec982989953@news.eternal-september.org>, 
> mborgerson@comcast.net says...
> > Isn't it Jeff Ciarcia of Circuit Cellar
> > who says "my favorite programming language is solder"?
> 
> If Jeff said that, he is a bastard and should give credit to Steve 
> Ciarcia.
> 
> 
DOH!   I should have visited the Circuit Cellar web site to get
the attribution correct.  I may have been mixing up names with
Jeff Bachiochi, who writes the "From the Bench" articles in
Circuit Cellar.


Mark Borgerson

In article <a5c9d81b-a087-43ec-99ec-
46ad11ba52cd@d10g2000yqh.googlegroups.com>, dp@tgi-sci.com says...
> On Nov 10, 9:57=A0am, Mark Borgerson <mborger...@comcast.net> wrote:
> > ...
> > > If I understood you correctly, masking the interrupts may be
> > > unnecessary.
> > > This is pretty much how time is kept on the PPC (power architecture,
> > > as
> > > they now have it); two 32 bit register accessing a 64 bit free runnin=
g
> > > counter. The way to do it is simple: read the MS-part, then read the
> > > LS
> > > part, then the MS again; if the two MS reads differ, repeat.
> >
> > That takes more cycles than the two instructions needed to
> > disable, then reenable interrupts. =A0However, it does have the
> > advantage of avoiding about =A01 microsecond of possible jitter
> > in the response to the timer interrupt.
>=20
> The benefit is indeed in latency - and in the ability to do this at
> user level where masking interrupts is not that fast/easy at all.
> But the penalty in time is not as bad as it may seem because of the
> "repeat" word; as I have it at the moment here, the timebase
> is clocked at 33 MHz, carry from ls to ms occurs once every
> 130 seconds or so. And without carry we just have 3 reads,
> a compare and a branch (with static prediction the obvious way).
> Masking/unmasking in power would take 6 instructions, which is
> actually more (but this is power/RISC specific, of course).

For an MSP430 running at 4MHz,  1 microsecond of jitter when
servicing  interrupts at 120Hz isn't usually a problem.=20

On a M68K system or some ARMs,  reading the 32-bit seconds requires
no masking, as reading a long word is an atomic operation.


Which all goes to prove the point that in embedded system programming
a LOT depends on the processor you are using--as well as the
OS (if any).


Mark Borgerson

On Nov 10, 9:57=A0am, Mark Borgerson <mborger...@comcast.net> wrote:
> ...
> > If I understood you correctly, masking the interrupts may be
> > unnecessary.
> > This is pretty much how time is kept on the PPC (power architecture,
> > as
> > they now have it); two 32 bit register accessing a 64 bit free running
> > counter. The way to do it is simple: read the MS-part, then read the
> > LS
> > part, then the MS again; if the two MS reads differ, repeat.
>
> That takes more cycles than the two instructions needed to
> disable, then reenable interrupts. =A0However, it does have the
> advantage of avoiding about =A01 microsecond of possible jitter
> in the response to the timer interrupt.

The benefit is indeed in latency - and in the ability to do this at
user level where masking interrupts is not that fast/easy at all.
But the penalty in time is not as bad as it may seem because of the
"repeat" word; as I have it at the moment here, the timebase
is clocked at 33 MHz, carry from ls to ms occurs once every
130 seconds or so. And without carry we just have 3 reads,
a compare and a branch (with static prediction the obvious way).
Masking/unmasking in power would take 6 instructions, which is
actually more (but this is power/RISC specific, of course).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/137=
5ba119288d85a?dmode=3Dsource

In article <MPG.2562bd87152ec982989953@news.eternal-september.org>, 
mborgerson@comcast.net says...
> Isn't it Jeff Ciarcia of Circuit Cellar
> who says "my favorite programming language is solder"?

If Jeff said that, he is a bastard and should give credit to Steve 
Ciarcia.

In article <v8hhf5tcu2r3f9eue4iadk73ako07f3581@4ax.com>, keinanen@sci.fi 
says...
> On Mon, 9 Nov 2009 16:49:25 -0800, Mark Borgerson
> <mborgerson@comcast.net> wrote:
> 
> >In article <99igf5pkf6kfbllsu4c5kjglcnj27kb2dd@4ax.com>, keinanen@sci.fi 
> >says...
> >> On Sun, 08 Nov 2009 09:35:23 -0600, "alex99" <alex.xander99@gmail.com>
> >> wrote:
> >> 
> >> >I am trying to implement a software real-time clock on ARM using
> >> >the timer module. 
> >> >
> >> >I am pretty much unable to do it at this point and was hoping that someone
> >> >could point me in the right direction -- perhaps even coded examples that
> >> >could serve as a way to better understand it. I C language but am a newbie
> >> >in
> >> >micro-controllers. Have to display time using one of the GPIO ports.
> >> 
> >> One way of implementing this is assuming that a timer interrupt is
> >> available say at 1234 Hz, thus the average time between interrupts is
> >> 810372,77147487844408427876823339 ns.
> >
> >Hmmm,  do you think that interval is sufficiently precise?   ;-)
> >Given the tolerances and temperature coefficients of standard
> >crystals,  6 significant figures ought to be enough.
> >> 
> >> Just use an ISR, which adds 810373 to a 32 bit nanosecond counter.
> >> Each time the counter overflows (mod 1E9), add one to the second
> >> counter. 
> >
> >Is this supposed to be a joke?  Why not just add 1 to a static
> >short integer in the ISR and increment the seconds count each time
> >the variable 'rolls over' at 1234?
> 
> What if the interrupt occurred at 1234.567890123456 Hz rate. That
> would require weeks to get a usable reading.

Or two minutes to change to a crystal which is an integer multiple of
your desired time interval.  Isn't it Jeff Ciarcia of Circuit Cellar
who says "my favorite programming language is solder"?
>  
> >> 
> >> If the hardware does not support div/mod instructions usable in ISRs,
> >> just use some base2 operations, which can be implemented with shifts
> >> and mask instructions.
> >
> >That sounds like a special-case software floating point function.
> >
> >I guess you can make a simple timing chore as complex as you like.
> >If you keep this up,  you'll get to the 18.2mSec tick interval of
> >the IBM PC.   ;-)
> 
> Some operating systems (Windows NT at least) allowed to specify how
> many time units (e.g. 100 ns) occurred between each timer interrupt.
> 

Mark Borgerson

In article <bc7dc65f-bdfa-4527-be36-
5c7f7902500e@v25g2000yqk.googlegroups.com>, dp@tgi-sci.com says...
> On Nov 9, 5:31=A0pm, Mark Borgerson <mborger...@comcast.net> wrote:
> > ....
> > The foreground routine calls a function to retrieve the integer seconds
> > and does all conversions between that long integer and various time
> > and date displays using the standard C time conversion routines.
> > The function to return the seconds has to disable interrupts when
> > fetching the seconds, since that is not an atomic operation on the
> > 16-bit MSP430.
>=20
> If I understood you correctly, masking the interrupts may be
> unnecessary.
> This is pretty much how time is kept on the PPC (power architecture,
> as
> they now have it); two 32 bit register accessing a 64 bit free running
> counter. The way to do it is simple: read the MS-part, then read the
> LS
> part, then the MS again; if the two MS reads differ, repeat.

That takes more cycles than the two instructions needed to
disable, then reenable interrupts.  However, it does have the
advantage of avoiding about  1 microsecond of possible jitter
in the response to the timer interrupt.
>=20
> Obviously the "correct" way to get the real time is the one you
> describe, just keep the time as simple as possible and calculate
> whatever is needed whenever it is needed. In DPS, I use the mentioned
> PPC timebase registers plus a known moment derived upon boot time
> and later each hour or so from some platform dependent RTC part
> (perhaps none... just using NTP to get the real time over the net
> then).
>=20
> Dimiter
>=20
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>=20
> http://www.tgi-sci.com
> ------------------------------------------------------
> http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
>=20
> Original message: http://groups.google.com/group/comp.arch.embedded/msg/2=
61c3d6ac7a3ab75?dmode=3Dsource
>=20


Mark Borgerson

Didi wrote:

> On Nov 10, 5:16 am, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> 
>>Didi wrote:
>>
>>>two 32 bit register accessing a 64 bit free running
>>>counter. The way to do it is simple: read the MS-part, then read the
>>>LS part, then the MS again; if the two MS reads differ, repeat.
>>
>>Problem with cycle counters is you can't put the CPU to sleep.
> 
> I am sure they do count in nap mode for the parts I have used,
> really never used the sleep mode on these though (seemed a bad deal,
> almost as much as nap consumption - leaky dense technology... - and
> a lot more hassle to get into and out of it).
>  But I can understand how this can be a problem with your MCU PPC
> parts, I guess you will have to do clock sync every time you come
> out of sleep... (not necessarily practical, but could be at times).

Our machine is BlackFin, and it has 64-bit cycle counter. That would be 
very neat for time measurement, however it is stopped in all low power 
modes. The cost of keeping the CPU core always awake is +200mW. There 
are peripheral timers which can run even if the core is halted, however 
they are only 32 bit wide (and designed by stupid idiots). I have to do 
tricks to get the continuous and accurate time measurement.

VLV

On Nov 10, 5:16=A0am, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Didi wrote:
> > two 32 bit register accessing a 64 bit free running
> > counter. The way to do it is simple: read the MS-part, then read the
> > LS part, then the MS again; if the two MS reads differ, repeat.
>
> Problem with cycle counters is you can't put the CPU to sleep.
>
> VLV

I am sure they do count in nap mode for the parts I have used,
really never used the sleep mode on these though (seemed a bad deal,
almost as much as nap consumption - leaky dense technology... - and
a lot more hassle to get into and out of it).
 But I can understand how this can be a problem with your MCU PPC
parts, I guess you will have to do clock sync every time you come
out of sleep... (not necessarily practical, but could be at times).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Didi wrote:


> two 32 bit register accessing a 64 bit free running
> counter. The way to do it is simple: read the MS-part, then read the
> LS part, then the MS again; if the two MS reads differ, repeat.

Problem with cycle counters is you can't put the CPU to sleep.

VLV

On Nov 9, 5:31=A0pm, Mark Borgerson <mborger...@comcast.net> wrote:
> ....
> The foreground routine calls a function to retrieve the integer seconds
> and does all conversions between that long integer and various time
> and date displays using the standard C time conversion routines.
> The function to return the seconds has to disable interrupts when
> fetching the seconds, since that is not an atomic operation on the
> 16-bit MSP430.

If I understood you correctly, masking the interrupts may be
unnecessary.
This is pretty much how time is kept on the PPC (power architecture,
as
they now have it); two 32 bit register accessing a 64 bit free running
counter. The way to do it is simple: read the MS-part, then read the
LS
part, then the MS again; if the two MS reads differ, repeat.

Obviously the "correct" way to get the real time is the one you
describe, just keep the time as simple as possible and calculate
whatever is needed whenever it is needed. In DPS, I use the mentioned
PPC timebase registers plus a known moment derived upon boot time
and later each hour or so from some platform dependent RTC part
(perhaps none... just using NTP to get the real time over the net
then).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/261=
c3d6ac7a3ab75?dmode=3Dsource