Looking for Microcontroller Recommendations

On Fri, 15 Jan 2010 11:43:22 +0100, Falk Willberg
<Faweglassenlk@falk-willberg.de> wrote:

Joel Koltner schrieb:
"Falk Willberg" <Faweglassenlk@falk-willberg.de> wrote in message
news:hio3ac$hll$1@news2.open-news-network.org...
PS: An almost free AVR-Development board is described here:
http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html

Nice idea, I like it!

Pharmaceutical company give them away including a few test strips. The
test strips are 50 Eurocent to 1 EUR each.

Some people sell the devices on ebay: 360224657755

Falk
In the US, ebay folks seem to be asking a fair amount more
than that -- shipping probably adding still more profit. Too
bad.

Jon
 
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Fri, 15 Jan 2010 03:35:11 -0800) it happened John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
n9k0l59pcncno9800o9c9h6n6ee9cnoh4s@4ax.com>:

The future seems to be the ARM architecture.

John

I bought a book on ARM in the eighties? I was also the future then ;-)
But somehow x86 grabbed it.

x86 has - for now - won on the desktop, but there are around 100
embedded uPs for every PC, and the embedded chips aren't x86. Some
netbooks are ARM+Linux, and that may be an increasing trend.

There's no justification for putting a hundred dollars (or more) worth
of power-hogging x86 CPU into a web browser or a cell phone. Some of
the low-end ARM chips cost well under a dollar now, and there is some
awesome stuff for $5 or so.

I'm sorta hoping that Intel will be the next DEC, except that I miss
DEC.

John

I dunno, the ARM netbooks had a lot of trouble few month ago running some
applications (in Linux), I think some applications still use extensive asm,
a simple example present on all those netbooks is the mpeg2 / H264 / mpeg4 ... long list... drivers.
That would all have to be re-written for 'RISC' architecture is asm, and as you probably know
x86 has many many special instructions specifically for multimedia,
Nope. Those drivers are already included in every major OS for ARM.
See below.

So, mmx, 3dnow, give the x86 an incredible speed advantage over ARM, as ARM will have to to a zillion asm instructions
for every high level x86 instruction.
It is possible (I did not keep up after that book in the eighties) that ARM also added some special multimedia
capabilities, but then again there is the overhead of re-encoding.
So I do not expect ARM to make big inroads into personal computing and especially multimedia soon.
Why do you think Apple left their old architecture for ix86? Multimedia likely!
That's where you're wrong. The ARM system-on-chips all have mpeg
accellerators. Just look closely to your CPU usage while playing an
mpeg movie. I have a pretty fast Intel based PC but it can't decode a
1080p movie. I need a video card with a mpeg accellerator to play such
movies.

You really should catch up with ARM. There is a lot of exciting stuff
going on. From the ultra low power small '16 bit' LPC1100 series by
NXP to the Cortex A8/A9 stuff from TI, Freescale and Samsung.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
MooseFET <kensmith@rahul.net> wrote:

On Jan 15, 3:35=A0am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Thu, 14 Jan 2010 23:38:45 GMT, Jan Panteltje



pNaonStpealm...@yahoo.com> wrote:
On a sunny day (Thu, 14 Jan 2010 14:39:11 -0800) it happened John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote in
777vk5tsp8r9616jnjcoaemmve2tc9j...@4ax.com>:

On Wed, 13 Jan 2010 20:22:56 -0600, "RogerN" <re...@midwest.net
wrote:

Years back I played some with PIC microcontrollers but I've heard that
manufacturers are making better microcontrollers for less money.

Not looking for professional ICE or anything but maybe something compe=
titive
with Microchips in circuit programmer/debugger. =A0I was considering b=
uying
Microchips ICD3 with PICDEM 2 board for $230, but thought maybe someth=
ing
would be a better choice. =A0I'm considering Atmels line but wanted so=
me input
on others worth checking into.

Any recommendations on favorite microcontrollers that I can get up an
running with for a reasonable amount of dollars?

Thanks!

RogerN

The future seems to be the ARM architecture.

John

I bought a book on ARM in the eighties? I was also the future then ;-)
But somehow x86 grabbed it.

x86 has - for now - won on the desktop, but there are around 100
embedded uPs for every PC, and the embedded chips aren't x86. Some
netbooks are ARM+Linux, and that may be an increasing trend.

There's no justification for putting a hundred dollars (or more) worth
of power-hogging x86 CPU into a web browser or a cell phone. Some of
the low-end ARM chips cost well under a dollar now, and there is some
awesome stuff for $5 or so.

I'm sorta hoping that Intel will be the next DEC, except that I miss
DEC.

As I have pointed out before the 8051 in fact out performed the 8088
on many operations.

A simple 32 bit Arm like processor would be just about the ideal
processor
for viewing web pages and working on documents etc. It can address
enough
memory and fling bytes around efficiently. For viewing a video a
little
hardware help could make it ok for that job. When something like
LTspice
is being run, a little more is needed:

Programs like LTspice need to be able to do long floating point
operations
and move the floats to and from memory quickly. For this it seems
that
having a second processor that does this would be the way to go. The
That is exactly why almost every ARM based system on chip has a
floating point unit.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On a sunny day (Fri, 15 Jan 2010 21:14:55 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b50d744.516134265@news.planet.nl>:

That's where you're wrong. The ARM system-on-chips all have mpeg
accellerators. Just look closely to your CPU usage while playing an
mpeg movie. I have a pretty fast Intel based PC but it can't decode a
1080p movie. I need a video card with a mpeg accellerator to play such
movies.
So, even if they do, the trend is indeed towards integrating the graphics controller with the CPU,
either in the same housing or on the same silicon.
The latest Intel Atoms do this, and AMD knows about it too.
Why then would you release a netbook where none of the current x86 software binaries run?
Everything needs to be recompiled, and all codecs have to be re-written.
For ***what*** gain? ARM is not _really_ using that less power.
I would never buy one, too much incompatibility.
And vendors of such high speed media applications really are not longing to write yet an other driver or codec in asm either.
Not even for Linux, and most certainly not for just a few ARM based notebooks.
And MS windows would likely not run on it either, unless they wrote in 7 in C....
All it's applications are closed source binaries, so forget that market!


You really should catch up with ARM. There is a lot of exciting stuff
going on. From the ultra low power small '16 bit' LPC1100 series by
NXP to the Cortex A8/A9 stuff from TI, Freescale and Samsung.
Well, a simple x86 motherboard will do for now, if it has a par port, then you can even test 2x40 character LCDs with it :)


Failure does not prove something is impossible,
failure simply
indicates you are not using the right tools...
Right I just ripped the pins of a W3100A, I know I should not have tried to bend those back
and get some solder wick, but alas, I was out of solder wick sooo.
hehe
 
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Fri, 15 Jan 2010 21:14:55 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b50d744.516134265@news.planet.nl>:

That's where you're wrong. The ARM system-on-chips all have mpeg
accellerators. Just look closely to your CPU usage while playing an
mpeg movie. I have a pretty fast Intel based PC but it can't decode a
1080p movie. I need a video card with a mpeg accellerator to play such
movies.

So, even if they do, the trend is indeed towards integrating the graphics controller with the CPU,
either in the same housing or on the same silicon.
The latest Intel Atoms do this, and AMD knows about it too.
Why then would you release a netbook where none of the current x86 software binaries run?
This sounds a bit strange from a Linux user. Ever installed Debian on
an SGI Indy? Its the same as installing it on a PC. Thats the beauty
of Linux. It just runs on almost anything. Netbooks included.

Everything needs to be recompiled, and all codecs have to be re-written.
Nope. That work is already done. You should get your facts right
before commenting. I'm using Linux almost daily a non x86 embedded
platform so I do have some real experience in that field.

A x86 platform is still very inefficient. We looked into the Intel
Atom and a Cortex A8 devices for a new embedded platform. The Atom
just isn't suitable for real low power and small size due to the
chipset. Also the price versus performance isn't that good compared to
Cortex. Together with the commonly found hardware openGL and hardware
video codecs (not included in the Atom!) a Cortex device has some
serious muscle.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Thu, 14 Jan 2010 23:38:45 +0000, Jan Panteltje wrote:

I bought a book on ARM in the eighties? I was also the future then ;-)
But somehow x86 grabbed it.
I'm fairly sure that there are more ARMs in use than x86's. Practically
evey mobile phone has one, the Nintendo DS has two, iPods have one or two,
and they're also common in other high-end embedded systems (e.g. GPS
navigation) and in low-end computer networking devices (routers, NAS,
etc).

The x86 probably wins in terms of total revenue, though.
 
On Fri, 15 Jan 2010 13:12:39 +0000, Jan Panteltje wrote:

I dunno, the ARM netbooks had a lot of trouble few month ago running some
applications (in Linux), I think some applications still use extensive asm,
a simple example present on all those netbooks is the mpeg2 / H264 /
mpeg4 ... long list... drivers. That would all have to be re-written for
'RISC' architecture is asm, and as you probably know x86 has many many
special instructions specifically for multimedia,
If you need raw processing power, the x86 is likely to win. I'd expect it
to, given that it's one or two orders of magnitude more expensive.

An ARM-based system which deals with TV-resolution (or better) video
would typically use a dedicated decoder. I certainly wouldn't try to do
1080p h.264 decoding with an ARM; a 3GHz P4 can barely handle it. OTOH,
QVGA-resolution XviD (i.e. watching YouTube on a mobile phone) isn't a
problem.

For embedded applications, not only is an x86 and a software decoder
a ridiculously expensive solution, you'd be lucky to finish a 25-minute
episode before the battery is flat.

Very few Linux applications use assembler. A handful of libraries use
assembler where available, invariably with a C fallback. Even the kernel
is only around 3.5% assembler.
 
Thanks for all the fantastic recommendations! It seems like for many of the
microcontrollers it doesn't cost much to get going at a hobby level. I
ordered a PIC18 something starter kit that comes with a PICkit2
programmer/debugger and I ordered a PICkit3 Debug Express.
I also have an Atmel STK500 starter kit that I bought around 10 years ago
and have hardly used. I downloaded Arduino software and GNU C compiler for
the AVRs.
I plan to look into the other stuff that I'm not familiar with but sounds
interesting, such as the Texas Instruments, Silabs, Arm, etc.

At work some of our electricians hacked into alarm clocks to automatically
start their car a few minutes before the end of their shift. They have the
Bulldog security remote starter and said it has an input you can use to
start your car, where we work is too far from the parking lot to use the
remote. That would be a nice microcontroller project, use a temperature
sensor and RTCC, if it's freezing out, start the car so many minutes before
the end of shift, the colder it is, the more warm up time is allowed.

I'm wanting to make some intelligent I/O and operator interface products
that would be compatible with the Basic Stamp but would have a ICSP plug and
perhaps a bootloader so these could be reprogrammed for anything else the
end user wanted. Of course the products being compatible with the Basic
Stamp would work with other microcontrollers and could even be controlled
from a PC.

Thanks again!

RogerN
 
"RogerN" <regor@midwest.net> wrote:

Thanks for all the fantastic recommendations! It seems like for many of the
microcontrollers it doesn't cost much to get going at a hobby level. I
ordered a PIC18 something starter kit that comes with a PICkit2
programmer/debugger and I ordered a PICkit3 Debug Express.
But be advised: as soon as you think 'I need 2 PICs for this project'
it is time to dump the PIC and learn to use a completely different
microcontroller. For more complicated projects using a PIC is like
eating soup with chopsticks. PIC gets you started real fast but it
also runs out of air real fast.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On a sunny day (Sat, 16 Jan 2010 08:35:19 +0000) it happened Nobody
<nobody@nowhere.com> wrote in <pan.2010.01.16.08.35.18.250000@nowhere.com>:

On Thu, 14 Jan 2010 23:38:45 +0000, Jan Panteltje wrote:

I bought a book on ARM in the eighties? I was also the future then ;-)
But somehow x86 grabbed it.

I'm fairly sure that there are more ARMs in use than x86's. Practically
evey mobile phone has one, the Nintendo DS has two, iPods have one or two,
and they're also common in other high-end embedded systems (e.g. GPS
navigation) and in low-end computer networking devices (routers, NAS,
etc).

The x86 probably wins in terms of total revenue, though.
I dunno my Linksys router run a Broadcom MIPS.
No idea what is in my cellphones.
I counted more then 20 micros in this room alone, let's see:

1 PC x86
2 notebook: Intel x86
3 CB transceiver Hitachi
4,5 SWR box: 2 x PIC
6 Digital camera Canon : no idea
7 Digital camera Mustek: no idea
8,9 2 x webcam Logitech: no Idea, could even be ASICs.
10 Soldering iron: I think PIC, but not sure
11 IP camera: x86 clone
12 WAP: Broadcom MIPS.
13 PC keyboard: some micro, the old PC one had a 8051, could be anything
14 LED light controller PIC
15 Temp controller: 8052AH
16 temperature sensor PIC
17 DLS modem, no idea
18 Seagate external harddisk, no idea
19, 20 2x DVB-T settop box, forgotten what processor no idea

There is one ARM processor in the SkyStar 1 sat TV PCI card, but that cars is no operational anymore.
And a box full of various PICs...
I am sure I forgot some.
21 Oh, mouse: no idea, no ARM, likely PIC
22 DVD player, could be a processor or some ASIC, dunno
The list goes on, so, ARM rules? I think not.

It is amazing how many processors are around us these days though.
Oops, I forgot the cellphones, now that could be ARM.
That makes 26 then.
Oops, forgot the LCD monitor, 27
and the beat goes on...
Portable CD player 28
Portable mp3 player 29
Lightning detector 30!

I made 30, but still counting.
How many do you have in the room you are in?
Let's have a contest, no cheating, not moving to the lab or so :)
 
On a sunny day (Fri, 15 Jan 2010 23:56:57 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b50f822.524548343@news.planet.nl>:

Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Fri, 15 Jan 2010 21:14:55 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b50d744.516134265@news.planet.nl>:

That's where you're wrong. The ARM system-on-chips all have mpeg
accellerators. Just look closely to your CPU usage while playing an
mpeg movie. I have a pretty fast Intel based PC but it can't decode a
1080p movie. I need a video card with a mpeg accellerator to play such
movies.

So, even if they do, the trend is indeed towards integrating the graphics controller with the CPU,
either in the same housing or on the same silicon.
The latest Intel Atoms do this, and AMD knows about it too.
Why then would you release a netbook where none of the current x86 software binaries run?

This sounds a bit strange from a Linux user. Ever installed Debian on
an SGI Indy? Its the same as installing it on a PC. Thats the beauty
of Linux. It just runs on almost anything. Netbooks included.
I have Linux on a Broadcom MIPS, cross compiled from the PC.
It will *not* run LTSPice in Wine see?
And you have to re-compile *every* application.


Everything needs to be recompiled, and all codecs have to be re-written.

Nope. That work is already done. You should get your facts right
before commenting. I'm using Linux almost daily a non x86 embedded
platform so I do have some real experience in that field.
So do I, but this was about netbooks, not about some system you have the sources for.
Let's face it ARM sucks :)
ix86 is soooooooooooooooo much better :)


A x86 platform is still very inefficient. We looked into the Intel
Atom and a Cortex A8 devices for a new embedded platform. The Atom
just isn't suitable for real low power and small size due to the
chipset. Also the price versus performance isn't that good compared to
Cortex. Together with the commonly found hardware openGL and hardware
video codecs (not included in the Atom!) a Cortex device has some
serious muscle.
I am sure there is some nice for an ARM here or there, 'embedded' takes a whole different meaning these days.
If it needs a user interface why not buy an netbook and simply stick your I/O extension in a USB port.
That gives you WiFi, Ethernet, serial via adaptor, display, keyboard, of the shelf, in 10 minutes to speed to a PC shop.
then you only need to design the USB I/O box.
This is what I do, and so much less worry.

X86 not efficient? You must be joking, the new netbooks run 8 hours on a battery charge.

Na x86 is the future, it has proven itself, after all we all want to run LTSpice on the Linux cellphone in Wine.
hehe


--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
You should have use a x86!
 
On a sunny day (Sat, 16 Jan 2010 08:56:49 +0000) it happened Nobody
<nobody@nowhere.com> wrote in <pan.2010.01.16.08.56.49.15000@nowhere.com>:

On Fri, 15 Jan 2010 13:12:39 +0000, Jan Panteltje wrote:

I dunno, the ARM netbooks had a lot of trouble few month ago running some
applications (in Linux), I think some applications still use extensive asm,
a simple example present on all those netbooks is the mpeg2 / H264 /
mpeg4 ... long list... drivers. That would all have to be re-written for
'RISC' architecture is asm, and as you probably know x86 has many many
special instructions specifically for multimedia,

If you need raw processing power, the x86 is likely to win. I'd expect it
to, given that it's one or two orders of magnitude more expensive.

An ARM-based system which deals with TV-resolution (or better) video
would typically use a dedicated decoder. I certainly wouldn't try to do
1080p h.264 decoding with an ARM; a 3GHz P4 can barely handle it. OTOH,
QVGA-resolution XviD (i.e. watching YouTube on a mobile phone) isn't a
problem.

For embedded applications, not only is an x86 and a software decoder
a ridiculously expensive solution, you'd be lucky to finish a 25-minute
episode before the battery is flat.

'embedded systems', that play full HD movies have a large screen or NEED a large screen.
That means they are big to begin with and you can then simply use a netbook or even standard mobo, or laptop.
Even my eeePC runs a 720x576 full length movie on a battery charge, when streaming it via Wifi too.
With time to spare.
If you are talking about some settop box, like the ones with ethernet in and HDMI out,
the ones that are more expensive then a netbook, and have a shitty 10 line or less character display,
I take the netbook anytime thank you.


Very few Linux applications use assembler.
Well, you know, you can compile ffmpeg to use C only,
you what happens? It slows to snail speed, CPU usage will go up to 100 %.



A handful of libraries use
assembler where available, invariably with a C fallback. Even the kernel
is only around 3.5% assembler.
 
On a sunny day (Sat, 16 Jan 2010 11:35:49 GMT) it happened
niks (Nico Coesel) wrote in <4b51a38c.568430625@news.planet.nl>:

But be advised: as soon as you think 'I need 2 PICs for this project'
it is time to dump the PIC and learn to use a completely different
microcontroller. For more complicated projects using a PIC is like
eating soup with chopsticks. PIC gets you started real fast but it
also runs out of air real fast.
You just have no clue about how to use those PIC micros.
You keep making that stupid remark over and over again,
while it is obvious to anyone familiar with PICs that
you can use as many as you want to do as many things as you want.
Here is a nice example of a project that uses 2 PICs for a start,
http://panteltje.com/panteltje/pic/swr_pic/index.html
And guess what, both are listening on the same RS232 line,
and one does the reply work and carries the help text.



--
Failure impossible, failure tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Keep dreaming.
 
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Fri, 15 Jan 2010 23:56:57 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b50f822.524548343@news.planet.nl>:

Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Fri, 15 Jan 2010 21:14:55 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b50d744.516134265@news.planet.nl>:

That's where you're wrong. The ARM system-on-chips all have mpeg
accellerators. Just look closely to your CPU usage while playing an
mpeg movie. I have a pretty fast Intel based PC but it can't decode a
1080p movie. I need a video card with a mpeg accellerator to play such
movies.

So, even if they do, the trend is indeed towards integrating the graphics controller with the CPU,
either in the same housing or on the same silicon.
The latest Intel Atoms do this, and AMD knows about it too.
Why then would you release a netbook where none of the current x86 software binaries run?

This sounds a bit strange from a Linux user. Ever installed Debian on
an SGI Indy? Its the same as installing it on a PC. Thats the beauty
of Linux. It just runs on almost anything. Netbooks included.

I have Linux on a Broadcom MIPS, cross compiled from the PC.
It will *not* run LTSPice in Wine see?
So, get another spice derivative which does compile/run on MIPS.

And you have to re-compile *every* application.
No, you don't have to recompile every application if you have enough
storage space to install a regular Linux distro. Flash drives are very
cheap these days. If you attach a flash or hard drive to your Broadcom
system then you can install a regular Linux distro on it.

If you have no storage space, then you'll have to resort to buildroot
or OpenEmbedded. But these basically strip all the unnecessary data
away from an application (like documentation). But that is getting a
thing of the past quickly. Even the use of small C libraries like
uClibc is getting obsolete.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Sat, 16 Jan 2010 11:35:49 GMT, the renowned nico@puntnl.niks (Nico
Coesel) wrote:

"RogerN" <regor@midwest.net> wrote:

Thanks for all the fantastic recommendations! It seems like for many of the
microcontrollers it doesn't cost much to get going at a hobby level. I
ordered a PIC18 something starter kit that comes with a PICkit2
programmer/debugger and I ordered a PICkit3 Debug Express.

But be advised: as soon as you think 'I need 2 PICs for this project'
it is time to dump the PIC and learn to use a completely different
microcontroller. For more complicated projects using a PIC is like
eating soup with chopsticks. PIC gets you started real fast but it
also runs out of air real fast.
What applications have you had to implement where a 40-80 MHz 32-bit
MIPS processor with 512M of flash is so woefully inadequate?


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
 
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

On a sunny day (Sat, 16 Jan 2010 11:35:49 GMT) it happened
niks (Nico Coesel) wrote in <4b51a38c.568430625@news.planet.nl>:

But be advised: as soon as you think 'I need 2 PICs for this project'
it is time to dump the PIC and learn to use a completely different
microcontroller. For more complicated projects using a PIC is like
eating soup with chopsticks. PIC gets you started real fast but it
also runs out of air real fast.

You just have no clue about how to use those PIC micros.
You keep making that stupid remark over and over again,
while it is obvious to anyone familiar with PICs that
you can use as many as you want to do as many things as you want.
Here is a nice example of a project that uses 2 PICs for a start,
http://panteltje.com/panteltje/pic/swr_pic/index.html
And guess what, both are listening on the same RS232 line,
and one does the reply work and carries the help text.
So you'll have to program 2 devices, keep 2 versions of software in
sync, place 2 devices, use more boardspace and have no way to move to
a different platform without rewriting from scratch if you have to.
Sounds like an excellent product I can redesign (I actually make a lot
of money doing such projects) to cut the product cost in half using an
ARM controller.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On a sunny day (Sat, 16 Jan 2010 15:53:57 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b51dc9b.583037562@news.planet.nl>:

I have Linux on a Broadcom MIPS, cross compiled from the PC.
It will *not* run LTSPice in Wine see?

So, get another spice derivative which does compile/run on MIPS.
Well, there are no better Spice then LTSpice


And you have to re-compile *every* application.

No, you don't have to recompile every application if you have enough
storage space to install a regular Linux distro. Flash drives are very
cheap these days. If you attach a flash or hard drive to your Broadcom
system then you can install a regular Linux distro on it.
You are WRONG.
Executable code that runs on a x86 will NOT run on a MIPS.
That is a very silly mistake you make here, I hope you do not design embedded.
I actually modified the Broadcom system so it HAS an external storage,
It runs a backup webserver.
http://panteltje.com/panteltje/wap54g/index.html#wapserver
Connect to it here:
http://81.207.135.196:82/index1.html
Even that needed cross compiling.

What do you think 'install a Linux distro' means anyways?
What code do you think the installer uses?
Where does it get the MIPS version of gcc?
Linux distros only install binaries, and the source is available optional.
If you want to run on an other platform then X86 then you need to compile *all* sources for that.

Man, such ignorance!





If you have no storage space, then you'll have to resort to buildroot
or OpenEmbedded. But these basically strip all the unnecessary data
away from an application (like documentation). But that is getting a
thing of the past quickly. Even the use of small C libraries like
uClibc is getting obsolete.
Nothing to do with it.
 
On a sunny day (Sat, 16 Jan 2010 16:06:28 GMT) it happened nico@puntnl.niks
(Nico Coesel) wrote in <4b51e214.584438953@news.planet.nl>:

Here is a nice example of a project that uses 2 PICs for a start,
http://panteltje.com/panteltje/pic/swr_pic/index.html
And guess what, both are listening on the same RS232 line,
and one does the reply work and carries the help text.

So you'll have to program 2 devices,
Yes, but the reason was actually not code space related but I/O pins.


keep 2 versions of software in
sync,
Now if that was the biggest problem, I have almost 1000 software versions out there,
this morning an other email about one with suggested code improvements.
Thats is how open source works, pfff 2 versions.... don't overwork yourself:)


place 2 devices,
So, 18 extra pins, I wonder how many I/O pins that ARM solution of yours has.


use more boardspace
Oh yes, that really is a worry if you have 1 cubic decimeter available...NOT.


and have no way to move to
a different platform
Why move? PICs last as long as the FLASH last, so does your ARM.



without rewriting from scratch if you have to.
Product lifetime... think about it.



Sounds like an excellent product I can redesign (I actually make a lot
of money doing such projects) to cut the product cost in half using an
ARM controller.
Well, if you design mama dolls that say 'Hello World', or 'I need to pee',
and they are reproduced in the millions, I guess you should consider PIC.
There is a single chip PIC solution that says 'I am mister Ed' on the web somewhere,
you can learn about PIC programming from it, I did.
In the movie I did see last night they had a doll that did say 'I love you'
when you pressed it, and 10 seconds later it would explode,
for that sort of design PIC is also a perfect solution.
Why bother with something as obscure as ARM?
I expect the big cellphone manufacturers to move to x86 too, it is so much
more appealing to the market if cellphones can run win 7..




--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
WTF do people use sigs, it is wasted bandwidth, says the same thing over and over again like an idiot,
and it is annoying to have to read it every time again to see it is crap.
 
On Sat, 16 Jan 2010 03:38:42 -0600, "RogerN" <regor@midwest.net>
wrote:

Thanks for all the fantastic recommendations! It seems like for many of the
microcontrollers it doesn't cost much to get going at a hobby level. I
ordered a PIC18 something starter kit that comes with a PICkit2
programmer/debugger and I ordered a PICkit3 Debug Express.
I also have an Atmel STK500 starter kit that I bought around 10 years ago
and have hardly used. I downloaded Arduino software and GNU C compiler for
the AVRs.
I plan to look into the other stuff that I'm not familiar with but sounds
interesting, such as the Texas Instruments, Silabs, Arm, etc.

At work some of our electricians hacked into alarm clocks to automatically
start their car a few minutes before the end of their shift. They have the
Bulldog security remote starter and said it has an input you can use to
start your car, where we work is too far from the parking lot to use the
remote. That would be a nice microcontroller project, use a temperature
sensor and RTCC, if it's freezing out, start the car so many minutes before
the end of shift, the colder it is, the more warm up time is allowed.
Be careful here. It's very easy to burn up a starter, wiring, or at
least kill a battery, when you least want a dead battery (BT). Even
professionally installed car starters cause enough problems to
invalidate car warranties. There is a *lot* to consider here. I
certainly wouldn't play with a car starter. I found it easier to move
to the South. ;-)

I'm wanting to make some intelligent I/O and operator interface products
that would be compatible with the Basic Stamp but would have a ICSP plug and
perhaps a bootloader so these could be reprogrammed for anything else the
end user wanted. Of course the products being compatible with the Basic
Stamp would work with other microcontrollers and could even be controlled
from a PC.

Thanks again!

RogerN
 
Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:

On Sat, 16 Jan 2010 11:35:49 GMT, the renowned nico@puntnl.niks (Nico
Coesel) wrote:

"RogerN" <regor@midwest.net> wrote:

Thanks for all the fantastic recommendations! It seems like for many of the
microcontrollers it doesn't cost much to get going at a hobby level. I
ordered a PIC18 something starter kit that comes with a PICkit2
programmer/debugger and I ordered a PICkit3 Debug Express.

But be advised: as soon as you think 'I need 2 PICs for this project'
it is time to dump the PIC and learn to use a completely different
microcontroller. For more complicated projects using a PIC is like
eating soup with chopsticks. PIC gets you started real fast but it
also runs out of air real fast.

What applications have you had to implement where a 40-80 MHz 32-bit
MIPS processor with 512M of flash is so woefully inadequate?
That is not a PIC. That is a PIC32! A whole different beast. If you
like your sanity, I wouldn't program those in assembly though (google
'MIPS one delay slot').

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 

Welcome to EDABoard.com

Sponsor

Back
Top