Microchip & OnSemi want to buy Atmel?

So, to sumarise : A pascal you cannot actually buy, is not suitable for low level programming, but almost any commercial compiler is.

Engineering is the art of making what you want, from what you can get.

Best not waste too much time worrying about what you cannot do, with something you cannot buy !!? ;)

-jg

The event logic gives you flexibility. With the event logic, you can create a 16 bit PWM and run a number of PWM cycles, and then take an interrupt. You cannot do that with a single 32 bit timer.

That is already in the list. The XMEGA supports DMA transfers, and when a capture event occurs you can use that event to trigger a two byte DMA transfer from the capture register to SRAM.

You can run a 2 bit counter at 100 MHz, that does not neccessarily mean that you can run a 16 bit counter at 100 MHz.

It *is* a recognized problem that peripherals run at CPU speed or slower, but it not a minor effort to fix this.

The more generic problem is how to run peripherals at a static frequency, while the CPU speed is varying.

Depends on the process, but you have already established the Xmega timer can run at 128 MHz.

Q: Can it hook into the Event System at that speed ?

True. Harder to solve on 8 bit uC, but most 32 bit cores have more core-peripheral elasticity already, and more buffered peripherals in general (FIFOs are common) so much of the needed framework is in place.

You mentioned the xmega is already part way there, on PWM modes alone.

Not much effort to extend that to capture/counter modes too.

-jg

You have two bits which runs at 128 MHz, and the rest run at 32 MHz.

The event system is clocked at 32 MHz.

All the AT91SAM/AVR32 peripherals derive their timing from the AMBA bus, and the AMBA bus derives its timing from the CPU clock, so there are some issues here.

I think there could be setup/hold problems, since the DFFs are not clocked by the same clock.

Now I am lost. If you are running PWM, then you surely need ALL bits for a compare, so the granularity should be 7.8ns, and smallest pulse is 7.8ns

If your system is doing that, I'd call that a 128MHz, 16 bit counter. ie able to sync count and do 16 bit compare, at 128Mhz

- or are you saying that is not the case with the xmega, when PWM clocked at 128Mhz ?

OK. So that makes a 100MHz NXP device (with 32 bit timers),

-jg

I think that's either true, or very nearly true.

I was pleasantly surprised when the Fedora Linux 7 distribution included gcc-gnat and GtkAda.

Provided that you don't want your code to be portable. Presumably if you wanted your code to be portable, you would write it in Pascal, and then you couldn't do the low-level stuff.

Yes. Therefore I choose a language that makes it easy to do what I want.

How much portability do you really expect in some embedded environment, especially if the hardware architecture is somewhat awkward. In practice you would still have to separate the platform dependent functions, which can always be written in assembler, provided that the HLL supports separate compilation.

Things get nasty of course, if every other line in the HLL code is a call to an assembler function.

A bizarre example: I once had to write a program In Cobol (due to customer demand) that manipulated a lot of 64 bit bit masks related to the OS security system. Fortunately the OS run time system bit mapping functions were directly callable from all supported languages, but even writing the calling sequence for any other language convention would not be an issue.

Paul

Since gnat uses the same back-end as gcc, basic Ada compilation is available for pretty much any target with gcc support, although you might have to compile it yourself. However, for uncommon targets (for Ada), there is a high chance of bugs since there will have been little testing. Library support is a problem too - at least some of the library needed for standard Ada will need specific porting for a given target. So Ada support on "large" platforms, like x86 and PPC will be solid, while Ada on the AVR for example is a work in progress (though I gather that it *is* in progress).

The same pretty much applies to C++, though it is a more popular choice for embedded development than Ada.

No, you can run a 16 bit counter at 32 MHz, and when you get the compare/match you add the resolution using a 2 bit counter running at 128 MHz. I don't know exactly how it is implemented, so it might be done in a different manner.

Yes.

I expect a lot of it to be portable, because on numerous occasions I've changed compilers in mid-project or when doing maintenance at a later date. Sometimes that's my decision, and sometimes it's the client's decision.

Sure. But that doesn't obviate the need to use the right tools for the job. If you need to write low-level code, and you want it to be portable, Pascal is the wrong answer, since you'll have to use non-standard language extensions.

I'm not a big fan of C, but it's certainly suitable for low-level programming. My criticisms of C are at the other end of the spectrum. I write a lot of C code because that's what my clients want, and in the case of Free Software, that's what people are likely to be able to run.

I prefer strongly-typed languages. I actually do like Pascal, and over the years I've written a lot of code for clients in UCSD Pascal, Turbo Pascal, etc., but I wouldn't recommend it to clientis now, especially for low-level work. I like Ada better; functionally it is almost a superset of Pascal, but it is significantly better in many regards including support for low-level programming. However, my clients generally don't want Ada, partly because it is supported on fewer target platforms, and partly because they'd have a harder time finding other engineers to maintain it.

in

various

if

anything

Hmm... how do you know most the engineering in Colorado Springs is gone? I'm still working on some of the test development on the RF products. In fact, most of my colleagues are still at work. Unless I am sleeping on the job or you have better insider information.

... snip ...

Now that Ada is available as part of the gcc package, it is available almost anywhere that C is available.