On Sep 25, 5:58 pm, "Peter Q." <pmous...@gmail.com> wrote:
> Hi All,
> I would like to hear your input for the selection of a
> microcontroller used on a vehicle gudiance/navigation system. The
> vehicle is required to track a long range signal beacon (~30meters
> away). The requirement of the microcontroller is: 1) low cost 2)
> programmable in C and 3) easy to debug.
> I would appreciate any suggestions that you can bring.
>
> Regards,
>
> PQ
http://www.luminarymicro.com/products/kits.html
luminary eval kits generally include usb jtag on-board. So no
additional hardware is required to program/debug your micro.
Keil & IAR has code limited versions (16kB & 32kB respectively)
for simple i/o applications it is also very easy to get something run.
They have a very good-simple library to use peripherals.
www.olimex.com -- you will generally need jtag.
But Some Atmel SAM7 parts (USB ones) can be progammed through USB
(samba).
Reply by Ulf Samuelsson●September 26, 20072007-09-26
"Peter Q." <pmouseca@gmail.com> skrev i meddelandet
news:1190761890.521327.57510@22g2000hsm.googlegroups.com...
> On Sep 25, 6:51 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>> s.p.q...@gmail.com wrote:
>> > Cost and energy spent is also an issue with this project. A high cost/
>> > high power consumption solution is not acceptable. I am willing to
>> > investigate the platform even if it takes weeks. Right now I'm
>> > considering PICs and Motorola 68HC12 series.
>>>
> Hi,
> I would hope to do most of the signal processing by means of
> circuitry, instead of DSP, since I've heard these chips may be limited
> in processing capabilities.
The AVR32 will run up to 89 Dhrystone MIPS which is not too bad
and it has extra DSP features, usually not present in a small Micro.
The instruction set support saturation which is important for DSP
applications.
Also single cycle multiply-accumulate, (ARM7 = 5 cycles)
and a divide instruction (not present on ARM7).
Single cycle load instruction (from internal SRAM). (ARM7 uses at least 3
cycles
-1 Sequential + 1 Non-Sequential + 1 Internal from zero waitstate SRAM).
It will have much lower power and higher performance than the ARM7
alternatives.
> My budget for the chip is < $10 unit cost bulk order, I don't care
> about the programmers and software cost.
> In terms of data input, eventually I will need to process two or
> three sensory inputs, and control two motors (differential drive for
> steering). Nothing complicated like image processing.
> Thanks to all of you who offered suggested, I'm looking into each
> one of them now.
>
> Regards,
>
> PQ
>
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by Tim Wescott●September 25, 20072007-09-25
On Tue, 25 Sep 2007 12:50:35 -0700, Peter Q. wrote:
> as much as I enjoy dissemabling old PCs (not really), we are very
> short on time, and need something that is readily available. We are
> investigating PICs as an option, but heard that it is very hard to
> debug them. Hence I came here to ask you guys for some suggestions.
>
> Regards,
>
> PQ
Why take it apart? Unless you are space constrained, using a PC whole
will get you a working microprocessor system very fast. Even an old
laptop running freeDOS or Linux would get you on the road (as it were).
PICs aren't that bad to debug if you get one of the development boards
with a built in JTAG to USB debugger. Any 8-bit processor is going to be
a similar debugging challenge to a PIC, if not worse.
How big is this thing?
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by Jim Granville●September 25, 20072007-09-25
Peter Q. wrote:
> On Sep 25, 6:51 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
>>s.p.q...@gmail.com wrote:
>>
>>>Cost and energy spent is also an issue with this project. A high cost/
>>>high power consumption solution is not acceptable. I am willing to
>>>investigate the platform even if it takes weeks. Right now I'm
>>>considering PICs and Motorola 68HC12 series.
>>
>> Do you know how much code, and what numeric data types you will work
>>with ?
>> That should help narrow the choices.
>>
>> At the smaller end, focus on the Debug pathway - a good example here,
>>are the SiLabs Low cost ToolStick series - USB debug, and a small
>>daughter card, with the target on it.
>> You can use these cards in low volume production.
>> Very good analog performance, and low powers, with fast wakeups.
>>
>> Moving up CPU power, I'd skip the HC12 (unless you have code-leverage
>>reasons for looking at this ).
>>
>> Again focus on Simulation and Debug. With a HLL, the core is more
>>'don't care' these days.
>>
>> We found the Zilog Zneo Z16F good : USB debug, one shop supply
>>advantages, Tools are mature and Non-Crippled Compiler is free, and
>>include a Simulator, and the Z16F has some 64 bit operand opcodes,
>>includes divide. sub $100, includes EvalPCB _and_ USB-debug
>>
>> Also Rabbit ? - Not single chip, and higher start price, but they
>>do have attractive modules for low-med volumes
>>
>> The 32 bit core market is expanding :
>>Again look for good Debug, and non-crippled tools.
>> ( The USB debug prices can creep a little here. )
>>
>> Freescale have a new V1 coldfire they are pushing.
>> Atmel have AVR32, and also ARM7 and ARM9
>> ST have ARM7, ARM9 and M3 cores.
>> NXP have ARM7, ARM9 uC, and some new ARM9 Flash devices
>> -etc-
>>
>>-jg
>
>
> Hi,
> I would hope to do most of the signal processing by means of
> circuitry, instead of DSP, since I've heard these chips may be limited
> in processing capabilities.
> My budget for the chip is < $10 unit cost bulk order, I don't care
> about the programmers and software cost.
> In terms of data input, eventually I will need to process two or
> three sensory inputs, and control two motors (differential drive for
> steering). Nothing complicated like image processing.
> Thanks to all of you who offered suggested, I'm looking into each
> one of them now.
>
> Regards,
On Sep 25, 6:51 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> s.p.q...@gmail.com wrote:
> > Cost and energy spent is also an issue with this project. A high cost/
> > high power consumption solution is not acceptable. I am willing to
> > investigate the platform even if it takes weeks. Right now I'm
> > considering PICs and Motorola 68HC12 series.
>
> Do you know how much code, and what numeric data types you will work
> with ?
> That should help narrow the choices.
>
> At the smaller end, focus on the Debug pathway - a good example here,
> are the SiLabs Low cost ToolStick series - USB debug, and a small
> daughter card, with the target on it.
> You can use these cards in low volume production.
> Very good analog performance, and low powers, with fast wakeups.
>
> Moving up CPU power, I'd skip the HC12 (unless you have code-leverage
> reasons for looking at this ).
>
> Again focus on Simulation and Debug. With a HLL, the core is more
> 'don't care' these days.
>
> We found the Zilog Zneo Z16F good : USB debug, one shop supply
> advantages, Tools are mature and Non-Crippled Compiler is free, and
> include a Simulator, and the Z16F has some 64 bit operand opcodes,
> includes divide. sub $100, includes EvalPCB _and_ USB-debug
>
> Also Rabbit ? - Not single chip, and higher start price, but they
> do have attractive modules for low-med volumes
>
> The 32 bit core market is expanding :
> Again look for good Debug, and non-crippled tools.
> ( The USB debug prices can creep a little here. )
>
> Freescale have a new V1 coldfire they are pushing.
> Atmel have AVR32, and also ARM7 and ARM9
> ST have ARM7, ARM9 and M3 cores.
> NXP have ARM7, ARM9 uC, and some new ARM9 Flash devices
> -etc-
>
> -jg
Hi,
I would hope to do most of the signal processing by means of
circuitry, instead of DSP, since I've heard these chips may be limited
in processing capabilities.
My budget for the chip is < $10 unit cost bulk order, I don't care
about the programmers and software cost.
In terms of data input, eventually I will need to process two or
three sensory inputs, and control two motors (differential drive for
steering). Nothing complicated like image processing.
Thanks to all of you who offered suggested, I'm looking into each
one of them now.
Regards,
PQ
Reply by Jim Granville●September 25, 20072007-09-25
s.p.qian@gmail.com wrote:
> Cost and energy spent is also an issue with this project. A high cost/
> high power consumption solution is not acceptable. I am willing to
> investigate the platform even if it takes weeks. Right now I'm
> considering PICs and Motorola 68HC12 series.
Do you know how much code, and what numeric data types you will work
with ?
That should help narrow the choices.
At the smaller end, focus on the Debug pathway - a good example here,
are the SiLabs Low cost ToolStick series - USB debug, and a small
daughter card, with the target on it.
You can use these cards in low volume production.
Very good analog performance, and low powers, with fast wakeups.
Moving up CPU power, I'd skip the HC12 (unless you have code-leverage
reasons for looking at this ).
Again focus on Simulation and Debug. With a HLL, the core is more
'don't care' these days.
We found the Zilog Zneo Z16F good : USB debug, one shop supply
advantages, Tools are mature and Non-Crippled Compiler is free, and
include a Simulator, and the Z16F has some 64 bit operand opcodes,
includes divide. sub $100, includes EvalPCB _and_ USB-debug
Also Rabbit ? - Not single chip, and higher start price, but they
do have attractive modules for low-med volumes
The 32 bit core market is expanding :
Again look for good Debug, and non-crippled tools.
( The USB debug prices can creep a little here. )
Freescale have a new V1 coldfire they are pushing.
Atmel have AVR32, and also ARM7 and ARM9
ST have ARM7, ARM9 and M3 cores.
NXP have ARM7, ARM9 uC, and some new ARM9 Flash devices
-etc-
-jg
>Hi All,
> I would like to hear your input for the selection of a
>microcontroller used on a vehicle gudiance/navigation system. The
>vehicle is required to track a long range signal beacon (~30meters
>away). The requirement of the microcontroller is: 1) low cost 2)
>programmable in C and 3) easy to debug.
> I would appreciate any suggestions that you can bring.
Get ye to Sparkfun http://www.sparkfun.com/commerce/categories.php
and take a look at their goodies. I'm lately fond of the NXP ARM7 dev
boards (LPC2000-series) that they offer. Most (many? all?) of them are
sourced from Olimex and are aimed at prototypes & small runs. Lots of
I/O, lots of memory.
I there's a GCC toolchain for the ARM7, as well as some expensive-ware
from the usual suspects. My personal preference is for the
not-so-expensive-ware from Imagecraft (trial and free-but-limited
versions at http://www.imagecraft.com).
For programming/debugging you'll probably want/need a JTAG setup. The
Segger J-Link is good but a bit $$. A low-cost option may be H-JTAG
software http://www.hjtag.com/ which works with the Olimex parallel
port JTAG adapter (see the Olimex site for a tweaked version); only
slightly higher is the USB Scarab dongle + software, also available at
Sparkfun.
While you're at Sparkfun, you're likely to find other gizmos that may
be useful, like 6 DOF IMUs (you supply the Kalman) and various RF
widgets. Fun place.
Reply by Walter Banks●September 25, 20072007-09-25
s.p.qian@gmail.com wrote:
> On Sep 25, 4:22 pm, Walter Banks <wal...@bytecraft.com> wrote:
> > "Peter Q." wrote:
> > > as much as I enjoy dissemabling old PCs (not really), we are very
> > > short on time, and need something that is readily available. We are
> > > investigating PICs as an option, but heard that it is very hard to
> > > debug them. Hence I came here to ask you guys for some suggestions.
> >
> > Vladimir gave you good advice. Assume it will take you a few weeks
> > to understand the tools and the mindset necessary to use a small
> > processor in an application. Add that to the project unknowns
> > and short term a disaster awaits.
> >
> > For a prototype a PC is a good choice. At the very least prototype
> > the software on a PC especially so you have a means of regression
> > testing the the navigation software.
> >
> > w..
>
> Cost and energy spent is also an issue with this project. A high cost/
> high power consumption solution is not acceptable. I am willing to
> investigate the platform even if it takes weeks. Right now I'm
> considering PICs and Motorola 68HC12 series.
>
> Regards,
Consider a handheld PC for the prototype, low cost and low power
requirements. Have a good idea of your system requirements before
selecting one.
w..
Reply by ●September 25, 20072007-09-25
On Sep 25, 4:22 pm, Walter Banks <wal...@bytecraft.com> wrote:
> "Peter Q." wrote:
> > as much as I enjoy dissemabling old PCs (not really), we are very
> > short on time, and need something that is readily available. We are
> > investigating PICs as an option, but heard that it is very hard to
> > debug them. Hence I came here to ask you guys for some suggestions.
>
> Vladimir gave you good advice. Assume it will take you a few weeks
> to understand the tools and the mindset necessary to use a small
> processor in an application. Add that to the project unknowns
> and short term a disaster awaits.
>
> For a prototype a PC is a good choice. At the very least prototype
> the software on a PC especially so you have a means of regression
> testing the the navigation software.
>
> w..
Cost and energy spent is also an issue with this project. A high cost/
high power consumption solution is not acceptable. I am willing to
investigate the platform even if it takes weeks. Right now I'm
considering PICs and Motorola 68HC12 series.
Regards,
PQ
Reply by Walter Banks●September 25, 20072007-09-25
"Peter Q." wrote:
> as much as I enjoy dissemabling old PCs (not really), we are very
> short on time, and need something that is readily available. We are
> investigating PICs as an option, but heard that it is very hard to
> debug them. Hence I came here to ask you guys for some suggestions.
Vladimir gave you good advice. Assume it will take you a few weeks
to understand the tools and the mindset necessary to use a small
processor in an application. Add that to the project unknowns
and short term a disaster awaits.
For a prototype a PC is a good choice. At the very least prototype
the software on a PC especially so you have a means of regression
testing the the navigation software.
w..