Microchip & OnSemi want to buy Atmel?
Wim Lewis
lines, selling some of them to OnSemi) ---
http://preview.tinyurl.com/4ltdbb
http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
Atmel seems uninterested, though. Just as well. I don't think that if
Atmel were bought and parted out that I as a customer would see anything
good as a result...
--
Wim Lewis <wi...@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1
Jim Thompson
>According to this, Microchip wants to buy Atmel (and split up its various
>lines, selling some of them to OnSemi) ---
> http://preview.tinyurl.com/4ltdbb
> http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
>
>Atmel seems uninterested, though. Just as well. I don't think that if
>Atmel were bought and parted out that I as a customer would see anything
>good as a result...
Except that Atmel has been in self-destruction for at least the past
two years.
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine Sometimes I even put it in the food
mi...@sushi.com
> According to this, Microchip wants to buy Atmel (and split up its various
> lines, selling some of them to OnSemi) ---
> http://preview.tinyurl.com/4ltdbb
> http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
>
> Atmel seems uninterested, though. Just as well. I don't think that if
> Atmel were bought and parted out that I as a customer would see anything
> good as a result...
>
> --
Don't these people know there is a credit crunch! ;-)
Jim Granville
> According to this, Microchip wants to buy Atmel (and split up its various
> lines, selling some of them to OnSemi) ---
> http://preview.tinyurl.com/4ltdbb
> http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
>
> Atmel seems uninterested, though. Just as well. I don't think that if
> Atmel were bought and parted out that I as a customer would see anything
> good as a result...
- The omission of mention of any Atmel Roadmaps, suggests this is a
typical cynical harvesting effort ?
No mention is made of Atmel's CPLDs ? ( or of Atmel's R&D efforts...)
Does Microchip even know what a CPLD is ?
Seems a strange move for Microchip. Maybe they are simply cashed up, and
see a fire-sale-price, in an industry they know ?
Or, a large Atmel shareholder wants out ?
On-Semi did just buy AMIS, but Microchip have always been
more of a loner.
Is the MIPS32 not getting the traction they hoped, so they need
a side-door to ARM, Cortex, or even AVR32 ?
Maybe Automotive AVR's ?
The ATxmega is an interesting family, tho not yet in small packages.
The AT89LP are nice single-cycle 80C51's with a road map
from 14 to 44+ pins
-jg
Bob Eld
"Jim Thompson" <To-Email-Use-Th...@My-Web-Site.com> wrote in
message news:94dae4hg2ca9ajpso...@4ax.com...
>
> On Thu, 2 Oct 2008 20:35:31 +0000 (UTC), wi...@underhill.hhhh.org (Wim
> Lewis) wrote:
>
> >According to this, Microchip wants to buy Atmel (and split up its various
> >lines, selling some of them to OnSemi) ---
> > http://preview.tinyurl.com/4ltdbb
> >
http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
> >
> >Atmel seems uninterested, though. Just as well. I don't think that if
> >Atmel were bought and parted out that I as a customer would see anything
> >good as a result...
>
> Except that Atmel has been in self-destruction for at least the past
> two years.
What has Atmel done to self destruct, please explain.
john jardine
"Wim Lewis" <wi...@underhill.hhhh.org> wrote in message
news:gc3baj$rlh$1...@underhill.hhhh.org...
Could be a really good deal for both Atmel and Microchip (maybe the
industry).
Atmel needs severe rationalising, yet have superb micro products (eg the
Mega series). Microchip know superbly well how to do -cheap- yet only have
third rate technology (eg the PICs).
We'll know how interested Atmel are when Mchip put their final offer on the
table.
Frank Buss
> 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.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
larwe
wrote:
> Seems a strange move for Microchip. Maybe they are simply cashed up, and
> see a fire-sale-price, in an industry they know ?
One can only hope that if this acquisition did in fact come to pass,
that uChip would phase out (read: burn at the stake) all parts based
on its frankly fucked-up legacy 8-ish-bit architectures. Budding EEs
would then no longer be poisoned. Dijkstra might as well have written
about the PIC architecture as about BASIC when he said "It is
practically impossible to teach good programming style to students
that have had prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration".
Jim Granville
> On Oct 2, 6:11 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
>
>>Seems a strange move for Microchip. Maybe they are simply cashed up, and
>>see a fire-sale-price, in an industry they know ?
>
>
> One can only hope that if this acquisition did in fact come to pass,
> that uChip would phase out (read: burn at the stake) all parts based
> on its frankly fucked-up legacy 8-ish-bit architectures. Budding EEs
Why ? They ship in large volumes, and obviously do the task adequately.
Elegence usually comes at a cost :)
Indeed, Microchip's low Average Selling prices indicate just how
widely popular their bottom-end devices are, and this move may
be an attempt to raise their average selling prices.
-jg
Eeyore
Wim Lewis wrote:
> According to this, Microchip wants to buy Atmel (and split up its various
> lines, selling some of them to OnSemi) ---
> http://preview.tinyurl.com/4ltdbb
> http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
>
> Atmel seems uninterested, though. Just as well. I don't think that if
> Atmel were bought and parted out that I as a customer would see anything
> good as a result...
Couldn't agree more !
Graham
Jim Thompson
On Thu, 2 Oct 2008 14:56:31 -0700, "Bob Eld" <nsmon...@yahoo.com>
wrote:
Most of the engineering in Colorado Springs is gone.
linnix
> >> Except that Atmel has been in self-destruction for at least the past
> >> two years.
>
> >What has Atmel done to self destruct, please explain.
>
> Most of the engineering in Colorado Springs is gone.
AVRs are designed in Norway. What do they do in Colorado?
Jan Panteltje
<zwsd...@gmail.com> wrote in
<f3c19442-07fa-4992...@59g2000hsb.googlegroups.com>:
>On Oct 2, 6:11�pm, Jim Granville <no.s...@designtools.maps.co.nz>
>wrote:
>
>> Seems a strange move for Microchip. Maybe they are simply cashed up, and
>> see a fire-sale-price, in an industry they know ?
>
>One can only hope that if this acquisition did in fact come to pass,
>that uChip would phase out (read: burn at the stake) all parts based
>on its frankly fucked-up legacy 8-ish-bit architectures.
Wha ta load of carp, 8 bit PIC is just fine.
>Budding EEs
>would then no longer be poisoned. Dijkstra might as well have written
>about the PIC architecture as about BASIC when he said "It is
>practically impossible to teach good programming style to students
>that have had prior exposure to BASIC: as potential programmers they
>are mentally mutilated beyond hope of regeneration".
Looks like Dijkstra is an idiot.
Probably was projecting some of his own shortcomings.
larwe
> 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.
larwe
wrote:
> > that uChip would phase out (read: burn at the stake) all parts based
> > on its frankly fucked-up legacy 8-ish-bit architectures. Budding EEs
> 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?
> Indeed, Microchip's low Average Selling prices indicate just how
> widely popular their bottom-end devices are, and this move may
> be an attempt to raise their average selling prices.
It's been a long time since I looked at pricing on their cheapest
cheapest parts (which I think are the SOT-23-6 devices). In the arena
where we play (8~64K flash) Atmel is cheaper than dirt and comparable
PIC devices are much more expensive, besides being a pain in the ass
to program. Code density sucks compared to MSP430 or AVR, too. A rabid
wombat in a bell jar full of crack smoke could not have designed a
less-pleasant ISA than PIC.
We're talking millions of units a year here, so uChip (which is very
hungry to get us to design in their parts) would already be factoring
in as much volume discount and foot-in-the-door discount as they can.
Jan Panteltje
<zwsd...@gmail.com> wrote in
<8717f370-7c85-4b6f...@v53g2000hsa.googlegroups.com>:
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.
CBFalconer
> 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.
>
>> 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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Didi
> ...
> 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.
C is lower level than Pascal, it wins there. Generally high level
languages are good for newcomers (like tourists who use a phrase
book while on a trip), but for real work one needs lower level
(that is, if you will write a novel you better learn the language
beyond the phrase book).
With so many of the assembly languages being so poorly designed,
no wonder C has gained its popularity, it thrives on poorly
designed hardware platforms. And no wonder the resulting software
is so messy, it takes an alphabet based language to write real
novels (e.g. English) rather than a hyeroglyph based one (not
many great pieces of literature written in Chinese or Japanese...).
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/f2afa662e4070c22?dmode=source
cs_po...@hotmail.com
> Wha ta load of carp, 8 bit PIC is just fine.
Indeed it is... as long as you are happy with 8 bit addressing ;-)
Uniden
@m45g2000hsb.googlegroups.com>, zwsd...@gmail.com says...
> A rabid
> wombat in a bell jar full of crack smoke could not have designed a
> less-pleasant ISA than PIC.
Funniest thing I've read in a long time. And laser accurate. :-P
Frank Buss
> 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.
That's no problem. The compiler just has to implement tests at runtime
whenever the pointer is used to execute the PC load instructions with retlw
for reading data in code space or a the mov instruction for reading RAM. To
save code memory, this should be done in a subroutine. Maybe the easiest
and most efficient way to program a PIC would be to implement a small Forth
system for it, if you don't like assembler.
Rob Gaddi
Ahhh, Pascal. All the elegance and programmer-friendliness of K&R C, with the unbridled horsepower of BASICA.
--
Rob Gaddi, Highland Technology
Email address is currently out of order
sod...@gmail.com
> Maybe the easiest and most efficient way to program a PIC would be to implement a small Forth
> system for it, if you don't like assembler.
If PIC assembly was designed by a rabid wombat high on crack smoke,
then Forth must have been designed by the same wombat tripping on
LSD. ;-)
Jim Granville
> On Oct 2, 8:43 pm, 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. Budding EEs
>
>
>>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?
>
>
>>Indeed, Microchip's low Average Selling prices indicate just how
>>widely popular their bottom-end devices are, and this move may
>>be an attempt to raise their average selling prices.
>
>
> It's been a long time since I looked at pricing on their cheapest
> cheapest parts (which I think are the SOT-23-6 devices). In the arena
> where we play (8~64K flash) Atmel is cheaper than dirt and comparable
> PIC devices are much more expensive, besides being a pain in the ass
> to program. Code density sucks compared to MSP430 or AVR, too. A rabid
> wombat in a bell jar full of crack smoke could not have designed a
> less-pleasant ISA than PIC.
It was not designed in 2008, so why judge it with a 2008 yardstick ?
There was a ceiling on what was even possible, when the PIC was
conceived, decades ago.
There are also MANY PIC cores, PIC is a brand, not a core.
Choose a newer core variant, if that is more to your taste.
Most designers choose the cheapest device that will get the job done.
A toothpaste timer does not really need
memory-agnostc function pointer support ;)
> We're talking millions of units a year here, so uChip (which is very
> hungry to get us to design in their parts) would already be factoring
> in as much volume discount and foot-in-the-door discount as they can.
Look at their respective corporate margins, and now take a guess
as to what the AVR prices will do, should Microchip succeed ?
-jg
linnix
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.
Ulf Samuelsson
"Frank Buss" <f...@frank-buss.de> skrev i meddelandet
news:9tbp78aqto6r$.ckvlf67b1wab.dlg@40tude.net...
> 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.
Funny, I shipped AT91SAM9G20 samples to customers in December 2007 :-)
First production batches are already sold out, that is the cause of the
delay.
> 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.
>
--
Best Regards,
Ulf Samuelsson
u...@a-t-m-e-l.com
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
A more likely scenario would be that the AVR core was redesigned
into an 11 bit RISC architecture :-)
Ulf Samuelsson
> 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.
That is an issue with all true Harvard architecture.
Same issue with the AVR.
You could conceivable pass a 24 bit pointer with a bit indicating
which address space. Pointer handling would be more expensive,
so the answer is normally, - you don't...
I usually copy flash constants to the stack before calling a routine
which only supports RAM pointers.
You could conceivably reserve part of the address space
for code, and another part for data and still keep the Harvard
but that never happened.
Jim Granville
>>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.
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
Ulf Samuelsson
"Jim Granville" <no....@designtools.maps.co.nz> skrev i meddelandet
news:48e68e7c$1...@clear.net.nz...
> 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.
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)
--
Jamie
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" :)
Jim Granville
> "Jim Granville" <no....@designtools.maps.co.nz> skrev i meddelandet
> news:48e68e7c$1...@clear.net.nz...
>
>>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.
>
>
> 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.
That was why I referred to "Apparent ROM" and "Apparent OTP"
- the wafers are the same, but the testing/pgm flows diverge.
Atmel already do factory pgm now, this just allows less FLASH testing
on those devices.
Xilinx do this with their easy-path, same silicon, different test flow.
-jg
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
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.
>
> 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
> 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. 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
"Jan Panteltje" <pNaonSt...@yahoo.com> wrote in message
news:gc4uv6$et6$1...@aioe.org...
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
<fabl...@abc.gov> wrote in <DOMFk.2265$as4....@nlpi069.nbdc.sbc.com>:
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
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
Jan Panteltje wrote:
> 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
<fabl...@abc.gov> wrote in <XCOFk.2204$x%.921@nlpi070.nbdc.sbc.com>:
>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.
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!
Jim Granville
> 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.
>>
>>This is an interesting area.
>>Many say flash is the only path, but others offer Flash and 'ROM/OTP'.
>
>
> Flash is too expensive, period
Flash can get down to ~25c, which covers a very large part of the
market. Companies decide if they want to chase the diminishing returns
of the sub 25c market.
>
>>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.
These days, "EMC-identical" is also important. Which Ulf alluded to,
which is what makes separate-die flows higher risk.
I've seen OTP silicon differ from ROM silicon.
In the ideal world, you want ROM prices, on a 'flash-cloned-die' :)
-jg
Mel
> On Oct 2, 1:35 pm, w...@underhill.hhhh.org (Wim Lewis) wrote:
>> According to this, Microchip wants to buy Atmel (and split up its various
>> lines, selling some of them to OnSemi) ---
>> http://preview.tinyurl.com/4ltdbb
>> http://blog.makezine.com/archive/2008/10/microchip_along_with_onse.html
>>
>> Atmel seems uninterested, though. Just as well. I don't think that if
>> Atmel were bought and parted out that I as a customer would see anything
>> good as a result...
>>
>> --
>> Wim Lewis <w...@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1
>
> 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.
Jim Granville
> 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.
Mostly, but there are sectors where the last 1c matters, and if your
client says "SOT23 uC", then you are already constrained.
Of course, as the designer if there are two similar SOT23 uC, and
one is better with a compiler than the other, then you have
the luxury of choice :) [PIC//Freescale spring to mind here]
-jg
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.
Nico Coesel
>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.
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++.
--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)
Jan Panteltje
<f...@frank-buss.de> wrote in <13ernnnlw08vy.1...@40tude.net>:
>Jan Panteltje wrote:
>
>> 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/
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
"Jan Panteltje" <pNaonSt...@yahoo.com> skrev i meddelandet
news:gc86jr$sff$1...@aioe.org...
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.
linnix
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.
>
> 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
> CBFalconer <cbfal...@yahoo.com> wrote:
>
>> 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.
That's because you (and others) are used to it.
>
>> 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.
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer
> CBFalconer <cbfal...@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. 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++.
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" <pNaonSt...@yahoo.com> 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.
>
>> 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.
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.
Jim Granville
> Didn't see my earlier post. Perhaps memory erased.
you can get funny latencies in news servers, I think the
post is on my reader,
>>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.
What volumes and price points, do you run each of Flash/OTP/ROM at ?
-jg
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.
Tom
...
>
> Flash is too expensive, period
Depends what for... I work for a company that makes industrial type not very cheap gear, our customers expect firmware upgrades and bug fixes without saying - it's cheaper for us to have flash in these products. I agree OTP is great for cheap throwaway items.
Tom
Frank Buss
> 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.
I hope you don't use something like BIND? The last time I installed a
nameserver and SMTP-server on a Linux system, I installed it in separate
chroot-jails. Nowadays my hoster provides these services and I'm using only
lighttpd for my webserver, which is small, clean, more secure and faster
than Apache.
If you really like to do all by yourself, there are nice features in
iptables, if you are using Linux.
> 6502, now that is long ago....
Yes, looks like I'm getting old :-) Today most people think it is cool to
write PHP or Visual Basic programs, if they are interested in programming
at all, but only a few people know the basics, or even like it.
Jim Granville
>>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.
ST is more like Modula-2, in that the Pascal 'begin' is implicit,
so you avoid the single-line context variance of pascal.
ST also includes the Modula-2 extensions, of IF..ELSIF and
adds an ELSE in the CASE statement.
ST slightly extends Moudla-2 in that it is more explicit on the
END - ST has END_FOR, END_IF, END_WHILE etc
ST also allows this super-set of Modula-2 on numbers
(more Ada like) :
binary numbers 2#111111111, 2#1111_1111, 2#1111_1101_0110_0101
octal numbers 8#123, 8#777, 8#14
hexadecimal numbers 16#FF, 16#ff, 16#9a, 16#01
-jg
Ulf Samuelsson
"CBFalconer" <cbfal...@yahoo.com> skrev i meddelandet
news:48E7EFE9...@yahoo.com...
The logical conclusion is that with the PIC you have two choices:
Poor productivity, by programming in assembler - or -
Poor code density which in the end means high cost.
Can't see how such a part can "serve you well".
The comments fromJan Penteltje:
"8 bit PIC is just fine." --
Shown incorrect
"Small PICs, like the 8 bit,
are ment to be programmed is asm." -- Should
therefore be avoided
"Use the right thing for the right job" -- See
above
"In asm, at least you know what actually happens." -- read the list file!
Then again, this is well known.
There are other of course other decision criteria.
> --
> [mail]: Chuck F (cbfalconer at maineline dot net)
> [page]: <http://cbfalconer.home.att.net>
> Try the download section.
--
CBFalconer
> CBFalconer wrote:
>
>> 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
Turbo totally fails to supply critical things such as the i/o
subsystem. This includes f^, which is a pointer to the last input
(or output) to file f, the put/get functions, which control those
transfers, etc. This completely fouls up normal Pascal i/o, which
is very capable of handling look ahead. Other limitations/faults
include the handling of numerical input, which insist on
termination with a <return> (I believe), rather than simply halting
at the first non-fitting char, which remains in f^.
You can partially tame Turbo with my txtfiles.zip unit, which is
available at:
<http://cbfalconer.home.att.net/download/txtfiles.zip>
but there was no excuse for this failure when they rebuilt Turbo
(for Turbo IV).
Jan Panteltje
<f...@frank-buss.de> wrote in <1hb52cut9l5ov$.1c9dhsai...@40tude.net>:
>Jan Panteltje wrote:
>
>> 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.
>
>I hope you don't use something like BIND?
Yes I am using bind, and the very latest too.
There is an issue with source port randomness, and transaction id randomness,
you can test it here (press on 'Test My DNS'):
https://www.dns-oarc.net/oarc/services/dnsentropy
When behind some NAT translation tables, like from a router, the port randomness
will be destroyed however.
>The last time I installed a
>nameserver and SMTP-server on a Linux system, I installed it in separate
>chroot-jails.
Well, OK, but the latest attacks are about something like poisoning the database.
>Nowadays my hoster provides these services
I A AM SO GLAD I DO NOT HAVE AN ISP, THEY ALL SUCKED.
>and I'm using only
>lighttpd for my webserver, which is small, clean, more secure and faster
>than Apache.
mmm, Apache does a good job so far here.
>If you really like to do all by yourself, there are nice features in
>iptables, if you are using Linux.
Yes of course I use IP tables, just passed the 1000 entries :-)
Imagine 1000 bad guys.
>> 6502, now that is long ago....
>
>Yes, looks like I'm getting old :-) Today most people think it is cool to
>write PHP or Visual Basic programs, if they are interested in programming
>at all, but only a few people know the basics, or even like it.
Once in a moment of confusion I bought a book on Visual Basic, thinking
it would expand my programming knowledge..
'Visual Basic 6.0', a thick book... I learned nothing from it,
not even how to write anything in VB...
Waste of money and time, it seems nothing it can do that I cannot do better and faster
in C using existing libs in Linux.
BASIC was OK, though, started on a Commodore PET, later a Timex Sinclair ZX80...
But then z80 asm was much more fun.. and the rest follows.
As for php, I use it on the website, it is useful.
In the end maybe 'which language' is not that important, I mean
*if* you can formulate the problem correctly, then you can write the program,
you have in fact the solution.
But you can do it as inefficient as you like of course :-)
Frank Buss
> Yes I am using bind, and the very latest too.
I wouldn't trust a program with such a bad security history (
http://www.isc.org/index.pl?/sw/bind/bind-security.php ). There are good
nameservers, which are more secure. E.g. the author of djbdns gives $1000
for the first person, who finds a security hole:
http://cr.yp.to/djbdns/guarantee.html
I didn't test it, because I used a simpler program last time I installed a
nameserver (didn't remember the name), because I don't need all the
complexity of BIND-like programs. But looks like djbdns is a good program.
It is even not vulnerable to the DNS poisoning exploit:
http://cr.yp.to/djbdns/blurb.html
> I A AM SO GLAD I DO NOT HAVE AN ISP, THEY ALL SUCKED.
I'm glad that I don't have to maintain the infrastructure and constantly
monitoring security issues, appplying patches etc. Nameserver and eMail
just works. It is not the cheapest, but my ISP has more than 2 million
paying customers, so there is a good chance that problems are fixed fast.
> In the end maybe 'which language' is not that important, I mean
> *if* you can formulate the problem correctly, then you can write the program,
> you have in fact the solution.
This depends on where you use the language. I don't write bug-free
programs, so I would feel uncomfortable to write a web application in C,
because it could have buffer overflows or crashs the whole webserver
program. If I write it in Java, I just get a nice exception trace in a log
file, but the rest of the server program continues to work and low-level
bugs like buffer overflows are impossible in Java (as long as you don't use
native parts of the system, like JPEG decoding).
Jan Panteltje
<f...@frank-buss.de> wrote in <dmkn0pnxg3fr$.10r1ask5...@40tude.net>:
>Jan Panteltje wrote:
>
>> Yes I am using bind, and the very latest too.
>
>I wouldn't trust a program with such a bad security history (
>http://www.isc.org/index.pl?/sw/bind/bind-security.php ). There are good
>nameservers, which are more secure. E.g. the author of djbdns gives $1000
>for the first person, who finds a security hole:
>
>http://cr.yp.to/djbdns/guarantee.html
Yes I know, and have, that program.
I find it a bit complicated and as long as bind works OK see no need to change.
>I didn't test it, because I used a simpler program last time I installed a
>nameserver (didn't remember the name), because I don't need all the
>complexity of BIND-like programs. But looks like djbdns is a good program.
>It is even not vulnerable to the DNS poisoning exploit:
>
>http://cr.yp.to/djbdns/blurb.html
I wrote a small name server myself, for the backup web server that runs from an SDcard
in a Linksys wireless access point:
http://panteltje.com/panteltje/wap54g/index.html#wapserver
As that name server is not finished (and perhaps never will) I am not releasing it and its source,
also to protect myself against evil forces wanting to see where all the weak spots are.
Now that runs the simplest web server you can imagine.
Asking for a login keeps most of the bots out.
>> I A AM SO GLAD I DO NOT HAVE AN ISP, THEY ALL SUCKED.
>
>I'm glad that I don't have to maintain the infrastructure and constantly
>monitoring security issues, appplying patches etc. Nameserver and eMail
>just works. It is not the cheapest, but my ISP has more than 2 million
>paying customers, so there is a good chance that problems are fixed fast.
Well, some have 1 euro / minute help desks, and then once you get a line have to explain to THEM what
they need to fix....
I tried more then 7 ISPs, now I have 'direct-adsl', faster, cheaper, better.
>> In the end maybe 'which language' is not that important, I mean
>> *if* you can formulate the problem correctly, then you can write the program,
>> you have in fact the solution.
>
>This depends on where you use the language. I don't write bug-free
>programs, so I would feel uncomfortable to write a web application in C,
>because it could have buffer overflows or crash the whole web server
>program. If I write it in Java, I just get a nice exception trace in a log
>file, but the rest of the server program continues to work and low-level
>bugs like buffer overflows are impossible in Java (as long as you don't use
>native parts of the system, like JPEG decoding).
I have a bit different philosophy about all this.
These days it seems like the following tactics are used:
A lock on every door in the house with 2 keys to open it, and an open front door.
I do prefer a good fence with a good lock, and doors and windows in the house that
you just can open without locks.
No, I do not always check for buffer overflow [exploits], for example this news reader
will likely crash if some overflow is deliberately created.
So what.
I do not know a lot about Java, in fact all I know is that it is slow, does not have pointers,
that makes it not interesting for me.
Now Java-people claim it is not slow, but some also claim the world is flat.
My view is that people who attack the internet, and its applications, an internet that
is used by much of humanity, and many things that are becoming more and more essential
to us are based on it, should get the death penalty.
Now that will help.
And that also goes for those self serving people who publish new attacks every so often,
like Kaspersky & friends, lock am up and execute them.
It is just their ego and business, the virus writers are THEY, and lots of little script kiddies
use their ideas and tools to create havoc.
Bit extreme POV I have, but alas, it is that way.
Grant Edwards
>>Nowadays my hoster provides these services
>
> I A AM SO GLAD I DO NOT HAVE AN ISP, THEY ALL SUCKED.
If you don't have an ISP, how to get packets to/from the
Internet?
--
Grant
Nico Coesel
>Nico Coesel wrote:
>> CBFalconer <cbfal...@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. 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++.
>
>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.
Turbo -several versions- and Delphi -several versions. Programming
Pascal seems like walking in mud. Too many constraints. Can't do this,
can't do that.
Jan Panteltje
<gra...@visi.com> wrote in
<crOdnZTMzMNeVXXV...@posted.usinternet>:
We have a special thing here, it is called 'direct-adsl',
basically the telco gives you a direct line.
It is cheaper then via ISP too.
But no servers, no email server, no web server, no whatever else
ISPs do..., no news server, but a fixed IP address.
So I bought a domain, installed smtp, named, apache, proftpd, lots
of other cool stuff, and pointed the domain to my IP address.
And since then I have been online with this since 2004 without a problem.
I can, from the notebook, ssh to my system from anywhere in the world,
control the heating, house electronics, even grab satellite TV if
the connection is fast enough (it can be compressed).
Also use the notebook as portable TV around the house via WiFi..
PC as media centre worldwide, MS is still dreaming about it...
All runs Linux here of course.
Anthony Fremont
> In article <0b4a9ce0-c18f-44ab-b418-3c9f169519c1
> @m45g2000hsb.googlegroups.com>, zwsd...@gmail.com says...
>> A rabid
>> wombat in a bell jar full of crack smoke could not have designed a
>> less-pleasant ISA than PIC.
>
> Funniest thing I've read in a long time. And laser accurate. :-P
I really don't get all the PIC hatred. I've played around with quite a few
different micros starting with the 1802. Every micro that I've used has its
own set of crappy handicaps; PICs by no means have the market cornered on
this. By far the best design I've ever worked with is the ARM.
Wilco Dijkstra
"MooseFET" <kens...@rahul.net> wrote in message
news:79fa4ff7-433e-4a42...@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?
>
> 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.
> 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 software
reliability. Most bugs are due to incorrect specification or implementation,
not due to accessing null pointers etc.
> 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.
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.
Wilco
Vladimir Vassilevsky
Wilco Dijkstra wrote:
> Experienced programmers don't need to be restricted by a language in order
> to write safe and reliable software.
Yes, of course. But the real problem is where to get many experienced
programmers for cheap.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Jim Thompson
India ?:-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
Vote Barack... Help Make America an Obama-nation
Anthony Fremont
> On Sun, 05 Oct 2008 10:40:45 -0500, Vladimir Vassilevsky
> <antispa...@hotmail.com> wrote:
>
>>
>>
>> Wilco Dijkstra wrote:
>>
>>> Experienced programmers don't need to be restricted by a language
>>> in order to write safe and reliable software.
>>
>> Yes, of course. But the real problem is where to get many experienced
>> programmers for cheap.
>>
>>
>> Vladimir Vassilevsky
>> DSP and Mixed Signal Design Consultant
>> http://www.abvolt.com
>
> India ?:-)
It's the classic "you can have two out of any three". With India you can
have many and cheap, not experienced. If you want experienced (using this
word as a substitute for capable) and many, look towards the many that were
left unemployed by outsourcing in the US, but they won't be cheap. Cheap
and experienced are mutually exclusive as you can clearly see. ;-)
Wilco Dijkstra
"Jim Thompson" <To-Email-Use-Th...@My-Web-Site.com> wrote in message
news:p7ohe45ki4pcq5jgb...@4ax.com...
>
> On Sun, 05 Oct 2008 10:40:45 -0500, Vladimir Vassilevsky
> <antispa...@hotmail.com> wrote:
>
>>
>>
>>Wilco Dijkstra wrote:
>>
>>> Experienced programmers don't need to be restricted by a language in order
>>> to write safe and reliable software.
>>
>>Yes, of course. But the real problem is where to get many experienced
>>programmers for cheap.
Indeed. But would you rather use several inexperienced programmers rather than
a few more experienced ones? In the long term the experienced ones are likely less
expensive.
> India ?:-)
Probably not for long, as salaries have increased. Companies are already starting to
look elsewhere.
Wilco
Jim Thompson
And "many" doesn't guarantee functional.
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
It's what you learn, after you know it all, that counts.
Vladimir Vassilevsky
Wilco Dijkstra wrote:
>>On Sun, 05 Oct 2008 10:40:45 -0500, Vladimir Vassilevsky
>><antispa...@hotmail.com> wrote:
>>>Wilco Dijkstra wrote:
>>>
>>>>Experienced programmers don't need to be restricted by a language in order
>>>>to write safe and reliable software.
>>>
>>>Yes, of course. But the real problem is where to get many experienced
>>>programmers for cheap.
>
>
> Indeed. But would you rather use several inexperienced programmers rather than
> a few more experienced ones? In the long term the experienced ones are likely less
> expensive.
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. There are the tasks for
professionals, too; however the main stream (where the money goes) is
handled by the hordes. So the goal of a modern programming language is
making the programming a blue collar job; the less is the possibility to
screw the things up, the better.
Alex Colvin
>>>>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.
And there's a long history of succesful projects carried out by crowds of
expendable and interchangeable conscripts to prove it ;-)
--
mac the naïf
Nico Coesel
The problem with PIC is that people who know PIC don't (want to) know
anything else. If you only have a hammer, then everything looks like a
nail. If someone suggests to use more than 1 PIC in a design instead
of a real microcontroller get rid of him/her. That's the first sign of
trouble!
linnix
> "Jim Granville" <no.s...@designtools.maps.co.nz> skrev i meddelandetnews:48e68e7c$1...@clear.net.nz...
>
> > 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.
>
> 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...
The 16K ROM uC we are considering is 25,000 minimum order. The cost
is low enough that even if we throw away half of them, it is still
cheaper than OTP and much cheaper than flash.
RumpelStiltSkin
"linnix" <m...@linnix.info-for.us> wrote in message
news:3567f7cb-c498-4c77...@r15g2000prh.googlegroups.com...
> Didn't see my earlier post. Perhaps memory erased.
>
> 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.
>
> under direct sun-light. They sometimes lose their memories.
Please explain. Makes no sense. Flash has no "erase" window.
>> 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.
RumpelStiltSkin
"Anthony Fremont" <nob...@noplace.net> wrote in message
news:fP-dnfvaLsAmRHXV...@supernews.com...
I hate PICs, but one thing you got to admit is that they have
much better support than any other micro. That is why they are successful.
larwe
wrote:
> Many say flash is the only path, but others offer Flash and 'ROM/OTP'.
At some point, it doesn't make any sense to optimize any more.
For example, I had a design containing a very expensive,
"ROM" (actually vendor-programmed OTP EPROM, I believe) micro, and I
had to cost it down. Let's say the old micro costs $3. I look at all
the preferred vendors and I get the following absolute best prices.
Either of these parts will fit the bill as far as the other
peripherals go:
- For an 8K ROM part with 512b RAM and no EEPROM, $0.84 + $7500 NRE.
Leadtime on first piece sample 8 weeks, leadtime on a code change once
production ramps up is 24 weeks. I can't qualify the RF performance of
my app on real silicon. If I need to change something (e.g. I find a
weird harmonic and need to change the base clock frequency, thereby
requiring code changes), I need to wait another 8 weeks to know if it
works.
- For a 16K FLASH part with 2K RAM and 1K EEPROM, $0.85 + no NRE.
Leadtime on first piece samples is 24 hours. Leadtime on 100Ku
production quantity is 6 weeks. Leadtime on code changes is 0 because
we can IAP new code. Plus I can develop and qualify with the
production part; I can shift those frequency spurs around however I
need to avoid the carrier and IF danger zones in my circuit.
Why would I buy into all this risk and problem quicksand for a penny a
unit, even at 250K units/year? And in this specific example, the ROM
part has gone up to $0.90 while the flash part has fallen to $0.83.
larwe
> Small PICs, like the 8 bit, are ment to be programmed is asm.
> Sure, many grab, for reasons unknown to me, but
If you're talking one of the truly miniscule devices like the 8-pin 1K
parts used for PlayStation modchips and so forth - yes, an asm
program, get in quickly, get out quickly.
But the braindead PIC architectural features are alive and well in
devices up to 64K or even more. For my money, code volumes in excess
of a few kilobytes are much easier to maintain, outsource and
technology-transfer if they're in an HLL.
Once you get up to dsPIC, then yes you have a reasonable architecture.
But dsPIC is not PIC.
ANY architecture with banked memory is simply not meant to be
programmed in any language. There is absolutely no reason for it in
this day and age.
Jim Granville
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.
Some companies are still releasing what they call ROM parts, along with
flash.
An example, from Korea : Wide family of nice 80C51's with first
OTP/'ROM', and now Flash/'ROM'
http://www.coreriver.co.kr/product-lines/top_corerivermcu.html
I suspect they are not classic ROM (ie not actually two metal custom
mask) for the reasons you mention above, but they may be 'Flow optimised
flash', with an Erase-kill fuse.
That approach does make sense.
-jg
Frank Buss
> This is an interesting area.
> Many say flash is the only path, but others offer Flash and 'ROM/OTP'.
I think one reason is that ROM is more reliable. Lifetime of Flash is much
smaller, if working at high temperature. And for high radiation
environments and where you can't replace chips, like in space, the lifetime
is important. A nice alternative solution is MRAM, if the price is not so
important:
http://www.nsti.org/press/PRshow.html?id=2964
Uwe Bonnes
> 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 ----------
MooseFET
<Wilco.removethisDijks...@ntlworld.com> wrote:
> "MooseFET" <kensm...@rahul.net> wrote in message
>
> news:79fa4ff7-433e-4a42...@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 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.
>
> > 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.
>
> 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 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.
>
> > 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 language will return, but Ada is available.
ADA is 3 of everyones favorite languages.
Jan Panteltje
<kens...@rahul.net> wrote in
<7f52e7c8-42c8-4c6f...@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.
Jan Panteltje
<kens...@rahul.net> wrote in
<b424f430-b267-416a...@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.
krw
> >>>>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
Eeyore
Jan Panteltje wrote:
Reminds me of formatting hard drives using debug. g = c8000 wasn't it ?
Graham
linnix
> "linnix" <m...@linnix.info-for.us> wrote in message
>
> news:3567f7cb-c498-4c77...@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.
Jamie
linnix
16K ROM LCD uC for $0.20 @25Ku, NRE $3000. So $0.31@25Ku, $0.26@50Ku
and $0.23@100Ku.
Anthony Fremont
g=c800:5
Jim Granville
> On Oct 5, 11:59 am, "RumpelStiltSkin" <fables...@abc.gov> wrote:
>
>>"linnix" <m...@linnix.info-for.us> wrote in message
>>>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.
So this is a plastic packaged device, but exposed top-up to direct
sunlight. What application operates like that ?
What temperatures do they reach ?
I recall intel threw a lot of R&D funds looking for a type of plastic
that would allow them to erase EPROMS, (save the expensive
ceramic+window) - don't think they actually cracked it (or maybe flash
just took over anyway)
I do like the asian approach to legacy EPROM: - they use MTP flash,
EPROM pinout, plastic package, and a high Vpp to erase.
Flash flows, but 100% retrofit into a 27C512 design.
>>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.
Which specific devices have that price footprint ? - none I am using
price like that. I HAVE had flash quotes down to 25c.
-jg
Jim Granville
> On Oct 5, 1:26 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>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.
That is cheap - that's just $8K order line!.
- was that your own device tho (so is really foundry costs)
On this type of device, ROM can also mean lower Vcc(min) and
lower operating Icc.
The 25c Flash I had, was a 1KF/128EE/32R device, targeting
remote controls (so nearly brain-dead)
-jg
linnix
wrote:
> linnix wrote:
> > On Oct 5, 1:26 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> >>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.
>
> 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
> "MooseFET" <kens...@rahul.net> wrote in message
>> 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?
>>>
>>> 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.
>>
>> before the program is even compiled.
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.
>
>> 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
> 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.
>
>> 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.
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?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer
> al...@TheWorld.com says...
>
... snip ...
>
>> 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".
Well, now we know your definition of 'successful'.
Ben Bradley
On Sun, 5 Oct 2008 14:34:07 -0700 (PDT), MooseFET <kens...@rahul.net>
wrote:
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
"CBFalconer" <cbfal...@yahoo.com> wrote in message news:48E95EDA...@yahoo.com...
> Wilco Dijkstra wrote:
>> "MooseFET" <kens...@rahul.net> wrote in message
>>> 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.
>
> 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.
>> 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.
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.
>>> 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
>> 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.
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 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?
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
On Oct 5, 8:27 am, "Wilco Dijkstra"
<Wilco.removethisDijks...@ntlworld.com> wrote:
> "MooseFET" <kensm...@rahul.net> wrote in message
>
> news:79fa4ff7-433e-4a42...@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.
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...
> > 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 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.
> > 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.
>
> 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