I can't imagine anybody getting any real work done using that environment. I was just generating some code for benchmark comparison with other compilers/languages, and we ended up being requierd by customer dictate to use a language other than Ada.
I should give GNAT a try someday. I presume it can be built for any target for which the C/C++ compiler can be built?
--
Grant Edwards grante Yow! I want EARS! I want
at two ROUND BLACK EARS
visi.com to make me feel warm
\'n secure!!
Wow. What an abomination of a development environment. Worst i have ever heard of. Far worse even that MS-DOS 3.0 and edlin. Put in that position i would have built my own based on standard *nix tool chain and taught it how to feed into the abomination.
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.
--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
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.
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.
--
--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
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.
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.
--
--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
San Jose, CA, October 29, 2008.Atmel® Corporation (Nasdaq: ATML), today announced that, after careful consideration, its Board of Directors has unanimously determined that the October 1, 2008, unsolicited proposal from Microchip Technology Inc. (NASDAQ: MCHP) and ON Semiconductor Corporation (NASDAQ: ONNN) is inadequate in multiple respects, including value, conditionality and complexity, and is not in the best interests of Atmel's stockholders.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
...and a few weeks later, seems it is still all on !?
[Nov 12: SAN JOSE, Calif. -- Despite receiving a rejection slip, Microchip Technology Inc. and On Semiconductor Corp. remain committed in their proposed and unsolicited acquisition of Atmel Corp.
And there is a major surprise in the latest announcement: Microchip now claims it owns approximately 4.1 percent of Atmel's outstanding common stock. ]
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.