Microchip & OnSemi want to buy Atmel?

[Ulf Samuelsson]

As technology move forward, you will see that ROM is no good.

With 6 inch wafers and 10 mm2 which might be more standard today
you have ~1500 dies/wafer and 36000 per lot.

Assume 8 inch wafer and 5 mm2 die in the future.
Each wafer is 32428 mm2 so you would get ~6000dies per wafer.
One lot of 24 wafers will give you 24 * 6000 dies = 144000 dies.

So that would be your minimum order...

Doing a ROM version means that you have to do two masksets for every
chip you do, and that will delay introduction.
Also you risk that the two versions are out of sync, so that something
that works on the flash part wont work on the ROM part.

This is an interesting area.
Many say flash is the only path, but others offer Flash and 'ROM/OTP'.

In some cases IAP capability is more a liability than an asset.
Some sectors demand a FLASH enable pin, to avoid any chance of
self-corruption.
Some companies offer Factory program services, making the flash
very similar to ROM.

SiLabs started in Flash, and have expanded with OTP devices, and some of
their OTP parts are in lowest-cost packages.
Are those true OTP, or just reduced-flow FLASH devices ?

In Asia, this is more common : CoreRiver offer FLASH and ROM
devices.

There does seem to be scope to reduce testing time, if all the vendor has
to do, is confirm the customer code programmed.
Genuine OTP and ROM have testing and yield issues, so the best
manufacturing path seems to be an "Apparent ROM" or "Apparent OTP"
offering.

Atmel had some OTP AVR's but they phased them out.

-jg

I remember that you could create your own OTP by not connecting AVCC
on some devices (Analog functions would not be available of course)

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

 

[Jamie]

You fail to see the issue at hand.
Small PICs, like the 8 bit, are ment to be programmed is asm.
Sure, many grab, for reasons unknown to me, but
likely incompetence with asm, for the first crappy C subset compiler at hand.
Now _that_ is bad.

To waste your time trying to convince C coders of anything but C for uC's.
We all know that real men program in "ASM"


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

 

[Jasen Betts]

I am amazed at the things programmers carp at and distinguish. The
C language is generally admired, yet it is one of the weirdest
languages in existance.

after it's creation, and popularity it has been worked over by two
committes (and that shows a bit). I don't find it weird.

PIC assembly language is also weird (but works),

It struck me as being similar to other 3 register 8 bit CISC processors

and is generally poked fun at. Pascal (real, not Turbo) is
almost the soundest language available to all, yet it is studiously
ignored.

by "real" you mean "ISO 10206" ?

It seems kind of limiting to me.

Bye.
Jasen

 

[linnix]

This is an interesting area.
Many say flash is the only path, but others offer Flash and 'ROM/OTP'.

Flash is too expensive, period

In some cases IAP capability is more a liability than an asset.
Some sectors demand a FLASH enable pin, to avoid any chance of
self-corruption.
Some companies offer Factory program services, making the flash
very similar to ROM.

We need a migration path. Small quantity developments in FLASH.
Medium quantity in OTP. Large quantity in ROM. They need to be source
and register level compatible, to minimize porting issues.

SiLabs started in Flash, and have expanded with OTP devices, and some of
their OTP parts are in lowest-cost packages.

Yes, lowest cost package: bare die.

Are those true OTP, or just reduced-flow FLASH devices ?

In Asia, this is more common : CoreRiver offer FLASH and ROM
devices.

We can get PIC ASIC core, but not AVR.

There does seem to be scope to reduce testing time, if all the vendor
has to do, is confirm the customer code programmed.
Genuine OTP and ROM have testing and yield issues, so the best
manufacturing path seems to be an "Apparent ROM" or "Apparent OTP"
offering.

Atmel had some OTP AVR's but they phased them out.

That's why we (our customers) need to phase out Atmel.

I like AVR. I spent lots of time with AVR. I strongly suggested
against using AVR in our productions.

 

[MooseFET]

I am amazed at the things programmers carp at and distinguish.  The
C language is generally admired, yet it is one of the weirdest
languages in existance.  PIC assembly language is also weird (but
works), and is generally poked fun at.  Pascal (real, not Turbo) is
almost the soundest language available to all, yet it is studiously
ignored.

Pascal's strict type enforcement means that most bugs are caught
before the program is even compiled. The run time type checking
prevents big trouble on the few that may slip by. This leads to its
downfall. If you think of programming as being like mountain
climbing, you will understand why. The guy who crawls up the side of
a mountain gets a lot more respect than some who takes a safe and
comfortable helicopter ride there.

 

[RumpelStiltSkin]

You fail to see the issue at hand.
Small PICs, like the 8 bit, are ment to be programmed is asm.
Sure, many grab, for reasons unknown to me, but
likely incompetence with asm, for the first crappy C subset compiler at
hand.
Now _that_ is bad.

In this day and age, programming in asm to save code space shouldn't be an
issue.
Neither should banking, limited stack space, or other limitations from the
1970s.

 

[Jan Panteltje]

In this day and age, programming in asm to save code space shouldn't be an
issue.
Neither should banking, limited stack space, or other limitations from the
1970s.

Well, it is like you say: we need no wood, we have concrete, we need no nails,
we have glue, etc...

Use the right thing for the right job! The little 8 bit pics are made for asm.
If you have problems understanding banks, small stack spaces, and some other
limitations / peculiarities, then you likely do not have the brains to fully
use C on a much bigger micro either.

PIC serves me well, learning a few special tricks took hours, not more,
this is the same for each new micro.
It is a very simple instruction set, and yes I know very well how to program in C.
But I would _never_ and I repeat _never_ use C on a simple micro like an 8 bit PIC.

 

[RumpelStiltSkin]

Well, it is like you say: we need no wood, we have concrete, we need no
nails,
we have glue, etc...

Use the right thing for the right job! The little 8 bit pics are made for
asm.
If you have problems understanding banks, small stack spaces, and some
other
limitations / peculiarities, then you likely do not have the brains to
fully
use C on a much bigger micro either.

I've used PICs extensively ... and hate them.

PIC serves me well, learning a few special tricks took hours, not more,
this is the same for each new micro.
It is a very simple instruction set, and yes I know very well how to
program in C.
But I would _never_ and I repeat _never_ use C on a simple micro like an 8
bit PIC.

In this day and age, chips are cheap enough with decent code space.
Shouldn't have to beat yourself to death to fit in 1K.

I never use assembly unless forced too.
Hitech C is quite efficient on a PIC.
Done may systems that way.

 

[Walter Banks]

PIC serves me well, learning a few special tricks took hours, not more,
this is the same for each new micro.
It is a very simple instruction set, and yes I know very well how to program in C.
But I would _never_ and I repeat _never_ use C on a simple micro like an 8 bit PIC.

Why?

w..

 

[Jan Panteltje]

I've used PICs extensively ... and hate them.


In this day and age, chips are cheap enough with decent code space.
Shouldn't have to beat yourself to death to fit in 1K.

I never use assembly unless forced too.
Hitech C is quite efficient on a PIC.
Done may systems that way.

Well, I am not getting into a C versus asm war, it is pointless.
This also replies to the other poster's 'why'.
If you dunno why you are in the wrong field.

In asm, at least you know what actually happens.
There is no problem playing around with data and registers.

Timing, adding a few nops, it is fun.
Only advantage I would see for C is, that if you have a lot of floating point
stuff, you can perhaps do the math in a simpler way.
OTOH you can do most stuff in integer math too.
The libraries are all there for asm.

No, I like to use the spare resources in a way I have full control over,
that is why asm.

It will work out cheaper too, as you can use smaller PICs, could
be important if you need a lot.

OK, I am out of this pointless discussion.
As a last remark, if you really want bigger, use Linux and gcc on
a board with a different processor supported by gcc.

That is an other price point all together.
The little PICs are great for lots of stuff.
And programming in asm is _not_ more complicated then in C for many
applications for those!

 

[Mel]

Don't these people know there is a credit crunch! ;-)

Now that the thirty-times leveraged million-dollar mortgages to paupers
market has imploded, bankers have to hustle up commissions someplace else.

Mel.

 

[Nico Coesel]

I am amazed at the things programmers carp at and distinguish. The
C language is generally admired, yet it is one of the weirdest
languages in existance. PIC assembly language is also weird (but
works), and is generally poked fun at. Pascal (real, not Turbo) is
almost the soundest language available to all, yet it is studiously
ignored.

There is a simple reason for that. C has been designed to be a usefull
programming language, Pascal has been designed to be a useless as
possible programming language. I've been using Pascal for years but I
still don't regret trading it in for C / C++.

 

[Frank Buss]

The little PICs are great for lots of stuff.
And programming in asm is _not_ more complicated then in C for many
applications for those!

I know how to program PICs and it is fun, because you have to think about
how to do solve a problem with the small instruction set and limited
resources (if it sounds strange that is is fun for me, the reaon is that
I'm a programmer, so it's relaxing like Sudoku for non-programmers, which I
don't like , but as you say, the advantage is that you have the full
control of the hardware. This was my last small hobby project:

http://www.frank-buss.de/PICMonoflop/

But I disagree that it is not more complicated than programming in C. I
think I could implement the monoflop project with 1/5 C source code
compared to the assembler code and it would be easier to understand and
faster to write, because you can concentrate on the problem and don't have
to think about strange PIC things like skip-if-not branches etc. at the
same time.

BTW: what do you think of the RS08 series from Freescale?

http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556109;keywords=rs08

Very nice 6502-like instruction set and they are cheaper than PICs with the
same functionalities.

 

[Jan Panteltje]

I know how to program PICs and it is fun, because you have to think about
how to do solve a problem with the small instruction set and limited
resources (if it sounds strange that is is fun for me, the reaon is that
I'm a programmer, so it's relaxing like Sudoku for non-programmers, which I
don't like , but as you say, the advantage is that you have the full
control of the hardware. This was my last small hobby project:

http://www.frank-buss.de/PICMonoflop/

Nice project, yes for signal detection this can be useful.

Here my last PIC hobby project:
http://panteltje.com/panteltje/pic/swr_pic/index.html

But I disagree that it is not more complicated than programming in C. I
think I could implement the monoflop project with 1/5 C source code
compared to the assembler code and it would be easier to understand and
faster to write, because you can concentrate on the problem and don't have
to think about strange PIC things like skip-if-not branches etc. at the
same time.

Well, it all depends, I was writing today (or am writing) some intrusion detection
and counter measure software in C, (Linux based), it detects those nasty
denial of service and even worse Kaspersky related attacks on my name server, and
automatically starts counter measures.
It is linked list based, and coding time was so far some hours.
Been test running now tonight (I am lucky somebody is attacking my port 53 now).
I need this so the server stuff can run unmanned for a long time, it sucks
if your log in the morning shows you have been made part of a botnet... or similar.
This program test frequently.

This programs depends on other stuff (like snort) and scripts, and is simply a bit complicated,
in the sense that writing it is asm would take a lot more time (for a x86),
but always remember 'Hello world' in asm is only a few bytes, and linking in libc
with printf() variants in C takes more space.
If all came down to it, then it would (with the right libs you build over time in asm) not be
that much more work to do in asm, but it 'looks' simpler in C.
But on this system I have practically unlimited memory and resources, so C is nice.

BTW: what do you think of the RS08 series from Freescale?

http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556109;keywords=rs08

Well I have not used it, so I cannot give an informed opinion

Very nice 6502-like instruction set and they are cheaper than PICs with the
same functionalities.

6502, now that is long ago....

 

[Ulf Samuelsson]

Well, it is like you say: we need no wood, we have concrete, we need no
nails,
we have glue, etc...

Use the right thing for the right job! The little 8 bit pics are made for
asm.

That is exactly why you want to avoid them...

If you have problems understanding banks, small stack spaces, and some
other
limitations / peculiarities, then you likely do not have the brains to
fully
use C on a much bigger micro either.

PIC serves me well, learning a few special tricks took hours, not more,
this is the same for each new micro.

Fact: Programmers are less productive in assembler than in a high level
language.
You therefore need to show that you have some other benefit from using the
PIC,
or you have just proven yourself to be a poor engineer.

It is a very simple instruction set, and yes I know very well how to
program in C.
But I would _never_ and I repeat _never_ use C on a simple micro like an 8
bit PIC.

Funny, I got a ~700 byte ATtiny13 assembler program
from a customer who wanted help finding a bug.
I rewrote the program in C using the IAR C compiler
and managed to reduce the code to ~400 bytes.

I would never *start* writing a program for the AVR in assembler,
simply because it rarely makes sense.
I find that most AVR customers agree with me.

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

 

[linnix]

Didn't see my earlier post. Perhaps memory erased.


Flash is too expensive, period. Furthermore, try running a flash uC
under direct sun-light. They sometimes lose their memories.

This is an interesting area.
Many say flash is the only path, but others offer Flash and 'ROM/OTP'.

We need migration path for: low quantity Flash, mid quantity OTP and
large quantity ROM. They should be C source and register level
compatible, for minimum porting issues.

Atmel had some OTP AVR's but they phased them out.

That's why our customers are phasing out Atmel for productions. I
love AVR. I spent lots of time prototyping with AVR. I am strongly
against using Flash AVR in our productions.

 

[CBFalconer]

after it's creation, and popularity it has been worked over by
two committes (and that shows a bit). I don't find it weird.

That's because you (and others) are used to it.

It struck me as being similar to other 3 register 8 bit CISC
processors


by "real" you mean "ISO 10206"? It seems kind of limiting to me.

Yes. It actually isn't. There is usually only one way of doing
something, rather than the 55 of C. But it isn't available for
everything.

 

[CBFalconer]

.... snip ...

There is a simple reason for that. C has been designed to be a
usefull programming language, Pascal has been designed to be a
useless as possible programming language. I've been using Pascal
for years but I still don't regret trading it in for C / C++.

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.

 

[CBFalconer]

"Jan Panteltje" <[email protected]> skrev:
.... snip ...

Fact: Programmers are less productive in assembler than in a high
level language. You therefore need to show that you have some
other benefit from using the PIC, or you have just proven yourself
to be a poor engineer.


Funny, I got a ~700 byte ATtiny13 assembler program from a
customer who wanted help finding a bug. I rewrote the program in
C using the IAR C compiler and managed to reduce the code to ~400
bytes.

I would never *start* writing a program for the AVR in assembler,
simply because it rarely makes sense. I find that most AVR
customers agree with me.

That says, among other things, that the AVR coding is suitable for
expressing C source, and that a decent compiler is available.
Nobody says that about PIC assembly coding. In my experience
attempting to move something to C for the PIC involves loss of
clarity, and something like a factor of three in code size.
Admittedly my PIC experience is about 10 or 15 years old.

If you want something simple, that can be handled by a PIC and its
memory, PIC assembly can be very attractive. Say for a Microwave
controller.

 

[Frank Buss]

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.

Which part of Turbo Pascal doesn't meet the language specification? I think
TP is a superset of Pascal, because it has some more features, like inline
assembler and object oriented extensions, but otherwise it should conform
to http://www.moorecad.com/standardpascal/iso10206.pdf

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

Something similar is used as structured text (ST) for PLCs:

http://www.eod.gvsu.edu/~jackh/books/plcs/chapters/plc_st.pdf

Looks like ST doesn't need begin/end for multiline blocks, which I always
disliked in Pascal.