On 2008-10-03, larwe <z...@gmail.com> wrote:
> On Oct 3, 6:51 am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote:
>
>> Wha ta load of carp, 8 bit PIC is just fine.
>
> Just out of interest, tell me how to write a C function that takes a
> pointer parameter where the pointer may be either in code space or in
> RAM.

void func(const void *ptr);

-- 
John W. Temples, III

In comp.arch.embedded Frank Buss <f...@frank-buss.de> wrote:
> Bob Eld wrote:

> > What has Atmel done to self destruct, please explain.

> 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"...
-- 
Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On Oct 5, 8:27=A0am, "Wilco Dijkstra"
<Wilco.removethisDijks...@ntlworld.com> wrote:
> "MooseFET" <kensm...@rahul.net> wrote in message
>
> news:7...@25g2000prz.googlegroups.com...
> On Oct 3, 6:20 am, CBFalconer <cbfalco...@yahoo.com> wrote:
>
>
>
> > larwe wrote:
> > > Jim Granville <no.s...@designtools.maps.co.nz> wrote:
>
> > >>> that uChip would phase out (read: burn at the stake) all parts
> > >>> based on its frankly fucked-up legacy 8-ish-bit architectures.
>
> > >> Why ? They ship in large volumes, and obviously do the task
> > >> adequately. Elegence usually comes at a cost :)
>
> > > Ten million flies can't be wrong, eh?
>
> > 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.
>
> 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.


> > The run time type checking prevents big trouble on the few that may
> > slip by.
>
> Again a myth. Automatic runtime checks don't significantly improve softwa=
re
> reliability. Most bugs are due to incorrect specification or implementati=
on,
> 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.

>
> > This leads to its
> > downfall. =A0If you think of programming as being like mountain
> > climbing, you will understand why. =A0The 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.
>
> 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.

On Oct 4, 3:14=A0pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> Nico Coesel wrote:
> > CBFalconer <cbfalco...@yahoo.com> wrote:
>
> ... snip ...
>
> >> 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. =A0PIC assembly language is also
> >> weird (but works), and is generally poked fun at. =A0Pascal (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++.
>
> I'll wager you used something like Turbo, which does not meet the
> language specifications. =A0I 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. =A0I don't believe
> the language will return, but Ada is available.

ADA is 3 of everyones favorite languages.

On a sunny day (Sun, 5 Oct 2008 14:34:07 -0700 (PDT)) it happened MooseFET
<k...@rahul.net> wrote in
<7...@b38g2000prf.googlegroups.com>:


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

On a sunny day (Sun, 5 Oct 2008 14:37:50 -0700 (PDT)) it happened MooseFET
<k...@rahul.net> wrote in
<b...@b2g2000prf.googlegroups.com>:

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

In article <gcaqhg$967$1...@pcls6.std.com>, a...@TheWorld.com says...
> >>>>Yes, of course. But the real problem is where to get many experienced
> >>>>programmers for cheap.
> 
> >This is a classic question of few knights vs many conscripts. It turns 
> >out that big practical tasks are better handled by the crowds of 
> >expendable and interchangeable conscripts.

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

-- 
Keith

Jan Panteltje wrote:

> On a sunny day (Sun, 5 Oct 2008 14:34:07 -0700 (PDT)) it happened MooseFET
> <k...@rahul.net> wrote in
> <7...@b38g2000prf.googlegroups.com>:
>
> >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.

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

Graham

On Oct 5, 11:59 am, "RumpelStiltSkin" <fables...@abc.gov> wrote:
> "linnix" <m...@linnix.info-for.us> wrote in message
>
> news:3...@r15g2000prh.googlegroups.com...
>
> > Didn't see my earlier post.  Perhaps memory erased.
>
> > On Oct 3, 3:29 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
> >> linnix wrote:
> >> > On Oct 3, 2:15 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> >> >>Most designers choose the cheapest device that will get the job done.
> >> >>A toothpaste timer does not really need
> >> >>memory-agnostc function pointer support  ;)
>
> >> > And we don't need flash uC for productions.  Most other uCs offer ROM/
> >> > OTP version. ROM/OTP AVRs should be much cheaper to make.
>
> > Flash is too expensive, period.  Furthermore, try running a flash uC
> > under direct sun-light.   They sometimes lose their memories.
>
> 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.

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

linnix wrote:

> On Oct 5, 11:59 am, "RumpelStiltSkin" <fables...@abc.gov> wrote:
> 
>>"linnix" <m...@linnix.info-for.us> wrote in message
>>
>>news:3...@r15g2000prh.googlegroups.com...
>>
>>
>>>Didn't see my earlier post.  Perhaps memory erased.
>>
>>>On Oct 3, 3:29 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>>wrote:
>>>
>>>>linnix wrote:
>>>>
>>>>>On Oct 3, 2:15 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>>>>
>>>>>>Most designers choose the cheapest device that will get the job done.
>>>>>>A toothpaste timer does not really need
>>>>>>memory-agnostc function pointer support  ;)
>>
>>>>>And we don't need flash uC for productions.  Most other uCs offer ROM/
>>>>>OTP version. ROM/OTP AVRs should be much cheaper to make.
>>
>>>Flash is too expensive, period.  Furthermore, try running a flash uC
>>>under direct sun-light.   They sometimes lose their memories.
>>
>>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.
> 
> 
>>>>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.
>>
>>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.
                                                                 Once 
anyways




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