Driver to drive?

[mike]

On 6/13/2012 3:47 AM, Jethro_uk wrote:

On Wed, 13 Jun 2012 19:39:21 +1000, Rod Speed wrote:

Jethro_uk<jethro_uk@hotmailbin.com> wrote
Andy Burns wrote
Jethro_uk wrote

Can anyone suggest an electronic circuit which can take 2 400W loads,
and switch instantaneously between them, so that to a connected
monitor, the draw appears consistent (i.e. no spikes or troughs) ?

what sort of loads (AC or DC, inductive such as motors or resistive
such as incandescent lamps or heaters)? are the two loads the same
type of load?

Sorry, should have said for UK AC Mains. Let's say both loads are like
a half bar fire - so plain resistive loads. I'm picturing a black box
which plugs into the wall, and which has 2 sockets. When the load on
one socket is removed, the box switches power to the other socket.

Why the requirement that 'switch instantaneously between them, so that
to a connected monitor, the draw appears consistent (i.e. no spikes or
troughs)'

That’s the hard thing to do.

I was just curious ... in the ongoing smart meter debates (e.g. http://
forums.theregister.co.uk/forum/1/2012/05/24/british_gas_alertme/) it
seems some people claim that smart meters will tell energy companies who
is growing cannabis, by looking for energy draws consistent with growlamps
coming on/off at set times. It seemed to be that a simple way to negate
that would be something which gave the *appearance* of a permanently-on
appliance drawing 400W. OK, it would add to the cost of such an
operation, but it would hide the profile from the meter.

I suspect there's space there for some snake-oil devices ....

It's hard to imagine they track transients.
It's gonna be hard to hide the turnon transients.
If the transients can't be tracked, just switch 'em at the same time
randomly.
How about this...
Grow twice as much and put the lights on a swivel to point
them one way or the other. Might as well put that 400W to good use.

I suppose they use every possible means to locate grow operations.
Low hanging fruit is right here on the internet. ;-)

 

[Dave Liquorice]

On Wed, 13 Jun 2012 02:57:55 -0700 (PDT), NT wrote:

Yes. Is it safe to assume its totally resistive?

A light bulb is resistive but it's non-linear from switch on...

And why does someone need to hide load switching from an upstream
monitor?

This has me wondering as well.

--
Cheers
Dave.

 

[Spehro Pefhany]

On Wed, 13 Jun 2012 04:58:49 -0700, the renowned mike
<spamme9@gmail.com> wrote:

On 6/13/2012 3:47 AM, Jethro_uk wrote:
On Wed, 13 Jun 2012 19:39:21 +1000, Rod Speed wrote:

Jethro_uk<jethro_uk@hotmailbin.com> wrote
Andy Burns wrote
Jethro_uk wrote

Can anyone suggest an electronic circuit which can take 2 400W loads,
and switch instantaneously between them, so that to a connected
monitor, the draw appears consistent (i.e. no spikes or troughs) ?

what sort of loads (AC or DC, inductive such as motors or resistive
such as incandescent lamps or heaters)? are the two loads the same
type of load?

Sorry, should have said for UK AC Mains. Let's say both loads are like
a half bar fire - so plain resistive loads. I'm picturing a black box
which plugs into the wall, and which has 2 sockets. When the load on
one socket is removed, the box switches power to the other socket.

Why the requirement that 'switch instantaneously between them, so that
to a connected monitor, the draw appears consistent (i.e. no spikes or
troughs)'

That’s the hard thing to do.

I was just curious ... in the ongoing smart meter debates (e.g. http://
forums.theregister.co.uk/forum/1/2012/05/24/british_gas_alertme/) it
seems some people claim that smart meters will tell energy companies who
is growing cannabis, by looking for energy draws consistent with growlamps
coming on/off at set times. It seemed to be that a simple way to negate
that would be something which gave the *appearance* of a permanently-on
appliance drawing 400W. OK, it would add to the cost of such an
operation, but it would hide the profile from the meter.

I suspect there's space there for some snake-oil devices ....

It's hard to imagine they track transients.
It's gonna be hard to hide the turnon transients.
If the transients can't be tracked, just switch 'em at the same time
randomly.
How about this...
Grow twice as much and put the lights on a swivel to point
them one way or the other. Might as well put that 400W to good use.

I suppose they use every possible means to locate grow operations.
Low hanging fruit is right here on the internet. ;-)

Why would energy companies want to locate grow operations? To target
products to them or something? They're paying customers, right?

OTOH, operations where they bypass the meter would likely be more of a
priority. Maybe they can correlate smart meters on a sub circuit with
monitors of aggregate energy flow and detect 'leakage'.


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

 

[mike]

On 6/13/2012 5:38 AM, Spehro Pefhany wrote:

On Wed, 13 Jun 2012 04:58:49 -0700, the renowned mike
spamme9@gmail.com> wrote:

On 6/13/2012 3:47 AM, Jethro_uk wrote:
On Wed, 13 Jun 2012 19:39:21 +1000, Rod Speed wrote:

Jethro_uk<jethro_uk@hotmailbin.com> wrote
Andy Burns wrote
Jethro_uk wrote

Can anyone suggest an electronic circuit which can take 2 400W loads,
and switch instantaneously between them, so that to a connected
monitor, the draw appears consistent (i.e. no spikes or troughs) ?

what sort of loads (AC or DC, inductive such as motors or resistive
such as incandescent lamps or heaters)? are the two loads the same
type of load?

Sorry, should have said for UK AC Mains. Let's say both loads are like
a half bar fire - so plain resistive loads. I'm picturing a black box
which plugs into the wall, and which has 2 sockets. When the load on
one socket is removed, the box switches power to the other socket.

Why the requirement that 'switch instantaneously between them, so that
to a connected monitor, the draw appears consistent (i.e. no spikes or
troughs)'

That’s the hard thing to do.

I was just curious ... in the ongoing smart meter debates (e.g. http://
forums.theregister.co.uk/forum/1/2012/05/24/british_gas_alertme/) it
seems some people claim that smart meters will tell energy companies who
is growing cannabis, by looking for energy draws consistent with growlamps
coming on/off at set times. It seemed to be that a simple way to negate
that would be something which gave the *appearance* of a permanently-on
appliance drawing 400W. OK, it would add to the cost of such an
operation, but it would hide the profile from the meter.

I suspect there's space there for some snake-oil devices ....

It's hard to imagine they track transients.
It's gonna be hard to hide the turnon transients.
If the transients can't be tracked, just switch 'em at the same time
randomly.
How about this...
Grow twice as much and put the lights on a swivel to point
them one way or the other. Might as well put that 400W to good use.

I suppose they use every possible means to locate grow operations.
Low hanging fruit is right here on the internet. ;-)

Why would energy companies want to locate grow operations? To target
products to them or something? They're paying customers, right?

They don't. Law Enforcement uses them as a tool.

OTOH, operations where they bypass the meter would likely be more of a
priority. Maybe they can correlate smart meters on a sub circuit with
monitors of aggregate energy flow and detect 'leakage'.


Best regards,
Spehro Pefhany

 

[NT]

On Jun 13, 11:23 am, "Rod Speed" <rod.speed....@gmail.com> wrote:

NT <meow2...@care2.com> wrote



Rod Speed <rod.speed....@gmail.com> wrote
NT <meow2...@care2.com> wrote
Jethro_uk <jethro...@hotmailbin.com> wrote
Andy Burns wrote
Jethro_uk wrote
Can anyone suggest an electronic circuit which can take 2 400W loads,
and switch instantaneously between them, so that to a connected
monitor, the draw appears consistent (i.e. no spikes or troughs) ?
what sort of loads (AC or DC, inductive such as motors or resistive
such as
incandescent lamps or heaters)? are the two loads the same type of
load?
Sorry, should have said for UK AC Mains. Let's say both loads are like
a half bar fire - so plain resistive loads. I'm picturing a black box
which
plugs into the wall, and which has 2 sockets. When the load on one
socket is removed, the box switches power to the other socket.
that's simple,
We'll see...
just 2 triacs controlled by whatever is making the decision.
Triacs would need to be switched at zero crossing to avoid
any glitch.
But 'whatever is making the decision' gets tricky doing the
detection that the first load is gone at the zero crossing point
in time. By definition if the first load goes away at other than
the zero crossing time, you will see some spike or trough.
Yes. One could switch it fast with a triac, and if necessary even
use a big LC or switched mode circuit  to smooth the transition.

I'd rather use mosfets so there is less to smooth out.

Still gets tricky detecting the removal of the first load
quickly enough to avoid any switching glitch unless he

very simple. Just detect near zero current, with the detector blanked
at times when V is close to zero

is happy with some system where the user effectively
has a 'switch loads' button and lets the system switch
when it wants to at say the next zero crossing etc.

That would be completely trivial to do.

The details of the switching vary depending
on whether the load is resistive or inductive.
He said its resistive.
Yes. Is it safe to assume its totally resistive?

Doesn't really matter if he's happy with a 'switch loads'
button that produces a switch at zero current flowing.

Tho there would still be a problem as John pointed
out with the other load being cold initially etc.

Even heating loads normally take more current when cold. Its all
solvable, but would take a much more complex control system.

NT

And why does someone need to hide load
switching from an upstream monitor?

Yeah, I asked him that, but he hasn't been back yet.

 

[Robert Macy]

On Jun 13, 1:28 am, Jethro_uk <jethro...@hotmailbin.com> wrote:

On Wed, 13 Jun 2012 07:20:54 +0100, Andy Burns wrote:
Jethro_uk wrote:

Can anyone suggest an electronic circuit which can take 2 400W loads,
and switch instantaneously between them, so that to a connected
monitor, the draw appears consistent (i.e. no spikes or troughs) ?

what sort of loads (AC or DC, inductive such as motors or resistive such
as incandescent lamps or heaters)? are the two loads the same type of
load?

Sorry, should have said for UK AC Mains. Let's say both loads are like a
half bar fire - so plain resistive loads. I'm picturing a black box which
plugs into the wall, and which has 2 sockets. When the load on one socket
is removed, the box switches power to the other socket.

X-posted to sci.electronics.design as previous poster suggested.

HOW IS THE LOAD REMOVED?

Do you have control over the switching between loads, or does some one
simply turn off a switch, or worse, pull a plug?

Either mechanical OFF will take anywhere from 5 to 20mS to accomplish
and during that time the inductance in the supply wiring will be
complaining about the changes in current.

Bottom line, yes it is possible to accomplish what you want but your
problem needs to be better stated. Take EVERYTHING into account.

 

[Rod Speed]

mike <spamme9@gmail.com> wrote

Jethro_uk wrote
Rod Speed wrote
Jethro_uk<jethro_uk@hotmailbin.com> wrote
Andy Burns wrote
Jethro_uk wrote

Can anyone suggest an electronic circuit which can take 2 400W loads,
and switch instantaneously between them, so that to a connected
monitor, the draw appears consistent (i.e. no spikes or troughs) ?

what sort of loads (AC or DC, inductive such as motors or resistive
such as incandescent lamps or heaters)? are the two loads the same
type of load?

Sorry, should have said for UK AC Mains. Let's say both loads are like
a half bar fire - so plain resistive loads. I'm picturing a black box
which plugs into the wall, and which has 2 sockets. When the load on
one socket is removed, the box switches power to the other socket.

Why the requirement that 'switch instantaneously between them, so that
to a connected monitor, the draw appears consistent (i.e. no spikes or
troughs)'

That’s the hard thing to do.

I was just curious ... in the ongoing smart meter debates (e.g. http://
forums.theregister.co.uk/forum/1/2012/05/24/british_gas_alertme/) it
seems some people claim that smart meters will tell energy companies who
is growing cannabis, by looking for energy draws consistent with
growlamps
coming on/off at set times. It seemed to be that a simple way to negate
that would be something which gave the *appearance* of a permanently-on
appliance drawing 400W. OK, it would add to the cost of such an
operation, but it would hide the profile from the meter.

I suspect there's space there for some snake-oil devices ....

It's hard to imagine they track transients.

Hard to believe that they would get much useful info out of them, anyway.

It's gonna be hard to hide the turnon transients.

Quite easy actually, don’t turn the loads off, just run
them at very low levels so the filaments don’t get cold.

If the transients can't be tracked, just switch 'em at the same time
randomly.

How about this...
Grow twice as much and put the lights on a swivel to point them one way or
the other.

Not trivial to do tho, particularly with a cannabis crop.

Lot simpler to just get the power before the meter.

Might as well put that 400W to good use.

I suppose they use every possible means to locate grow operations.

Bet they don’t.

> Low hanging fruit is right here on the internet. ;-)

 

[Tim Wescott]

On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:

I'm using an STM32F103VB, and one of the things that I'm doing is doing
a set of ADC reads which are then being transferred via DMA to a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel gets
written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the DMA
(theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of conversion
interrupt (which is only supposed to happen at the end of the scan in
scan mode) the DMA engine gets reinitialized to point to the base of the
memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong? Does ST have
any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 

[Tim Wescott]

On Wed, 20 Jun 2012 09:11:07 -0700, langwadt@fonz.dk wrote:

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong?  Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.



a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/
#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC. My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places. Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 

[langwadt@fonz.dk]

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:

On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is doing
a set of ADC reads which are then being transferred via DMA to a buffer..

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel gets
written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the DMA
(theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of conversion
interrupt (which is only supposed to happen at the end of the scan in
scan mode) the DMA engine gets reinitialized to point to the base of the
memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong?  Does ST have
any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/#axzz1yLmVUCe5

-Lasse

 

[langwadt@fonz.dk]

On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote:

On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:
On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory..

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong?  Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/

#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC.  My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places.  Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up.

should have mentioned I was looking at the post by "tony" two thirds
down
the page, look like scan of two channels with dma


-Lasse

 

[Mark Borgerson]

In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdnZ2d@web-ster.com>,
tim@seemywebsite.com says...

On Wed, 20 Jun 2012 09:11:07 -0700, langwadt@fonz.dk wrote:

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong?  Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.



a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/
#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC. My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places. Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up.

I think the STM32 debug hardware has the option to stop the timer clocks
when debugging. If you don't do that, perhaps your timer is triggering
an ADC cycle while in the debug mode.


Mark Borgerson

 

[Mark Borgerson]

In article <89321ffc-6291-439a-893a-
2686e0df5aec@v9g2000vbc.googlegroups.com>, langwadt@fonz.dk says...

On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote:
In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>,
t...@seemywebsite.com says...











On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong? Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/
#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC.  My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places.  Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up.

I think the STM32 debug hardware has the option to stop the timer clocks
when debugging.  If you don't do that, perhaps your timer is triggering
an ADC cycle while in the debug mode.

Mark Borgerson

generally when you are working on stuff that controls with motors and
power
stopping the cpu is not an option. You have to use some type of
realtime
debugger to look at variables and such

used to be that you had to make your own with uart or something like
that, but
now most also have to the option to do it over the jtag or what ever
debug
interface is used

The manual for the STM32F2xx mentions that the option to keep the timer

clocks running when the CPU is halted for debugging is useful when using
the timers to generate PWM for motor control.

Mark Borgerson

 

[Mark Borgerson]

In article <96260cdf-ec22-4dac-9848-8dbee8e9d327
@p27g2000vbl.googlegroups.com>, langwadt@fonz.dk says...

On 20 Jun., 22:45, Mark Borgerson <mborger...@comcast.net> wrote:
In article <89321ffc-6291-439a-893a-
2686e0df5...@v9g2000vbc.googlegroups.com>, langw...@fonz.dk says...









On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote:
In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>,
t...@seemywebsite.com says...

On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong? Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/
#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC. My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places. Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up.

I think the STM32 debug hardware has the option to stop the timer clocks
when debugging. If you don't do that, perhaps your timer is triggering
an ADC cycle while in the debug mode.

Mark Borgerson

generally when you are working on stuff that controls with motors and
power
stopping the cpu is not an option. You have to use some type of
realtime
debugger to look at variables and such

used to be that you had to make your own with uart or something like
that, but
now most also have to the option to do it over the jtag or what ever
debug
interface is used

The manual for the STM32F2xx mentions that the option to keep the timer
clocks running when the CPU is halted for debugging is useful when using
the timers to generate PWM for motor control.

Mark Borgerson

depends on how intelligent the timer is of course, but imagine a
robot
controlled by that motor, stop the cpu at the wrong time at it might
just
keep going until it hits something HARD

That kind of problem is always present when controlling motors and other

mechanical systems. Real-Time debugging is difficult even with the best
of hardware. That's one reason I've never been particularly interested
in writing code for computer-controlled sawmills!

When I was working on autonomous aerial vehicle code, there were two
kinds of debugging----offline PC sims to debug algorithms, and the
"record everything and analyze after the crash" for the hardware-
associated problems. (The 'crash' was usually not a computer
reset type crash. It was an "I was flying and now I'm not" type
of crash.)

Mark Borgerson

 

[Tim Wescott]

On Wed, 20 Jun 2012 10:04:16 -0700, langwadt@fonz.dk wrote:

On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:
On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA
to a buffer.

For some reason, when I'm debugging the DMA transfer gets
scrambled: channel 0 ends up where channel 1 is supposed to go,
channel 1 where channel 2 should be, on up the line until finally
the last channel gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into
memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end
of the scan in scan mode) the DMA engine gets reinitialized to
point to the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong?  Does
ST have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be
folks over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-
stm32/

#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC.  My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC
conversions with that part is to use the ADC scan mode and DMA -- so I
pretty much must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places.  Scary, too, considering that
I'm controlling enough power to make things awfully toasty if I screw
it up.


should have mentioned I was looking at the post by "tony" two thirds
down
the page, look like scan of two channels with dma

It looks like he's doing what I'm trying; maybe he didn't debug.

At any rate, I found a horrible kludge that seems to work. At the end of
the ISR, I reset the DMA controller leaving room for the ADC channels
_plus one_. I'm sure that when I die and I'm trying to convince St.
Peter that I belong up instead of down, that this kludge will be raised
as a topic of conversation:

DMA.CHAN_1.CCR.bits.EN = 0; // disable DMA
DMA.CHAN_1.CMAR = raw_adc_readings; // set address
DMA.CHAN_1.CNDTR.bits.NDT = ADC_CHANNELS + 1; // Number of ADC
channels + kludge
DMA.IFCR.bits.TCF1 = 1; // Clear the transfer
complete interrupt
DMA.CHAN_1.CCR.bits.EN = 1; // enable DMA

ADC1.SR.bits.EOC = 0; // clear interrupt


--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 

[langwadt@fonz.dk]

On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote:

In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>,
t...@seemywebsite.com says...











On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong? Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/
#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC.  My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places.  Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up..

I think the STM32 debug hardware has the option to stop the timer clocks
when debugging.  If you don't do that, perhaps your timer is triggering
an ADC cycle while in the debug mode.

Mark Borgerson

generally when you are working on stuff that controls with motors and
power
stopping the cpu is not an option. You have to use some type of
realtime
debugger to look at variables and such

used to be that you had to make your own with uart or something like
that, but
now most also have to the option to do it over the jtag or what ever
debug
interface is used

-Lasse

 

[langwadt@fonz.dk]

On 20 Jun., 22:45, Mark Borgerson <mborger...@comcast.net> wrote:

In article <89321ffc-6291-439a-893a-
2686e0df5...@v9g2000vbc.googlegroups.com>, langw...@fonz.dk says...









On 20 Jun., 22:25, Mark Borgerson <mborger...@comcast.net> wrote:
In article <0vidnfqFnZKEYXzSnZ2dnUVZ_uKdn...@web-ster.com>,
t...@seemywebsite.com says...

On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:

On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA to
a buffer.

For some reason, when I'm debugging the DMA transfer gets scrambled:
channel 0 ends up where channel 1 is supposed to go, channel 1 where
channel 2 should be, on up the line until finally the last channel
gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end of
the scan in scan mode) the DMA engine gets reinitialized to point to
the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong? Does ST
have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be folks
over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-stm32/
#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC. My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions
with that part is to use the ADC scan mode and DMA -- so I pretty much
must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places. Scary, too, considering that I'm
controlling enough power to make things awfully toasty if I screw it up.

I think the STM32 debug hardware has the option to stop the timer clocks
when debugging. If you don't do that, perhaps your timer is triggering
an ADC cycle while in the debug mode.

Mark Borgerson

generally when you are working on stuff that controls with motors and
power
stopping the cpu is not an option. You have to use some type of
realtime
debugger to look at variables and such

used to be that you had to make your own with uart or something like
that, but
now most also have to the option to do it over the jtag or what ever
debug
interface is used

The manual for the STM32F2xx mentions that the option to keep the timer
clocks running when the CPU is halted for debugging is useful when using
the timers to generate PWM for motor control.

Mark Borgerson

depends on how intelligent the timer is of course, but imagine a
robot
controlled by that motor, stop the cpu at the wrong time at it might
just
keep going until it hits something HARD

-Lasse

 

[Tim Wescott]

On Thu, 21 Jun 2012 09:30:52 -0700, langwadt@fonz.dk wrote:

On 21 Jun., 00:34, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:04:16 -0700, langw...@fonz.dk wrote:
On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:
On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing
is doing a set of ADC reads which are then being transferred
via DMA to a buffer.

For some reason, when I'm debugging the DMA transfer gets
scrambled: channel 0 ends up where channel 1 is supposed to go,
channel 1 where channel 2 should be, on up the line until
finally the last channel gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with
the DMA (theoretically!) sucking the data off and putting it
into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the
end of the scan in scan mode) the DMA engine gets reinitialized
to point to the base of the memory array it's supposed to write
to.

Does anyone have any obvious clue to what I'm doing wrong?
 Does ST have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be
folks over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-
stm32/

#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers
out of the ADC.  My problem is getting the right numbers out of the
ADC, at the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC
conversions with that part is to use the ADC scan mode and DMA -- so
I pretty much must get it working.

It is very frustrating to halt the processor, restart, and see all
the right numbers in all the wrong places.  Scary, too, considering
that I'm controlling enough power to make things awfully toasty if I
screw it up.

should have mentioned I was looking at the post by "tony" two thirds
down the page, look like scan of two channels with dma

It looks like he's doing what I'm trying; maybe he didn't debug.

so it is only when you debug? what are you using for debug?


At any rate, I found a horrible kludge that seems to work.  At the end
of the ISR, I reset the DMA controller leaving room for the ADC
channels _plus one_.  I'm sure that when I die and I'm trying to
convince St. Peter that I belong up instead of down, that this kludge
will be raised as a topic of conversation:


I've seen worse but, are you setting the dma up for circular mode? if
you do that and have the plus one aren't you pretty sure it will go
wrong if you are ever late with the interrupt?

guess you could put a magic number at that extra location and if it ever
gets overwritten panic or what ever makes most sense


-Lasse

JTAG, OpenOCD and gdb for debugging.

The DMA is _not_ in circular mode.

I may monitor the extra location -- but I suspect that I'll just find out
that it stays zero until after I halt and restart.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

 

[langwadt@fonz.dk]

On 21 Jun., 00:34, Tim Wescott <t...@seemywebsite.com> wrote:

On Wed, 20 Jun 2012 10:04:16 -0700, langw...@fonz.dk wrote:
On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:
On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing is
doing a set of ADC reads which are then being transferred via DMA
to a buffer.

For some reason, when I'm debugging the DMA transfer gets
scrambled: channel 0 ends up where channel 1 is supposed to go,
channel 1 where channel 2 should be, on up the line until finally
the last channel gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with the
DMA (theoretically!) sucking the data off and putting it into
memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the end
of the scan in scan mode) the DMA engine gets reinitialized to
point to the base of the memory array it's supposed to write to.

Does anyone have any obvious clue to what I'm doing wrong?  Does
ST have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be
folks over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-
stm32/

#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out
of the ADC.  My problem is getting the right numbers out of the ADC, at
the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC
conversions with that part is to use the ADC scan mode and DMA -- so I
pretty much must get it working.

It is very frustrating to halt the processor, restart, and see all the
right numbers in all the wrong places.  Scary, too, considering that
I'm controlling enough power to make things awfully toasty if I screw
it up.

should have mentioned I was looking at the post by "tony" two thirds
down
the page, look like scan of two channels with dma

It looks like he's doing what I'm trying; maybe he didn't debug.

so it is only when you debug? what are you using for debug?

At any rate, I found a horrible kludge that seems to work.  At the end of
the ISR, I reset the DMA controller leaving room for the ADC channels
_plus one_.  I'm sure that when I die and I'm trying to convince St.
Peter that I belong up instead of down, that this kludge will be raised
as a topic of conversation:

I've seen worse but, are you setting the dma up for circular mode? if
you do
that and have the plus one aren't you pretty sure it will go wrong if
you are
ever late with the interrupt?

guess you could put a magic number at that extra location and if it
ever gets
overwritten panic or what ever makes most sense


-Lasse

 

[langwadt@fonz.dk]

On 21 Jun., 19:21, Tim Wescott <t...@seemywebsite.please> wrote:

On Thu, 21 Jun 2012 09:30:52 -0700, langw...@fonz.dk wrote:
On 21 Jun., 00:34, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:04:16 -0700, langw...@fonz.dk wrote:
On 20 Jun., 18:36, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 09:11:07 -0700, langw...@fonz.dk wrote:
On 20 Jun., 17:53, Tim Wescott <t...@seemywebsite.com> wrote:
On Wed, 20 Jun 2012 10:51:52 -0500, Tim Wescott wrote:
I'm using an STM32F103VB, and one of the things that I'm doing
is doing a set of ADC reads which are then being transferred
via DMA to a buffer.

For some reason, when I'm debugging the DMA transfer gets
scrambled: channel 0 ends up where channel 1 is supposed to go,
channel 1 where channel 2 should be, on up the line until
finally the last channel gets written to channel 0.

I have the code set up for the ADC to run in "scan" mode, with
the DMA (theoretically!) sucking the data off and putting it
into memory.

Furthermore, I have the ADC ISR set up so that on an end of
conversion interrupt (which is only supposed to happen at the
end of the scan in scan mode) the DMA engine gets reinitialized
to point to the base of the memory array it's supposed to write
to.

Does anyone have any obvious clue to what I'm doing wrong?
 Does ST have any good bits of sample code that I've missed?

Thanks in advance.

Whoops -- I meant to cross-post this to sed, 'cause there may be
folks over there with useful information, too.

a suggestion from a quick google
http://www.micromouseonline.com/2009/05/26/simple-adc-use-on-the-
stm32/

#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers
out of the ADC.  My problem is getting the right numbers out of the
ADC, at the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC
conversions with that part is to use the ADC scan mode and DMA -- so
I pretty much must get it working.

It is very frustrating to halt the processor, restart, and see all
the right numbers in all the wrong places.  Scary, too, considering
that I'm controlling enough power to make things awfully toasty if I
screw it up.

should have mentioned I was looking at the post by "tony" two thirds
down the page, look like scan of two channels with dma

It looks like he's doing what I'm trying; maybe he didn't debug.

so it is only when you debug? what are you using for debug?

At any rate, I found a horrible kludge that seems to work.  At the end
of the ISR, I reset the DMA controller leaving room for the ADC
channels _plus one_.  I'm sure that when I die and I'm trying to
convince St. Peter that I belong up instead of down, that this kludge
will be raised as a topic of conversation:

I've seen worse but, are you setting the dma up for circular mode? if
you do that and have the plus one aren't you pretty sure it will go
wrong if you are ever late with the interrupt?

guess you could put a magic number at that extra location and if it ever
gets overwritten panic or what ever makes most sense

-Lasse

JTAG, OpenOCD and gdb for debugging.

The DMA is _not_ in circular mode.

did you have that before?

I may monitor the extra location -- but I suspect that I'll just find out
that it stays zero until after I halt and restart.

it should tell you something about whether it is the dma or the adc
that
gets confused

-Lasse