SD24 to sample a resistive bridge with pulsed bridge supply

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

SD24 to sample a resistive bridge with pulsed bridge supply

MSP430 - Discuss mailing list
Hi,

I want to use the SD24 (24 bit ADC in the MSP430AFE2x3) to sample a resistive  
strain gauge bridge (load cell) with 350ohms directly. This is no rocket
science in case the bridge supply is at a DC reference voltage. But I want to
save power! The bridge supply is power hungry (2.5V at 350 ohms).
My idea is to pulse the bridge supply e.g. 10 times per second (the load is
stable) and sample it with the adc24 10 times per second.
I want to get a load resolution of at least 12 bits.
(bridge sensivity is 2mV/V, in case of a 2.5V supply I have 1uV for the LSB)

I have not worked with the ad24 yet. Will this approach save power? From the
datasheet I see that the reference needs at least 5ms turn on time.
But in case I use the ratiometric concept (ADC-reference = bridge supply), I
do not need the reference at all.
How low can I get the supply current? How long does it take for the AD24 to
take a sample? (I do not see any timings in the datasheet?)

Or should I go a different way (e.g. sample and hold circuit in front of high
impedance low power OPV-instrumenation amplifier) and then I use the 12bit
ADC to sample it.

Any of your ideas are valuable for me.

Thanks!
Matthias


Reply | Threaded
Open this post in threaded view
|

Re: SD24 to sample a resistive bridge with pulsed bridge supply

MSP430 - Discuss mailing list
I apologize for top posting, but in this case I don't want to
address specific points below but instead "just talk." Keep
in mind I'm more of a hobbyist here. But perhaps something I
say may help a little, just the same.

First off, the idea of periodically powering the bridge is
probably a good idea. So you are on the right track here.
However, I don't think sigma-delta converters are the right
approach when combined with the idea of powering and
unpowering the bridge circuit. So, if you can change to a SAR
type ADC, for example, that might help a lot in simplifying
what you do.

A 16-bit SAR would be nice and I've used one that was on a
SiLabs which could run quite fast, but the analog section is
over-kill for your needs (though the C8051 core probably
isn't over-kill.) I don't know of an MSP430 with a 16-bit SAR
on it. But there are 12-bit ones. You could plan your noise
level to give you about 10 bits and then over-sample enough
to make sure you get a good 12 bits. Your 10Hz rate wouldn't
be at all hard to achieve.

The 350 ohm impedance you are talking about is "normal" for
strain gauges. Typically, I seem to recall, you get about 1mV
to 3mV of output per drive-volt on the bridge. The first
thing that came to mind was to run the bridge on a low supply
rail. But at 1V of drive, you're still talking about 3mA of
supply current. Dropping that to 0.1V brings the current down
into "reasonable" but then you will have trouble with
accuracy and precision. So I think this is why your thoughts
about short, powered samples is the correct approach. I just
don't think that goes well with sigma-delta.

Use a standard differential amplifier arrangement (3 op-amps)
and set up a three-terminal regulator with a BJT (or two)
that you use to enable its output into the bridge. This way
you can have a precision supply rail that you easily control
and can actively turn off when you don't need it. That supply
will supply your bridge AND your opamps. You'll have to work
out the setup time before sampling starts. Also, you might
want to consider using a CD4016 switch that is constantly
powered to gate the final amp output to your micro input. I'd
expect something less than 150 microamps (regulator, mostly)
as achievable for the OFF current compliance figure. ON, of
course, will be lots more.

You can look up ideas with google using "sampled strain gauge
signal conditioner" and see where that takes you. I'd avoid
the sigma-delta for a pulse-powered bridge, though. But
perhaps you can get enough experimental data from that one to
see if you can make it work okay. I've never attempted it so
I really don't have any experience to draw on, regarding real
results. I just avoid them when I know I will be powering up
and powering down an analog input system or using an analog
input multiplexer. (They generally "don't like" switched
inputs as it takes them time to "re-acquire" an input without
mixing it up into a mush from the other states the input goes
though.)

Jon


On Wed, 9 Sep 2015 10:10:11 +0000 (UTC), you wrote:

>I want to use the SD24 (24 bit ADC in the MSP430AFE2x3) to sample a resistive  
>strain gauge bridge (load cell) with 350ohms directly. This is no rocket
>science in case the bridge supply is at a DC reference voltage. But I want to
>save power! The bridge supply is power hungry (2.5V at 350 ohms).
>My idea is to pulse the bridge supply e.g. 10 times per second (the load is
>stable) and sample it with the adc24 10 times per second.
>I want to get a load resolution of at least 12 bits.
>(bridge sensivity is 2mV/V, in case of a 2.5V supply I have 1uV for the LSB)
>
>I have not worked with the ad24 yet. Will this approach save power? From the
>datasheet I see that the reference needs at least 5ms turn on time.
>But in case I use the ratiometric concept (ADC-reference = bridge supply), I
>do not need the reference at all.
>How low can I get the supply current? How long does it take for the AD24 to
>take a sample? (I do not see any timings in the datasheet?)
>
>Or should I go a different way (e.g. sample and hold circuit in front of high
>impedance low power OPV-instrumenation amplifier) and then I use the 12bit
>ADC to sample it.
>
>Any of your ideas are valuable for me.
>
>Thanks!
>Matthias
Reply | Threaded
Open this post in threaded view
|

Re: SD24 to sample a resistive bridge with pulsed bridge supply

MSP430 - Discuss mailing list


"Jon Kirwan [hidden email] [msp430]" <[hidden email]>:

> You can look up ideas with google using "sampled strain gauge
> signal conditioner" and see where that takes you. I'd avoid
> the sigma-delta for a pulse-powered bridge, though. But
> perhaps you can get enough experimental data from that one to
> see if you can make it work okay. I've never attempted it so
> I really don't have any experience to draw on, regarding real
> results. I just avoid them when I know I will be powering up
> and powering down an analog input system or using an analog
> input multiplexer. (They generally "don't like" switched
> inputs as it takes them time to "re-acquire" an input without
> mixing it up into a mush from the other states the input goes
> though.)

Jon, thank you for your idea's.  

Isn't it possible to just "pause" the sampling of the delta sigma converter
(let it sleeping, all registers keep their values) and awake it after 100ms
with nearly the same input level as before the sleep? The sd24_a input is
just a 18pF capacitor. The 350ohms will charge it quickly...
Sure, I have to clock the adc as long as it is required to step the new
reading completely through the full decimation filter.

The PIR example from texas instrument slaa283 is quite interesting,
It uses the sd16 to sample a big capacitor behind the PIR sensor. It is
sampling the input for 1ms (4 samples each time) and sleep for 341ms. It
seems interrupted sampling is possible with delta sigma too.
To further reduce power consumtion they also switch the reference voltage
off during sleep. It seems that the charge in the capacitor at the ref-pin
will stay - accurate enough for this application - at ref-level for 341ms.

https://www.olimex.com/Products/MSP430/Starter/MSP430-
PIR/resources/slaa283.pdf

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: SD24 to sample a resistive bridge with pulsed bridge supply

MSP430 - Discuss mailing list
On Sun, 13 Sep 2015 23:08:19 +0000 (UTC), you wrote:

>"Jon Kirwan [hidden email] [msp430]" <[hidden email]>:
>
>> You can look up ideas with google using "sampled strain gauge
>> signal conditioner" and see where that takes you. I'd avoid
>> the sigma-delta for a pulse-powered bridge, though. But
>> perhaps you can get enough experimental data from that one to
>> see if you can make it work okay. I've never attempted it so
>> I really don't have any experience to draw on, regarding real
>> results. I just avoid them when I know I will be powering up
>> and powering down an analog input system or using an analog
>> input multiplexer. (They generally "don't like" switched
>> inputs as it takes them time to "re-acquire" an input without
>> mixing it up into a mush from the other states the input goes
>> though.)
>
>Jon, thank you for your idea's.

Well, don't thank me too quickly. I haven't helped at all.
Just offered a few of my mostly ignorant thoughts.

>Isn't it possible to just "pause" the sampling of the delta sigma converter
>(let it sleeping, all registers keep their values) and awake it after 100ms
>with nearly the same input level as before the sleep?

I haven't seen one work like that. They are basically very
fast "1 bit" converters with a lot of state behind it. It
takes a long time for those "bits" to fill the state. Once
you get the pipeline filled up, you can get very precise
values at a fairly reasonable rate.... if it is still
attached to the same input which is "drifting" around the
nominal value at less than some specified rate. But the
sample rate is based upon an ALREADY FILLED pipeline. You
have to fill it before the first value is really any good.
You can find out how long it takes to fill the state and, in
my limited experience, that will take a LOT LONGER than the
specified sample rate for the unit.

Whether or not you are able to stop the filling process on a
dime is another question. I haven't spent the time on the
MSP430 24 bit sigma-delta module. Nor have I tested it. So I
can't offer any experience there. Perhaps if you shut down
the module, then shut off the power to the bridge, and before
starting the module back up again first re-power the bridge,
you might be okay. But one problem of several that comes to
mind is that the bridge value may have drifted too far away
from its earlier value and may require, therefore, a complete
"refill" in order to re-acquire the ADC value. Even with all
that. So you'd need to explore this, I think. The counter to
what I just wrote is that you aren't looking for 24 bits or
21 bits or even 16 bits... but more like 12? So.... maybe.

>The sd24_a input is
>just a 18pF capacitor. The 350ohms will charge it quickly...

Hehe. That's true. Have you computed your expected S/N for
the analog portion of the input system, yet? Just curious.

>Sure, I have to clock the adc as long as it is required to step the new
>reading completely through the full decimation filter.
>
>The PIR example from texas instrument slaa283 is quite interesting,
>It uses the sd16 to sample a big capacitor behind the PIR sensor. It is
>sampling the input for 1ms (4 samples each time) and sleep for 341ms. It
>seems interrupted sampling is possible with delta sigma too.

I've just used the ADC10 and ADC12 sections, never the SD16
section. But yes, if you find some good examples there then I
think that you may be able to cross-apply them to your case.
Again... test things out. But perhaps it will work out fine.

>To further reduce power consumtion they also switch the reference voltage
>off during sleep. It seems that the charge in the capacitor at the ref-pin
>will stay - accurate enough for this application - at ref-level for 341ms.
>
>https://www.olimex.com/Products/MSP430/Starter/MSP430-
>PIR/resources/slaa283.pdf

Yes. To save power you should switch off everything you can
think of and handle. That's a given.

I'm interested in what you find out. I think you already have
figured out enough to take a fair shot at it. Sounds like you
may be able to do just fine. [Personally? I'd have preferred
to use an ADC12 or ADC10 section and use over sampling to
achieve the desired resolution... after making sure that my
noise is where it needs to be (for an ADC12 the noise should
be about 1000 ppm or so, I think, and for an ADC10 perhaps
5000 ppm; then use averaging to squeeze back down.)]

Jon
Reply | Threaded
Open this post in threaded view
|

Re: Re: SD24 to sample a resistive bridge with pulsed bridge supply

MSP430 - Discuss mailing list
"Jon Kirwan [hidden email] [msp430]" <[hidden email]>:

> On Sun, 13 Sep 2015 23:08:19 +0000 (UTC), you wrote:

>>Isn't it possible to just "pause" the sampling of the delta sigma
>>converter (let it sleeping, all registers keep their values) and awake
>>it after 100ms with nearly the same input level as before the sleep?
>
> I haven't seen one work like that. They are basically very
> fast "1 bit" converters with a lot of state behind it. It
> takes a long time for those "bits" to fill the state. Once
> you get the pipeline filled up, you can get very precise
> values at a fairly reasonable rate.... if it is still
> attached to the same input which is "drifting" around the
> nominal value at less than some specified rate. But the
> sample rate is based upon an ALREADY FILLED pipeline. You
> have to fill it before the first value is really any good.
> You can find out how long it takes to fill the state and, in
> my limited experience, that will take a LOT LONGER than the
> specified sample rate for the unit.

The question is: how does the decimation filter work. In case it is working
like a FIR, then it should be filled after a fixed time and I should ne able
to find out, how long it take, in case it is a IIR, well then the fill-time
is not really fixed....
 
>>The sd24_a input is
>>just a 18pF capacitor. The 350ohms will charge it quickly...
>
> Hehe. That's true. Have you computed your expected S/N for
> the analog portion of the input system, yet? Just curious.

No, not yet. :-) Maybe the noise from the resistors will be quite large and I
have to add additinal capacitance to get it lower? I am not experienced with
calculating noise figures, but surpricingly according to

https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise

it seems the noise in a RC system does not depend from R, just
from C, and with 18pF it is 15uV/sqrt(Hz) and at 100nF it is at
0.2uV/sqrt(Hz), and it takes (7*tau) 250us to stabilize.
I am at 10Hz sample rate, so I think I do not have to add a sample and hold
circuit to further reduce this time and increase accuracy..

> I'm interested in what you find out. I think you already have
> figured out enough to take a fair shot at it. Sounds like you
> may be able to do just fine. [Personally? I'd have preferred
> to use an ADC12 or ADC10 section and use over sampling to
> achieve the desired resolution... after making sure that my
> noise is where it needs to be (for an ADC12 the noise should
> be about 1000 ppm or so, I think, and for an ADC10 perhaps
> 5000 ppm; then use averaging to squeeze back down.)]

I will give it a try; on last week I was still in the "find out how" phase of
the project, now it is getting more and more out of the dust, it is nice to
share ideas with you. :-)

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: Re: SD24 to sample a resistive bridge with pulsed bridge supply

MSP430 - Discuss mailing list
On Mon, 14 Sep 2015 07:21:42 +0000 (UTC), you wrote:

>"Jon Kirwan [hidden email] [msp430]" <[hidden email]>:
>
>> On Sun, 13 Sep 2015 23:08:19 +0000 (UTC), you wrote:
>
>>>Isn't it possible to just "pause" the sampling of the delta sigma
>>>converter (let it sleeping, all registers keep their values) and awake
>>>it after 100ms with nearly the same input level as before the sleep?
>>
>> I haven't seen one work like that. They are basically very
>> fast "1 bit" converters with a lot of state behind it. It
>> takes a long time for those "bits" to fill the state. Once
>> you get the pipeline filled up, you can get very precise
>> values at a fairly reasonable rate.... if it is still
>> attached to the same input which is "drifting" around the
>> nominal value at less than some specified rate. But the
>> sample rate is based upon an ALREADY FILLED pipeline. You
>> have to fill it before the first value is really any good.
>> You can find out how long it takes to fill the state and, in
>> my limited experience, that will take a LOT LONGER than the
>> specified sample rate for the unit.
>
>The question is: how does the decimation filter work. In case it is working
>like a FIR, then it should be filled after a fixed time and I should ne able
>to find out, how long it take, in case it is a IIR, well then the fill-time
>is not really fixed....

It's NOT an IIR. I don't know the details, because I haven't
taken the time to do more than read the occasional discussion
from manufacturers. But I do know that it is more like an FIR
+ some stuff that "shapes the noise" where possible to push
it into higher frequencies, so that it can be nicely cut off
in the digital filters.

It is this "noise shaping part" that I feel is a uniquely
added concept to an FIR. So it's not exactly an FIR, as I
ignorantly see it. I believe some smart person worked out a
method, looking over the 1-bit converter process, that could
help push the shape of the normal distribution of noise so
that it's a somewhat distorted distribution. But as I said,
I'm ignorant about the details.

>>>The sd24_a input is
>>>just a 18pF capacitor. The 350ohms will charge it quickly...
>>
>> Hehe. That's true. Have you computed your expected S/N for
>> the analog portion of the input system, yet? Just curious.
>
>No, not yet. :-) Maybe the noise from the resistors will be quite large and I
>have to add additinal capacitance to get it lower? I am not experienced with
>calculating noise figures, but surpricingly according to
>
>https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise

The following has almost nothing to do with the question at
hand, but I thought it would be worth writing out what I
understand of some basics, first.

There is a treatment of noise issues from resistors and
capacitors -- both are based upon the fundamental idea of
assuming an equipartion of thermal energy, 1/2 kT per
available vibrational mode (almost always a valid
assumption.)

Thermal noise is also "Johnson noise" in the early
literature, but as a hobbyist perspective I think Johnson
noise has become associated with resistor noise today.
Capacitor noise, though technically based on the same
mechanism but with a different resulting algebraic equation,
might also be called Johnson noise. But most reading I've
done doesn't use Johnson noise for that.

The electromotive force developed across the ends of a
conductor due to Thermal noise is una ected by the presence
or absence of direct current. Electron thermal velocities in
a conductor are much greater than electron drift velocities
by a factor of a 1000 or more. This means you don't worry
about current noise, as something inherent in the current,
unless it crosses a PN junction (diode.) If it does, because
this affects the above relationship of thermal vs drift
velocities, you get "shot noise" and you have to take it into
account. To add things, though, you have to put apples to
apples -- so it needs to be converted to an equivalent
voltage noise first or else visa versa.

There is also flicker noise. This in resistors depends on
manufacturing. But there is flicker noise in the base
junction of BJTs, FETs, and so on. In BJTs, flicker noise is
said to increase a lot if the BE junction is subjected to
repeated breakdown voltages (often, that value can be in the
area of 5-6V or so, which can easily happen in switcher
circuits where the base isn't well protected when turned
off.)

Back to the topic. Your input amplifier is responding to
voltage. So what you want is some kind of estimate of the
"equivalent voltage noise" as referred to the input (or you
could refer things to the output... but you don't control
what is attached there.)

I did a quick search. You might read this paper:

http://users.ece.gatech.edu/mleach/papers/AnalogNoise.pdf

Just get down into it a few pages and you'll see some
treatments there. I can't vouch for it, as I haven't read it,
but it seems to broadly cover the kind of analysis I was
wondering about.

The point here is that if you were using over-sampling to
achieve your 12-bit precision figure, then you'd want to set
your noise level (S/N) to about 2-3 bits WORSE than your ADC
specified precision. Noise tends to be Poison in nature,
which integrated looks like a Gaussian curve. And more
averaging of Poisson events narrows the skirts of the
Gaussian nicely, so averaging works in this case. But you
need noise to create that random walk process so that the
averaging can do its work. If you have too little noise,
averaging is pretty much useless in making things better.

So if you know in advance you will be averaging to improve
precision, you want to know that your noise is Poisson around
the "real value."

>it seems the noise in a RC system does not depend from R, just
>from C, and with 18pF it is 15uV/sqrt(Hz) and at 100nF it is at
>0.2uV/sqrt(Hz), and it takes (7*tau) 250us to stabilize.
>I am at 10Hz sample rate, so I think I do not have to add a sample and hold
>circuit to further reduce this time and increase accuracy..

In low pass filters, I think that is correct. (I don't recall
seeing an analysis for a high pass filter, so I'm reserving
judgment there.)

Because it is so "fast" with respect to your desired sample
rate, though, I think this is an argument for more filtering.
Here's my thinking.

You want a measurement period of 100ms. If you have a high
bandwidth input signal, it will move around a lot. This is
because everything is proportional to the square root of
bandwidth. A wider bandwidth means more probability at
distant skirts away from the real signal. And that is what
your ADC will be "seeing." (Now, again, none of this
necessarily applies to sigma-delta in quite the same way,
because of those "noise shaping" things they do that I don't
fully appreciate.) So without a sample and hold, you want as
much low pass filtering as you can get away with, consistent
with a fast enough response time that your input "settles"
before your next sample.

So, let's say you want your signal to settle to within 12
bits of precision between these 100ms samples. Let's say to
1/2 bit. With 12 bits, that's 1:8000, or so. Solving for
time, you want tau = 11ms. That is, if I got the calcs right:

        tau = t / ln(8000) = 100ms / ln(8000) approx 11.1ms

Your tau is, therefore, too fast. Which means you are letting
in unnecessarily high noise.

But then, you are using a sigma-delta. So... I'm not sure how
that thinking should be modified.

>> I'm interested in what you find out. I think you already have
>> figured out enough to take a fair shot at it. Sounds like you
>> may be able to do just fine. [Personally? I'd have preferred
>> to use an ADC12 or ADC10 section and use over sampling to
>> achieve the desired resolution... after making sure that my
>> noise is where it needs to be (for an ADC12 the noise should
>> be about 1000 ppm or so, I think, and for an ADC10 perhaps
>> 5000 ppm; then use averaging to squeeze back down.)]
>
>I will give it a try; on last week I was still in the "find out how" phase of
>the project, now it is getting more and more out of the dust, it is nice to
>share ideas with you. :-)

Hehe. I'll learn, too. I probably said something (more than
one) stupid above and someone will correct me. Or you will.
And I'll gain a somewhat better understanding from that,
which is all to the good.

Jon

>
>Matthias
>
>
>
>------------------------------------
>Posted by: Matthias Weingart <[hidden email]>
>------------------------------------
>
>To unsubscribe from the msp430 group, send an email to:
>[hidden email]
>
>
>------------------------------------
>
>Yahoo Groups Links
>
>
>
Reply | Threaded
Open this post in threaded view
|

Cycle Counting--Too Many

MSP430 - Discuss mailing list
I am using Tom Baugh's MSP430F2274 board and software in a class.  We are also using IAR Kickstart.

In his second lab exercise, BetterNextProject, we see various timing interrupt methods and LPM3 to reduce the number of cycles and power consumed.  Each time the LED output, P1.0, toggles due to a timer firing its interrupt, the SMCLK can be seen making a burst of 28 cycles of running in active mode.  Analyzing the disassembly code and reading the Family User's Guide, I can only account for 24 cycles.

Here are the details:

Action/Instruction (in execution order)          Cycles (from Tables 3-14 & 16 in the Family User's Guide)

            Interrupt Accepted                             6
008094  bic.w #0xF0, 0x0(SP)                         5     // First line of WatchdogTimer_ISR.  All low-power modes cleared.
00809A  reti                                                  5
008050  xor.b #0x1,&P1OUT                          4      // Constant Generator register source to absolute destination.
                                                                           // This toggles the LED.
008054  jmp 0x804C                                      2      // End of While Loop.

00804C  bis.w #0xD8,SR                                2      // Beginning of While Loop.  Start LPM3.  Instruction immediately    
                                                                 ___     //before the XOR.
Total                                                          24 cycles
 
When I monitor SMCLK on P2.1 on an oscilloscope, it idles high and has 28 falling edges.  In addition, the LED toggles on the 22nd falling edge.  

I count 24 cycles in the code, but measure 28 on the oscilloscope.  (And I count 20 until the end of the instruction toggling the LED but measure it occurring on the 22nd falling edge.

So, what am I missing?

Thanks,

Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
I know it makes sense that "xor.b #0x1,&P1OUT" should be 4
cycles, given the constant generator. But can you find the
specific statement in the Family Guide that mentions using
the constant generator, instead of an inline constant,
requires one less clock than it would if the constant were
say #0xDD?

I just looked at SLAA0024 on TI's web site, looking at a
table on page 9-24, section 9.3.1, and it looks to me like it
is still 5 cycles. If I'm reading this correctly, then that
is at least one tiny detail to start the process of
accounting for differences.

I haven't spent more than 10 minutes yet, though. Just a
quick scan and then dragging up the PDFs for a moment. The
other thing that crosses my mind is if there might be a few
SMCLKs involved after the LPM mode bits are changed to sleep
the CPU. Do you know if there is a paper around where
counting SMCLK cycles at a pin is addressed when going into
sleep, or coming out? I don't recall reading one, but perhaps
looking for one might also help resolve the question.

Meanwhile, if something else comes to mind I'll post it.

Jon
Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
In reply to this post by MSP430 - Discuss mailing list
How is the xor.b   #01,&p1out encoded? It would still potentially
disassemble correctly if it didn't use the register for the #01, but
would then require 3 words. As Jon says, that would still only recover 1
clock for you. I haven't tried this myself, so don't know what else
might be added but can you stop the process after the reti.? A break on
the xor.b might change the behaviour, if so, perhaps move the LPM3 start
instruction there and see what happens.

Al

On 18/09/2015 4:57 AM, 'Redd, Emmett R' [hidden email]
[msp430] wrote:

> I am using Tom Baugh's MSP430F2274 board and software in a class.  We are also using IAR Kickstart.
>
> In his second lab exercise, BetterNextProject, we see various timing interrupt methods and LPM3 to reduce the number of cycles and power consumed.  Each time the LED output, P1.0, toggles due to a timer firing its interrupt, the SMCLK can be seen making a burst of 28 cycles of running in active mode.  Analyzing the disassembly code and reading the Family User's Guide, I can only account for 24 cycles.
>
> Here are the details:
>
> Action/Instruction (in execution order)          Cycles (from Tables 3-14 & 16 in the Family User's Guide)
>
>              Interrupt Accepted                             6
> 008094  bic.w #0xF0, 0x0(SP)                         5     // First line of WatchdogTimer_ISR.  All low-power modes cleared.
> 00809A  reti                                                  5
> 008050  xor.b #0x1,&P1OUT                          4      // Constant Generator register source to absolute destination.
>                                                                             // This toggles the LED.
> 008054  jmp 0x804C                                      2      // End of While Loop.
>
> 00804C  bis.w #0xD8,SR                                2      // Beginning of While Loop.  Start LPM3.  Instruction immediately
>                                                                   ___     //before the XOR.
> Total                                                          24 cycles
>  
> When I monitor SMCLK on P2.1 on an oscilloscope, it idles high and has 28 falling edges.  In addition, the LED toggles on the 22nd falling edge.
>
> I count 24 cycles in the code, but measure 28 on the oscilloscope.  (And I count 20 until the end of the instruction toggling the LED but measure it occurring on the 22nd falling edge.
>
> So, what am I missing?
>
> Thanks,
>
> Emmett Redd Ph.D.   mailto:[hidden email]
> Professor                                 (417)836-5221
> Department of Physics, Astronomy, and Materials Science
> Missouri State University             Fax (417)836-6226
> 901 SOUTH NATIONAL                   Lab (417)836-3770
> SPRINGFIELD, MO  65897   USA    Dept (417)836-5131
>
> In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
>
>
> ------------------------------------
> Posted by: "Redd, Emmett R" <[hidden email]>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> [hidden email]
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Cycle Counting--Too Many

MSP430 - Discuss mailing list
Yes, the xor.b is encoded as two words (E3D2 0021) and this is consistent with Table 3-16 (to partially answer Jon's question)


Addressing Mode Length of

Src   Dst    No. of Cycles    Length of Instruction       Example

Rn    &EDE         4                   2                  MOV R5,&EDE

versus

#N    &EDE         5                   3                  ADD #33,&EDE


And to further address Jon's question the Family Guide has a list of advantages for using the constant generators:

The constant generator advantages are:

• No special instructions required

• No additional code word for the six constants

• No code memory access required to retrieve the constant


The last one implies saving a cycle although it does not explicitly say so.

But, Jon's SLAA024 has this:


If the interrupt is requested during the low power modes 3 or 4, then additional two cycles are needed.


So that counts for 2 of the 4 missing cycles although it gives no further explanation.  It would be easy to try the other low power modes and see what happens.  The LED reference signal could also help determine when those 2 extra cycles happen.

Concerning stopping the process after the RETI, not clearing the low-power bits inside the ISR would do that.

So, I have a couple of things to try and a new (to me) document to read.  I'll report back when I have some more details.

Thanks both of you for the help and pointers.

Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.

________________________________
From: [hidden email] [[hidden email]]
Sent: Thursday, September 17, 2015 10:32 PM
To: [hidden email]
Subject: Re: [msp430] Cycle Counting--Too Many



How is the xor.b   #01,&p1out encoded? It would still potentially disassemble correctly if it didn't use the register for the #01, but would then require 3 words. As Jon says, that would still only recover 1 clock for you. I haven't tried this myself, so don't know what else might be added but can you stop the process after the reti.? A break on the xor.b might change the behaviour, if so, perhaps move the LPM3 start instruction there and see what happens.

Al

On 18/09/2015 4:57 AM, 'Redd, Emmett R' [hidden email]<mailto:[hidden email]> [msp430] wrote:

I am using Tom Baugh's MSP430F2274 board and software in a class.  We are also using IAR Kickstart.

In his second lab exercise, BetterNextProject, we see various timing interrupt methods and LPM3 to reduce the number of cycles and power consumed.  Each time the LED output, P1.0, toggles due to a timer firing its interrupt, the SMCLK can be seen making a burst of 28 cycles of running in active mode.  Analyzing the disassembly code and reading the Family User's Guide, I can only account for 24 cycles.

Here are the details:

Action/Instruction (in execution order)          Cycles (from Tables 3-14 & 16 in the Family User's Guide)

            Interrupt Accepted                             6
008094  bic.w #0xF0, 0x0(SP)                         5     // First line of WatchdogTimer_ISR.  All low-power modes cleared.
00809A  reti                                                  5
008050  xor.b #0x1,&P1OUT                          4      // Constant Generator register source to absolute destination.
                                                                           // This toggles the LED.
008054  jmp 0x804C                                      2      // End of While Loop.

00804C  bis.w #0xD8,SR                                2      // Beginning of While Loop.  Start LPM3.  Instruction immediately
                                                                 ___     //before the XOR.
Total                                                          24 cycles

When I monitor SMCLK on P2.1 on an oscilloscope, it idles high and has 28 falling edges.  In addition, the LED toggles on the 22nd falling edge.

I count 24 cycles in the code, but measure 28 on the oscilloscope.  (And I count 20 until the end of the instruction toggling the LED but measure it occurring on the 22nd falling edge.

So, what am I missing?

Thanks,

Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.


------------------------------------
Posted by: "Redd, Emmett R" <[hidden email]><mailto:[hidden email]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[hidden email]<mailto:[hidden email]>


------------------------------------

Yahoo Groups Links









Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
On Fri, 18 Sep 2015 09:44:06 -0500, you wrote:

> But, Jon's SLAA024 has this:
>
> If the interrupt is requested during the low power modes 3
> or 4, then additional two cycles are needed.

Your discovery, here, of the two additional cycles for the
interrupt accounts exactly for the 22 vs 20 cycles regarding
the LED itself.

and, the table on page 9-24, section 9.3.1, that I earlier
also pointed out on SLAA0024 which makes it explicit in my
own view that one of your instructions requires 5 cycles, not
4 ...

It looks like together we may have accounted for three of the
four cycles you are seeing.

Not perfect. But not bad. Narrowing in on the observations,
at least.

Jon
Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
In reply to this post by MSP430 - Discuss mailing list
I forgot to add another thought about your "Table 3-16" here:

On Fri, 18 Sep 2015 09:44:06 -0500, you wrote:

>Addressing Mode Length of
>Src   Dst    No. of Cycles    Length of Instruction       Example
>Rn    &EDE         4                   2                  MOV R5,&EDE versus
>#N    &EDE         5                   3                  ADD #33,&EDE

as juxtapositioned against the table on page 9-24, section
9.3.1, that I earlier pointed out on SLAA0024. That table I
provided IS explicit. Your table is also explicit. They are
in conflict, it appears. Mine comes from an ancient MSP430
document and it may be wrong, now. I don't know.

So this means to perhaps try out the simulator or, if
possible, to use an actual emulation through a JTAG port and
see what actually transpires.

Can you do that test?

Jon
Reply | Threaded
Open this post in threaded view
|

RE: Cycle Counting--Too Many

MSP430 - Discuss mailing list
Jon,

I think your argument in using only the figure on page 9-24 of SLAA024 is flawed in that the figure does not account for Constant Generator use for the 6 (from memory?) constants unless the reader makes the conversion to register mode for them.  Now we could go back and forth on this for a long time, so I just programmed a second xor.b #0x1,&P1OUT to immediately follow the first.  The resulting pulse is 4 cycles long.  And, just to be complete I changed the two xors to xor.b #0x11,&P1OUT.  This pulse is 5 cycles long.
/end/ message to Jon

So far, I have found two more things:

1) LPM2 needs to be added to the list of LPM 3 and 4 needing 2 extra cycles;  Its burst length is the same as LPM3; I have not and probably will not test LPM4.

2)Curiouser and curiouser: If I just comment out the clearing of the low power modes within the ISR, I count a burst of 12 cycles but the 8 cycles for LPM3 Interrupt Acceptance and 5 for RETI says the burst should be 13.  (I was about to give a crazy enough analysis here that would have almost been bad enough to justify removing me from the group, but, luckily, I was aroused from my sleep-deprived stupor.)

I'll keep investigating, but may be silent over the weekend and into next week.

Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
________________________________________
From: [hidden email] [[hidden email]]
Sent: Friday, September 18, 2015 12:02 PM
To: MSP430 List
Subject: Re: [msp430] Cycle Counting--Too Many

I forgot to add another thought about your "Table 3-16" here:

On Fri, 18 Sep 2015 09:44:06 -0500, you wrote:

>Addressing Mode Length of
>Src   Dst    No. of Cycles    Length of Instruction       Example
>Rn    &EDE         4                   2                  MOV R5,&EDE versus
>#N    &EDE         5                   3                  ADD #33,&EDE

as juxtapositioned against the table on page 9-24, section
9.3.1, that I earlier pointed out on SLAA0024. That table I
provided IS explicit. Your table is also explicit. They are
in conflict, it appears. Mine comes from an ancient MSP430
document and it may be wrong, now. I don't know.

So this means to perhaps try out the simulator or, if
possible, to use an actual emulation through a JTAG port and
see what actually transpires.

Can you do that test?

Jon


------------------------------------
Posted by: Jon Kirwan <[hidden email]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[hidden email]


------------------------------------

Yahoo Groups Links



    https://info.yahoo.com/legal/us/yahoo/utos/terms/
Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
On Fri, 18 Sep 2015 14:56:33 -0500, you wrote:

> I think your argument in using only the figure on page 9-24
> of SLAA024 is flawed in that the figure does not account for
> Constant Generator use for the 6 (from memory?) constants
> unless the reader makes the conversion to register mode for
> them.

I completely took your first post's point on this issue, as
well. It makes sense, too. Just as you say. I take your point
above, once again.

> Now we could go back and forth on this for a long
> time,

I really didn't want to belabor things. I just wanted to
tweek your thinking so that you'd do an experiment. The
documentation wasn't outright explicit about it, as I read
through it.

> so I just programmed a second xor.b #0x1,&P1OUT to
> immediately follow the first.  The resulting pulse is 4
> cycles long.  And, just to be complete I changed the two
> xors to xor.b #0x11,&P1OUT.  This pulse is 5 cycles long.

Perfect!

><snip>
> Curiouser and curiouser: If I just comment out the clearing
> of the low power modes within the ISR, I count a burst of 12
> cycles but the 8 cycles for LPM3 Interrupt Acceptance and 5
> for RETI says the burst should be 13.
><snip>

Interesting. I really enjoy seeing the detailed work going on
here and will be very interested in how things resolve as you
work through it. I do similar kinds of tests (often to the
despair of those who would prefer I just accept "handwaving"
and call it "close enough for horseshoes"), so I really like
seeing when someone else is just as anal about the details as
I prefer. Will be watching, so please do update when you have
more information on this.

Jon
Reply | Threaded
Open this post in threaded view
|

RE: Cycle Counting--Too Many

MSP430 - Discuss mailing list
First, a summary and then details will follow.



Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
________________________________________
From: [hidden email] [[hidden email]]
Sent: Friday, September 18, 2015 3:16 PM
To: MSP430 List
Subject: Re: [msp430] Cycle Counting--Too Many

On Fri, 18 Sep 2015 14:56:33 -0500, you wrote:

> I think your argument in using only the figure on page 9-24
> of SLAA024 is flawed in that the figure does not account for
> Constant Generator use for the 6 (from memory?) constants
> unless the reader makes the conversion to register mode for
> them.

I completely took your first post's point on this issue, as
well. It makes sense, too. Just as you say. I take your point
above, once again.

> Now we could go back and forth on this for a long
> time,

I really didn't want to belabor things. I just wanted to
tweek your thinking so that you'd do an experiment. The
documentation wasn't outright explicit about it, as I read
through it.

> so I just programmed a second xor.b #0x1,&P1OUT to
> immediately follow the first.  The resulting pulse is 4
> cycles long.  And, just to be complete I changed the two
> xors to xor.b #0x11,&P1OUT.  This pulse is 5 cycles long.

Perfect!

><snip>
> Curiouser and curiouser: If I just comment out the clearing
> of the low power modes within the ISR, I count a burst of 12
> cycles but the 8 cycles for LPM3 Interrupt Acceptance and 5
> for RETI says the burst should be 13.
><snip>

Interesting. I really enjoy seeing the detailed work going on
here and will be very interested in how things resolve as you
work through it. I do similar kinds of tests (often to the
despair of those who would prefer I just accept "handwaving"
and call it "close enough for horseshoes"), so I really like
seeing when someone else is just as anal about the details as
I prefer. Will be watching, so please do update when you have
more information on this.

Jon


------------------------------------
Posted by: Jon Kirwan <[hidden email]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[hidden email]


------------------------------------

Yahoo Groups Links



    https://info.yahoo.com/legal/us/yahoo/utos/terms/
Reply | Threaded
Open this post in threaded view
|

RE: Cycle Counting--Too Many

MSP430 - Discuss mailing list
In reply to this post by MSP430 - Discuss mailing list
Please ignore today's previous email.  Windows 10 and my touchpad sent it before I had put all the information contained in this email.

Update:  First a summary and then the details.

Summary:  There remain two extra cycles when going into and out of LPM3 and there is still one cycle short when the low-power bits are not cleared and the main never gets to run in active mode.

Details:

Since the xor and oscilloscope functions like a print statement for me in debugging, I decided to put one in between every operation I could.  And, since the xor transitions on the falling edge of SMCLK, I will be counting the falling edge as the end of a cpu cycle.

So, with the first instruction in the ISR being an xor, it should be 8 (interrupt acceptance in LPM3) + 4 (xor) = 12 to first LED edge.  That is what I count IF the long, SMCLK idling high, cycle is counted as the first cycle. Then comes the bic (5 cycles) to clear the low-power bits and xor (4 cycles) for a total of 9.  The next edge comes after the 5-cycle RETI and 4-cycle xor.  The next edge comes after a 2-cycle jmp and a 4-cycle xor.  Then comes the 2-cycle bis that sets the low-power bits and 2 unexplained cycles before the long cycle counted as the first cycle above.

Speculation: Could it be that it takes an undocumented 2 cycles for the clocks to get into a low power mode like it takes a barely-documented 2 cycles to get out?

When not clearing the low-power bits in the ISR, the SMCLK burst remains 1 cycle short.  If RETI is the only instruction, 12 cycles (11 short and 1 long) are all that appear.  With the ISR consisting of two xors and RETI, it is 20 cycles long (19 short and 1 long).  The first xor indicates that the long cycle remains with the 8 cycles of the interrupt acceptance in LPM3; the RETI is only 4 cycles (not 5 as documented).

I cannot think of any experiments from here.

Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
________________________________________
From: [hidden email] [[hidden email]]
Sent: Friday, September 18, 2015 3:16 PM
To: MSP430 List
Subject: Re: [msp430] Cycle Counting--Too Many

On Fri, 18 Sep 2015 14:56:33 -0500, you wrote:

> I think your argument in using only the figure on page 9-24
> of SLAA024 is flawed in that the figure does not account for
> Constant Generator use for the 6 (from memory?) constants
> unless the reader makes the conversion to register mode for
> them.

I completely took your first post's point on this issue, as
well. It makes sense, too. Just as you say. I take your point
above, once again.

> Now we could go back and forth on this for a long
> time,

I really didn't want to belabor things. I just wanted to
tweek your thinking so that you'd do an experiment. The
documentation wasn't outright explicit about it, as I read
through it.

> so I just programmed a second xor.b #0x1,&P1OUT to
> immediately follow the first.  The resulting pulse is 4
> cycles long.  And, just to be complete I changed the two
> xors to xor.b #0x11,&P1OUT.  This pulse is 5 cycles long.

Perfect!

><snip>
> Curiouser and curiouser: If I just comment out the clearing
> of the low power modes within the ISR, I count a burst of 12
> cycles but the 8 cycles for LPM3 Interrupt Acceptance and 5
> for RETI says the burst should be 13.
><snip>

Interesting. I really enjoy seeing the detailed work going on
here and will be very interested in how things resolve as you
work through it. I do similar kinds of tests (often to the
despair of those who would prefer I just accept "handwaving"
and call it "close enough for horseshoes"), so I really like
seeing when someone else is just as anal about the details as
I prefer. Will be watching, so please do update when you have
more information on this.

Jon


------------------------------------
Posted by: Jon Kirwan <[hidden email]>
------------------------------------

To unsubscribe from the msp430 group, send an email to:
[hidden email]


------------------------------------

Yahoo Groups Links



    https://info.yahoo.com/legal/us/yahoo/utos/terms/
Reply | Threaded
Open this post in threaded view
|

RE: Cycle Counting--Too Many

MSP430 - Discuss mailing list
Another update:  I posted to the Texas Instruments e2e site:  https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/454350 and received one answer.  It contains no direct knowledge nor reference to documentation that directly applies.  Although I don't really mean it to sound negative, it is a bit of a let-down that the answer may turn out to be the best available.

Emmett Redd Ph.D.   mailto:[hidden email]
Professor                                 (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University             Fax (417)836-6226
901 SOUTH NATIONAL                   Lab (417)836-3770
SPRINGFIELD, MO  65897   USA    Dept (417)836-5131

In statesmanship get the formalities right, never mind about the moralities. -- Mark Twain.
Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
In reply to this post by MSP430 - Discuss mailing list
See that's the problem you have the most notorious virus there is.....
Windows....

On Tue, Sep 22, 2015 at 11:00 AM, 'Redd, Emmett R'
[hidden email] [msp430] <[hidden email]> wrote:

>
>
> Please ignore today's previous email. Windows 10 and my touchpad sent it
> before I had put all the information contained in this email.
>
> Update: First a summary and then the details.
>
> Summary: There remain two extra cycles when going into and out of LPM3 and
> there is still one cycle short when the low-power bits are not cleared and
> the main never gets to run in active mode.
>
> Details:
>
> Since the xor and oscilloscope functions like a print statement for me in
> debugging, I decided to put one in between every operation I could. And,
> since the xor transitions on the falling edge of SMCLK, I will be counting
> the falling edge as the end of a cpu cycle.
>
> So, with the first instruction in the ISR being an xor, it should be 8
> (interrupt acceptance in LPM3) + 4 (xor) = 12 to first LED edge. That is
> what I count IF the long, SMCLK idling high, cycle is counted as the first
> cycle. Then comes the bic (5 cycles) to clear the low-power bits and xor (4
> cycles) for a total of 9. The next edge comes after the 5-cycle RETI and
> 4-cycle xor. The next edge comes after a 2-cycle jmp and a 4-cycle xor.
> Then comes the 2-cycle bis that sets the low-power bits and 2 unexplained
> cycles before the long cycle counted as the first cycle above.
>
> Speculation: Could it be that it takes an undocumented 2 cycles for the
> clocks to get into a low power mode like it takes a barely-documented 2
> cycles to get out?
>
> When not clearing the low-power bits in the ISR, the SMCLK burst remains 1
> cycle short. If RETI is the only instruction, 12 cycles (11 short and 1
> long) are all that appear. With the ISR consisting of two xors and RETI, it
> is 20 cycles long (19 short and 1 long). The first xor indicates that the
> long cycle remains with the 8 cycles of the interrupt acceptance in LPM3;
> the RETI is only 4 cycles (not 5 as documented).
>
> I cannot think of any experiments from here.
>
> Emmett Redd Ph.D. mailto:[hidden email]
> Professor (417)836-5221
> Department of Physics, Astronomy, and Materials Science
> Missouri State University Fax (417)836-6226
> 901 SOUTH NATIONAL Lab (417)836-3770
> SPRINGFIELD, MO 65897 USA Dept (417)836-5131
>
> In statesmanship get the formalities right, never mind about the
> moralities. -- Mark Twain.
> ________________________________________
> From: [hidden email] [[hidden email]]
> Sent: Friday, September 18, 2015 3:16 PM
> To: MSP430 List
> Subject: Re: [msp430] Cycle Counting--Too Many
>
> On Fri, 18 Sep 2015 14:56:33 -0500, you wrote:
>
> > I think your argument in using only the figure on page 9-24
> > of SLAA024 is flawed in that the figure does not account for
> > Constant Generator use for the 6 (from memory?) constants
> > unless the reader makes the conversion to register mode for
> > them.
>
> I completely took your first post's point on this issue, as
> well. It makes sense, too. Just as you say. I take your point
> above, once again.
>
> > Now we could go back and forth on this for a long
> > time,
>
> I really didn't want to belabor things. I just wanted to
> tweek your thinking so that you'd do an experiment. The
> documentation wasn't outright explicit about it, as I read
> through it.
>
> > so I just programmed a second xor.b #0x1,&P1OUT to
> > immediately follow the first. The resulting pulse is 4
> > cycles long. And, just to be complete I changed the two
> > xors to xor.b #0x11,&P1OUT. This pulse is 5 cycles long.
>
> Perfect!
>
> ><snip>
> > Curiouser and curiouser: If I just comment out the clearing
> > of the low power modes within the ISR, I count a burst of 12
> > cycles but the 8 cycles for LPM3 Interrupt Acceptance and 5
> > for RETI says the burst should be 13.
> ><snip>
>
> Interesting. I really enjoy seeing the detailed work going on
> here and will be very interested in how things resolve as you
> work through it. I do similar kinds of tests (often to the
> despair of those who would prefer I just accept "handwaving"
> and call it "close enough for horseshoes"), so I really like
> seeing when someone else is just as anal about the details as
> I prefer. Will be watching, so please do update when you have
> more information on this.
>
> Jon
>
> ------------------------------------
> Posted by: Jon Kirwan <[hidden email]>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> [hidden email]
>
> ------------------------------------
>
> Yahoo Groups Links
>
> https://info.yahoo.com/legal/us/yahoo/utos/terms/
>
>
>



--
Thomas J. Grajewski
Reply | Threaded
Open this post in threaded view
|

Re: Cycle Counting--Too Many

MSP430 - Discuss mailing list
In reply to this post by MSP430 - Discuss mailing list
On Wed, 23 Sep 2015 15:48:17 -0500, you wrote:

> Another update:  I posted to the Texas Instruments e2e site:
> https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/454350
> and received one answer.  It contains no direct knowledge
> nor reference to documentation that directly applies.
> Although I don't really mean it to sound negative, it is a
> bit of a let-down that the answer may turn out to be the
> best available.

Interesting answer you got.

I had been thinking about the pipeline and had prepared
several pages here with it operating the way I see it in my
mind's eye (I've designed a cpu or two in my life, so I have
perhaps a very small clue here.) I didn't publish it here,
though, as I still wanted to find time to go back through it
before showing my ignorance to all and sunder. If I get some
time to complete that work, and feel comfortable about it,
I'll post it here. Meanwhile, I'll save that hand-work for
that moment.

The referenced to the area discussing switching clocks is a
good one. I think you should dwell there a bit and see where
that takes you.

Are you developing classwork/labs?

Jon