Microchip & OnSemi want to buy Atmel?

[Uwe Bonnes]

Bob Eld wrote:

No self destruct, but at least for one of my clients an Atmel field
applications engineer promised that a new chip will be available in samples
at the beginning of 4th quarter (I think it was the AT91SAM9G20), now looks
like it is postponed to 1st quarter 2009, which is not good, because 2nd
quarter 2009 samples of the end-product are planned for tradeshows. But
maybe this is not the fault of Atmel, but of the field applications
engineer, because I can't find a written promise of the date, and better
wait one quarter instead of having a chip with bugs. But if I would have a
say in planning (I'm only a software expert for this project and not
responsible for the hardware), I would plan projects with chips which I
have lying on my table, only.

Atmel has a well known history of "Announce early, deliver late"...

 

[MooseFET]

That's a myth. Pascal's type checking is not stronger than C as long
as you don't use explicit type casts. Pascal is more restrictive so it's
harder for a novice to create a program that compiles.

No it is not a myth. What is this restrictive that you speak of if it
isn't the strong type checking? It is easier to make a program that
runs in Pascal than C.

Again a myth. Automatic runtime checks don't significantly improve software
reliability. Most bugs are due to incorrect specification or implementation,
not due to accessing null pointers etc.

Run time check prevent the software from continuing and creating the
"big trouble" I referred to. Running off the end of an array in C can
result in a reformatted hard disk. In Pascal, the program just bombs
leaving the hard disk as it was.

A better comparison would be between a novice climber using safety ropes
and an experienced climber without.

Again you are wrong. The helicopter is a far better comparison.

The safety equiment doesn't stop the
inexperienced climber from falling all the time or getting lost.

The strong type checking and the run time error checking means that an
error in a Pascal program is just a little slip. In C you end up with
the MBR on the disk overwrittten.

The experienced
climber knows to choose a safe route without risking a fall and so doesn't >need
the ropes that slow him down.

Idiots go without ropes. Experienced climbers use ropes.

 

[MooseFET]

... snip ...



I'll wager you used something like Turbo, which does not meet the
language specifications.  I used it for nearly 15 years in embedded
work, with very wide applications, and minimum problems.

The above attitude is just what I am regretting.  I don't believe
the language will return, but Ada is available.

ADA is 3 of everyones favorite languages.

 

[Jan Panteltje]

The strong type checking and the run time error checking means that an
error in a Pascal program is just a little slip. In C you end up with
the MBR on the disk overwrittten.

Hell I can do that from the command line:

dd if=/dev/zero of=/dev/hda bs=512 count=1 (1)

You mean Pascal is so limited you cannot even do anything with your hd?

GRIN

(1) Warning: Do NOT run that line.

 

[Jan Panteltje]

ADA is 3 of everyones favorite languages.

I have a 20 year old boook about ADA, wanna buy it?
20 years onward I still have no use for it.

 

[krw]

That's what the compiler salesmen tell the PHBs. It's been the holy
grail for the past five decades, at least. In reality all it does
is breed a higher class of morons.

And there's a long history of succesful projects carried out by crowds of
expendable and interchangeable conscripts to prove it ;-)

Windows is pretty "successful".

 

[Eeyore]

Hell I can do that from the command line:

dd if=/dev/zero of=/dev/hda bs=512 count=1 (1)

You mean Pascal is so limited you cannot even do anything with your hd?

GRIN

(1) Warning: Do NOT run that line.

Reminds me of formatting hard drives using debug. g = c8000 wasn't it ?

Graham

 

[linnix]

Please explain. Makes no sense. Flash has no "erase" window.

I can't explain it. But it happens to more than one of them. They
just stop working until I reprogram them. Same board works fine
indoor.

Please elaborate on the pitfalls of Flash. Everyone is abandoning OTP
and masked rom in favor of Flash.

Costs, Costs and Costs. Flash costs $1. OTP costs $0.50 and ROM
costs $0.25. We might not go for ROM, but will go for OTP at least.

 

[Jamie]

I can't explain it. But it happens to more than one of them. They
just stop working until I reprogram them. Same board works fine
indoor.




Costs, Costs and Costs. Flash costs $1. OTP costs $0.50 and ROM
costs $0.25. We might not go for ROM, but will go for OTP at least.

Once
anyways




http://webpages.charter.net/jamie_5"

 

[linnix]

Yes, clearly in your example Flash is the correct choice.
linnix must be working in a different number space, which is why I asked
for some examples.

16K ROM LCD uC for $0.20 @25Ku, NRE $3000. So $0.31@25Ku, $0.26@50Ku
and $0.23@100Ku.

 

[linnix]

That is cheap - that's just $8K order line!.
- was that your own device tho (so is really foundry costs)

Factory outlet store. No other markups.

On this type of device, ROM can also mean lower Vcc(min) and
lower operating Icc.

2.7V and 0.9mA operating. 0.08/0.003/0.0005mA standby.

The 25c Flash I had, was a 1KF/128EE/32R device, targeting
remote controls (so nearly brain-dead)

16K ROM and 192 SRAM, 40x4 or 40x8 LCD, 8 bits 6502 based.

I've been working on the compiler/simulator using the OTP version,
which is $0.50 each in hundreds.

 

[CBFalconer]

First, please take more care with your quoting. Your message
attributed quotes to the wrong people, by omitting some of the '>'
quote markers. I think I fixed it.

That's a myth. Pascal's type checking is not stronger than C as
long as you don't use explicit type casts. Pascal is more
restrictive so it's harder for a novice to create a program that
compiles.

If you don't use the facilities of the language, you are using the
language incorrectly. I greatly prefer a correct program to an
incorrect one that actually compiles.

Again a myth. Automatic runtime checks don't significantly improve
software reliability. Most bugs are due to incorrect specification
or implementation, not due to accessing null pointers etc.

No myth. Yes, such as failing to use the elaborate typeing
facilities of Pascal. Note that your null (it's nil in Pascal)
access would be promptly pointed out by the system, and thus cannot
happen if the program has been exercized.

And the programmer who produces a working system, on schedule, and
with minimum bugs, is considered much superior to the one who
cannot so do.

A better comparison would be between a novice climber using safety
ropes and an experienced climber without. The safety equiment
doesn't stop the inexperienced climber from falling all the time
or getting lost. The experienced climber knows to choose a safe
route without risking a fall and so doesn't need the ropes that
slow him down.

Experienced programmers don't need to be restricted by a language
in order to write safe and reliable software.

Experienced programmers are more likely to know what language
features can trap them, and avoid those. Should I gather that you
recommend releasing software with the maximum count of undisclosed
bugs present?

 

[CBFalconer]

[email protected] says...
.... snip ...


Windows is pretty "successful".

Well, now we know your definition of 'successful'.

 

[Ben Bradley]

In comp.arch.embedded and sci.electronics.design,

No it is not a myth. What is this restrictive that you speak of if it
isn't the strong type checking? It is easier to make a program that
runs in Pascal than C.



Run time check prevent the software from continuing and creating the
"big trouble" I referred to. Running off the end of an array in C can
result in a reformatted hard disk.

While that's definitely possible and "tragic," I don't think that's
quite the worst case. What more often happens is the stuff that "runs
off the end of an array" can be malacious executable code, thus making
an otherwise perfectly good program or operating system vulnerable to
trojan horses, viruses and such.

In Pascal, the program just bombs
leaving the hard disk as it was.

I don't see this as an argument for Pascal NEARLY as much as an
argument for doing proper bounds checking (or asserts) in the code
BEFORE using the argument (in C, FORTRAN or other such language where
array bounds aren't normally checked) anywhere you're not ABSOLUTELY
SURE of the size of the input argument.
This (buffer overflows that can turn program control over to "data"
that came from who-knows-where) appears to be cause of the vast
majority of vulnarbilities in all versions of MS Windows.

Actually, this makes a good argument AGAINST Pascal, and especially
letting its runtime code be the one to check bounds. If you rely on
the compiler/language's bounds checking, you lose control - when an
out-of-bounds access is attempted, the program stops with a run-time
error (is there . The user then becomes confused.
If you write the code to check before doing the access, you retain
control and can take appropriate steps and possibly display a message
appropriate to your program, and keep going. This is especially
important if the program is meant to be continuously running, as would
MANY of the embedded programs developed by those in these two
newsgroups.

Many years ago I went from BASIC to Pascal (and not only survived
but quickly learned to like Pascal much better than BASIC - perhaps I
always smelled the inherent evil in "goto"), went from UCSD on the
Apple II to Turbo on the PC with no problem...
Then I started to learn C. I became frustrated over various points,
for various reasons, partly because of some misleading "how to program
in C" textbook statements, and partly "just because." It was a bit
tough, but I eventually learned that (among other things) Pascal was
doing for me what I should have been be doing for myself, taking
responsibility for things such as proper array bounds checking.

 

[Wilco Dijkstra]

First, please take more care with your quoting. Your message
attributed quotes to the wrong people, by omitting some of the '>'
quote markers. I think I fixed it.

I added them by hand as the original post didn't quote correctly.

If you don't use the facilities of the language, you are using the
language incorrectly. I greatly prefer a correct program to an
incorrect one that actually compiles.

I greatly prefer to be able to write a program the way I want to rather
than being forced to write it the way the language designer thought
I should write it. C/C++ allows one to implement a problem in the most
obvious way.

No myth. Yes, such as failing to use the elaborate typeing
facilities of Pascal. Note that your null (it's nil in Pascal)
access would be promptly pointed out by the system, and thus cannot
happen if the program has been exercized.

So we agree automatic null-pointer checking adds absolutely nothing.
Automatic runtime checks only give the illusion of safety, but they only point out
the most stupid mistakes. Checking the specification at runtime using explicit
assertions is far more useful. This also allows you to take appropriate action.

Experienced programmers are more likely to know what language
features can trap them, and avoid those. Should I gather that you
recommend releasing software with the maximum count of undisclosed
bugs present?

Avoiding language features is not a solution, except perhaps when you first
start programming and learn the features one at a time. Despite all the myths,
one can learn how to write safe and reliable software using pointers, including
pointer arithmetic, pointer casts etc. As I said the most common bugs are logic
and specification bugs.

Wilco

 

[Wilco Dijkstra]

That's a myth. Pascal's type checking is not stronger than C as long
as you don't use explicit type casts. Pascal is more restrictive so it's
harder for a novice to create a program that compiles.

Btw There is something wrong with your settings, automatic quoting
doesn't work.

No it is not a myth. What is this restrictive that you speak of if it
isn't the strong type checking? It is easier to make a program that
runs in Pascal than C.

Where to begin? Everything is more restrictive in Pascal, from the syntax,
semantics to the programming constructs. So it's significantly more work to
write a Pascal program, even for simple problems. And many problems
cannot even be expressed in Pascal. Try writing memcpy in ISO Pascal
for example...

Again a myth. Automatic runtime checks don't significantly improve software
reliability. Most bugs are due to incorrect specification or implementation,
not due to accessing null pointers etc.

Run time check prevent the software from continuing and creating the
"big trouble" I referred to. Running off the end of an array in C can
result in a reformatted hard disk. In Pascal, the program just bombs
leaving the hard disk as it was.

No it can't format the hard disk. It will likely crash the program, allowing
the programmer to fix the problem. An inexperienced programmer will
quickly learn never to make that mistake again. Problem solved.

A better comparison would be between a novice climber using safety ropes
and an experienced climber without.

Again you are wrong. The helicopter is a far better comparison.

No it's not. Automatc runtime checks don't give you an easy ride. They don't
find any bugs in the logic or specification. At best they flag up the most stupid
bugs. But they do nothing to prevent them in the first place or allow one to take
appropriate action (such as a controlled shutdown that doesn't lose your work).
So if you want to compare it with a helicopter ride, it would be one that ended
with a crash.

The safety equiment doesn't stop the
inexperienced climber from falling all the time or getting lost.

The strong type checking and the run time error checking means that an
error in a Pascal program is just a little slip. In C you end up with
the MBR on the disk overwrittten.

That's pretty much impossible. Can you give a link that proves this ever happened?

The experienced
climber knows to choose a safe route without risking a fall and so doesn't >need
the ropes that slow him down.

Idiots go without ropes. Experienced climbers use ropes.

Ropes don't stop you from killing yourself. It's all down to you.

Wilco

 

[MooseFET]

In comp.arch.embedded and sci.electronics.design,


While that's definitely possible and "tragic," I don't think that's
quite the worst case.

I agree. The trashing of your hard disk is the default behavior of a C
program with a bug in it. People can write C programs that do far
worse things.

What more often happens is the stuff that "runs
off the end of an array" can be malacious executable code, thus making
an otherwise perfectly good program or operating system vulnerable to
trojan horses, viruses and such.

Yes, this is a very big problem. Doubly so on OSes where large
sections of the code run with all permissions. Modern CPUs can make
things a little safer by protecting sections of the system from the
buggy C code.

I don't see this as an argument for Pascal NEARLY as much as an
argument for doing proper bounds checking (or asserts) in the code
BEFORE using the argument (in C, FORTRAN or other such language where
array bounds aren't normally checked) anywhere you're not ABSOLUTELY
SURE of the size of the input argument.

Pascals checking, assuming a correct compiler, does the check
correctly. When the programmer has to code it, you are allowing the
same mistake to be made in two places near each other to cause
troubles. Having the range checking built into the language means
that someone else has done the check on a different day.

This (buffer overflows that can turn program control over to "data"
that came from who-knows-where) appears to be cause of the vast
majority of vulnarbilities in all versions of MS Windows.

Yes, this shows the danger of allowing any important program to be
written in C.

Actually, this makes a good argument AGAINST Pascal, and especially
letting its runtime code be the one to check bounds. If you rely on
the compiler/language's bounds checking, you lose control - when an
out-of-bounds access is attempted, the program stops with a run-time
error (is there .

The checking does not prevent you from checking your inputs. It
protects the machine against trouble on the things that the programmer
missed.

The user then becomes confused.

It is better that the user become confused than having their machine
taken over or vital data going missing.

If you write the code to check before doing the access, you retain
control and can take appropriate steps and possibly display a message
appropriate to your program, and keep going. This is especially
important if the program is meant to be continuously running, as would
MANY of the embedded programs developed by those in these two
newsgroups.

Again there is nothing preventing a programmer from checking things in
Pascal.

BTW: I code imbedded stuff in ASM.

Many years ago I went from BASIC to Pascal (and not only survived
but quickly learned to like Pascal much better than BASIC - perhaps I
always smelled the inherent evil in "goto"), went from UCSD on the
Apple II to Turbo on the PC with no problem...
Then I started to learn C. I became frustrated over various points,
for various reasons, partly because of some misleading "how to program
in C" textbook statements, and partly "just because." It was a bit
tough, but I eventually learned that (among other things) Pascal was
doing for me what I should have been be doing for myself, taking
responsibility for things such as proper array bounds checking.

I program in C a fair amount too. I also have to root out the drains
here at home sometimes too.

 

[MooseFET]

On Oct 6, 6:57 pm, "Wilco Dijkstra"

Btw There is something wrong with your settings, automatic quoting
doesn't work

The google groups interface does some silly things.

Where to begin? Everything is more restrictive in Pascal, from the syntax,
semantics to the programming constructs.

Pascal prevents you from doing things that you shouldn't do so yes it
is more restrictive but other than that it lets you write correct
programs so it isn't really restrictive. C requires you to declare a
variable before you use it. This is a restriction in C. I don't see
people complaining about it much.

So it's significantly more work to
write a Pascal program, even for simple problems.

I find no such problem on any program I wish to write.

And many problems

cannot even be expressed in Pascal. Try writing memcpy in ISO Pascal
for example...

I don't want to write a memcpy. It is a subroutine that someone might
use in a C program. I want to write a program that does something
useful.

[..C program failing..]
No it can't format the hard disk.

Oh yes it can. It may not format it correctly but it most certainly
can reformat the hard disk. When you write off the end of the array,
the return address is overwritten. Depending on what you wrote over
the return address, the code can jump anywhere. The result in at
least one case on a DOS machine was a jump into the midst of the
BIOS.

It will likely crash the program, allowing
the programmer to fix the problem. An inexperienced programmer will
quickly learn never to make that mistake again. Problem solved.

The programmer is allowed to fix a bug in any language. We are
talking about the damage done by the bug before it is fixed.

No it's not. Automatc runtime checks don't give you an easy ride. They don't
find any bugs in the logic or specification.

The specification was "go to the top of the mountain". In C you
have to crawl up the side slowly and with great effort.

At best they flag up the most stupid
bugs.

The checking in Pascal catches the most commonly made sorts of
mistakes. You may consider these as "stupid bugs" but they are still
important ones.

That's pretty much impossible. Can you give a link that proves this ever happened?

I can't give you a link because I didn't create a web page for the
case where it happened to me.

 

[krw]

Well, now we know your definition of 'successful'.

I use the standard dictionary definition of words, unlike you who
make things up as he goes along.


You and Slowman are two peas in a pod; both arrogant, bitter old men
in their own little worlds.

 

[Ulf Samuelsson]

Flash is too expensive, period. Furthermore, try running a flash uC

I can't explain it. But it happens to more than one of them. They
just stop working until I reprogram them. Same board works fine
indoor.

Note that flash memory often start to leak at high temperatures.
Leak = lose charge.
Some are worse than others.
You are sure you are not running the parts out of temp spec?

I know that 5-6 years ago, it was not advisable to run the parts at 105'C.
Atmel made an effort and now there are parts specified up to 150'C.


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