Can you turn off Pipeline in ARM Cortex M3

[Klaus Kragelund]

Hi

I am not an embedded expert, so please be patient

I have an application with 6 phase PWM and the CC2650 TI processor does not have deadtime support (to avoid cross conduction in a 3 stage halfbridge design)

So, I could code this so when the timer PWM compare capture is updated, I check the value that is needed to setup and adjust both the lowside and highside compare values.

That requires IF statement, and no control of where the program might continue in flash and thus the 3 stage pipeline in the Cortex M3 must be flushed

A colleague said it would require a lot of code to do that. But, is it possible to disable the pipeline all together, so there will be no flushes and time used for this check is determined by the clock frequency directly? (no optimization from the pipeline)

Regards

Klaus

[David Brown]

If I understand you correctly, what you are trying to get here is
cycle-accurate deterministic instruction counts for a series of
instructions - i.e., you want to be sure of /exactly/ how long those
instructions will take, in order to make exactly the right changes to
your lowside and highside values.

If that is true, then the pipeline in the cpu is only one relatively
minor issue - there are many more factors that can affect exact timing.
Some factors can be eliminated or reduced (depending on the details of
the chip), but not all.

Putting it bluntly, you don't have that sort of control - and if you
think you need it, you've got a poor design (of hardware or software).
Take a step back and look at what you are really trying to do, and if
you have the right approach.

If you conclude that you /do/ need accurate timing, but not necessarily
cycle accurate, then there are various possibilities to deal with that.
Disabling the cpu's pipeline is not one of those possibilities. Post
some rough code, and perhaps someone can give you some ideas. (Also
note what compiler you are using, as this sort of stuff can be
compiler-dependent.)

[Tom Gardner]

There is, of course, a significant difference between
predictability, repeatability and worst-case behaviour.
I have no idea whether the OP was thinking of that.

If you want the compiler to predict the number of cycles
required, then the only processor/compiler that I know can
do that is the XMOS series. Multicore variants are surprisingly
cheap at digikey. Next time I have a hard real-time control-loop,
I'll look at them very seriously.

[rickman]

On 9/8/2015 8:43 AM, Klaus Kragelund wrote:
> Hi
>
> I am not an embedded expert, so please be patient
>
> I have an application with 6 phase PWM and the CC2650 TI processor
> does not have deadtime support (to avoid cross conduction in a 3
> stage halfbridge design)
>
> So, I could code this so when the timer PWM compare capture is
> updated, I check the value that is needed to setup and adjust both
> the lowside and highside compare values.
>
> That requires IF statement, and no control of where the program might
> continue in flash and thus the 3 stage pipeline in the Cortex M3 must
> be flushed

I don't know the details of the Cortex line, but most processors assume
the processing will continue in sequence and if the branch is taken the
pipeline is flushed. So this is entirely predictable if you know which
way the code branches. You have not indicated exactly what the concern
is. Whatever your issue with the pipeline is, I doubt you really need
to "turn it off" which would slow your code to as little as 1/3.

> A colleague said it would require a lot of code to do that. But, is
> it possible to disable the pipeline all together, so there will be no
> flushes and time used for this check is determined by the clock
> frequency directly? (no optimization from the pipeline)

You haven't given much info to go on. The ARM instruction set also
includes conditional instructions which are always fetched in line, but
only executed if the appropriate flag is set vs. clear. I believe the
timing is always the same for those. If you code in assembly I expect
you can find a suitable set of code to meet your needs whatever they may
be.

--

Rick

[Tim Wescott]

I'm pretty sure that your concern is that as you change the duty cycle
you may update one capture compare (I'm gonna call it 'CC') value in a
way that causes both transistors to be on at the same time, then have the
timer fire off, then update the other one -- yes? What, I ask, is a bit
of noxious smoke between friends?

My first urge is to change the hardware. This situation should not have
been allowed to develop in the first place -- either someone should have
used a processor with dead time control, or they should have used gate
drive circuitry with dead time control (there are scads of ways to do
this in hardware-only), or they should have made damned sure that they
knew how to make it work in software.

If you have any influence over the hardware at all, I would start by
checking the schematic -- if you're lucky, someone used a gate driver
with dead-time control, meaning you can just add the appropriate
capacitor and you're done. Or someone may have put in the older-style
diode-and-resistor network that accomplishes the same thing.

If all of that failed, I would check to see if the processor buffers the
CC numbers -- some companies design their PWM peripherals so that the
command registers are buffered and are only written at a specific point
in the PWM cycle. If you interrupt on this point, and always manage to
write the command values well within one PWM interval, then all you need
to do is make sure to write the correct values.

Failing all else, I would monitor the direction that the PWM is going,
and always write the CC commands in such an order that during the
interval that one register has been written and the other hasn't, the
dead time is increased rather than made overlapping. This may cause the
occasional inefficient operation and some strange EMI issues, but at
least it won't let out the magic smoke. As long as your CC registers are
declared volatile and your hardware doesn't do anything funny then you
should be OK.

If you are concerned that the pipeline may disorder your ordered memory
writes, the ARM has an instruction to flush the pipeline before
proceeding (I'm pretty sure that it's absolutely unnecessary in your case
-- but if you're feeling paranoid it's there.) If you were using a
PowerPC processor then I could recommend the EIEIO instruction which has
my FAVORITE MNEMONIC EVER, but you're not, so you'll have to live with
whatever stogy British mnemonic goes with the ARM stuff.

--

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

[David Brown]

Absolutely - and once the OP has thought about the real issues and what
he actually needs, we can suggest ideas to implement it.

>
> If you want the compiler to predict the number of cycles
> required, then the only processor/compiler that I know can
> do that is the XMOS series. Multicore variants are surprisingly
> cheap at digikey. Next time I have a hard real-time control-loop,
> I'll look at them very seriously.
>

I have used XMOS devices a little, a few years ago. They are definitely
an interesting architecture (my boss always worries when a developer
describes a chip or a project as "interesting" :-). The development
tools were a bit problematic at that time, and their example code was a
bit of a mess, but I believe things have improved since then. I would
enjoy doing another project with them. Just beware that they have quite
limited memory that is needed for both program and data - although XMOS
are keen on doing both USB and Ethernet in software, the chips don't
have enough RAM to do much with such interfaces.

[David Brown]

For modern embedded PPC cores (such as Freescale's MPC5xxx families,
using the z6 core), the EIEIO instruction has been replaced by the
depressingly boring MBAR opcode. It's a great step backward, in my opinion.

[Tim Wescott]

Man, you go to sleep for JUST ONE DECADE and they go and change things!

I just want to know if that mnemonic was intentional -- I know it would
have been if I'd been on the team and had enough influence.

[Dimiter_Popoff]

On 08.9.2015 г. 20:55, Tim Wescott wrote:
> On Tue, 08 Sep 2015 19:48:19 +0200, David Brown wrote:

>.....

>> For modern embedded PPC cores (such as Freescale's MPC5xxx families,
>> using the z6 core), the EIEIO instruction has been replaced by the
>> depressingly boring MBAR opcode. It's a great step backward, in my
>> opinion.
>
> Man, you go to sleep for JUST ONE DECADE and they go and change things!
>
> I just want to know if that mnemonic was intentional -- I know it would
> have been if I'd been on the team and had enough influence.
>

Oh I suspect it has been intentional - the guy who did the power
architecture has been too good to not have a sense of humour.
The mnemonics overall are no good (few of them have made it into
my vpa, mostly those which are cpu unique) but this one just can't
have come by chance :-).

On the OP issue - trying to do timing in the nS range using
the processor load/store is no good. Two output compare (OC)
timer outputs will do what is needed, there should be plenty of
these on any mcu nowadays (???).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[Tom Gardner]

It would help if he told us his goal or problem, not his
solution. 'Twas ever thus.

>> If you want the compiler to predict the number of cycles
>> required, then the only processor/compiler that I know can
>> do that is the XMOS series. Multicore variants are surprisingly
>> cheap at digikey. Next time I have a hard real-time control-loop,
>> I'll look at them very seriously.
>>
>
> I have used XMOS devices a little, a few years ago. They are definitely an
> interesting architecture (my boss always worries when a developer describes a
> chip or a project as "interesting" :-).

:)

> The development tools were a bit
> problematic at that time, and their example code was a bit of a mess, but I
> believe things have improved since then. I would enjoy doing another project
> with them. Just beware that they have quite limited memory that is needed for
> both program and data - although XMOS are keen on doing both USB and Ethernet in
> software, the chips don't have enough RAM to do much with such interfaces.

Just so. But I'll take the stance that a hard real-time kernel
should be small, and that usb/ethernet should be out of that loop.

[Tim Wescott]

On Tue, 08 Sep 2015 22:13:49 +0300, Dimiter_Popoff wrote:

> On 08.9.2015 г. 20:55, Tim Wescott wrote:
>> On Tue, 08 Sep 2015 19:48:19 +0200, David Brown wrote:
>>.....
>>> For modern embedded PPC cores (such as Freescale's MPC5xxx families,
>>> using the z6 core), the EIEIO instruction has been replaced by the
>>> depressingly boring MBAR opcode. It's a great step backward, in my
>>> opinion.
>>
>> Man, you go to sleep for JUST ONE DECADE and they go and change things!
>>
>> I just want to know if that mnemonic was intentional -- I know it would
>> have been if I'd been on the team and had enough influence.
>>
>>
> Oh I suspect it has been intentional - the guy who did the power
> architecture has been too good to not have a sense of humour.
> The mnemonics overall are no good (few of them have made it into my vpa,
> mostly those which are cpu unique) but this one just can't have come by
> chance :-).
>
> On the OP issue - trying to do timing in the nS range using the
> processor load/store is no good. Two output compare (OC) timer outputs
> will do what is needed, there should be plenty of these on any mcu
> nowadays (???).

If I read it right the OP is using two output compares per half bridge,
but he is concerned about a compare happening at just the wrong moment
and having insufficient dead time.

[Klaus Kragelund]

On Tuesday, September 8, 2015 at 7:23:57 PM UTC+2, Tim Wescott wrote:
> On Tue, 08 Sep 2015 05:43:15 -0700, Klaus Kragelund wrote:
>
> > Hi
> >
> > I am not an embedded expert, so please be patient
> >
> > I have an application with 6 phase PWM and the CC2650 TI processor does
> > not have deadtime support (to avoid cross conduction in a 3 stage
> > halfbridge design)
> >
> > So, I could code this so when the timer PWM compare capture is updated,
> > I check the value that is needed to setup and adjust both the lowside
> > and highside compare values.
> >
> > That requires IF statement, and no control of where the program might
> > continue in flash and thus the 3 stage pipeline in the Cortex M3 must be
> > flushed
> >
> > A colleague said it would require a lot of code to do that. But, is it
> > possible to disable the pipeline all together, so there will be no
> > flushes and time used for this check is determined by the clock
> > frequency directly? (no optimization from the pipeline)
>
> I'm pretty sure that your concern is that as you change the duty cycle
> you may update one capture compare (I'm gonna call it 'CC') value in a
> way that causes both transistors to be on at the same time, then have the
> timer fire off, then update the other one -- yes? What, I ask, is a bit
> of noxious smoke between friends?
>

You are correct, the objective is to use the microcontroller without the crossconduction and resulting smoke.

The PWM frequency is above 10kHz, and the update of the compare capture can happen almost at that frequency, so for worst case I define that at 10kHz

We need deadtime for sure, I am just trying to see if I can avoid using external circuitry to blank simultaneous LS and HS active signals.

The processor is running at 48MHz and most instructions are executed in less than 2 clock cycles. So something like 40ns max per instruction. So lets say I have a control loop that updates the compare values at 10kHz (100us period). I could add an interrupt to trigger at the compare value and handle the deadtime in raw code (or for long deadtime, initiate a timer to set the time). Even if this code would take 10-20 cycles, it's still less than 1us, so 1% of the period. I may be able to tolerate this since this is not an high end product

Still, using 20 cents for deadtime circuit begins to sound like a needed option. The above constrution is not clean and will cause jitter in the PWM duty cycle due to issues when transitions overlap

> My first urge is to change the hardware. This situation should not have
> been allowed to develop in the first place -- either someone should have
> used a processor with dead time control, or they should have used gate
> drive circuitry with dead time control (there are scads of ways to do
> this in hardware-only), or they should have made damned sure that they
> knew how to make it work in software.
>
> If you have any influence over the hardware at all, I would start by
> checking the schematic -- if you're lucky, someone used a gate driver
> with dead-time control, meaning you can just add the appropriate
> capacitor and you're done. Or someone may have put in the older-style
> diode-and-resistor network that accomplishes the same thing.
>

I have control over the HW, but need to save every cent possible

> If all of that failed, I would check to see if the processor buffers the
> CC numbers -- some companies design their PWM peripherals so that the
> command registers are buffered and are only written at a specific point
> in the PWM cycle. If you interrupt on this point, and always manage to
> write the command values well within one PWM interval, then all you need
> to do is make sure to write the correct values.
>

As far as I can see, it does not. I would prefer center aligned PWM, and it does not support that, so I need to make adjustments to get that working too

I am seriously contemplating a semi SW PWM, a function that checks the compare values and triggering a timer that when runs out triggers the relevant output. That way I have 100% control of the PWM outputs, but it would take a lot of computing power, but I do not care about that

One could perhaps even setup the DMA trigger, so on the run-out of the timer, the relevant output is set directly by the DMA

> Failing all else, I would monitor the direction that the PWM is going,
> and always write the CC commands in such an order that during the
> interval that one register has been written and the other hasn't, the
> dead time is increased rather than made overlapping. This may cause the
> occasional inefficient operation and some strange EMI issues, but at
> least it won't let out the magic smoke. As long as your CC registers are
> declared volatile and your hardware doesn't do anything funny then you
> should be OK.
>
> If you are concerned that the pipeline may disorder your ordered memory
> writes, the ARM has an instruction to flush the pipeline before
> proceeding (I'm pretty sure that it's absolutely unnecessary in your case
> -- but if you're feeling paranoid it's there.) If you were using a
> PowerPC processor then I could recommend the EIEIO instruction which has
> my FAVORITE MNEMONIC EVER, but you're not, so you'll have to live with
> whatever stogy British mnemonic goes with the ARM stuff.

The pipeline question was to quantify if the flushing of it would cause a hickup/stall of the code, but I guess not. Disabling the pipeline would make the code more determistic

Cheers

Klaus

[Klaus Kragelund]

On Tuesday, September 8, 2015 at 7:05:56 PM UTC+2, rickman wrote:
> On 9/8/2015 8:43 AM, Klaus Kragelund wrote:
> > Hi
> >
> > I am not an embedded expert, so please be patient
> >
> > I have an application with 6 phase PWM and the CC2650 TI processor
> > does not have deadtime support (to avoid cross conduction in a 3
> > stage halfbridge design)
> >
> > So, I could code this so when the timer PWM compare capture is
> > updated, I check the value that is needed to setup and adjust both
> > the lowside and highside compare values.
> >
> > That requires IF statement, and no control of where the program might
> > continue in flash and thus the 3 stage pipeline in the Cortex M3 must
> > be flushed
>
> I don't know the details of the Cortex line, but most processors assume
> the processing will continue in sequence and if the branch is taken the
> pipeline is flushed. So this is entirely predictable if you know which
> way the code branches. You have not indicated exactly what the concern
> is. Whatever your issue with the pipeline is, I doubt you really need
> to "turn it off" which would slow your code to as little as 1/3.
>

Thanks. I looked deeper into the Cortex M3. It has a 3 level pipeline, and you are right the code will be predictable. I just need to take into account that I cannot count on the performance boost that the pipeline offers in all cases

Cheers

Klaus

[Klaus Kragelund]

I may have an option to add the Silicon Labs Busy bee:

http://www.silabs.com/Support%20Documents/TechnicalDocs/EFM8BB1_DataSheet.pdf

Pricing seems to be at 0.2USD in high volume negotiated etc, and it has center aligned PWM. In addition a kill signal from a comparator, so if a cross conduction ever occur, we can respond before the current is too high

Really a nice part :-)

Cheers

Klaus

[Tim Wescott]

For the most part, a comparator is good for limiting the duty cycle if a
motor stalls, but if you're cross-conducting it will, at best, deliver
the suicide note.

[Klaus Kragelund]

We use this technique routinely. The low side transistors does not refer to ground directly, but through a resistor. All though the current rises fast, we can sustain crossconduction. For worse cases, you can get gatedrivers that has the feature inherent (measures conduction voltage)

Cheers

Klaus

[lasselangwad...@gmail.com]

how about stm32f100?, afaict it has timers specifically for doing 3 complementary pwms with dead time and break

-Lasse

[lasselangwad...@gmail.com]

the circuit used with an IR2171 is quite nifty,

http://www.irf.com/product-info/datasheets/data/ir2127.pdf

if the gate is high and the Vce/Vds isn't low there is trouble

-Lasse

[Klaus Kragelund]

As far as I can tell the cheapest STM32F100 is double the price of the EFM8B

They are nice parts though, used them before :-)

Cheers

Klaus

[lasselangwad...@gmail.com]

Den onsdag den 9. september 2015 kl. 00.34.22 UTC+2 skrev Klaus Kragelund:
> As far as I can tell the cheapest STM32F100 is double the price of the EFM8B
>
> They are nice parts though, used them before :-)
>

ST says ~$1.3@10k , TI say ~$4@1k for the cc2650

-Lasse

[Przemek Klosowski]

On Tue, 08 Sep 2015 14:09:41 -0700, Klaus Kragelund wrote:

> Thanks. I looked deeper into the Cortex M3. It has a 3 level pipeline,
> and you are right the code will be predictable. I just need to take into
> account that I cannot count on the performance boost that the pipeline
> offers in all cases

I am not sure that the pipeline depth is an architecture feature of M3.
I'd think it's an implementation detail that could change, e.g. when your
current P/N is replaced. Plus, as others have said, you are at a mercy of
other implementation details: caches, if any, memory bank effects,
interrupt latencies, etc.

If you need cycle-accurate timing, you should use something that is
guaranteed to be cycle accurate, for instance the PRU units in TI AM335x,
as used in e.g. BeagleBone http://beagleboard.org/pru; or a dedicated
logic/FPGA.

[Dimiter_Popoff]

I don't get it then, what is stopping him to have the two OC-s
always offset by the dead time needed?

Dimiter

[rickman]

On 9/8/2015 4:51 PM, Klaus Kragelund wrote:
>
> We need deadtime for sure, I am just trying to see if I can avoid
> using external circuitry to blank simultaneous LS and HS active
> signals.
>
> The processor is running at 48MHz and most instructions are executed
> in less than 2 clock cycles. So something like 40ns max per
> instruction. So lets say I have a control loop that updates the
> compare values at 10kHz (100us period). I could add an interrupt to
> trigger at the compare value and handle the deadtime in raw code (or
> for long deadtime, initiate a timer to set the time). Even if this
> code would take 10-20 cycles, it's still less than 1us, so 1% of the
> period. I may be able to tolerate this since this is not an high end
> product
>
> Still, using 20 cents for deadtime circuit begins to sound like a
> needed option. The above constrution is not clean and will cause
> jitter in the PWM duty cycle due to issues when transitions overlap

I think you are making this too complicated. How much dead time do you
need? What is the range of the times you need to set and what are the
absolute limits?

--

Rick

[David Brown]

Why can't you just use two separate timer outputs with non-overlapping
signals? At worst, you will need an inverter on the output if the timer
block does not support inverting the output on the second block, but
most microcontroller timers can do that themselves (I am not familiar
with the exact device you are using).

Using DMA to transfer new values into the PWM unit might be convenient
if you don't want to respond to an interrupt, but you should also manage
it from an interrupt on the timer.

>
>> Failing all else, I would monitor the direction that the PWM is
>> going, and always write the CC commands in such an order that
>> during the interval that one register has been written and the
>> other hasn't, the dead time is increased rather than made
>> overlapping. This may cause the occasional inefficient operation
>> and some strange EMI issues, but at least it won't let out the
>> magic smoke. As long as your CC registers are declared volatile
>> and your hardware doesn't do anything funny then you should be OK.
>>
>> If you are concerned that the pipeline may disorder your ordered
>> memory writes, the ARM has an instruction to flush the pipeline
>> before proceeding (I'm pretty sure that it's absolutely unnecessary
>> in your case -- but if you're feeling paranoid it's there.) If you
>> were using a PowerPC processor then I could recommend the EIEIO
>> instruction which has my FAVORITE MNEMONIC EVER, but you're not, so
>> you'll have to live with whatever stogy British mnemonic goes with
>> the ARM stuff.
>
> The pipeline question was to quantify if the flushing of it would
> cause a hickup/stall of the code, but I guess not. Disabling the
> pipeline would make the code more determistic
>

Please forget about the pipeline:

1. You cannot disable the pipeline, making the discussion pointless.

2. Disabling the pipeline would not affect the predictability and
determinism of the code - the pipeline is deterministic.

3. Flushing pipelines does not disable them.

4. The determinism of the cpu is dominated by effects such as memory
buses, caches, instruction pre-fetches, etc. The pipeline itself would
be a minor issue even if it were non-deterministic.

5. If your design depends on accuracy, predictability or jitter in the
cpu execution speed, the design is broken. You are re-arranging the
chairs on the deck of the Titanic.

[Tom Gardner]

On 08/09/15 21:51, Klaus Kragelund wrote:
> Disabling the pipeline would make the code more determistic

Not significantly.

Even with i486s, with their tiny caches, the ratio between
mean and worst case (IIRC) interrupt latencies could be 10:1
(from memory 70us vs 700us).

Modern processors have much larger caches, and the variations
can be far larger.

The disparity between cache speeds and main memory speeds
is far larger, so cache misses have a larger affect on the
latency.

The i960 enabled its cache to be frozen, to avoid that kind
of problem.

Quite frankly, if you are worried about any determinism effects
due to pipelining, either you are misguided or your hardware/software
architecture needs to be changed.

If /variations/ in instruction timing really is that critical,
then you'll have to use something like the XMOS toolchain.

[Dimiter_Popoff]

On 09.9.2015 г. 12:18, Tom Gardner wrote:
> On 08/09/15 21:51, Klaus Kragelund wrote:
>> Disabling the pipeline would make the code more determistic
>
> Not significantly.
>
> Even with i486s, with their tiny caches, the ratio between
> mean and worst case (IIRC) interrupt latencies could be 10:1
> (from memory 70us vs 700us).

Hmmm, these are huge figures, even the 70uS is too huge I suppose.
A 1 MHz 6800 had IRQ latency in the range of 30uS or so.

Dimiter

[Klaus Kragelund]

The minimum deadtime is about 1us, maximum is 2-3us

Regards

Klaus

[Klaus Kragelund]

I can generate standard 6 phase PWM that way, but I need center aligned PWM in which the individual PWM signal goes both high and low with a wait state before next cycle

Regards

Klaus

[John Devereux]

We are talking about a CM3, that has sub-microsecond latency (12 cycles
from memory).


>
> Dimiter
>

--

John Devereux

[Tom Gardner]

The figures were from memory, but were definitely in units of
time (s), not conductance (S).

I've disinterred the original, "Perils of the PC Cache" by
Phillip J Koopman. In that he read data from a port and put
it in a simple circular queue. Naively looking at the data
book indicated it would take 104 clocks. Measuring the mean
time of 1e6 iterations took 149.6 clocks. The worst case
took 272 clocks.

So clearly I has mis-remembered clocks as microseconds, and
there was a factor of 2:1 (i.e. 100%) for the I/D caches,
not 10:1.

With the I/D caches turned off, he measured min-max of
484-508 clocks, i.e. 5% - a considerable improvement.

But then he also measured the effects when the TLB and cache
could get in the way, and found that the mean was 300 clocks
and the max was 900 clocks, which is the source of my 10:1.

Summary: even trivial I/D caches caused a 100% variation
between mean and max. variations. Switching caches off
reduced that to a 5% variation.

TL;DR: forget worst-case predictablity if you have caches;
loss of predictability is inherent with caches.

[Dimiter_Popoff]

On 09.9.2015 г. 18:07, Tom Gardner wrote:
> On 09/09/15 13:09, Dimiter_Popoff wrote:
>> On 09.9.2015 г. 12:18, Tom Gardner wrote:
>>> On 08/09/15 21:51, Klaus Kragelund wrote:
>>>> Disabling the pipeline would make the code more determistic
>>>
>>> Not significantly.
>>>
>>> Even with i486s, with their tiny caches, the ratio between
>>> mean and worst case (IIRC) interrupt latencies could be 10:1
>>> (from memory 70us vs 700us).
>>
>> Hmmm, these are huge figures, even the 70uS is too huge I suppose.
>> A 1 MHz 6800 had IRQ latency in the range of 30uS or so.
>
> The figures were from memory, but were definitely in units of
> time (s), not conductance (S).

Hah! I have thought for decades second was supposed to be abbreviated
to a capital S.... may be it has been the case in the past, may be
I remembered wrongly. I have been pretty consistent in my documentation
etc., if I have used a lower case s it has been an error of mine... :-).
Thanks for noting that, it may take me a while to get used to the
lower case s but I'll work on it.

>
> So clearly I has mis-remembered clocks as microseconds,

> ...

Ah that sounds more sane. 700 is still huge but comparable to say the
70 of a 68k mcu of that era (its division was in that ballpark).

[George Neuner]

On Wed, 09 Sep 2015 10:18:54 +0100, Tom Gardner
<spam...@blueyonder.co.uk> wrote:

>Quite frankly, if you are worried about any determinism effects
>due to pipelining, either you are misguided or your hardware/software
>architecture needs to be changed.

The Pentium IV has a _20_ stage pipeline: a mispredicted branch on
that chip has a significant impact on performance even if both branch
targets are in cache.

Of course, nobody in their right mind would use such a chip in a HRT
system, and it is true that load stalls are far more worrisome than a
pipeline flush ... but it is not "misguided" to be concerned about the
pipeline length.

George

[Dimiter_Popoff]

I expected something like that - do the 12 cycles include the worst case
opcode in execution (probably division)? (I guess it does, trapping
must take just a cycle or two).

The 6800 needed 22 cycles to stack all its registers.... or may be to
stack them and to fetch the vector and go there, actually I think it
was the latter. Last time I have needed that figure must have been
over 30 years ago, strange I remember it (unless I just think I
remember something, could well be the case).

Dimiter

[Tom Gardner]

On 09/09/15 16:51, Dimiter_Popoff wrote:
> On 09.9.2015 г. 18:07, Tom Gardner wrote:
>> On 09/09/15 13:09, Dimiter_Popoff wrote:
>>> On 09.9.2015 г. 12:18, Tom Gardner wrote:
>>>> On 08/09/15 21:51, Klaus Kragelund wrote:
>>>>> Disabling the pipeline would make the code more determistic
>>>>
>>>> Not significantly.
>>>>
>>>> Even with i486s, with their tiny caches, the ratio between
>>>> mean and worst case (IIRC) interrupt latencies could be 10:1
>>>> (from memory 70us vs 700us).
>>>
>>> Hmmm, these are huge figures, even the 70uS is too huge I suppose.
>>> A 1 MHz 6800 had IRQ latency in the range of 30uS or so.
>>
>> The figures were from memory, but were definitely in units of
>> time (s), not conductance (S).
>
> Hah! I have thought for decades second was supposed to be abbreviated
> to a capital S.... may be it has been the case in the past, may be
> I remembered wrongly.

It never was.

However, Tektronix used to get it wrong on their oscilloscopes - and
as a metrology company they really ought to have know better. I
suspect they finally realised the error of their ways when specifying
their digitising scope's sampling rate, e.g. 100MS/s.
Not that S=samples is correct!

> I have been pretty consistent in my documentation
> etc., if I have used a lower case s it has been an error of mine... :-).
> Thanks for noting that, it may take me a while to get used to the
> lower case s but I'll work on it.

Hey! A convert! My life's work is complete :)

[Dimiter_Popoff]

On 09.9.2015 г. 19:25, Tom Gardner wrote:
> On 09/09/15 16:51, Dimiter_Popoff wrote:
>> On 09.9.2015 г. 18:07, Tom Gardner wrote:
>>> On 09/09/15 13:09, Dimiter_Popoff wrote:
>>>> On 09.9.2015 г. 12:18, Tom Gardner wrote:
>>>>> On 08/09/15 21:51, Klaus Kragelund wrote:
>>>>>> Disabling the pipeline would make the code more determistic
>>>>>
>>>>> Not significantly.
>>>>>
>>>>> Even with i486s, with their tiny caches, the ratio between
>>>>> mean and worst case (IIRC) interrupt latencies could be 10:1
>>>>> (from memory 70us vs 700us).
>>>>
>>>> Hmmm, these are huge figures, even the 70uS is too huge I suppose.
>>>> A 1 MHz 6800 had IRQ latency in the range of 30uS or so.
>>>
>>> The figures were from memory, but were definitely in units of
>>> time (s), not conductance (S).
>>
>> Hah! I have thought for decades second was supposed to be abbreviated
>> to a capital S.... may be it has been the case in the past, may be
>> I remembered wrongly.
>
> It never was.
>
> However, Tektronix used to get it wrong on their oscilloscopes - and
> as a metrology company they really ought to have know better. I
> suspect they finally realised the error of their ways when specifying
> their digitising scope's sampling rate, e.g. 100MS/s.
> Not that S=samples is correct!

May be I have taken it from them. I used to look at some of their
service manuals when I was making my first steps in analog design
(back then I wanted to build an oscilloscope... never built it,
not many projects I have left unfinished but this is one of them.
Learned a lot while trying though. I may still build one, now at
least I know how to :D ).

Dimiter

[Tom Gardner]

One of my projects, when I get A Round Tuit, is to make a 2GS/s
4GHz scope. The trick is to find a way to do it with only trivial
analogue front end components. Hence no amplifiers, no ADCs, just
a 50ohm input with very simple analogue components. Yes, there
will be limitations, but that's half the fun :)

Yes, I know you can buy remarkably fast remarkably cheap ADCs
nowadays. But I want to do it for tens of dollars, not thousands :)

[lasselangwad...@gmail.com]

instructions like divide are aborted to take the interrupt, so the 12 cycles
(29 with floating point) from interrupt to first isr instruction executed it the real maximum

-Lasse

[Klaus Kragelund]

Yes, and that takes 600ns for at 50MHz cpu with no optimization

Is it correct that the pipeline works also in the ISR latency, so that is may shorten off the 12 cycles to effective 4? (for at 3 stage pipeline)

Cheers

Klaus

[David Brown]

A 3-stage pipeline does not mean that the cpu does 3 instructions per
clock cycle! The 12 cycle maximum latency of interrupts on an M3/M4
takes the pipeline into account, but assumes there are no latencies on
memory or buses (all instructions and vectors in cache or single-cycle
memory).

>
> Cheers
>
> Klaus
>

[Dimiter_Popoff]

On 09.9.2015 г. 22:47, Klaus Kragelund wrote:
> ....

>
> Yes, and that takes 600ns for at 50MHz cpu with no optimization
>
> Is it correct that the pipeline works also in the ISR latency, so that is may shorten off the 12 cycles to effective 4? (for at 3 stage pipeline)

No, the pipeline needs filling so it does not improve latency.

But this is not the point here.
It looks as if you are trying to figure out a way to use a hammer
on a screw; screws are meant to be used with screwdrivers, not
with hammers.

If you do not have enough timers to program them such that you will
get the dead time, you can still use those you have to initiate the
opening of one of the transistors and open the other after that by the
core in an interrupt handler. You can only guarantee the minimum time
for that, but it might be enough if the IRQ latency is in the ns range,
perhaps you can afford a jitter of a miscosecond [uS is what I would
have written, how am I supposed to do that now? "us" is more ambiguous?
Tom?] or so. If you cannot there is nothing much better you can do
with that mcu anyway.

Dimiter

[Tom Gardner]

On 09/09/15 21:56, Dimiter_Popoff wrote:
> [uS is what I would
> have written, how am I supposed to do that now? "us" is more ambiguous?
> Tom?]

:(

Prepend a number :)

More seriously I have seen a "micro" character in some usenet posts.
I wonder how it got there, and whether other people's clients rendered
it correctly.

Let's try "μ" which is simply a "special character" inserted into
an OpenOffice document then copied/pasted into this message, which
I'm composing in SeaMonkey. Since it can also be copied/pasted
into a linux/bash command line in the xfce terminal emulator, there's
cause for hope.

If it works I don't know whether I'll use it every time and become
a major nitpicker with those that don't!

[Tom Gardner]

Well, it has apparently worked from my PoV.
Has it worked for you?
Do you see it as U+03BC or something?

[Tim Wescott]

It worked for me.

I'll stick with 'us'.

You could use 'mms'.

--

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

[Tom Gardner]

Oh, I'd forgotten about that one! But "us" works in most cases.

[rickman]

Only if the interrupt is enabled. Depending on what the code is doing
it can be a lot longer. That is the real concern in an ISR.

--

Rick

[rickman]

Going back to my old days when caps were measured in mmf, mms would be a
picosecond.

--

Rick

[Dimiter_Popoff]

It worked for me, too. And I have the character available in my
editors (text and graphics) under dps but not via a single key;
I have used it earlier but I think lately I just use "u".

I suppose I can get used to "us" instead of "uS", but may be an
option would be se-6 or sE-6... I still can't quite swallow the
thought that S is invalid for seconds. I looked at my very
old tek 465B, well, its front panel is also designated with
lower case around the timebase knob.

Dimiter

[David Brown]

µs works fine for me. As long as readers have a reasonably modern
newsreader, there should be no problem with the letter "mu" for micro -
it is a standard character in the standard fonts on most systems. If
someone has customised their desktop or newsreader to use a weird font
with a more limited character range, then it might show up oddly. If
there are any fans of command-line newsreaders, they should also see it
if they have a utf-8 locale on their systems.

As for typing it, that depends on your system and your keyboard.
Windows is (as always) more limited. It should be easy for most
non-English keyboard layouts, which separate the "Alt" and the "Alt Gr"
keys - on my Norwegian keyboard layout, it's just AltGr-m. But if that
doesn't work, character map is probably the least inconvenient method
unless you can remember the Alt + numeric keyboard sequence.

For Linux, you have other options. Again, depending on the keyboard
layout, AltGr-m is likely to work - certainly on my Norwegian layout I
can get a wide range of characters with combinations of AltGr, shift,
and different keys. Then there is also the "compose" key - typically,
this is not assigned by default, but you can set it up if you want it (I
use the "scroll lock" key as compose). Then µ is compose + m + u.

[Jan Coombs <Jan-54 >]

On Wed, 09 Sep 2015 17:32:50 -0500
Tim Wescott <seemyw...@myfooter.really> wrote:

> On Wed, 09 Sep 2015 22:32:38 +0100, Tom Gardner wrote:
>
> >> Let's try "μ" which is simply a "special character"
>

> It worked for me.
>
> I'll stick with 'us'.
>
> You could use 'mms'.
>

Or going deviant bigtime, follow the Pharmaceutical industry and
use 'MC' ?

Jan Coombs
--
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[rickman]

Along with the often used

° - Alt-0176
± - Alt-0177

mu is
µ - Alt-0181

The zero is very important. Without it you get other chars.

--

Rick

[John Devereux]

Yes if he is relying on a guaranteed interrupt latency he should not
turn them off. Also should be top priority irq!

He should not turn the clock down to 1 khz either. Or set his timer
output back to a GPIO. Etc.

I don't think it is a good idea to have the deadtime enforced by
software, regardless. OP is going to get mighty tired of changing blown
FETS during development. I was just responding to the talk above about
caches and pipelines and 70us vs 700us latencies. None of that matters
on a CM3 if a guaranteed <1us jitter is acceptable.


--

John Devereux

[John Devereux]

Hmm, there was the "slideback sampler" that John Larkin and Mike Monet
used to fight about, a decade or two ago in sci.electronics.design.

> Yes, I know you can buy remarkably fast remarkably cheap ADCs
> nowadays. But I want to do it for tens of dollars, not thousands :)
>

--

John Devereux

[Tom Gardner]

Don't throw that scope out; there's a thriving market
for them on ebay, /especially/ if they are working :)
I have the HP equivalent, the HP1740A, and the local
hackspace has a near relative, the Tek2213.

[Tom Gardner]

On 10/09/15 08:05, David Brown wrote:
> For Linux, you have other options. Again, depending on the keyboard
> layout, AltGr-m is likely to work - certainly on my Norwegian layout I
> can get a wide range of characters with combinations of AltGr, shift,
> and different keys. Then there is also the "compose" key - typically,
> this is not assigned by default, but you can set it up if you want it (I
> use the "scroll lock" key as compose). Then µ is compose + m + u.

Oh, excellent.

Trying the other combinations is going to be a great way of
pointing out to idiot companies that valid email
addresses aren't limited to roman alphanumeric characters.
I think I'll use something like "þomas gardner"- they
won't notice the inaccuracy.

[David Brown]

Shift-AltGr-0 or Compose+o+o gives me °

> ± - Alt-0177

AltGr-+ or Compose+++- gives me ±

Both of these work in Linux, but not Windows.

[David Brown]

UTF-8 characters should, in theory, work in email addresses - but only
in theory. In practice, you can expect trouble somewhere along the line.

But UTF-8 characters should be fine in email bodies, as long as they are
reasonably common. So letters like þðñçıß should be no problem, as well
as symbols like ½²“‘”’«»ħ .

How do these ones turn out?

Real numbers: ℝ
Mho (inverted Ohmega): ℧
Aleph: ℵ
Set membership: ∊
fi ligature: fi
alpha: α
beta: β
infinity: ∞

[Tom Gardner]

On 10/09/15 10:06, David Brown wrote:
> On 10/09/15 10:46, Tom Gardner wrote:
>> On 10/09/15 08:05, David Brown wrote:
>>> For Linux, you have other options. Again, depending on the keyboard
>>> layout, AltGr-m is likely to work - certainly on my Norwegian layout I
>>> can get a wide range of characters with combinations of AltGr, shift,
>>> and different keys. Then there is also the "compose" key - typically,
>>> this is not assigned by default, but you can set it up if you want it (I
>>> use the "scroll lock" key as compose). Then µ is compose + m + u.
>>
>> Oh, excellent.
>>
>> Trying the other combinations is going to be a great way of
>> pointing out to idiot companies that valid email
>> addresses aren't limited to roman alphanumeric characters.
>> I think I'll use something like "þomas gardner"- they
>> won't notice the inaccuracy.
>>
>
> UTF-8 characters should, in theory, work in email addresses - but only
> in theory. In practice, you can expect trouble somewhere along the line.

My objection is to web pages where I fill in my email address
and their stupid validation procedure rejects it. Even worse is
the case where one of the company's systems accept it and others
reject it - which can make it impossible for their internal staff
to change it!

I like using foo+s...@gmail.com when communicating with
Scrotty Co, so I can track leaks and easily filter messages.

[Tom Gardner]

On 10/09/15 07:42, Dimiter_Popoff wrote:

> I suppose I can get used to "us" instead of "uS", but may be an
> option would be se-6 or sE-6... I still can't quite swallow the
> thought that S is invalid for seconds. I looked at my very
> old tek 465B, well, its front panel is also designated with
> lower case around the timebase knob.

It more often occurred on their on-screen displays, e.g.
the first one I came across: http://www.jvgavila.com/t7d20_w1.jpg

[Tom Gardner]

On 10/09/15 08:51, John Devereux wrote:

> Tom Gardner <spam...@blueyonder.co.uk> writes:
>> One of my projects, when I get A Round Tuit, is to make a 2GS/s
>> 4GHz scope. The trick is to find a way to do it with only trivial
>> analogue front end components. Hence no amplifiers, no ADCs, just
>> a 50ohm input with very simple analogue components. Yes, there
>> will be limitations, but that's half the fun :)
>
> Hmm, there was the "slideback sampler" that John Larkin and Mike Monet
> used to fight about, a decade or two ago in sci.electronics.design.

As far as I can tell from mostly dead links, similar
but not quite the same.

Given that it is solely a hobby project, I would expect
my performance to be worse. For example, if someone mentions
jitter then I will shut my eyes, put my hands over my ears
and sing "la la la".

[Dimiter_Popoff]

I now remember seeing that as well on newer scopes than my 465B
(which works and I am not planning to part with, it was THE scope
back in the day when I wanted to build one I was looking up to :-).
I may well have taken it from there.

I suppose the capital S is justified though. While invalid in "normal"
text, put into context - as on a scope display - it deals with the
"us" ambiguity which might be annoying at a subconscious level
not only to me. Well I may only be looking for an excuse to not
start changing the S in the spectrometry software on our devices :-).

Dimiter

[Tom Gardner]

Some Tek scopes had curve-tracers, and one of the principal
characteristics of FETs is their conductance - measured in
Siemens (S). Hence it might not be unambiguous on a Tek display!

Nowadays, "S" often means samples, as in S/s. While the purist
in me still prefers "Sa/s", I don't find "S/s" so visually
jarring as "uS".

So, I hope your spectrometry software never has to display
anything w.r.t. samples.

[Dimiter_Popoff]

The software does not talk of samples indeed but it does
display them in an oscilloscope window (the input signal is
continuously digitized at a few megasamples/s).
However in all references I have been consistent with the
capital s for seconds.... I write MspS IIRC :-).
But these are for internal usage, I have deliberately
avoided giving figures on that - it is too low level to be
of interest to most customers and I have had more than one
wannabe cloner (none successful, if they knew what they
were trying to do they would never have tried) - why save
them some head scratching and scope probing :-).
I do have a cpS (or CpS, not sure now) (counts per second)
in at least one of the result windows.

Dimiter

[Tom Gardner]

On 10/09/15 12:26, Dimiter_Popoff wrote:
> I write MspS IIRC :-)

And measure power station output in mW and
FM band frequency in mHz or Mhz? :)

The next misstep would be to measure power in MWh
or energy in MW but I'm sure you wouldn't fall
into that trap! (Unlike others, typically w.r.t.
green energy :( )

[Tom Gardner]

When feeling perverse I like to measure velocity
in furlongs per fortnight, or time in nano-centuries.
(1 nc ~= pi s)

Best not to ask about gallons, hundredweights and
ton.*s

[dp]

Well MW is a megawatt and mW is a milliwatt, that is no
problem. MHz for megahertz etc., M fot mega and m for
milli is standard I think.

Dimiter

(posting from a phone on a bus using google groups mobile,
let us see what a mess that will produce :). I tried to copy/paste
the text I wanted to quote, was hopeless so I gave up on that.)

[John Devereux]

Tom Gardner <spam...@blueyonder.co.uk> writes:

> On 10/09/15 08:51, John Devereux wrote:
>> Tom Gardner <spam...@blueyonder.co.uk> writes:
>>> One of my projects, when I get A Round Tuit, is to make a 2GS/s
>>> 4GHz scope. The trick is to find a way to do it with only trivial
>>> analogue front end components. Hence no amplifiers, no ADCs, just
>>> a 50ohm input with very simple analogue components. Yes, there
>>> will be limitations, but that's half the fun :)
>>
>> Hmm, there was the "slideback sampler" that John Larkin and Mike Monet
>> used to fight about, a decade or two ago in sci.electronics.design.
>
> As far as I can tell from mostly dead links, similar
> but not quite the same.

Hey I archived one of them

<http://ee.devereux.me.uk/20150910130650.pdf>

> Given that it is solely a hobby project, I would expect
> my performance to be worse. For example, if someone mentions
> jitter then I will shut my eyes, put my hands over my ears
> and sing "la la la".

--

John Devereux

[Tom Gardner]

On 10/09/15 13:07, dp wrote:
> Well MW is a megawatt and mW is a milliwatt, that is no
> problem. MHz for megahertz etc., M fot mega and m for
> milli is standard I think.

Just so.

Hence mW for a power station output indicates a certain, um,
lack of ambition.

[Tom Gardner]

On 10/09/15 13:10, John Devereux wrote:
> Tom Gardner <spam...@blueyonder.co.uk> writes:
>
>> On 10/09/15 08:51, John Devereux wrote:
>>> Tom Gardner <spam...@blueyonder.co.uk> writes:
>>>> One of my projects, when I get A Round Tuit, is to make a 2GS/s
>>>> 4GHz scope. The trick is to find a way to do it with only trivial
>>>> analogue front end components. Hence no amplifiers, no ADCs, just
>>>> a 50ohm input with very simple analogue components. Yes, there
>>>> will be limitations, but that's half the fun :)
>>>
>>> Hmm, there was the "slideback sampler" that John Larkin and Mike Monet
>>> used to fight about, a decade or two ago in sci.electronics.design.
>>
>> As far as I can tell from mostly dead links, similar
>> but not quite the same.
>
> Hey I archived one of them
>
> <http://ee.devereux.me.uk/20150910130650.pdf>

Ah, thanks.

No, that isn't exactly the technique I'm planning on using,
and I haven't assessed the relative advantages and disadvantages.

[rickman]

On 9/10/2015 3:10 AM, Jan-54 wrote:
> On Wed, 09 Sep 2015 17:32:50 -0500
> Tim Wescott <seemyw...@myfooter.really> wrote:
>
>> On Wed, 09 Sep 2015 22:32:38 +0100, Tom Gardner wrote:
>>
>>>> Let's try "μ" which is simply a "special character"
>>
>> It worked for me.
>>
>> I'll stick with 'us'.
>>
>> You could use 'mms'.
>>
>
> Or going deviant bigtime, follow the Pharmaceutical industry and
> use 'MC' ?

What is the "C"? Oh, "MC" means micro! Yeah, I hear they kill people
with that labeling issue.

--

Rick

[rickman]

What is AltGr?

--

Rick

[Tom Gardner]

On most keyboards, the key to the right of the space bar (Alt is on the left)
IBM standard for 30 years.

[rickman]

The two keys were always labeled the same on all of my keyboards
including a couple of IBM units. I never noticed a difference in
function. I don't get anything when using AltGr on this keyboard. When
I run through the alphabet with the AltGr key pressed, it does the
various ALT key functions.

Should I ask what "compose" is?

--

Rick

[Klaus Kragelund]

We have a kill function for the PWM outputs if a half-bridge is shorted. By you are right, it is a slippery slope

Cheers

Klaus

[David Brown]

Maybe the AltGr key is only common on non-US keyboards. Certainly the
US keyboard layout has far fewer characters and combinations than
international keyboard layouts, with the UK layout only marginally
better. (This applies to Windows and Linux layouts, AFAIK.)

>
> Should I ask what "compose" is?
>

It is a key common in *nix systems, at least under X. Unix workstation
keyboards would have a dedicated "compose" key, but most people use PC
keyboards these days and you have to configure a compose key if you want
it (I always use the Scroll Lock key, but there are many options).

When you press "compose" and then another two keys, you get a character
according to a layout table. The choice of characters in this table are
made to be somewhat logical - thus compose+m+u will give you µ,
compose+A+E will give you Æ, compose+1+4 will give you ¼. It is far
more intuitive than trying to remember codes for the numerical keypad.

[George Neuner]

The two ALT keys [and CTRL keys also] aren't labeled differently, but
they have different scan codes and can be differentiated by software.

Even prior to Unicode [going back to DOS 2.0 and maybe farther], PCs
supported multiple display character sets. The convention for
entering an alternate character was to hold the right hand ALT key
while typing the character's code on the numeric keypad.

Some compatibles allowed to use either ALT key, but IBM PCs did not
and so the right hand ALT key was "special". However, I admit that I
also have never seen/heard it called "AltGr".

George

[George Neuner]

On Thu, 10 Sep 2015 23:17:28 -0400, George Neuner
<gneu...@comcast.net> wrote:

>Some compatibles allowed to use either ALT key, but IBM PCs did not
>and so the right hand ALT key was "special".

Just to be clear - this was an issue of PC-DOS vs MS-DOS. IBM only
used the right ALT key, compatibles did whatever they wanted.

Any program could hook into the keyboard read/filter chain to see the
actual key presses ... the limitation of only using the right hand ALT
key to enter alternate characters was just the default behavior under
PC-DOS.

George

[rickman]

On 9/10/2015 8:10 AM, John Devereux wrote:
> Tom Gardner <spam...@blueyonder.co.uk> writes:
>
>> On 10/09/15 08:51, John Devereux wrote:
>>> Tom Gardner <spam...@blueyonder.co.uk> writes:
>>>> One of my projects, when I get A Round Tuit, is to make a 2GS/s
>>>> 4GHz scope. The trick is to find a way to do it with only trivial
>>>> analogue front end components. Hence no amplifiers, no ADCs, just
>>>> a 50ohm input with very simple analogue components. Yes, there
>>>> will be limitations, but that's half the fun :)
>>>
>>> Hmm, there was the "slideback sampler" that John Larkin and Mike Monet
>>> used to fight about, a decade or two ago in sci.electronics.design.
>>
>> As far as I can tell from mostly dead links, similar
>> but not quite the same.
>
> Hey I archived one of them
>
> <http://ee.devereux.me.uk/20150910130650.pdf>

I took a look and I must be missing something. The initial circuit
claims "The output of the op amp is the waveform of the HF signal
converted to a much lower frequency." But it clearly isn't. In the
following simulation graphs, the output of the waveform is similar to
the input signal only limited to the slew rate and ripple added.

He talks about increasing the bandwidth from 1.5 GHz for a MAX104 to 7
GHz for this circuit. I'm not at all clear how this circuit would be
used. Is the FF output used as a pulse density representation of the
input signal? Otherwise how is it an ADC at all?

--

Rick

[rickman]

I don't see any difference in behavior between the two ALT keys. Both
work fine with the key codes I provided and neither work as the AltGr
key is described. It is much handier to use the left ALT key while
entering digits with the right hand.

--

Rick

[George Neuner]

On Fri, 11 Sep 2015 00:04:18 -0400, rickman <gnu...@gmail.com> wrote:

>I don't see any difference in behavior between the two ALT keys.

There is no difference unless software defines it.

Each key on the keyboard has a unique "scan" code, which differs from
the "character" code. [This is how keyboard remappers work.]
Using the scan codes, left and right ALT and CTRL keys can be
distinguished, but the default keyboard handler simply returns the
same character code for both keys. You need to do a raw read of the
keyboard device to see the different scan codes.

Most software works just with character codes and doesn't need to know
which keys actually were pressed.

>Both work fine with the key codes I provided and neither work as the
>AltGr key is described.

https://en.wikipedia.org/wiki/AltGr_key

The "AltGr" key on non-US keyboards has the same scan code as the
right ALT key on US keyboards, so it is the software that makes it
operate differently.

George

[rickman]

On 9/11/2015 3:37 AM, George Neuner wrote:
> On Fri, 11 Sep 2015 00:04:18 -0400, rickman <gnu...@gmail.com> wrote:
>
>> I don't see any difference in behavior between the two ALT keys.
>
> There is no difference unless software defines it.

What software is doing this? Are the BIOS in PCs sold outside the US
different? I thought it was windows that set the char set. I had no
idea it would also give the ALT keys different functions.

> Each key on the keyboard has a unique "scan" code, which differs from
> the "character" code. [This is how keyboard remappers work.]
> Using the scan codes, left and right ALT and CTRL keys can be
> distinguished, but the default keyboard handler simply returns the
> same character code for both keys. You need to do a raw read of the
> keyboard device to see the different scan codes.
>
> Most software works just with character codes and doesn't need to know
> which keys actually were pressed.
>
>
>> Both work fine with the key codes I provided and neither work as the
>> AltGr key is described.
>
> https://en.wikipedia.org/wiki/AltGr_key
>
> The "AltGr" key on non-US keyboards has the same scan code as the
> right ALT key on US keyboards, so it is the software that makes it
> operate differently.
>
> George
>

--

Rick

[David Brown]

On 11/09/15 09:52, rickman wrote:
> On 9/11/2015 3:37 AM, George Neuner wrote:
>> On Fri, 11 Sep 2015 00:04:18 -0400, rickman <gnu...@gmail.com> wrote:
>>
>>> I don't see any difference in behavior between the two ALT keys.
>>
>> There is no difference unless software defines it.
>
> What software is doing this? Are the BIOS in PCs sold outside the US
> different? I thought it was windows that set the char set. I had no
> idea it would also give the ALT keys different functions.

The keyboard scan codes are built into the keyboard - they are reported
on USB, PS/2, Bluetooth, or whatever other interface is used. Then it
is up to the software controlling it to interpret the scan codes in the
way it wants.

Simple software, such as the BIOS, only does simple handling - typically
not supporting different keyboard layouts.

DOS and Windows support a variety of layouts, which is chosen by
configuration of the OS - it is completely independent of the BIOS, and
of whatever keys happen to be on the keyboard. The US keyboard layout
on Windows is pretty simplistic - amongst other things it makes little
distinction between the left and right Alt keys (though only the right
one works with the numeric keypad for entering ASCII/utf codes), and it
has no support for dead keys.

Many international keyboard layouts are a bit more sophisticated, with a
separation between Alt and AltGr (right-hand Alt) which lets you use the
normal Alt for menu shortcuts, etc., and the right-hand AltGr to get
more symbols, accents or letters required for other languages. They
also generally support dead keys.

A dead key is one that does not generate any character when pressed,
until you press another key. For example, in many layouts the backtick
` is a dead key. Pressing it does not produce anything unless you
follow it with a space or a new ` to get a ` symbol. But if you follow
it with an e, you get è. Similarly, ü is produced by pressing ¨ and then u.

More advanced software, such as X, support much more configurable
keyboard setups, and many more accessible characters.

[lasselangwad...@gmail.com]

here's a danish keyboard, all the blue symbols are made with ALT-GR

https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/KB_Danish.svg/2000px-KB_Danish.svg.png

the left ALT doesn't do the same

i believe all most all the keys have separate scan code, so if you wanted to
you could make left and right shift or ctrl key do something different

-Lasse

[Hans-Bernhard Bröker]

Am 11.09.2015 um 06:04 schrieb rickman:

> I don't see any difference in behavior between the two ALT keys.

Then you're using the plain US-american keyboard layout. This is great
for programming because all of []{}()<> and \| are easy to reach.

It's not so great for entering text in languages other than English
which use lots of dîácrìtîcs, or characters outside the standard
alphabets like German äöüß, though. Even typing currency symbols other
than the $ is hard on the default US keymap. So what about €, or £?

All this is the reason PC's have had localized keyboard layouts since
just about forever. Many of these have one or two more keys than the
US' 101. But that's not sufficient to accomodate all those accents and
special characters. So at some point, the non-English special keys will
squeeze some (presumably) not-so-frequently used keys off the layout.
Typical victims of this include []{}<>\|~# and @.

> Bothwork fine with the key codes I provided and neither work as the AltGr
> key is described.

International layouts have to routinely sacrifice the right Alt keys'
original function to provide a secondary "shift" function that gives
back access to those characters which got squeezed off the original
layout. E.g. on the German layout, to get \ one can either type
Ctrl+leftAlt+ß, or rightAlt + ß. To indicate this difference, the right
Alt is relabeled AltGr (for "alternative graphic characters" or
something like that). One consequence is that the Alt+<numeric keypad>
only work with the left Alt key on these layout.

Incidentally, this makes typing C source on non-US PC keyboards a royal
pain, particularly if you've mastered touch typing. IMHO it qualifies
as a miracle that any working C code was ever written in Belgium or
Switzerland :-)

[George Neuner]

On Sat, 12 Sep 2015 01:05:55 +0200, Hans-Bernhard Bröker
<HBBr...@t-online.de> wrote:

>International layouts have to routinely sacrifice the right Alt keys'
>original function to provide a secondary "shift" function that gives
>back access to those characters which got squeezed off the original
>layout.

> :

>Incidentally, this makes typing C source on non-US PC keyboards a royal
>pain, particularly if you've mastered touch typing. IMHO it qualifies
>as a miracle that any working C code was ever written in Belgium or
>Switzerland :-)

I wonder now if the keyboard was part of the reason that Pascal family
languages remained popular in Europe much longer than they did in the
US.

George

[Les Cargill]

I was around when Pascal got supplanted by 'C' in the U.S. I think
Borland sank Pascal when they went to a 'C' offering. But
they were chasing Microsoft.

We have to be careful, because there's always
observer bias. But 'C' had semi-legendary status back
to when I was in school in the early '80s
without the ability to use 'C'.

The tribe I was with went first to MSC then to Borland, a
lot because of Paradigm Locate and how well it worked
with Borland tools to produce ROMable images.

Side note: I got handed a Netburner a year or two ago,
which still uses the Borland tool chain. I maxed out the
available memory on the second day* and gave up :) The
symptom was a complete latchup of the target. The weary
support person had the solution far too ready.

*application already ran on a big ARM platform.

The old days weren't so good :)

--
Les Cargill

[David Brown]

On 12/09/15 01:05, Hans-Bernhard Bröker wrote:

> Incidentally, this makes typing C source on non-US PC keyboards a royal
> pain, particularly if you've mastered touch typing. IMHO it qualifies
> as a miracle that any working C code was ever written in Belgium or
> Switzerland :-)

You get used to it quickly - I found it a slight inconvenience for a few
weeks when I moved to Norway, but not more than that. It was actually
not the {[]} symbols, that need the AltGr key on a Norwegian layout,
that were the most annoying. It is the shifted symbols above the number
keys that are worst (at least when I now occasionally have to deal with
a US or UK layout).

And there is the odd program around whose developers think the world
ends at the borders of the USA, and can't cope when the keyboard layout
is different. But fortunately those are rare.

[David Brown]

No, that would have absolutely nothing to do with it. It is not hard to
type {} on non-US keyboards - it is certainly quicker and shorter than
typing begin/end. And despite the myth that many design decisions in C
were because of the terrible DEC keyboards used by K&R, such
considerations are totally insignificant in choosing a language.
(Except for APL, of course.)

[George Neuner]

On Fri, 11 Sep 2015 22:03:35 -0500, Les Cargill
<lcarg...@comcast.com> wrote:

>George Neuner wrote:
>
>> I wonder now if the keyboard was part of the reason that Pascal family
>> languages remained popular in Europe much longer than they did in the
>> US.
>

>I was around when Pascal got supplanted by 'C' in the U.S.

Same here.

But languages evolve and I have always wondered why some of the more
capable family members didn't generate more interest.

Apple pushed Object Pascal quite hard with Lisa and Mac. It was a
number of years before they made C available [as an Apple product -
there were Macintosh C compilers available from other vendors. I
don't ever recall seeing C for the Lisa].

I really liked Modula 3. I know Wirth himself had nothing to do with
it, but it was based on (extended) Modula 2 and I consider it to be in
the Pascal family [a cousin maybe].

>Borland sank Pascal when they went to a 'C' offering. But they
>were chasing Microsoft.

I'm not sure I really agree with that. They continued to work on and
improve Pascal long after they introduced the C compiler.

I think the problem far more was delay in offering a decent Pascal for
Windows ... TPW on Windows 3 was horrible. It took them 6 years to
bring out Delphi and although it could [theoretically] run on Windows
3 or 95, it was unstable on those systems and really needed NT4 to do
serious work. For quite a while there was no low-cost starter
version, so until Win98 came along, Delphi effectively excluded many
students and hobbyists.

I don't recall other Pascals being available for Windows early on, so
Borland's mis-steps there certainly can be credited with Pascal's
demise. I just don't think their offering C had quite so much to do
with it. YMMV.

George

[George Neuner]

Source code is intended to be read by humans as well as by compilers.
I use C because employers will pay me to do so, not because I
particularly like it. All of C's power [and then some] is available
in languages that are safer to use and don't look so much like line
noise. That may not have been true in 1975 [though I could make a
case that it was], but it certainly was true by 1985.

George

[Les Cargill]

George Neuner wrote:
> On Fri, 11 Sep 2015 22:03:35 -0500, Les Cargill
> <lcarg...@comcast.com> wrote:
>
>> George Neuner wrote:
>>
>>> I wonder now if the keyboard was part of the reason that Pascal family
>>> languages remained popular in Europe much longer than they did in the
>>> US.
>>
>> I was around when Pascal got supplanted by 'C' in the U.S.
>
> Same here.
>
> But languages evolve and I have always wondered why some of the more
> capable family members didn't generate more interest.
>

Beats me. But I don't consider Pascal that vast an improvement
over 'C'. No disrespect to Wirth, but I disagree
with his complaints about that.

> Apple pushed Object Pascal quite hard with Lisa and Mac. It was a
> number of years before they made C available [as an Apple product -
> there were Macintosh C compilers available from other vendors. I
> don't ever recall seeing C for the Lisa].
>
> I really liked Modula 3. I know Wirth himself had nothing to do with
> it, but it was based on (extended) Modula 2 and I consider it to be in
> the Pascal family [a cousin maybe].
>
>

Agreed - but I never saw any interest in it. There was a short span
of time where I could be on a project that mixed 68000 and x86,
and the most sensible thing seemed to be 'C' for that.

>> Borland sank Pascal when they went to a 'C' offering. But they
>> were chasing Microsoft.
>
> I'm not sure I really agree with that. They continued to work on and
> improve Pascal long after they introduced the C compiler.
>
> I think the problem far more was delay in offering a decent Pascal for
> Windows ... TPW on Windows 3 was horrible. It took them 6 years to
> bring out Delphi and although it could [theoretically] run on Windows
> 3 or 95, it was unstable on those systems and really needed NT4 to do
> serious work. For quite a while there was no low-cost starter
> version, so until Win98 came along, Delphi effectively excluded many
> students and hobbyists.
>

Excellent point - I sort of recall that now. I had
one contact who used Delphi and he'd complained about this.

It never made sense to me that it should be unstable.

> I don't recall other Pascals being available for Windows early on, so
> Borland's mis-steps there certainly can be credited with Pascal's
> demise. I just don't think their offering C had quite so much to do
> with it. YMMV.
>

It's probably observer bias on my part - the people I knew who could
decide between Pascal and 'C' weren't writing GUI applications and
'C' was the better choice for systems work.

> George
>

--
Les Cargill

[Hans-Bernhard Bröker]

Am 12.09.2015 um 14:34 schrieb David Brown:
> On 12/09/15 01:05, Hans-Bernhard Bröker wrote:

>> Incidentally, this makes typing C source on non-US PC keyboards a royal
>> pain, particularly if you've mastered touch typing. IMHO it qualifies
>> as a miracle that any working C code was ever written in Belgium or
>> Switzerland :-)
>
> You get used to it quickly - I found it a slight inconvenience for a few
> weeks when I moved to Norway, but not more than that.

I find it enough of one to have my German keyboard set to US layout for
everything but writing actual German prose. Drives colleagues crazy if
they want to type something on my machine, too ;-). In my student years
I even used actual US keyboards both at home and on the university's
machines.

At least on the German layout, the AltGr and {[]} are really in the
worst position they could possibly have picked, from a touch typing
point-of-view. Given where AltGr is located, you can't really keep your
right hand in home position; the thumb just won't go there. And once
the hand is up in the air, targeting along the row from 7890ß to get
{[]}\ is just too error-prone to be acceptable. Typing those [] alone
sometimes took longer than all the stuff that went in between them!

> It was actually
> not the {[]} symbols, that need the AltGr key on a Norwegian layout,
> that were the most annoying. It is the shifted symbols above the number
> keys that are worst (at least when I now occasionally have to deal with
> a US or UK layout).

Absolutely. Why on earth are the () Shift+8 and Shift+9 on a German
layout, but Shift+9 and Shift+0 in US?

[Dimiter_Popoff]

[Dimiter_Popoff]

On 12.9.2015 г. 23:40, Hans-Bernhard Bröker wrote:

> Am 12.09.2015 um 14:34 schrieb David Brown:
>> On 12/09/15 01:05, Hans-Bernhard Bröker wrote:
>
>>> Incidentally, this makes typing C source on non-US PC keyboards a royal
>>> pain, particularly if you've mastered touch typing. IMHO it qualifies
>>> as a miracle that any working C code was ever written in Belgium or
>>> Switzerland :-)
>>
>> You get used to it quickly - I found it a slight inconvenience for a few
>> weeks when I moved to Norway, but not more than that.
>
> I find it enough of one to have my German keyboard set to US layout for
> everything but writing actual German prose. Drives colleagues crazy if
> they want to type something on my machine, too ;-). In my student years
> I even used actual US keyboards both at home and on the university's
> machines.

During my years in Germany (20+years ago) I had a US layout keyboard.
When I had to use some of the PC-s at the company I had learned how
to switch off the German layout, was something like alt-f1 or
alt-ctrl-f2 (or completely different, I may have forgotten it
altogether).
The keys were coming to their normal places which was good enough for
me, although many did not correspond to the key caps... Obviously I
used these keyboards rarely and for short tasks. I never got used to
the German layout; and I think the French one is even worse.

Dimiter

(sorry for the null message I posted - was just beginning to write what
was supposed to be this one and inadvertently hit "send").

[David Brown]

That's fair enough as an argument. There is plenty in C that I don't
like. To paraphrase Churchill, C is the worst of all programming
languages - but it's the best we've got.

I just disagree with the theory that keyboard layouts had any say in the
matter.

[Allan Herriman]

Shift+8 and Shift-9 date back to earlier (19th century, Remington?)
keyboard layouts, which in turn influenced ASCII.


Shift+9 and Shift-0 come from the IBM Selectric (early '60s).
According to this Wikipedia article:
https://en.wikipedia.org/wiki/IBM_Selectric_typewriter
"This change was made because smaller characters hit the paper with less
force, and consolidating smaller characters such as '" into a pair on a
single key avoided needing to adjust the force based on shift state."


Regards,
Allan

[Robert Wessel]

On Sat, 12 Sep 2015 22:40:45 +0200, Hans-Bernhard Bröker

<HBBr...@t-online.de> wrote:


>Absolutely. Why on earth are the () Shift+8 and Shift+9 on a German
>layout, but Shift+9 and Shift+0 in US?

Tradition/history in both places. I've seen typewriters from the
early 20th century from both countries with the 8/9 and 9/0 placement
of the parenthesis. Of course those were not completely standardized,
so you can find exceptions for both.

[Anssi Saari]

Hans-Bernhard Bröker <HBBr...@t-online.de> writes:

> Incidentally, this makes typing C source on non-US PC keyboards a
> royal pain, particularly if you've mastered touch typing. IMHO it
> qualifies as a miracle that any working C code was ever written in
> Belgium or Switzerland :-)

Conveniently Windows at least since XP installs the US keyboard layout
and has a quick key to switch layouts. People do tend to cling to the
various awful national layouts like a baby to a mother's teat but really
a proper layout is easily toggled into and back out of for when one
writes in their native language. Same thing in at least the bigger Linux
desktops.