Lpc2000

Hello,
My name's Denny and I've just joined your little group here. I've been 
working with PICs for several years but I've recently been given a 
project that is going to need a more powerfull proccessor. Basicly the 
requirements look like this:

Monitor a remote sensor (probably a CAN node, but I'm bulding the 
sensor to, so it could be something else)
Monitor several local sensors (ADC, timers, but most notably- count 
quadrature from a linear encoder)
Control a ~200 watt brushless servo motor (PID loop with the linear 
encoder)
Perform unspecified (but complicated, floating point) math on the 
sensor data to position the servo. (may be possible to implement as a 
large lookup table but would require ~20Kb)
Datalogging of the sensor data (expect ~50Kb)
Allow non-electronics types in the field to update the positioning 
algorithim and retrieve the logged data (probably USB, though a flash 
memory card might be an option)
5 mS or faster update rate to the PID loop
Not a high volume project (less than five units per year)

Most of this I've done before with PICs, but never all on the same 
project. I think this is a good fit for an ARM7 (thus the reason I'm 
here) but I hadn't decided witch one.
I was looking at the Phillips LPC parts but it looks as though CAN and 
USB are incompatible options (no parts have both) so my current 
thinking is the LPC2129 and an external USB chip (probably FTDI)

Any better sugestions?

As to development hardware, What's everybody else using? I'm thinking 
the LPC-P2129 board and JTAG programmer from Olimex - is their a better 
option?

What is the current reccomendation for the software toolchain?

I've budgeted fairly heavily for development tools in this project, so 
cost isn't a significant concern.

Thank you,
-Denny

> Not a high volume project (less than five units per year)

I guess another useful metric would be how much do you
plan to charge for such a device?

For such a low-volume product, if price is not the issue,
then perhaps a pre-built module, if one exists, would be
an option. You could throw a little more weight into it
too, eg. a processor that runs a full OS.

Thats not to say the LPCs are too lightweight. I like
them, and run the uCOS-II RTOS for my tinkering projects.

However, I also tinker with other processors too.
I'm looking at Linux on a PowerPC for some other work.
The ColdFire processors have all the peripherals you
want too. For example, check out the Netburner modules
(http://www.netburner.com), or modules from
http://www.cogcomp.com or http://www.logicpd.com.
Kontron has stuff too, and Gumstix, and ...

Just a thought.
Dave

Hi Denny,

> I was looking at the Phillips LPC parts but it looks as though CAN and
> USB are incompatible options (no parts have both) so my current
> thinking is the LPC2129 and an external USB chip (probably FTDI)

Note the LPC2129 currently has some errata.  I understand all errata will be
fixed in upcoming release sometime in May.  The LPC2129 implements a 32-bit
version of the SJA1000.

> 
> Any better sugestions?

Depending on bus protocol and baud rate you could also consider a LPC214x
with a SPI CAN interface.  Something along the lines of the PIC MCP2515,
although once revised the LPC2129/32-bit SJA1000 will be a superior
solution.
 
> 
> As to development hardware, What's everybody else using? I'm thinking
> the LPC-P2129 board and JTAG programmer from Olimex - is their a better
> option?
> 
> What is the current reccomendation for the software toolchain?

You might consider the IAR KickStart Kit for LPC2129:
http://www.iar.com/index.php?show=31418_ENG&&page_anchor=http://www.iar.com/
p31418/p31418_eng.php

The KickStart version of the IAR compiler is free for unlimited time, and as
a code limit of 32k.  The baseline version is limited to 256k.

Keil of course is another option.  I've used both and prefer the IAR
debugger, but opinions are free and widely available ;)
http://www.keil.com/arm/Default.asp?bhcp=1

For pricing you might check out:
http://www.lpctools.com/


Joel

--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@...> wrote:
>
> Hi Denny,
> 
> > I was looking at the Phillips LPC parts but it looks as though 
CAN and
> > USB are incompatible options (no parts have both) so my current
> > thinking is the LPC2129 and an external USB chip (probably FTDI)
> 
> Note the LPC2129 currently has some errata.  I understand all 
errata will be
> fixed in upcoming release sometime in May.  The LPC2129 implements 
a 32-bit
> version of the SJA1000.
> 

Interesting, what are / where can I find specifics about this errata?

> > 
> > Any better sugestions?
> 
> Depending on bus protocol and baud rate you could also consider a 
LPC214x
> with a SPI CAN interface.  Something along the lines of the PIC 
MCP2515,
> although once revised the LPC2129/32-bit SJA1000 will be a superior
> solution.
>  

Since it doesn't seem I can do USB _and_ CAN on naitive hardware, one 
will need to be an add on chip. I suspect it would be easier to do 
the USB as an add on because of the PC driver support for the FTDI 
products. It'll have to do CAN in real time, but it'll only need the 
USB when the mechanicals are stopped, so I thought on-chip CAN was 
the better trade off.

As to the CAN baud rate / protocol issues; I need 3 bytes of data 
from a sensor about 10 feet away in a very noisy enviroment about 
every 5mS. I have control over both ends of the system.

> > 
> > As to development hardware, What's everybody else using? I'm 
thinking
> > the LPC-P2129 board and JTAG programmer from Olimex - is their a 
better
> > option?
> > 
> > What is the current reccomendation for the software toolchain?
> 
> You might consider the IAR KickStart Kit for LPC2129:
> http://www.iar.com/index.php?
show=31418_ENG&&page_anchor=http://www.iar.com/
> p31418/p31418_eng.php
> 
> The KickStart version of the IAR compiler is free for unlimited 
time, and as
> a code limit of 32k.  The baseline version is limited to 256k.
> 
> Keil of course is another option.  I've used both and prefer the IAR
> debugger, but opinions are free and widely available ;)
> http://www.keil.com/arm/Default.asp?bhcp=1
> 
> For pricing you might check out:
> http://www.lpctools.com/
> 

Cool, thanks for the links.

-Denny

--- In lpc2000@yahoogroups.com, David Hawkins <dwh@...> wrote:
>
> 
> > Not a high volume project (less than five units per year)
> 
> I guess another useful metric would be how much do you
> plan to charge for such a device?

I didn't actualy want this project. But I've dealt with this customer 
for a long time and they wanted _me_ to do it. I wouldn't agree to 
take it until they offered cost plus. I initialy budgeted $1k for dev 
tools.

> For such a low-volume product, if price is not the issue,
> then perhaps a pre-built module, if one exists, would be
> an option. You could throw a little more weight into it
> too, eg. a processor that runs a full OS.
 
I fully expect to build a prototype with a pre-built module (maybe 
one of the olimex boards) but the installation is very mass sensitive 
so it will require a custom board. I'm not at all against a bigger 
proccessor, that's part of why I'm seeking advice from this group. If 
an ARM7 isn't a good fit for this type of application please say so. 
I haven't worked with any proccessors large enough to run a full OS 
(other than a PC) so I'm not sure what bennifits that can give me.

> Thats not to say the LPCs are too lightweight. I like
> them, and run the uCOS-II RTOS for my tinkering projects.
> 
> However, I also tinker with other processors too.
> I'm looking at Linux on a PowerPC for some other work.
> The ColdFire processors have all the peripherals you
> want too. For example, check out the Netburner modules
> (http://www.netburner.com), or modules from
> http://www.cogcomp.com or http://www.logicpd.com.
> Kontron has stuff too, and Gumstix, and ...
> 
> Just a thought.
> Dave
>

Thanks, I'll check those out.

-Denny

> Interesting, what are / where can I find specifics about this errata?

http://www.standardics.philips.com/products/lpc2000/all/
Select LPC2129, then Erratasheet.

You might also look at Phillip's app note AN10324.  Same URL, select device,
then Tech Docs.

There is also an evaluation microCANopen driver that is a good starting
point for using CAN on the LPC2129.  This can be found here:
http://esacademy.com/


Joel

With CAN and motor control you might consider an RTOS.  A good choice for a
high speed RTOS on the LPC2129 is Segger's embOS, free demo is available.
Similar price to uC/OS-II, but royalty free, and includes extras that
Micrium charges extra.  uC/OS-II is licensed per product model.  Then again
if your efforts are academia related there is no charge to use uC/OS-II.
There's also a FreeRTOS Keil and IAR port for the LPC2129.  No cost.

http://www.segger.com/embos_general.html
http://www.micrium.com/products/rtos/kernel/rtos.html
http://www.freertos.org/

If time to market is a concern, IAR and Segger embOS provide a good combo.
You should be up and running in a day.  EmbOS has the most advanced
debugging/profiling features of the three. 



Joel

> I didn't actualy want this project. But I've dealt with this 
customer 
> for a long time and they wanted _me_ to do it. I wouldn't agree to 
> take it until they offered cost plus. I initialy budgeted $1k for 
dev 
> tools.

That won't even buy a JTAG dongle other than a Wiggler - not a 
highly regarded solution, by the way.

Not to worry, the GNU toolchain will deal with anything you can come 
up with.  After all, it is used all the time to build Linux kernels 
for the ARM9s and PCs and bigger boxes.

If you are developing under Windows you need Cygwin, under Linux you 
have everything.  You can integrate the tool chain under Eclipse for 
an IDE if you want to skip the command line experience (I do...).

Read through the tutorial at http://tinyurl.com/camje

>I'm not at all against a bigger 
> proccessor, that's part of why I'm seeking advice from this group. 
If 
> an ARM7 isn't a good fit for this type of application please say 
so. 
> I haven't worked with any proccessors large enough to run a full 
OS 
> (other than a PC) so I'm not sure what bennifits that can give me.

Tom Walsh has done a lot of work connecting a MMC card to the 
LPC2138 and has an entire set of code ready to go.  You can log all 
day long to a 1 GB SD/MMC card.  See www.openhardware.net.  There is 
a FreeRTOS port for just about every eventuality if you need a real 
time operating system.

Richard

The advantage to the LPC2148 series is they are small full system-on-chip 
that require minimal external components.  You can have an entire basic 
setup on a double sided board 2cm by 2cm.  If size and weight is a factor 
then these chips are a good idea.  Unfortunately it only has 40KB of RAM, 
so if you need more you'll either need to put on a serial flash chip or 
bitbang your own SRAM.  If you need to store data then a flash chip or even 
SD/MMC card may work out well.  You may want to check out Atmel's AT91SAM7S 
chip as well.

You say that you're designing the interface yourself, so you don't need to 
use CAN, so what about other interfaces?  How much distance will there be 
between the micro and the sensors?  How many sensors will you be 
interfacing to?  If the distance is small then you can always use I2C or 
SPI.  Even for medium distances these will work by adding in driver 
chips.  If you have a longer distance, you could try RS485 or even RS232 or 
even just plain TTL logic levels (possibly with a driver/isolator).  These 
are simpler than CAN AFAIK.  How noisy is the environment where these will 
need to operate?

-- Sean

At 15:39 2/10/2006, you wrote:

>--- In lpc2000@yahoogroups.com, David Hawkins <dwh@...> wrote:
> >
> > > Not a high volume project (less than five units per year)
> >
> > I guess another useful metric would be how much do you
> > plan to charge for such a device?
>
>I didn't actualy want this project. But I've dealt with this customer
>for a long time and they wanted _me_ to do it. I wouldn't agree to
>take it until they offered cost plus. I initialy budgeted $1k for dev
>tools.
>
> > For such a low-volume product, if price is not the issue,
> > then perhaps a pre-built module, if one exists, would be
> > an option. You could throw a little more weight into it
> > too, eg. a processor that runs a full OS.
>
>I fully expect to build a prototype with a pre-built module (maybe
>one of the olimex boards) but the installation is very mass sensitive
>so it will require a custom board. I'm not at all against a bigger
>proccessor, that's part of why I'm seeking advice from this group. If
>an ARM7 isn't a good fit for this type of application please say so.
>I haven't worked with any proccessors large enough to run a full OS
>(other than a PC) so I'm not sure what bennifits that can give me.
>
> > Thats not to say the LPCs are too lightweight. I like
> > them, and run the uCOS-II RTOS for my tinkering projects.
> >
> > However, I also tinker with other processors too.
> > I'm looking at Linux on a PowerPC for some other work.
> > The ColdFire processors have all the peripherals you
> > want too. For example, check out the Netburner modules
> > (<http://www.netburner.com),>http://www.netburner.com), or modules from
> > <http://www.cogcomp.com>http://www.cogcomp.com or 
> <http://www.logicpd.com.>http://www.logicpd.com.
> > Kontron has stuff too, and Gumstix, and ...
> >
> > Just a thought.
> > Dave
> >
>
>Thanks, I'll check those out.
>
>-Denny

> You say that you're designing the interface yourself, so you don't 
need to 
> use CAN, so what about other interfaces?  How much distance will 
there be 
> between the micro and the sensors?  How many sensors will you be 
> interfacing to?  If the distance is small then you can always use 
I2C or 
> SPI.  Even for medium distances these will work by adding in driver 
> chips.  If you have a longer distance, you could try RS485 or even 
RS232 or 
> even just plain TTL logic levels (possibly with a 
driver/isolator).  These 
> are simpler than CAN AFAIK.  How noisy is the environment where 
these will 
> need to operate?
> 
> -- Sean

It'll be about 10 ft of wire between sensor and controller. There 
doesn't need to be any other nodes on the network (at least that's 
what they say now). Data payload is about 3 bytes every 5mS and it'll 
be very noisy (automotive engine compartment) I suspect I could 
design it robust enough so that single packet loss could be 
tolerated.  Like I mentioned I have control over both ends of the 
system, so it could be any interface I see fit. I was thinking that 
CAN would be good for several reasons:
It's a standard
Noise resistant
Easy to add to in the future

That last one's the big deal, they swear that these are the only 
sensors they need on the system, but they made a big deal about 
wanting to tweek the algorithim and logging the results so I strongly 
suspect the sensor requirements are likely to change in unpredictable 
ways.

-Denny

> driver/isolator).  These
> > are simpler than CAN AFAIK.  How noisy is the environment where

CAN isn't difficult, some of the upper level protocols can be quite complex.

> It'll be about 10 ft of wire between sensor and controller. There
> doesn't need to be any other nodes on the network (at least that's
> what they say now). Data payload is about 3 bytes every 5mS and it'll
> be very noisy (automotive engine compartment) I suspect I could
> design it robust enough so that single packet loss could be
> tolerated.  Like I mentioned I have control over both ends of the
> system, so it could be any interface I see fit. I was thinking that
> CAN would be good for several reasons:
> It's a standard
> Noise resistant
> Easy to add to in the future

J1939 (CAN 250k Baud) is generally applied to this sort of concept: Heavy
equipment, bus, etc.  But in your case it may be overkill.  You might
consider microCANopen which I referenced in an earlier email would work
quite well for what you need, without much modification.  License for code
is ~$495.  www.canopenstore.com

CAN would be a very good solution for your application.

If you need more/smaller nodes check out the Atmel AT90CANxx(x) series.
These use a highly optimized CAN peripheral that greatly minimizes CPU
involvement.


Joel

Well SPI, I2C and even TTL can handle 10ft runs, I2C only requires 3 wires 
no matter how many sensors, SPI takes 3 + 1 per sensor, however I'm not 
sure on the noise tolerance.  I suspect you will be fine if you use 
shielded wiring, clock them low enough, use filter caps, and design your 
protocol to have a simple error detection algorithm.

-- Sean

At 17:31 2/10/2006, you wrote:

> > You say that you're designing the interface yourself, so you don't
>need to
> > use CAN, so what about other interfaces?  How much distance will
>there be
> > between the micro and the sensors?  How many sensors will you be
> > interfacing to?  If the distance is small then you can always use
>I2C or
> > SPI.  Even for medium distances these will work by adding in driver
> > chips.  If you have a longer distance, you could try RS485 or even
>RS232 or
> > even just plain TTL logic levels (possibly with a
>driver/isolator).  These
> > are simpler than CAN AFAIK.  How noisy is the environment where
>these will
> > need to operate?
> >
> > -- Sean
>
>It'll be about 10 ft of wire between sensor and controller. There
>doesn't need to be any other nodes on the network (at least that's
>what they say now). Data payload is about 3 bytes every 5mS and it'll
>be very noisy (automotive engine compartment) I suspect I could
>design it robust enough so that single packet loss could be
>tolerated.  Like I mentioned I have control over both ends of the
>system, so it could be any interface I see fit. I was thinking that
>CAN would be good for several reasons:
>It's a standard
>Noise resistant
>Easy to add to in the future
>
>That last one's the big deal, they swear that these are the only
>sensors they need on the system, but they made a big deal about
>wanting to tweek the algorithim and logging the results so I strongly
>suspect the sensor requirements are likely to change in unpredictable
>ways.
>
>-Denny
>
>
>
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel 
>microprocessors
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic 
>microcontrollers
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

> Well SPI, I2C and even TTL can handle 10ft runs, I2C only requires 3 wires
> no matter how many sensors, SPI takes 3 + 1 per sensor, however I'm not
> sure on the noise tolerance.  I suspect you will be fine if you use
> shielded wiring, clock them low enough, use filter caps, and design your
> protocol to have a simple error detection algorithm.

Fault tolerance, hardware filtering, bus arbitration, etc. are all built
into the CAN silicon.  I would only recommend using CAN in this application.


Joel

At 02:50 PM 2/10/06 -0800, Joel Winarske wrote:
> > driver/isolator).  These
> > > are simpler than CAN AFAIK.  How noisy is the environment where
>
>CAN isn't difficult, some of the upper level protocols can be quite complex.
>
> > It'll be about 10 ft of wire between sensor and controller. There
> > doesn't need to be any other nodes on the network (at least that's
> > what they say now). Data payload is about 3 bytes every 5mS and it'll
> > be very noisy (automotive engine compartment) I suspect I could
> > design it robust enough so that single packet loss could be
> > tolerated.  Like I mentioned I have control over both ends of the
> > system, so it could be any interface I see fit. I was thinking that
> > CAN would be good for several reasons:
> > It's a standard
> > Noise resistant
> > Easy to add to in the future
>
>J1939 (CAN 250k Baud) is generally applied to this sort of concept: Heavy
>equipment, bus, etc.  But in your case it may be overkill.  You might
>consider microCANopen which I referenced in an earlier email would work
>quite well for what you need, without much modification.  License for code
>is ~$495.  www.canopenstore.com
>
>CAN would be a very good solution for your application.

I agree CAN looks like a good solution but from the description so far 
there is no need for anything as complex as CANopen.  Just reserve an 
identifier as the one to contain your data and set the CAN filters so that 
a specific CAN mailbox is reserved for that identifier.  Then read as it 
arrives.  If you want a little more security against reading the same value 
multiple times (a perfectly valid occurrence on CAN, especially in a noisy 
environment) add a field in the data to indicate which sample is being 
sent.  Go hog wild and reserve a whole byte for it.  If the byte is the 
same on two readings you know you've received the same entry twice.  If it 
skips a value you know you've dropped a sample.  Simple and reasonably 
robust. No need to implement a higher level protocol.

Personally I'd avoid the Microchip SPI based CAN chip, but a lot of that 
has to do with how I dislike their filtering mechanism.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

To CAN or not to CAN is an important detail, but I'm still trying to 
get a big picture here, so let's change the question a little. 
Given your experiance with ARM7 development and some background on 
what I'm looking to do, what's your recomndations for a development 
board, programmer and software toolchain.

Budget isn't the primary limitation but I don't think I can justify 
$5K for an ICE.

I've seen the Olimex stuff - looks good (and I've used other Olimex 
stuff before)
It looks like the IAR KickStart Kit for LPC2129 actualy uses the 
Olimex board, but a USB programmer - that's a plus

Looking at the offerings from LPCtools.com I see boards from Embedded 
Artists, Kiel, Embest, Olimex and some high end stuff from Ashling.

I'm sure all of them work - otherwise they couldn't sell them. But 
which is most popular and has the most example code.

Thanks,
-Denny

dkesterline wrote:

>To CAN or not to CAN is an important detail, but I'm still trying to 
>get a big picture here, so let's change the question a little. 
>Given your experiance with ARM7 development and some background on 
>what I'm looking to do, what's your recomndations for a development 
>board, programmer and software toolchain.
>
>Budget isn't the primary limitation but I don't think I can justify 
>$5K for an ICE.
>
>I've seen the Olimex stuff - looks good (and I've used other Olimex 
>stuff before)
>It looks like the IAR KickStart Kit for LPC2129 actualy uses the 
>Olimex board, but a USB programmer - that's a plus
>
>Looking at the offerings from LPCtools.com I see boards from Embedded 
>Artists, Kiel, Embest, Olimex and some high end stuff from Ashling.
>
>I'm sure all of them work - otherwise they couldn't sell them. But 
>which is most popular and has the most example code.
>
>  
>
It all depends on your level of expertise, comfort, and operating 
system.  I've been running Linux as my primary o/s for 6 years now.  I 
program code, that is all I do with a computer, write code.  So, Linux 
has the tools for me to build code quickly (perl, grep, etc.).  When it 
came time for a dev environ for LPC2000, I naturally chose binutils, 
gcc, and insight.  These are tools I have used for years and am quite 
comfortable with.  After all, they build beowulf clusters with these 
tools...  I built my own dev tools from source: 
http://www.openhardware.net/?title=ARM%20Thumb%20tools%20for%20LPC2000&dir=ArmTools&file=ThumbToolchain.html

For the JTAG I chose the Abatron BDI2000.  My experience with wigglers 
has been such that I needed something more reliable, and portable.  The 
Abatron BDI2000 is operating system agnostic, I use it on Linux and 
recommend it's use to a client running Win2K.  The unit is not cheap, 
but quality never is: USD $2700.

However, if you need the comfort of someone to yell at, then choose one 
of the other off-the-shelf solutions.

Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------