Microchip & OnSemi want to buy Atmel?

[linnix]

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 don't think so. They were Atmega169 running at 32KHz using 3V
button cell. Unless the sun is heating it up to 105C; if so, we
can't use flash in this project anyway.

 

[Wilco Dijkstra]

On Oct 6, 6:57 pm, "Wilco Dijkstra"
<[email protected]> wrote:

And many problems

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.

It's typical to need to do low level stuff on embedded systems. And
there are libraries - it's not possible to write Pascal libraries in Pascal.

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

If you're talking about an unprotected real mode OS, with totally unprotected
system calls (15 years ago?), then yes, there is a tiny chance you might end
up executing dangerous code. There are fairly trivial measures one can take
to stop it from ever happening. It's impossible to do this on a modern OS.

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.

What damage, apart from a bruised ego perhaps?

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

What makes you think writing C is any slower than Pascal? C is more
expressive and less restrictive and so it is far easier to write C.

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.

Sure. I'm not saying that is it wrong to check for them, but that it is wrong
to teach the programmer that it is OK to be lazy and not add their own
checks. Ideally none of the automatic checks should ever trigger, either
because there is an explicit check or there is a proof the check is redundant.

Wilco

 

[Wilco Dijkstra]

The most obvious way is not always the most efficient algorithm. Certain C constructs are hell for optimising
compilers.

Absolutely. But I believe it is important to have the choice. I can choose to
write C code quickly but it might not be efficient, or I can choose spend
more time and write highly optimised code. I'm not forced down a
particular route by the language designer. And that freedom is why many
of us prefer C.

And without using lint (or a similar tool) there are far too many gotchas from typos possible. A well known classic
one being (and variants thereof):

if (x=OK) {
do something
}

It is virtually certain that the author meant (x==OK) but provided that the value of OK is non-zero the condition is
always satisfied.

Just about every C compiler gives a warning for this (which can often be
configured to be reported as an error), no need to use lint.

They do improve overall productivity though since a wild pointer or array indexing error is trapped imediately before
it can do signifcant damage. Defence in depth is the maxim for high reliability code. It may not be as exciting as a
high wire act without safety nets.

Terminating a program is damaging as well if it happens for real.

The first you know about wild pointers or improperly terminated arrays in Windows is when some hacker takes control of
root priviledges on your machine.

These are typically basic mistakes when reading input data without adding
the correct checks. You always have to assume the data might be manipulated
or corrupted.

Strongly typed languages that force you to write clearly what you intend have the effect of removing a lot of
ambiguity. In embedded systems this can have advantages. The code may be somewhat more verbose as a result, but it is
more amenable to static testing tools as a result.

Having to think about the problem can be an advantage indeed. But it is also
a disadvantage if you just want to do some prototyping or want to make design
changes at a later date. For example you can easily change a structure into a
union in C, while in Pascal it requires major changes.

Automatic runtime checks during development are a powerful productivity aid. The sooner a program is faulted for an
error the better. Manually adding debugging assertions improperly can have side effects that only show up in the
production build. This is particularly true in a mixed ability team of programmers.

The goal is to add explicit checks that make all automatic checks completely
redundant. One typically enables all checks for debug and testing but a subset
in the release build. So you get faster development using the extra checks but
don't pay the runtime cost of checks that are not strictly required in the release.

And that is why Windows Vista is such a perfect bullet proof robust operating system that will run for months on end
without crashing. Pull the other one it has got bells on. Most of the MS security defects are caused by various buffer
overrun defects in C/C++ code.

You are quite right, Vista is indeed a very robust OS that runs for months without
crashing. I've use it on a daily basis for the past 18 months and it is at least as
reliable as XP (not a single crash despite uptimes of many months). Have you
even used Vista yourself? I guess bashing Vista is still a popular pastime.

Wilco

 

[MooseFET]

If you're talking about an unprotected real mode OS, with totally unprotected
system calls (15 years ago?), then yes, there is a tiny chance you might end
up executing dangerous code.

That tiny chance happened once and that was bad enough.

There are fairly trivial measures one can take
to stop it from ever happening.

Yes, like using Pascal instead.

It's impossible to do this on a modern OS.

... unless that OS is written in C by some folks in Redmond. No
wait ... you said modern so I take that back. You are right.

What damage, apart from a bruised ego perhaps?

The overwritten MBR for example.


[....]

What makes you think writing C is any slower than Pascal? C is more
expressive and less restrictive and so it is far easier to write C.

Pascal is much easier to write than C. I use both and have seen
enough projects written by others in C to know that C is not easier.

Sure. I'm not saying that is it wrong to check for them, but that it is wrong
to teach the programmer that it is OK to be lazy and not add their own
checks.

I add own checks. Adding your own checks for inputs being as you
expect them is a good idea in any language. Those checks however may
contain the same error as the code of the program because the same
person wrote them.

Ideally none of the automatic checks should ever trigger, either
because there is an explicit check or there is a proof the check is redundant.

Ideally, the hard disk should not have been trashed. Ideally, I'd be
rich(er) and good looking.

 

[Frank Buss]

Apparently Digikey finally shipped my AT91SAM9G20-EK order yesterday,
so perhaps another batch came back from fab just recently?

I hope that there is distributor stock of the chip by the time I'm
ready to go to production.

We have the information, that now we will get new samples in 6 weeks.

 

[Ulf Samuelsson]

I don't think so. They were Atmega169 running at 32KHz using 3V
button cell. Unless the sun is heating it up to 105C; if so, we
can't use flash in this project anyway.

The ATmega169 is specified for -40'C .. 85'C to guarantee full operation.
Max rating is -55 .. +125'C
Max storage is -65'C .. +150'C.

If you believe that you are not violating these specs, then
you should probably send in the parts for study by
the Atmel Quality department.

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

 

[-jg]

A more likely scenario would be that the AVR core was redesigned
into an 11 bit RISC architecture

rofl...

More seriously, looking at the lineup that microchip could harvest:
PIC16 and below are 'very mature' architectures
PIC18 is more modern, but volumes are ?? [Suspect << AVR & 80C51 ?]
dsPIC are a unusual branch
PIC32 is mainstream 32 bit, and most users are core-agnostic - the
peripherals and speeds matter more.

On Peripherals and speed @ 32 bit :
Atmel have data (Silicon?) on Flash ARM9 > 100MHz
- but this has ?? peripheral speed, and only 16 bit timers.
- NXP have just announced 125MHz ARM9 - 32 bit timers
- NXP have just announced 100MHz cM3-Rev2 - 32 bit timers, 12b ADC

Atmel have talked about a CAN AVR32

The extra MHz is not just MIPS, it gives better peripheral precision,
and 100MHz gives a a nice round 10ns timer resolution

I've always wondered why anyone releases a 32 bit uC, with 16 bit
timers ?!

NXP say this on LPC17xx
[ Support for communication peripherals including 10/100 Ethernet, USB
On-The-Go/Host/Device and two CAN interfaces, all of which can operate
simultaneously and without bus contention}
Seems to fix a blindspot of the ST variants, which could not do CAN
+USB

-jg

 

[Jasen Betts]

Yes, of course. But the real problem is where to get many experienced
programmers for cheap.

ah, and hence we have dotnet.

Bye.
Jasen

 

[Jasen Betts]

for this there was created 'gpart'
and it works well to guess the partition table.

last time I erased the MBR on my hard disk I was writing in pascal.
I learned that interrupt $33 is the mouse driver interrupt and 33 is
a dos OS call.

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

g C800:0005

it does ask you first.

back on the subject of the unix command-line:
today I reminded myself learned that

find -name foo -delete

is different to

find -delete -name foo

luckily nothing mission critical was lost.

Bye.
Jasen

 

[Jasen Betts]

The most obvious way is not always the most efficient algorithm. Certain
C constructs are hell for optimising compilers. And without using lint
(or a similar tool) there are far too many gotchas from typos possible.
A well known classic one being (and variants thereof):

if (x=OK) {
do something
}

Any decent compiler will complain about that.

It is virtually certain that the author meant (x==OK) but provided that
the value of OK is non-zero the condition is always satisfied.

it is not certain, I used a similar construct yesterday.
and when I did I wrote it like this.

if( (x=somefunc()) )

so that the next person to inspect the code, and the compiler, would
know that I really meant it.

 

[Jasen Betts]

I've always wondered why anyone releases a 32 bit uC, with 16 bit
timers ?!

"you can fix that in software."

Bye.
Jasen

 

[Rich Webb]

There's no reason to use an assignment in the condition of an if statement.
Loop conditions are another matter, but in C and C++ you can use the comma
operator, i.e.

while(x = somefunc(), x)
{}

That'll bring the maintenance programmer up short if he doesn't know C well.

Eeuuuuuwww... Yeah, but it's UGLY

My preference for the if-embedded assignment is to

if ((x = somefunc()) != 0)

which should compile to identical code to the simple assignment while
making the intent clear to the maintainer.

 

[DJ Delorie]

if ((x = somefunc()) != 0)

GCC allows you to do this:

if ((x = somefunc()))

The extra set of parens tells gcc that you intentionally tested the
result of an assignment as a value.

 

[Ben Bradley]

...

I've always wondered why anyone releases a 32 bit uC, with 16 bit
timers ?!

Seriously, perhaps they've got a 16-bit timer design laying around,
and they're too lazy, or time-to-market's too short, to design in a
32-bit timer?

Also, it could be the sort of thing Freescale (this isn't an ad,
I've just been using their parts lately and saw all this on the
website) is doing with its new line of "8-bit and 32-bit compatible
microcontrollers." It appears what they've done is made certain
versions of 32-bit-core microcontrollers that have the exact same
on-chip peripherals as some models with 8-bit cores. Thus if you
design in the 8-bit controller and then find out it doesn't have
enough horsepower, you can "drop in" the 32-bit part (more expensive,
but I think pin-compatible) and just recompile your C code for the
32-bit target.
I'm not sure if or how useful all that would be, but as the 8-bit
parts tend to have 16-bit timers, the equivalent 32-bit parts would
also have those same 16-bit timers.

 

[Paul Keinanen]

"you can fix that in software."

Assuming 1 instruction/clock cycle and 6-60 cycles for the timer ISR,
this is still going to cost you less than 1/1000 of the CPU power.

Even with a 32 bit timer, you would not get the final latency much
better than with 16bit+ISR configuration.

Of course, if the processor requires 10-20 cycles/instruction or the
timer clock can be much larger than the CPU clock, the situation is
different.

Paul

 

[Paul Keinanen]

Sadly true.

- but really, at 100MHz clocks, 16 bits is just too small, and
trying to expand in SW is best avoided.....

100 MHz clock = 10 ns cycle and the 16 bit counter overflows every
655.36 us.

You must be running on a quite low power design, if an extra ISR every
0.65 ms will cause problems. A 9600 bit/s UART would have a similar
interrupt _load_.

Paul

 

[Jasen Betts]

Some things are more complex than simple timer ticks.

Try things like capture, or wide dynamic range handling or
jitter free frequency generation....

can still be done with software assisitance, you just need to think
ahead.

Bye.
Jasen

 

[Ulf Samuelsson]

A more likely scenario would be that the AVR core was redesigned
into an 11 bit RISC architecture

rofl...

More seriously, looking at the lineup that microchip could harvest:
PIC16 and below are 'very mature' architectures
PIC18 is more modern, but volumes are ?? [Suspect << AVR & 80C51 ?]
dsPIC are a unusual branch
PIC32 is mainstream 32 bit, and most users are core-agnostic - the
peripherals and speeds matter more.

On Peripherals and speed @ 32 bit :
Atmel have data (Silicon?) on Flash ARM9 > 100MHz
- but this has ?? peripheral speed, and only 16 bit timers.
- NXP have just announced 125MHz ARM9 - 32 bit timers
- NXP have just announced 100MHz cM3-Rev2 - 32 bit timers, 12b ADC

Atmel have talked about a CAN AVR32

Yes, and this will have 16,32,48,64,... bit timers.
Have been closely working with the product line on this.
Think you will like it!

The extra MHz is not just MIPS, it gives better peripheral precision,
and 100MHz gives a a nice round 10ns timer resolution

I've always wondered why anyone releases a 32 bit uC, with 16 bit
timers ?!

Becasue normally you can handle the upper 16 bits in S/W.
At 100 MHz, you have 655 us to handle the interrupt for this.

NXP say this on LPC17xx
[ Support for communication peripherals including 10/100 Ethernet, USB
On-The-Go/Host/Device and two CAN interfaces, all of which can operate
simultaneously and without bus contention}
Seems to fix a blindspot of the ST variants, which could not do CAN
+USB

-jg

The AT91SAM9263 has 10/100 Ethernet, USB host, USB device, CAN,.
all which can operate simultaneously, without bus contention.
It is not a flash MCU though.



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

 

[TheM]

anything 'can be done' - the point is you have just moved to a nice, shiny 32 bit CPU, with a 100MHz clock to get away from all
the queue kludges, fingers crossed, and fish hooks....
So, why cripple the 32 bit CPU with 16 bit timers ?!
That's just short-sighted, or corner cutting.....

Peripherals are where the design-win decisions are made.

-jg

I agree, >16-bit timers are convenient, especially with such a high clock.

M

 

[Didi]

So, why cripple the 32 bit CPU with 16 bit timers ?!
That's just short-sighted, or corner cutting.....

Jim, "cripple" is hardly applicable in this context. The IRQ load
(as I am sure you know and as others already mentioned) is negligible
for a 16 bit timer, so making it 32 bit does not buy much if anything.
OTOH, all the associated logic - OC, IC etc., most importantly, busses
which have to be routed - is halved, which can be very significant.
You do not want to encourage the trend of the day to make things just
look better, before we know some real functionality will be gone for
the
sake of having 32 bits where we don't need them...

Peripherals are where the design-win decisions are made.

Very true - how much the world has changed over the last 20 years...
Even I - being pretty attached to PPC and other Freescale cores - am
doing it, I suspect to many of those doing just some C programming to
put something together the core is close to 100% irrelevant.
Embedding an MCU has become more like working in a PC shop, just
fetch what the customer asks for and throw it over the counter...

Didi