Microchip & OnSemi want to buy Atmel?

Assuming 1 instruction/clock cycle and 6-60 cycles for the timer ISR, this is still going to cost you less than 1/1000 of the CPU power.

Even with a 32 bit timer, you would not get the final latency much better than with 16bit+ISR configuration.

Of course, if the processor requires 10-20 cycles/instruction or the timer clock can be much larger than the CPU clock, the situation is different.

Paul

Reply to
Paul Keinanen
Loading thread data ...

100 MHz clock = 10 ns cycle and the 16 bit counter overflows every 655.36 us.

You must be running on a quite low power design, if an extra ISR every

0.65 ms will cause problems. A 9600 bit/s UART would have a similar interrupt _load_.

Paul

Reply to
Paul Keinanen

Some things are more complex than simple timer ticks.

Try things like capture, or wide dynamic range handling or jitter free frequency generation....

One reason you choose a bigger micro, is to make the task easier (or add more precision). It is silly NOT to give designers 32 bit entities, and it is good to see NXP have woken up to that.

-jg

Reply to
Jim Granville

can still be done with software assisitance, you just need to think ahead.

Bye. Jasen

Reply to
Jasen Betts

anything 'can be done' - the point is you have just moved to a nice, shiny 32 bit CPU, with a 100MHz clock to get away from all the queue kludges, fingers crossed, and fish hooks.... So, why cripple the 32 bit CPU with 16 bit timers ?! That's just short-sighted, or corner cutting.....

Peripherals are where the design-win decisions are made.

-jg

Reply to
Jim Granville

bit CPU, with a 100MHz clock to get away from all

I agree, >16-bit timers are convenient, especially with such a high clock.

M
Reply to
TheM

Jim, "cripple" is hardly applicable in this context. The IRQ load (as I am sure you know and as others already mentioned) is negligible for a 16 bit timer, so making it 32 bit does not buy much if anything. OTOH, all the associated logic - OC, IC etc., most importantly, busses which have to be routed - is halved, which can be very significant. You do not want to encourage the trend of the day to make things just look better, before we know some real functionality will be gone for the sake of having 32 bits where we don't need them...

Very true - how much the world has changed over the last 20 years... Even I - being pretty attached to PPC and other Freescale cores - am doing it, I suspect to many of those doing just some C programming to put something together the core is close to 100% irrelevant. Embedding an MCU has become more like working in a PC shop, just fetch what the customer asks for and throw it over the counter...

Didi

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

formatting link

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

formatting link

Original message:

formatting link

Reply to
Didi

For a simple timer-tick, that might be true, but move into Capture, and Frequency generate to any precision, (or try Quadrature counting?) and a split SW/HW hybrid can get complex/fragile very quickly. - and all this work, on a part you moved to, in order to make designs easier ?

Hardly. Typical is to have whole peripheral blocks unused on a given design. Take the new LPC17xx series: all have CAN,USB, SSI+FIFO, quadrature Counter with velocity, etc (starting under $2.50), so with whole Petipheral blocks optional, the cost of a few bus routings, is in the noise floor.

True, and the average designer is less likely to even know a) how to mix time critical SW/HW b) what fishhooks might lurk in doing so :)

So, they expect FIFOs and even DMA, and other resource to make life easier, and 'load and forget' operations.

This also saves testing time, and improves code maintenance, so it is not all just for the programmer....

-jg

Reply to
Jim Granville

"Ben Bradley" skrev i meddelandet

Would people require a 64 bit timer on a 64 bit machine?

I.E.: The width of the datapath has nothing to do with the width of timers...

You only need 32 bit timers when you have very slow events or need very high resolution AND long times. At 100 MHz, the timer will wrap around after 655 us. Would be interesting with an example where this is an issue.

The peripheral development is driven by market needs, so enough people will have to be vocal for a change to happen.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

I think you are right and this is no problem, you can implement it in software. E.g. if you need a PWM signal of some ms, most of the time you don't need 1 us resolution, which makes it even easier to write it in software.

BTW: what do you think of the SEAforth 40C18?

formatting link

There are 40 cores and a interesting idea is that you can implement your own IO function in firmware, like SPI, I2C, CAN etc. Sounds like a good idea, because you'll get all protocols you want. E.g. sometimes there are nice microcontrollers, but you need CAN, which is not provided. With a concept where you can implement it in firmware, all protocols are possible (but maybe not very fast ones, like ethernet or USB).

And using non-clocked, asynchronous concepts sounds interesting, too. I guess they are using something like dual-rail signalling or the Muller C gate:

formatting link
formatting link

This would help for EMI, too.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Some might :)

- but the jump from 32 to 64 is much less practically usefull, than from

16 to 32.

Of course not, but it has a LOT do do with precision, and dynamic range. If you can calculate in 32 bit numbers, why feed that with an UPPER limit of 16 bit granularity ?

Timers also Capture, and generate.

Precision frequency generation, and precision frequency measurement are two examples. Your example has you stuck at >1.52KHz, or if you prescale, you lose step size.

With 16 bits timers, you hit a 16 bit quantize limit, on any PWM DAC design, but 18-20-24 bit ADCs are common. With 100MHz/32Bits, you can deliver 18 bits at 380Hz, and 20 bits at 95Hz.

Or, you may have a LVDT type problem, that needs precise phase measurement at 400Hz - suddenly, a 32 bit timer, delivers 4x the performance.

Try doing a reciprocal frequency counter with 16 bit peripherals....

100MHz can give you 8 digits/second, or ~27 bits

What you want is to be able to have the system granularity, under the noise floor.

Quadrature counters are also a natural for 32 bits, rather than 16 bits.

Plently of examples, you just need to look around.... ;)

TI have some nice features, where they get precisions above the clock frequency on some of their DSP peripherals.

..and the designers need to also think about how these might be used.

It is already happening, 32 bit timers are becoming more common. The newest NXP parts also have 32 bit Quad counters, with velocity features.

-jg

Reply to
Jim Granville

I can handle precision frequency measurement by running an interrupt at mid level of the timer, which checks if something has triggered or not and this will give me the same precision. I can set up compare registers which toggle at a specific time with the same precision as a 32 bit timer. The 32 bit timer will simplify some S/W, I'd admit to that, but it is really not neccessary.

This is only a problem, if you run the PWM at less than 2 kHz. I doubt the "DAC" will work as expected in this case.

If you want to have a 24 bit DAC; using a single slope ADC, you can again take an interrupt every 655 us, and figure out in which frame the capture register triggered.

No, you interrupt every 655 us, and update the upper 16 bits in an SRAM location. You can do 32 bit PWM and 32 bit capture in S/W, and it is not that hard, because once the 32 bit is needed, then you got plenty of time.

If you look at stepper motors, then you have ~200 steps per revolution. Why do you need much higher granularity?

Many of the ATtinys have a PLL allowing you to run timers at higher speed than the core. So does the XMEGA. Timers can run at 128 MHz and the event system will allow you to expand timers to 32/48 bits etc..

Yes, all other things alike, you would rather have a 32 bit timer, instead of a 16 bit timer, with S/W for the upper part. If you have a 10 Mu application, you would not pay much more for a 32 bit timer, if you can live with a 16 bit timer.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

That's a very popular misunderstanding. Pascal has higher level concepts than C, but it has everything necessary for low-level programming. Just like C, compilers need extra support for things like interrupts, but otherwise it's complete - just like Ada. There is no particular reason for a given program to be smaller and faster (target code) in C than in Pascal, nor is there any reason to think a processor architecture is suited to C but not Pascal (or vice versa).

In fact, for 8-bit processors, you would expect Pascal compilers to be better - after all, they have native support for 8-bit arithmetic without any of this "promotion to int" nonsense.

C became popular because of Unix. Since then, the main reason C is the most heavily used low-level language is because it is the most heavily used low-level language.

Reply to
David Brown

It sounds like you haven't ever actually used Pascal, but rather some kind of non-standard extended Pascal. In you're going to claim that Pascal is useful for low-level programming, please explain how to efficiently perform common low-level tasks, such as to set bit 5 of a

16-bit integer (assuming that bit 0 is the LSB), or to compute the logical AND of two 16-bit integers.

If you think standard Pascal has features to do that, perhaps you can point us to the relevant section numbers of the ISO standard.

Hint: abuse of variant records to do this doesn't count, because the results are undefined.

Pascal is a Turing-complete language, so of course it is possible to do bitwise logical operations, e.g.

formatting link

To be suitable for low-level programming, however, it would be necessary to do them much more efficiently.

Pascal was designed as an instructional language, and does not have all the features necessary to be a good general purpose or systems programming language. If you want a strongly-typed language that is also capable of use for low-level programming, there are several choices including Ada.

Reply to
Eric Smith

Don't knock it. That's what keeps some of us in business.

Reply to
Everett M. Greene

I have used ISO standard (level 0) Pascal for almost everything. You need to stop thinking about setting bits, etc., and think about the operations. I think you will find that sets do a more than adequate job.

Don't forget that the 'non-standard extended Pascal' you refer to is probably from Borland, and that none of their products even meet the requirements of the Pascal standard. This is one of the major crosses Pascal has had to bear.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

Have you actually tried doing this ?

As soon as you expand a capture system with SW, you have serious aperture problems. There is a window between the HW register, and SW register, where they are out of sync. You also have TWO interrupts racing, one on the capture edge, and another trying to keep the MSB up to date.

That simply does not happen with a 32 bit capture, and the better timers are adding small fifos on capture. That allows narrow pulses to be easily handled.

Microstepping, and shock effects on encoders are a couple of reasons.

Your replies illustrate the classic blinkered thinking of some chip-designers. The key is how someone COULD use the system for a better design, not how many band-aids can be stacked to make it sort-of work :)

I've done many CPLD designs, to extend/fix shortcomings in peripherals

- those blindspots are things the chip designers SHOULD be chasing down. On 32 bit uC, the excuses have gone :)

Timers tend to be 'not sexy' and so the evolution rate is slow...

Do you mean Xmega timers can run to 128MHz ? - which data sheet shows that ?

Can I do a no-aperture-error, 32 bit capture, from a 100MHz clocked timer ?

The Xmega have nice peripherals, is there a AVR32 with the same peripherals ? (or will the new cortex devices use some of the xmega ideas ?)

I do like the better peripherals in the NXP Cortex releases.

-jg

Reply to
Jim Granville

How would it be in [ISO level 0] Pascal the equivalent operation of clearing the Timer 1 Interrupt Flag of garden variety PIC?

Reply to
Cesar Rabak

I've used plenty of Pascal on PC's, including for low-level work, but not in embedded systems (I said the language is perfectly suitable for low-level embedded work, but the tools available are not as good as for C).

Looking through the standards (for the first time), I have to agree with you - I see no way to make get bitwise operators such as "and" and "or" without making messy functions, while relying purely on the wording of the standard. In practice, however, I think you'd be part pushed to find a real Pascal compiler that does not extend the "and" and "or" operators to work bitwise on integers. In the same way, there is no way to specify a variable in C that is precisely 16 bits (in Pascal, you can use the type "0 .. 65535") - yet any modern compiler will support "uint16_t" in .

formatting link

The original Pascal had a number of limitations, such as a lack of modules. By the time you get to ISO 10206 "Extended Pascal", and practical implementations (which normally include extensions such as inline assembly, "and" and "or" operators, specifically defined integer type sizes, and a variety of useful library functions), you have a language that is suited to a very wide range of uses - including low-level work.

Of course, the most popular range of Pascal compilers is Borland's tools (though they stray further from the standards than most other compilers). These are used for a very wide range of real-life software, not just for "instruction".

Pascal was designed to be useful as an instructional language - but also useful as a real working language. It has certainly always had an emphasis on encouraging good structured programming techniques, with its strong type system and support for nested scopes. But it was also designed for it to be easy to write good, fast compilers that generate small and fast code - precisely because it is a real useful language, not just for teaching.

Reply to
David Brown

For low-level programming, I need to clear, set, and test bits, often in the same registers that also contain numeric fields. Often I need to do these kind of things in interrupt handlers, so they need to be efficient. Trying to use a Pascal set is NOT acceptable, especially since Pascal doesn't define the bit or byte order of the internal representation of a set.

I've used UCSD Pascal, Turbo Pascal, and Apple MPW Pascal, and several other non-standard Pascal dialects to do this kind of stuff in the past, but that has nothing to do with whether the Pascal language is suited to it.

Eric

Reply to
Eric Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.