Driver to drive?

[alb]

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]

we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a heavy
burden for this type of application).

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

There are two fundamental aspects that make a difference between the two
worlds:

1. ease to change
2. complexity

Re-programming and FPGA is rather a PITA compared to just running
'make' and this very simple aspect has a huge impact on the way
development is carried out. That is also why, for space applications,
the development flow tends to limit the possibility to wildly change the
code base, increasing the risk to break everything.

Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.

Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.

[]

If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.

We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.

You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.

This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?

Al

 

[alb]

Hi Jan,

Jan Panteltje <panteltje@yahoo.com> wrote:
[]

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

Maybe the FPGA code is simpler, or the programmer more concentrated.

The quality of a product is not given by the programmer capability but
the quality of the process he's working with. The reason why the Shuttle
program has a code base of 750 KLOC and 17 documented bugs is because
the process they worked with was rock solid.

A simpler code may rely on lighter processes, but as soon as complexity
rise the process needs to rely less on the programmer's ability and more
on the thought through development flow.

> I have very few reliability issues with software, if any.

have you ever done an HSIA? What about an FMECA? What's the code
coverage? If your code is relying on any driver, OS, library, are they
verified?

I guess we are talking about a different type of reliability.

FPGAs may have timing issues, something a software writer do not normally
have to bother about as that has been taken care of by the processor vendor.

Software /writers/ need to take care about asynchronous tasks
interaction, priority inversion, dead locks, interrupt handling...I'd
say the FPGA guy must be happy with his two flops resynchronization
effort for clock domain crossing...

> What else is a processor than a state machine?

The issue is not if the processor is a state machine or not, the issue
is about the branches a software can get into and all the time you need
to test and/or analyse those branches.

On top of it, compilers, as well as languages, are far from being
optimally defined and leave undefined behavior creeping in your work of
art silently. Likely enough norms and guidelines do exist to get you out
of the mud and 'safely' produce high quality code, but the process is
far from being cheap.

Al

 

[Tim Wescott]

On Thu, 11 Dec 2014 08:11:08 +0000, alb wrote:

Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]
The 3kHz limit could reflect the nature of the rotating component in
the particular motor.

Be careful with your terminology. Does Al mean a 3kHz loop bandwidth,
or a 3kHz filter between drive and motor?

The 3KHz are on the loop bandwidth. Apologize if I wasn't clear from the
beginning.


If the latter, I would expect some limitation on harmonic content, not
just something called a "cutoff".

w.r.t. filtering the customer is specifying wants to *avoid* any source
of emission between 5KHz and 50KHz because this is where the scientific
signal will by laying.

When we talked about a 20KHz PWM in our first proposal they saw the risk
and changed the spec to impose a hard notch in that region. That is why
we are somehow obliged to go beyond that notch.

20kHz or so is normal, but you may be able to get by with 60. (or 62.5,
to make the dividers easy). Be sure to either filter it on board, or
check to see that you're not inducing too much loss in the motor.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Tim Wescott]

On Thu, 11 Dec 2014 22:55:37 +0000, alb wrote:

Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]
That's the idea, measure current and regulate through the delta-sigma,
but can the output of the delta-sigma comparator be used directly to
drive the half H-bridge? It would be a PDM.

Sigma-delta around the PWM command modulus, per this article. The
short story is that if the number you need to command the PWM is 23.4,
you command it with 23, 23, 25, 23, 25, repeat.

http://www.embedded.com/design/configurable-systems/4006431/Sigma-
delta-
techniques-extend-DAC-resolution

So the duty cycle of a PWM would be regulated with a d-s which would
have, on average, a better resolution than just the PWM. Still I do not
see from the Fig. 6 of the above link, why a dithered DAC gives less DC
error than a straight DAC.

When a straight DAC is wrong, it's wrong forever. If you dither it, then
you can make it exactly right on average, at the expense of increasing the
overall error energy.

And still I do not see how do I relate my precision in the current
provided to the motor with the PWM frequency and the resolution of the
current sense and the d-s.

Ahh -- it's complicated. Really, with an integrating controller and
perfect current sense, your average error will be zero. Worrying about
the resolution of the current sense ADC is probably pointless -- you'll
have so much noise in there that even a sleazy 12-bit ADC will be far
better than the signal it's trying to read.

The lower the precision of your PWM is (with or without D-S modulation),
the harder it is for the control loop to hold the current steady.

If you've got more than 6 or 7 bits of resolution to the PWM generator,
noise in the system will probably swamp out any attempts to sigma-delta
the thing. Sometimes noise _is_ your friend.

Lost you here. From the article above I understood that dithering would
help me to get a closer desired output even if the resolution of the DAC
is not extremely high. Considering that a higher resolution on my
current would potentially pick up 'free noise' from the load itself, why
would it swamp out the attempt to delta sigma the loop?

Because the magnitude of the changes to the PWM command as a consequence
of the free noise will be far larger than the magnitude of the changes to
the PWM command as a consequence of the D-S modulator.

There are certain requirements on the amount of harmonics going onto
the motor and/or propagating through cables (related to EMI
constraints).

Then you need to pay attention to those. Do you just need to round off
the edges, or do you need to keep the PWM out?

Still don't have access to the EMI spec (due to ongoing changes!), but I
believe the notch would be so severe that the only practical solution
would be to keep the PWM out of the range 5KHz - 50 KHz. The
interferometer is measuring uV in that frequency range, the entire
scientific mission is running on that frequency range.

That's new to me. Just run the PWM higher, and possibly filter if that
gives the motor gas pains.

1. should the sampling frequency simply be above Nyquist or does it
need to meet other criteria like precision?

If you are working on a control loop and Harry Nyquist knocks on the
door,
escort him to the nearest Starbucks (or priest, given his birth date).
Then get on with your job.

You don't want to even _think_ in terms of the Nyquist limit when
you're working on control loops. Sample at least ten times faster than
your desired loop bandwidth, unless you have a superlatively
well-behaved plant. Higher precision loops need higher sampling rates.

Where the factor 10 comes from? What makes me choose a higher/lower
frequency? Is it related to the 'uncertainties' of the plant that I want
to be able to *meausure* in order to control them?

It's a rule of thumb, that mostly comes from the fact that sampling adds
delay and delay means phase shift. Ignoring the delay in the processor,
sampling adds, on average, sorta, 1/2 of a sampling interval of delay.
That means that -- again sorta -- the phase shift at loop closure from
sampling alone will be about 20 degrees if you close the loop at 10 times
below sampling rate.

If you're driving the PWM frequency above 50kHz, and you're sampling at
the same frequency, then if you have the processing power for it just make
sure that your integrators are deep enough not to underflow and enjoy the
fact that you don't have to worry about the sampling rate as a limiting
factor.

Re-read my article on sampling:
http://wescottdesign.com/articles/Sampling/sampling.pdf

I like the 3500 pole order filter to get to a 40dB signal to alias
ratio, a hell of a filter Thanks for the pointer.

I like reductio ad absurdum arguments. It seems like the quickest line
between "oooh, shiny!" and "nope, this ain't going to work".

2. Even considering a PWM (and not a PDM), what shall be the frequency
of it and what should be it's resolution?

Over 20kHz if audible noise is an issue (over 25kHz or 30kHz if you
want to cover 99.9% of the population instead of just 99%).

audible noise may not be as important as microvibrations on the
platform.

That's a good argument against sigma-delta -- but again, I don't think
that's going to be a problem for you.

Resolution should be enough that, after cleaning up the rest with
sigma- delta modulation, the residual noise does not make audible noise
(growling, hissing, or singing) and does not consume excess power.

Lost again. Which residual noise you're talkin about?

Residual noise from the sigma-delta. It works by taking the DC error and
pitch-forking it up in frequency: you have to account for what it does
wherever it ends up.

If you have 11 bits of resolution into the motor, you are worrying
needlessly. The noise in your current sensing loop will swamp out the
bottom three to five bits anyway, so sigma-delta techniques would be a
waste of time (oh, if I'd read this earlier...).

Is that because the noise replace our 'dithering' and therefore allows
for a increased resolution?

Yes.

The problem I have is that I'd like to have
a relationship between the desired precision *and* one or more
paramenters of my control loop.

This is getting beyond what I want to answer for free. The way to find
the answer is to analyze the loop for noise response, with noise injected
at the various points that you know will cause difficulty (like the
current measurement).

It's in my book. It's in any decent book on control systems, except they
usually don't tell you why you want to know it (I'm pretty sure I do).

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is
the motivation.

Do you mean the current loop bandwidth?

Yup.

The driver for that is their required control loop bandwidth, and how
close they think they can push it to the current loop bandwidth.

So if the control loop bandwidth is higher than the current loop one it
would be limited by the latter, correct?

No, the control loop bandwidth is limited by the phase shift of the
current loop, even when the current loop bandwidth is higher. Look at the
phase shift of a simple 1st-order lowpass filter, and how low a frequency
it starts to come on compared to the 3dB point.

They probably need between 300Hz and 1kHz. If they're smart they have
some sort of a rider on their specification about phase -- either a
phase shift bandwidth, or a requirement of 3kHz with a simple 1st-order
response.

Let's see how smart they are...new specs is coming under the Christmas
Tree, just to delight the family reunion!

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[John Larkin]

On 11 Dec 2014 23:33:55 GMT, al.basili@gmail.com (alb) wrote:

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a heavy
burden for this type of application).

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

There are two fundamental aspects that make a difference between the two
worlds:

1. ease to change
2. complexity

Re-programming and FPGA is rather a PITA compared to just running
'make' and this very simple aspect has a huge impact on the way
development is carried out. That is also why, for space applications,
the development flow tends to limit the possibility to wildly change the
code base, increasing the risk to break everything.

Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.

Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.

[]
If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.

We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.

I sure wouldn't design a motor driver without ever connecting it to a
motor.

You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.

This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?

Al

What kind of motor is it? DC motors make back EMFs. Steppers have
variable coil inductance. Both store rotational energy. All sorts of
fun stuff.




--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:

On 10/12/2014 3:32 AM, meow2222@care2.com.remove-cdt-this wrote:
To: Bill Sloman
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow2222@care2.com wrote:

That misses the point completely. No sane person would buy a 100k PV
system sized to run an all electric house when they can spend 5k and
have gas heating and a well insulated fridge.

You're assuming you can *get* gas at your home. I can think of lots
of places that have electricity but no gas. I can't think of any
that have gas but no electricity!

gas, oil, pellets, random solid fuel, all far cheaper than electric runoff
solar.

[you're also assuming fossil fuel costs remain cheap]

no I'm not. But it will, relatively.

Not forever. There's only so much fossil carbon to dig up, and we are digging
it up a lot faster than it fossilised. And the more we dig up, the more
expensive it gets to dig out the deeply buried stuff that nobody bothered to
dig out before.

There is the point that anthropogenic global warming will probably destroy
advanced industrial society as we know it quite a bit before we've dug up and
burnt all the fossil carbon, so burning fossil carbon for fuel may remain
"relatively cheap" right up to the point where the side-effects make it
impractical to keep on doing it - in the sense that the climate will
have
gone west to the point where we can't grow food like we used to, or
extremeweather will have got to the point where we can't ship
the fossil carbon from where we dig it up to where we wanted to burn it.

So it could remain "relatively cheap" until the real costs of burning it
became obvious to the most dim-witted right-wing nitwit, just before it killed
him (or her).

There are so many holes in that idea I don't know where to begin.

In other words you don't like the ideas presented, but can't construct a
counter argument - probably because I'm right, and whenever you try to
construct one of your counter-arguments, you find yourself stuck with a
fallacy at the core of your response.

In other words I've got better things to do than address foolish political views yet again


NT

 

[Tim Wescott]

On Thu, 11 Dec 2014 18:20:22 -0800, John Larkin wrote:

On 11 Dec 2014 23:33:55 GMT, al.basili@gmail.com (alb) wrote:

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a
heavy burden for this type of application).

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

There are two fundamental aspects that make a difference between the two
worlds:

1. ease to change 2. complexity

Re-programming and FPGA is rather a PITA compared to just running 'make'
and this very simple aspect has a huge impact on the way development is
carried out. That is also why, for space applications, the development
flow tends to limit the possibility to wildly change the code base,
increasing the risk to break everything.

Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.

Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.

[]
If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.

We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.

I sure wouldn't design a motor driver without ever connecting it to a
motor.


You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.

This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?

Al

What kind of motor is it? DC motors make back EMFs. Steppers have
variable coil inductance. Both store rotational energy. All sorts of fun
stuff.

The fact that the title of this thread has "BLDC motor" in it certainly
indicates that it's a BLDC motor.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[alb]

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]

In an FPGA, there are usually many small synchronous state machines
that interact in controlled ways.

Do not underestimate the garbage you could produce within an FPGA and
how eventually strongly coupled are all those tiny synchronous FSMs,
just to the point that they become a giant blob of gates!

The idea to break functionality into small, manageable pieces of logic,
which interact in a /controlled/ way is very applicable to software as
well. Yet the practice is not always the most common one.

Usually, data does not affect
control states. States are visible and usually explicitely managed...
ALL of them. The biggest hazard in FPGA design is usually clock-domain
crossings. Pure timing problems are rare, what with modern FPGAs being
blindingly fast and the tools being pretty conservative about margins.

The biggest hazard in FPGA is the very same as software...a big blob of
unstructured and unmaintainable code. Most of the times functions are
tightly coupled and faults in one propagate way too far before revealing
themselves. In the end a debugging nightmare.

And FPGAs do not depend on operating systems and drivers and
undocumented peripherial controllers. Well, sometimes they do use a
mysterious PCIe block, or encrypted IP, but even those usually work.

As the number of IPs and their configuration space increases, a very
similar scenario is starting to appear in the ASIC/FPGA world as well
(and we do not have open/free platforms to play with like we do with
software).

Once you add a couple of ARM cores to an FPGA, naturally the ARMs
inherit all the bug potential of C procedural software... horrors of
interrupts, mutexes, threads, pipes, callbacks, logic mazes.

You can do the same horrors on FPGAs fabric, but as I said, the software
complexity is way bigger.

C is a sequential, procedural language. VHDL is not. That seems to
make a lot of difference.

Threads do provide a very similar level of 'concurrency' between tasks.
The main difference I see is in the mindset. When you have to go to
silicon the cost is such that you are forced to instrument your code
with lots of testing features and the verification is not something you
can scrap off the schedule easily.

IMO this is why big software projects fail or are far too expensive
since they inherit the very quick modify-compile-try cycle from the
'hello world' program, believing that you can *always* modify the code.
When you are forced to change the pillars of your software it may easily
fall as a card castle, beyond repair. Yes you can change the code, but
the consequences are far too often not perceived correctly.

Al

 

[Bill Sloman]

On Friday, 12 December 2014 21:46:04 UTC+11, meow...@care2.com wrote:

On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:
On 10/12/2014 3:32 AM, meow2222@care2.com.remove-cdt-this wrote:
To: Bill Sloman
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow2222@care2.com wrote:

<snip>

In other words you don't like the ideas presented, but can't construct a
counter argument - probably because I'm right, and whenever you try to
construct one of your counter-arguments, you find yourself stuck with a
fallacy at the core of your response.

In other words I've got better things to do than address foolish political views yet again

Nice try. But if you want to label a view either "political" or "foolish" you have to explain why. Since the basic argument about anthropogenic global warming is scientific, you've missed the point that the science is quite solid enough to make both the "denialist" and "it doesn't matter positions" look decidedly foolish.

The only political part in the anthropogenic global warming question is working out how we take the collective action which is obviously necessary.

The people who object to that are objecting to the word "collective" - as far as they are concerned, every problem has to be solved by the application of the free market. They don't seem to have noticed that we can't buy another planet, in the same way that they earlier found it difficult to appreciate that you can't buy another ozone layer, or a new set of lungs if you've wrecked the set you were born with by smoking cigarettes.

Sadly, the foolish political view is all yours.

--
Bill Sloman, Sydney

 

[Jan Panteltje]

On a sunny day (11 Dec 2014 23:49:50 GMT) it happened al.basili@gmail.com
(alb) wrote in <ceuosuF9gvoU3@mid.individual.net>:

Hi Jan,

Jan Panteltje <panteltje@yahoo.com> wrote:
[]
It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

Maybe the FPGA code is simpler, or the programmer more concentrated.

The quality of a product is not given by the programmer capability but
the quality of the process he's working with. The reason why the Shuttle
program has a code base of 750 KLOC and 17 documented bugs is because
the process they worked with was rock solid.

A simpler code may rely on lighter processes, but as soon as complexity
rise the process needs to rely less on the programmer's ability and more
on the thought through development flow.

I have very few reliability issues with software, if any.

have you ever done an HSIA? What about an FMECA? What's the code
coverage? If your code is relying on any driver, OS, library, are they
verified?

I guess we are talking about a different type of reliability.

FPGAs may have timing issues, something a software writer do not normally
have to bother about as that has been taken care of by the processor vendor.

Software /writers/ need to take care about asynchronous tasks
interaction, priority inversion, dead locks, interrupt handling...I'd
say the FPGA guy must be happy with his two flops resynchronization
effort for clock domain crossing...

What else is a processor than a state machine?

The issue is not if the processor is a state machine or not, the issue
is about the branches a software can get into and all the time you need
to test and/or analyse those branches.

On top of it, compilers, as well as languages, are far from being
optimally defined and leave undefined behavior creeping in your work of
art silently. Likely enough norms and guidelines do exist to get you out
of the mud and 'safely' produce high quality code, but the process is
far from being cheap.

Al

Hi Al,
yes I agree 100% with you on all points.
That may be an unicum, but OK.

After posting reply to J.L. I was looking last night if opencores.org
still existed, and yes, and in the processor tab I found old Apollo guidance system.
Did you write that?

BTW of course processors are not 100% checked these days either,
have long errata, say PICs or even 386 had long lists.
Still undetected bugs happened, say 386 math bug.

I use gcc, it is a good compiler, PICs and other micros I like to program in asm.
I try to avoid libraries but this is not always possible,
[avoid] mostly because library APIs change all the time, do not like to rewrite soft
every time.
The rest I write in C, C is extremely portable, compilers (or gcc support) exists for most micros.
Most errors I make are typos (all the time with this keyboard),
gcc will find those, assembler will find those.
For FPGA I use Icarus verilog and then webpack or whatever.
I do not really understand the problems people like J.L. seem to have with code.
I think he has some slave coding for him?

Coding is very much like math, just the same in an other language.
Like telling somebody directions, go left, go right go right again,
if you make one mistake than everything after that is wrong.
What's the problem?
If you can solve the problem (know where to go) then you can tell the computah to do it too.
If you do NOT know how to solve the problem (where to go),
work that out first (we have great tools for that these days, mathlab, octave ,etc)
and then start giving directions (to the computah, processor, how to wire the hardware).
Do you need to think object oriented of learn python because you are too lazy to learn C?
or even bash scripting?
Too much is babble and too little code is released by those people.
They always complain and never come with solutions.

I play like this:
http://panteltje.com/panteltje/newsflex/download.html

J.L. was stating 'timing is no problem with the current FPGA tools',
at the same time he is dangling with pico seconds for some laser fusion.
if timing is no problem what is the deal?
OK.

And my programs have bugs, I could say those are features, not bugs, but I would be lying.
J.L. claimed several times in the past his programs or hardware is bug free.
have not heard that much of that lately.
My thoughts for the moment.

So, I was actually talking to him, will need to copy this OK (saving text).

 

On Friday, December 12, 2014 2:01:15 PM UTC, Bill Sloman wrote:

On Friday, 12 December 2014 21:46:04 UTC+11, meow...@care2.com wrote:
On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:
On 10/12/2014 3:32 AM, meow2222@care2.com.remove-cdt-this wrote:
To: Bill Sloman
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow2222@care2.com wrote:

snip

In other words you don't like the ideas presented, but can't construct a
counter argument - probably because I'm right, and whenever you try to
construct one of your counter-arguments, you find yourself stuck with a
fallacy at the core of your response.

In other words I've got better things to do than address foolish political views yet again

Nice try. But if you want to label a view either "political" or "foolish" you have to explain why. Since the basic argument about anthropogenic global warming is scientific, you've missed the point that the science is quite solid enough to make both the "denialist" and "it doesn't matter positions" look decidedly foolish.

The only political part in the anthropogenic global warming question is working out how we take the collective action which is obviously necessary.

The people who object to that are objecting to the word "collective" - as far as they are concerned, every problem has to be solved by the application of the free market. They don't seem to have noticed that we can't buy another planet, in the same way that they earlier found it difficult to appreciate that you can't buy another ozone layer, or a new set of lungs if you've wrecked the set you were born with by smoking cigarettes.

Sadly, the foolish political view is all yours.

more naive green-pov.

 

[alb]

Hi Jan,

Jan Panteltje <panteltje@yahoo.com> wrote:
[]

After posting reply to J.L. I was looking last night if opencores.org
still existed, and yes, and in the processor tab I found old Apollo
guidance system. Did you write that?

project maintainer is Dave Roberts, what makes you think that I wrote
that??? While I certainly encourage the sharing of IP cores with free
(as in libre) licenses to foster collaboration and preserve the right to
protect your ideas, I find opencores.org a timid attempt to provide a
platform of exchange.

When at my GNU/Linux console I can install a package from a trusted
source in a matter of seconds. The package comes with documentation and
a horde of people willing to help/share/contribute.

Try to imagine a similar world for FPGA development, as of today is just
a chimera. And EDA vendors are not certainly helping to make the
transition.

BTW of course processors are not 100% checked these days either, have
long errata, say PICs or even 386 had long lists. Still undetected
bugs happened, say 386 math bug.

it all depends on the project criticality. Manned missions CPU systems
are massively complex yet with a reliability that is extremely close to
100%. And bugs are documented so that are avoided operationally.

I use gcc, it is a good compiler, PICs and other micros I like to
program in asm.

I'm not sure what kind of validation you can get of your gcc, but I can
tell you that cross-compilers for a space rated processor are rather
expensive. And they *are* validated.

mostly because library APIs change all the time, do not like to
rewrite soft every time.

as long as the library has been previously validated you could use it as
is, but you need to prove that you did not change a single line of code.
Otherwise it'll be as if you wrote the library and you have to provide
verification of that code.

[]

Like telling somebody directions, go left, go right go right again, if
you make one mistake than everything after that is wrong. What's the
problem?

the problem is that when you make a mistake, the impact may appear many
hours, days, years after that mistake. Dormant bugs lay in your code
until an assumption is misinterpreted or an environment condition has
drifted beyond the original considered margins.

If you can solve the problem (know where to go) then you can tell the
computah to do it too.

Sure, the solution may well be to throw away your code and restart,
which you won't do it so easily because you are sentimentally or
psicologically attached to it and you drag on with a crappy piece of
software.

[]

I play like this:
http://panteltje.com/panteltje/newsflex/download.html

I like your meditation technique...after few minutes in the meditation
I'd fall asleep for at least a day or two...

> And my programs have bugs []

Nearly all of them have, the difficult part is to know them and identify
way around the bugs.

Al

 

[John Larkin]

On Fri, 12 Dec 2014 01:32:45 -0600, Tim Wescott
<seemywebsite@myfooter.really> wrote:

On Thu, 11 Dec 2014 18:20:22 -0800, John Larkin wrote:

On 11 Dec 2014 23:33:55 GMT, al.basili@gmail.com (alb) wrote:

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a
heavy burden for this type of application).

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

There are two fundamental aspects that make a difference between the two
worlds:

1. ease to change 2. complexity

Re-programming and FPGA is rather a PITA compared to just running 'make'
and this very simple aspect has a huge impact on the way development is
carried out. That is also why, for space applications, the development
flow tends to limit the possibility to wildly change the code base,
increasing the risk to break everything.

Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.

Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.

[]
If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.

We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.

I sure wouldn't design a motor driver without ever connecting it to a
motor.


You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.

This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?

Al

What kind of motor is it? DC motors make back EMFs. Steppers have
variable coil inductance. Both store rotational energy. All sorts of fun
stuff.

The fact that the title of this thread has "BLDC motor" in it certainly
indicates that it's a BLDC motor.

Ah. Good point.

Even more reason to connect said driver to said motor. Or at least to
a similar motor. Besides, spinning things is fun.


--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Jan Panteltje]

On a sunny day (12 Dec 2014 15:41:01 GMT) it happened al.basili@gmail.com
(alb) wrote in <cf0gkdFnkv8U1@mid.individual.net>:

Hi Jan,

Jan Panteltje <panteltje@yahoo.com> wrote:
[]
After posting reply to J.L. I was looking last night if opencores.org
still existed, and yes, and in the processor tab I found old Apollo
guidance system. Did you write that?

project maintainer is Dave Roberts, what makes you think that I wrote
that??? While I certainly encourage the sharing of IP cores with free
(as in libre) licenses to foster collaboration and preserve the right to
protect your ideas, I find opencores.org a timid attempt to provide a
platform of exchange.

Hi Al,

Well, OK, it is better than nothing.
Had not been there for maybe 10 years, happy it still exists.

When at my GNU/Linux console I can install a package from a trusted
source in a matter of seconds. The package comes with documentation and
a horde of people willing to help/share/contribute.

Now wait a minute, but maybe that is more for sci.crypt,
but 'trusted' is a word that makes me wonder twice.
Recently FSF released a program that is supposed to find government spy
programs... now who controls who, we see RSA was payed 10 million to put a NSA
hack into their encryption.
Open SSL or whatever Sel-Linux?? yamustabekidding.

When I started with 'Linux' in 1998? it was SLS Linux,
found it on some CD that came with a magazine.
Because the apps I needed (not that the apps word even existed at that time)
did not even exist, so started writing my own.
Honestly sometimes because it was faster and more fun than RTFM for things others wrote,
that is how this news reader I use (NewsFleX) was born, I needed a Free Agent for Linux.

Try to imagine a similar world for FPGA development, as of today is just
a chimera. And EDA vendors are not certainly helping to make the
transition.

I did use some jpeg encoding stuff that many years ago from opencores,
and I learned a lot from looking at others code.

BTW of course processors are not 100% checked these days either, have
long errata, say PICs or even 386 had long lists. Still undetected
bugs happened, say 386 math bug.

it all depends on the project criticality. Manned missions CPU systems
are massively complex yet with a reliability that is extremely close to
100%. And bugs are documented so that are avoided operationally.

We used to say:
The difference between professional equipment and just commercial stuff is that he professional
equipment has all things documented.
Need not be better though, sometimes it was not.

I use gcc, it is a good compiler, PICs and other micros I like to
program in asm.

I'm not sure what kind of validation you can get of your gcc, but I can
tell you that cross-compilers for a space rated processor are rather
expensive. And they *are* validated.

I try to avoid libraries but this is not always possible, [avoid]
mostly because library APIs change all the time, do not like to
rewrite soft every time.

as long as the library has been previously validated you could use it as
is, but you need to prove that you did not change a single line of code.
Otherwise it'll be as if you wrote the library and you have to provide
verification of that code.

Yes, and no.
There is the F35 (fighter), and recently on the air show in the UK (where it could not
go because it was grounded and limited to a 4 hour flight or something),
there also was a small fighter design made with of the shelves parts,
faster, cheaper, and 4sure better than the F35, in the sense that it did really fly for example.
So all the bean counters or women quotes in power of political assigned puppets who decide where it goes
are fully concentrated on job creation and not an any result whatsoever.
At that point J.L. is right, large software projects are sold because what is really sold (at the most) is simulations,
that cargo handling system for the UK for example, and reality was a bit different,
cost overruns, customers pissed etc.
We had the same with the tax system modification software, millions were spend, and nothing worked.

Like telling somebody directions, go left, go right go right again, if
you make one mistake than everything after that is wrong. What's the
problem?

the problem is that when you make a mistake, the impact may appear many
hours, days, years after that mistake.

Sure, work from bottom up, modular, I re-use code I wrote all the time.
So do not use exotic languages, keep an overview of the total thing,
NASA had that landing gear switch problem on one of the mars landers that caused it to crash.
In the time of Von Braun there was one man who knew his stuff who had overview, he was bottom up.
Now some ballpen sucker in the pentagon draws up something and it goes nowhere.
Like an architect that does not know about stones.

Dormant bugs lay in your code
until an assumption is misinterpreted or an environment condition has
drifted beyond the original considered margins.

No, it means you had no clue when writing it, I know, I often have no clue,
and have to search of hours or find out the hard way how to do it,
but that experience is worth it, from that point on things fly.

If you can solve the problem (know where to go) then you can tell the
computah to do it too.

Sure, the solution may well be to throw away your code and restart,
which you won't do it so easily because you are sentimentally or
psicologically attached to it and you drag on with a crappy piece of
software.

I have several directories with programs i started and then abandoned (never finished) because
there were better ways.
In fact I have so many programs that on a regular basis I run into some code (and gave it name too) I wrote,
and just wonder 'what in the world is this',
If i did not bother with a README, run the -h for help,
if that still means nothing then I have to read the source.. Oh yea, I remember now.

I play like this:
http://panteltje.com/panteltje/newsflex/download.html

I like your meditation technique...after few minutes in the meditation
I'd fall asleep for at least a day or two...

And my programs have bugs []

Nearly all of them have, the difficult part is to know them and identify
way around the bugs.

Would I trust my life with my own programs? Probably not
But, if I had to, maybe yes. Depends.

 

[John Larkin]

On 12 Dec 2014 07:58:32 GMT, al.basili@gmail.com (alb) wrote:

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
In an FPGA, there are usually many small synchronous state machines
that interact in controlled ways.

Do not underestimate the garbage you could produce within an FPGA and
how eventually strongly coupled are all those tiny synchronous FSMs,
just to the point that they become a giant blob of gates!

Sure, some people design logic hairballs. But the true religion of
synchronous logic design can be taught, to willing listeners, pretty
quickly.

The idea to break functionality into small, manageable pieces of logic,
which interact in a /controlled/ way is very applicable to software as
well. Yet the practice is not always the most common one.

Programs are never commonly-clocked synchronous state machines, and
the interactions are not synchronous or necessarily atomic. Emulating
the FPGA model in software is possible (I do it) but rare. Most
multi-thread programs, and maybe most single-thread programs, are
hairballs.

Usually, data does not affect
control states. States are visible and usually explicitely managed...
ALL of them. The biggest hazard in FPGA design is usually clock-domain
crossings. Pure timing problems are rare, what with modern FPGAs being
blindingly fast and the tools being pretty conservative about margins.

The biggest hazard in FPGA is the very same as software...a big blob of
unstructured and unmaintainable code. Most of the times functions are
tightly coupled and faults in one propagate way too far before revealing
themselves. In the end a debugging nightmare.

My guys test bench things before they run it, with logic simulators.
FPGAs usually work at first compile. The worst situation is when we
use other peoples' hard or soft IP, which tends to be poorly
documented. So we often do stuff by hand, like DDSs, to be sure we
understand it.

An FPGA doesn't have an OS or RTOS, so at least we don't have to fight
that.

And FPGAs do not depend on operating systems and drivers and
undocumented peripherial controllers. Well, sometimes they do use a
mysterious PCIe block, or encrypted IP, but even those usually work.

As the number of IPs and their configuration space increases, a very
similar scenario is starting to appear in the ASIC/FPGA world as well
(and we do not have open/free platforms to play with like we do with
software).

Once you add a couple of ARM cores to an FPGA, naturally the ARMs
inherit all the bug potential of C procedural software... horrors of
interrupts, mutexes, threads, pipes, callbacks, logic mazes.

You can do the same horrors on FPGAs fabric, but as I said, the software
complexity is way bigger.

C is a sequential, procedural language. VHDL is not. That seems to
make a lot of difference.

Threads do provide a very similar level of 'concurrency' between tasks.
The main difference I see is in the mindset. When you have to go to
silicon the cost is such that you are forced to instrument your code
with lots of testing features and the verification is not something you
can scrap off the schedule easily.

Sure. I have observed here in the past that, the easier it is to
change something, the less likely it will be right. Software can be
changed and compiled and run in seconds, so people tend to hack and
try it. I do that myself for things like screen layouts... futz it
until it looks good. People who build bridges and airplanes and ASICS
tend to be more careful. I think FPGA designers tend to be more
careful than c coders.

Good book: "Showstopper!" by Zachary.

IMO this is why big software projects fail or are far too expensive
since they inherit the very quick modify-compile-try cycle from the
'hello world' program, believing that you can *always* modify the code.
When you are forced to change the pillars of your software it may easily
fall as a card castle, beyond repair. Yes you can change the code, but
the consequences are far too often not perceived correctly.

Yeah, the tipping point is when the project complexity exceeds the
module quality; then, as you say, it often goes to hell. Small single
programs, like the embedded things that Jan (and I) write, can be done
well and quickly. The dangerous size of a programming team is two or
more.

We live in the dark ages of computer programming. Something better has
to come along, along the *rough* idea of LabView.

One of the best programming languages of all time was/is COBOL.


--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Bill Sloman]

On Saturday, 13 December 2014 03:12:49 UTC+11, meow...@care2.com wrote:

On Friday, December 12, 2014 2:01:15 PM UTC, Bill Sloman wrote:
On Friday, 12 December 2014 21:46:04 UTC+11, meow...@care2.com wrote:
On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:
On 10/12/2014 3:32 AM, meow2222@care2.com.remove-cdt-this wrote:
To: Bill Sloman
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow2222@care2.com wrote:

snip

In other words you don't like the ideas presented, but can't construct a
counter argument - probably because I'm right, and whenever you try to
construct one of your counter-arguments, you find yourself stuck with a
fallacy at the core of your response.

In other words I've got better things to do than address foolish political views yet again

Nice try. But if you want to label a view either "political" or "foolish" you have to explain why. Since the basic argument about anthropogenic global warming is scientific, you've missed the point that the science is quite solid enough to make both the "denialist" and "it doesn't matter positions" look decidedly foolish.

The only political part in the anthropogenic global warming question is working out how we take the collective action which is obviously necessary..

The people who object to that are objecting to the word "collective" - as far as they are concerned, every problem has to be solved by the application of the free market. They don't seem to have noticed that we can't buy another planet, in the same way that they earlier found it difficult to appreciate that you can't buy another ozone layer, or a new set of lungs if you've wrecked the set you were born with by smoking cigarettes.

Sadly, the foolish political view is all yours.

more naive green-pov.

There's nothing naive about my point of view

http://www.aip.org/history/climate/index.htm

I've ploughed through the AIP website (and read a lot of printed material on the subject as well).

Since you seem to be a brainwashed right-winger who declines to even try to construct an argument, this really isn't a plausible claim.

You sound like James Arthur, who sets aside a generation of climate science on the basis of what he was told at a dinner party by a failed would-be climate scientist.

--
Bill Sloman, Sydney

 

On Saturday, December 13, 2014 12:49:17 AM UTC, Bill Sloman wrote:

On Saturday, 13 December 2014 03:12:49 UTC+11, meow...@care2.com wrote:
On Friday, December 12, 2014 2:01:15 PM UTC, Bill Sloman wrote:
On Friday, 12 December 2014 21:46:04 UTC+11, meow...@care2.com wrote:
On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:
On 10/12/2014 3:32 AM, meow2222@care2.com.remove-cdt-this wrote:
To: Bill Sloman
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow2222@care2.com wrote:

snip

In other words you don't like the ideas presented, but can't construct a
counter argument - probably because I'm right, and whenever you try to
construct one of your counter-arguments, you find yourself stuck with a
fallacy at the core of your response.

In other words I've got better things to do than address foolish political views yet again

Nice try. But if you want to label a view either "political" or "foolish" you have to explain why. Since the basic argument about anthropogenic global warming is scientific, you've missed the point that the science is quite solid enough to make both the "denialist" and "it doesn't matter positions" look decidedly foolish.

The only political part in the anthropogenic global warming question is working out how we take the collective action which is obviously necessary.

The people who object to that are objecting to the word "collective" - as far as they are concerned, every problem has to be solved by the application of the free market. They don't seem to have noticed that we can't buy another planet, in the same way that they earlier found it difficult to appreciate that you can't buy another ozone layer, or a new set of lungs if you've wrecked the set you were born with by smoking cigarettes.

Sadly, the foolish political view is all yours.

more naive green-pov.

There's nothing naive about my point of view

http://www.aip.org/history/climate/index.htm

I've ploughed through the AIP website (and read a lot of printed material on the subject as well).

Since you seem to be a brainwashed right-winger who declines to even try to construct an argument, this really isn't a plausible claim.

You sound like James Arthur, who sets aside a generation of climate science on the basis of what he was told at a dinner party by a failed would-be climate scientist.

You sound like someone that thinks he can mind read, but cant. Why do such people always come up with silly explanations?


NT

 

[Bill Sloman]

On Saturday, 13 December 2014 11:58:59 UTC+11, meow...@care2.com wrote:

On Saturday, December 13, 2014 12:49:17 AM UTC, Bill Sloman wrote:
On Saturday, 13 December 2014 03:12:49 UTC+11, meow...@care2.com wrote:
On Friday, December 12, 2014 2:01:15 PM UTC, Bill Sloman wrote:
On Friday, 12 December 2014 21:46:04 UTC+11, meow...@care2.com wrote:
On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:
On 10/12/2014 3:32 AM, meow2222@care2.com.remove-cdt-this wrote:
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com
wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow2222@care2.com wrote:

<snip>

Sadly, the foolish political view is all yours.

more naive green-pov.

There's nothing naive about my point of view

http://www.aip.org/history/climate/index.htm

I've ploughed through the AIP website (and read a lot of printed material on the subject as well).

Since you seem to be a brainwashed right-winger who declines to even try to construct an argument, this really isn't a plausible claim.

You sound like James Arthur, who sets aside a generation of climate science on the basis of what he was told at a dinner party by a failed would-be climate scientist.

You sound like someone that thinks he can mind read, but can't. Why do such people always come up with silly explanations?

I wonder where the "mind-read" came from? Perhaps NT entertains the delusion that I think he has a mind? He comes across as a pre-programmed parrot - and not an African Grey parrot either.

http://en.wikipedia.org/wiki/Alex_%28parrot%29

--
Bill Sloman, Sydney

 

[Phil Hobbs]

On 12/11/2014 9:20 PM, John Larkin wrote:

On 11 Dec 2014 23:33:55 GMT, al.basili@gmail.com (alb) wrote:

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a heavy
burden for this type of application).

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

There are two fundamental aspects that make a difference between the two
worlds:

1. ease to change
2. complexity

Re-programming and FPGA is rather a PITA compared to just running
'make' and this very simple aspect has a huge impact on the way
development is carried out. That is also why, for space applications,
the development flow tends to limit the possibility to wildly change the
code base, increasing the risk to break everything.

Most of the FPGA used in space applications are also *not*
reprogrammable and they cost a fortune, so great care is taken before
giving the go to program the device. Usually code coverage aims to 100%
and often gets very close to it, yet bad specifications are the very
root of all mistakes.

Secondly the complexities tackled by a software stack w.r.t. to an FPGA
is certainly far from being comparable. A software system is extremely
more complex to handle, but things are changing rapidly since new space
rated FPGAs are becoming huge monsters for multicore SoC and loads of
fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift
would be required in handling those devices since verification efforts
will skyrocket together with complexity.

[]
If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.

We do not have the motor, we *just* make the electronics for it and when
(or if) we get the motor it will be too late to make mods. We need to
rely our choices on analysis and not on a trial.

I sure wouldn't design a motor driver without ever connecting it to a
motor.


You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.

This is what I also believed. But maybe for my precision requirement I
do not need to know motor losses and a static inductive load would
suffice, am I wrong?

Al

What kind of motor is it? DC motors make back EMFs. Steppers have
variable coil inductance. Both store rotational energy. All sorts of
fun stuff.

And PM motors look like gigantic capacitors at low frequency.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

On Friday, December 12, 2014 7:49:17 PM UTC-5, Bill Sloman wrote:

On Saturday, 13 December 2014 03:12:49 UTC+11, meow...@care2.com wrote:
On Friday, December 12, 2014 2:01:15 PM UTC, Bill Sloman wrote:
On Friday, 12 December 2014 21:46:04 UTC+11, meow...@care2.com wrote:
On Wednesday, December 10, 2014 12:33:09 AM UTC, Bill Sloman wrote:
On 10/12/2014 3:32 AM, meow...@care2.com wrote:
To: Bill Sloman
On Monday, December 8, 2014 10:50:00 AM UTC, Bill Sloman wrote:
On Monday, 8 December 2014 17:31:38 UTC+11, meow...@care2.com wrote:
On Monday, December 8, 2014 6:14:23 AM UTC, Don Y wrote:
On 12/7/2014 10:22 PM, meow...@care2.com wrote:

snip

In other words you don't like the ideas presented, but can't construct a
counter argument - probably because I'm right, and whenever you try to
construct one of your counter-arguments, you find yourself stuck with a
fallacy at the core of your response.

In other words I've got better things to do than address foolish political views yet again

Nice try. But if you want to label a view either "political" or "foolish" you have to explain why. Since the basic argument about anthropogenic global warming is scientific, you've missed the point that the science is quite solid enough to make both the "denialist" and "it doesn't matter positions" look decidedly foolish.

The only political part in the anthropogenic global warming question is working out how we take the collective action which is obviously necessary.

The people who object to that are objecting to the word "collective" - as far as they are concerned, every problem has to be solved by the application of the free market. They don't seem to have noticed that we can't buy another planet, in the same way that they earlier found it difficult to appreciate that you can't buy another ozone layer, or a new set of lungs if you've wrecked the set you were born with by smoking cigarettes.

Sadly, the foolish political view is all yours.

more naive green-pov.

There's nothing naive about my point of view

http://www.aip.org/history/climate/index.htm

I've ploughed through the AIP website (and read a lot of printed material on the subject as well).

Since you seem to be a brainwashed right-winger who declines to even try to construct an argument, this really isn't a plausible claim.

You sound like James Arthur, who sets aside a generation of climate science on the basis of what he was told at a dinner party by a failed would-be climate scientist.

It was one of the model-writers, employed by the government on one of the
major climate models at the time--not failed at all--and nothing to do with
a dinner party.

IOW you got every detail wrong, and made several up.

He said the models became uncorrelated with observed reality within a year or
so.

Just looking at the models, anyone can see they're hopelessly naive--they're
not faithful representations of known physical processes. They're collections
of fudge-factors and subjective characterizations.

Go ahead--extrapolate out two centuries. The moon's made of cheese, we're all
under water, and the polar caps exploded. Twice.

Cheers,
James Arthur