Microchip & OnSemi want to buy Atmel?

[Paul Keinanen]

Grant Edwards wrote:

The Modula2 derived IEC (6)1131 Structured Text (ST) is quite popular
in PLC programming,

Paul

 

[David Brown]

David Brown <[email protected]> writes:

Many Ada compilers are fully compliant with the standard, though they
may also offer extensions. Ada with the admittedly optional representation
specs is perfectly well suited to embedded programming, without needing
any non-standard extensions. Arguably it is a more suitable language than
C, since C still leaves many important things as implementation-defined.

That's certainly true about Ada, as far as I understand it (I haven't
written much more than "Hello World" in Ada in practice, but I've read a
fair bit about it). Ada (again, AFAIK) also has support for concepts
such as tasks, locking, and atomic accesses which are important in
embedded development - I'd be interested to hear how well these work in
practice. I expect a lot will depend on the target-specific libraries
for a given Ada port.

Sure. But then it isn't "Pascal", it's "someone's nonstandard language
based on Pascal", so you can't use it to claim that Pascal is suitable
for low-level programming.

If the claim was that brand XYZ "Extended Pascal" is suitable for low-level
programming, I'd have no argument.

Fair enough. I'll settle for standard Pascal (even the ISO "extended
Pascal") being unsuitable for low-level work, mainly because it is
missing bitwise operations. Real-life Pascal compilers (which have
bitwise operators) *are* suitable for low-level work.

I don't claim that any of them were "made just for fun". I also don't
claim that none of Wirth's languages are suitable for low-level programming.
I only claim that Pascal is not suitable for low-level programming, and
that it was designed as a teaching language. I doubt that Wirth himself
would disagree.

Pascal was certainly designed with teaching very much in mind - and
certainly low-level programming was not a design goal. But it was
always intended to be practical for real software development. Some
languages, such as Logo, are aimed purely at teaching - you use it to
teach people about programming concepts, then use a "real" language
later. Some languages, such as Pascal and Python (which is not very
suitable for low-level embedded programming...), work well for both
teaching and real-world programming. And some, such as C, work well for
real-world programming but are unsuitable for teaching.

mvh.,

David

 

[Jasen Betts]

"with" is very useful - it can make some kinds of code a lot clearer,

and some kinds more opaque.

if you use a pointer after int the with clause and then change the
value of the pointer in the following block...

and it is easy for the compiler to optimise it (for example, if you have
a "with" block on a record in an array indexed by a global, the compiler
can easily use a pointer for all the accesses.

see above.

Without "with", a C compiler may have to be conservative and re-calculate
the pointer).

no it doesn't, not unless the pointer is declared as volatile.

Yes,

cool, I was wondring

and you can also get the size of arrays passed to functions (arrays
are a different type from pointers).

I do find that feature neat

I don't know - why would you want variadic functions in a strongly typed
and strongly structured language?

suppose I wanted to write something like sscanf

Higher level concepts that Pascal has are proper enumerated types,
integer range types (both of which give much better compile-time
checking), and local procedures and functions (which improve modularity
and structure).

Sets are another very useful higher level concept.

When I've been working with Delphi for a while, and go back to C
programming, I find I miss the better type support (enumerated types,
subranges, and sets) most.

cool. I can't see the lack of those things being a great hardship, but
having the compler stop you from doing

ThisMonth:=Tuesday;

does seem like a useful feature,

can you choose the binary representation for the members of the enumerated
type or do you have to go with what the compiler chooses?

 

[Jasen Betts]

What string support does Pascal have? Lack of a string type
is a major deficiency (of the original standard Pascal).

Does C have any real character string support ?

The only "string support" C has is putting an extra null after the
last quote character in the source code. The rest of the string
operations are handled by (standardized) library calls.[/QUOTE]

as a language by itself C has none. In combination with the standard
libraries it has some good support for both null-terminated, and
strings with a length stored separately. the latter requiring
immanginative use of sscanf printf and the mem... functions

And you've gotta track the allocation of every byte...
C is not a good language for pushing paragraphs around with as
seeminly trivial operations often require careful thought lest they
leak or become computationally over complex.

While I like null terminated strings when programming in an assembly
language, does it really belong to a high level language ?

if you want to use the string as a buffer for binary data it's not
useful, but for most other purposes it's just fine,

one good thing it does is force you to think about strings of
unlimited size, on the other hand haveing an accepted limit imposed on
you does make programming easier (at the cost of functionality at the
end of the day)

Bye.
Jasen

 

[Jasen Betts]

Interrupt on Timer wraparound (Higher Interrupt priority than Capture)
Timer = Timer + 1

Interrupt on Capture
Capture[15:0] = H/W Timer
Capture[31:16] = S/W Timer

If you cannot prioritize interrupts, then there would be a problem.

Imagine you get a capture edge, on what should be 5FFFF.
(or even close to that)
During the Capture INT propogation delays, the timer ticks over and
fires its int, which now takes priority, and when the capture Sw finally
gets to Capture[31:16] it gets 6FFFF as the answer.

Now do you see the aperture problem ?

yeah, the above won't work reliably.

One solution is to have a counter and a copy, when the hardware counter hits 0xc000.
increment the counter when the counter hits 0x4000 copy the counter into the copy.

when you detect an event, if the high bit is set use the copy for the
high word of the result, if it's clear use the counter.
either way you have about 16000 cyctles to respond to each interrupt.

Capture is one of those things that really needs hardware.

if you can have output match (or some other interrupt you can use) it just
needs immagination. the 0xc000 and 0x4000 figures above don't even need
timing precision to one significant figure.

Bye.
Jasen

 

[Paul Keinanen]

if you want to use the string as a buffer for binary data it's not
useful, but for most other purposes it's just fine,

That convention is usable only with character representations like
ASCII/ISO-646/ISO-8859-x/UTF8, but not with 6 bit characters on 36
bit mainframes (OK, the requirement for 8 bit byte addressability
would make that useless anyway nor in systems using UCS-2/UTF16 or
UTF32 character representations.

Paul

 

[Ulf Samuelsson]

"Jim Granville" <[email protected]> skrev

True, I do hamper a lot about timers internally...

Keep a presentation on what to improve on peripherals which
I provide to the MCU product lines.
This is now ~150 pages, and a significant part is on timers.

The designers must love to see you coming with your punch
list! They probably also love you hampering[sic] about
timers...

It is interesting to see the shell-shocked stare when I unexpectedly appear
right in front of them

I updated the presentation some time ago, and used a 1 year old version as a
basis.
Just for fun, I check what had been accomplished in this year, and about 50%
of the items on my wish list were either implemented, or they wer scheduled
to be implemented in the future, which is a pretty good track record for the
product line.

--
--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[Ulf Samuelsson]

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.

Interrupt on Timer wraparound (Higher Interrupt priority than Capture)
Timer = Timer + 1

Interrupt on Capture
Capture[15:0] = H/W Timer
Capture[31:16] = S/W Timer

If you cannot prioritize interrupts, then there would be a problem.

Imagine you get a capture edge, on what should be 5FFFF.
(or even close to that)
During the Capture INT propogation delays, the timer ticks over and fires
its int, which now takes priority, and when the capture Sw finally
gets to Capture[31:16] it gets 6FFFF as the answer.

Now do you see the aperture problem ?

I realized this as well, and sent another mail illustrating the solution.

Capture is one of those things that really needs hardware.


Good, looks like that just got some more content


What propogation delay does this have ? is this aperture free ?
(or at least aperture locked, so I guess a SW patch could apply to
fix a known fixed phase error)

Event system will take one clock to update a timer.
Max time for an events is 2 clocks.
The capture for the upper 16 bits are delayed by one clock,
so that they are always in sync.

The counters will look like this:

1: 0003:FFFE
2: 0003:FFFF
3: 0003:0000
4: 0004:0001

If you get a capture event at (3); then the lower counter is 0000 and
the upper counter is 0003, but since you delay the capture by one
clock, the capture register will be written with the high counter value 0004
in (4)

All the data says is HiResolution mode exists, but does NOT say what
happens to the pin sampling, or if that is CPU or Timer clocked.

Can the pins sample faster than the CPU clock (ideally, at the x4 clock?)

No, you can drive outputs at 4 x, but not sample outputs at 4x as
I interpret the documentation.

 

[CBFalconer]

"Jim Granville" <[email protected]> skrev:
.... snip ...


True, I do hamper a lot about timers internally...

Hamper? A hamper is a sort of box to carry a picnic in. To me.

 

[JosephKK]

I've always thought that Ada looked like a pretty good embedded
programming language (which is, after all, what it was intended
for). However, my one experience with Ada for an embedded
system was so incredibly awful that I still have nightmares
about it. It was under VAX/VMS, and you couldn't just do
cross-development like you could with other languages (using
normal files, standard text editors, source control, etc.).

You had to log into some horrible stand-alone Ada shell
database environment torture chamber. You couldn't use your
normal programming editor or source control or
build/documentation tools. Just copying an external source
file into or out of the Ada development environment/database
was painful. I thought moving from Unix to VMS was bad, but
the Ada development environment was worse than programming
using an ASR-33 and paper tape. At least with paper tape, you
got all the fun paper dots to play with (though the big oil
stains that the reels of tape left everywhere were unpleasant).

I don't remember much about the Ada environment other than it
was something either the DoD or the Navy wanted to torture
people with.

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.

 

[Ulf Samuelsson]

Ulf Samuelsson wrote:


Sounds good.
Would simply moving to 32 bit registers not be less silicon than all the
event logic ? (ignoring the other benefits of event logic, for a moment)

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.

.. this can be something else to add to your list ?
(Oh, and add having a simple queue/buffer to capture registers, to allow
very narrow pulse measurement.

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.

So do the pins sample at the CPU speed, which places another
restriction on the designer ?

Since the silicon can go >> 100MHz, it's not sensible to limit
timers on frequency or time measurements to something much lower.

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.

The ideal here is 100MHz Frequency or 10ns edge precisions, with
a core ticking over at 1MHz, or even slower...

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.

-jg

--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[Ulf Samuelsson]

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

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

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

The event system is clocked at 32 MHz.

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.

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.

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

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

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

-jg

--
--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[Paul Keinanen]

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.

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

 

[Ulf Samuelsson]

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

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.

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), 3 times as
precise.
Yes.


-jg

--
--
Best Regards,
Ulf Samuelsson
[email protected]
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

 

[CBFalconer]

.... snip ...

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.

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

 

[Ulf Samuelsson]

FYI: Todays press announcement

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.

 

[TheM]

FYI: Todays press announcement

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

Thanks God! I was worried about the future of my AVR babies.

M

 

[TheM]

FYI: Todays press announcement

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.

...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. ]

-jg

Time to get atmel stocks?

M