I did a project 4 years ago using an LPC2138, which is an ARM7 device. It
has served us very well.
I am starting a new project. The application is machine control. Lots of
I/O, real time processing, CAN, USB connectivity, etc.
I would like to use the LPC2939, which is an ARM968E-S device. However,
for a variety of reasons, I am wondering what the life span of that device
might be and whether I might be better off using a Cortex device instead.
A certain other manufacturer offers a very similar processor to the
LPC2939, but with a Cortex core.
What say thee.... ARM9 or Cortex ?
I am very sorry that the discussion of a non LPC product has to come up in
this forum. I love LPC devices and this forum has treated me well. But I
must ask this question.
Thanks !
ARM7 vs ARM9 versus Cortex... LPC2939, obsolesence, etc.
Started by ●January 28, 2012
Reply by ●January 28, 20122012-01-28
Maybe a Cortex M4. Check out the I/O cycles because they can be pretty
slow, especially on an M3.
DaveS
slow, especially on an M3.
DaveS
Reply by ●January 28, 20122012-01-28
What do you mean by I/O cycles ?
Accessing the peripherals ?
Or the delays between writing to a register and having the result appear on
an I/O pin ?
Thanks for the heads up !
Accessing the peripherals ?
Or the delays between writing to a register and having the result appear on
an I/O pin ?
Thanks for the heads up !
Reply by ●January 28, 20122012-01-28
An M3 I've been using to port code to takes about 4 clock cycles to
change
a bit in an output port. And back to back bit changes take even longer.
It's not an NXP processor - I've given up on them until there is better
support for OpenOCD.
DaveS
a bit in an output port. And back to back bit changes take even longer.
It's not an NXP processor - I've given up on them until there is better
support for OpenOCD.
DaveS
Reply by ●January 29, 20122012-01-29
Just my 2 cents.
Port switching is really important in most 8-bit applications. If you need to bit-bang serial interfaces or a PWM, you selected the wrong chip, the selection is huge. If you are one of the guys that need six UARTs in a 64 pin package, get your self a PSoC and generate the chip.
Making bit banging a significant part of the selection process of a 32-bit micro is beyond me and sounds so much last millennium.
Making a decision like abandoning NXP because their support of open OCD is not up to par is down right ridiculous, at least for professional use it is. The difference between Open OCD and a professional JTAG debugger is a couple hundred $$ or Euros or whatever. Making the wrong decision about a chip selection in a professional environment starts at a penalty of tens of thousands and can easily go into the millions give a high volume, time to market....
Now to the original question. How many CAN interfaces do you need? This is the only reason why I might even consider the 2939, needing several CAN interfaces. Overall, leave the ARM9 especially the 968 or 966 behind and go with the flow, use a Cortex.
There has been one good suggestions, have a look at the M4 based devices, they outperform the 2939 already and the factor will just be more in future.
As I said, just my 2 cents.
Bob
Port switching is really important in most 8-bit applications. If you need to bit-bang serial interfaces or a PWM, you selected the wrong chip, the selection is huge. If you are one of the guys that need six UARTs in a 64 pin package, get your self a PSoC and generate the chip.
Making bit banging a significant part of the selection process of a 32-bit micro is beyond me and sounds so much last millennium.
Making a decision like abandoning NXP because their support of open OCD is not up to par is down right ridiculous, at least for professional use it is. The difference between Open OCD and a professional JTAG debugger is a couple hundred $$ or Euros or whatever. Making the wrong decision about a chip selection in a professional environment starts at a penalty of tens of thousands and can easily go into the millions give a high volume, time to market....
Now to the original question. How many CAN interfaces do you need? This is the only reason why I might even consider the 2939, needing several CAN interfaces. Overall, leave the ARM9 especially the 968 or 966 behind and go with the flow, use a Cortex.
There has been one good suggestions, have a look at the M4 based devices, they outperform the 2939 already and the factor will just be more in future.
As I said, just my 2 cents.
Bob
Reply by ●January 29, 20122012-01-29
On Sat, Jan 28, 2012 at 6:51 PM, David Smead wrote:
> An M3 I've been using to port code to takes about 4 clock cycles to change
> a bit in an output port. And back to back bit changes take even longer.
>
Interesting comment. I'm not sure I would have caught this had you not
mentioned it. I thank you for your post.
However, I took a look at our application and it seems, for our use anyway,
that we won't be directly bit banging to an output port.
Actually, it seems that some of these devices have sophisticated enough I/O
that one would never need to bang, at least not how we used to.
For example, several of the Cortex devices do capture/counting of
quadrature encoded signals. Can you imagine !
I'm sure there will be one case where I'll have to bang something. When
it happens, I'll be aware of the latency.
> An M3 I've been using to port code to takes about 4 clock cycles to change
> a bit in an output port. And back to back bit changes take even longer.
>
Interesting comment. I'm not sure I would have caught this had you not
mentioned it. I thank you for your post.
However, I took a look at our application and it seems, for our use anyway,
that we won't be directly bit banging to an output port.
Actually, it seems that some of these devices have sophisticated enough I/O
that one would never need to bang, at least not how we used to.
For example, several of the Cortex devices do capture/counting of
quadrature encoded signals. Can you imagine !
I'm sure there will be one case where I'll have to bang something. When
it happens, I'll be aware of the latency.
Reply by ●January 29, 20122012-01-29
I've been using OpenOCD almost from it's first release - 2003?
It's
been a good tool on the LPC21XX processors, and it works fine on
STM32FXX processors. What would a "professional" jtag debugger offer?
Maybe some GUI with it's own learning curve and all the pitfalls of
closed source software? No thanks, I'm happy with gdb.
BTW, ST is sharing the secrets of their SWD interface with the OpenOCD
developers. They obviously understand that supporting open source tools
is good business. It looks like NXP wants to ball and chain developers
with their mbed program.
If there is only one instance where bit-banging needs to be fast, and it
isn't, then a different processor is necessary.
And, I'll add that your advice was grossly overvalued at 2 cents.
DaveS
been a good tool on the LPC21XX processors, and it works fine on
STM32FXX processors. What would a "professional" jtag debugger offer?
Maybe some GUI with it's own learning curve and all the pitfalls of
closed source software? No thanks, I'm happy with gdb.
BTW, ST is sharing the secrets of their SWD interface with the OpenOCD
developers. They obviously understand that supporting open source tools
is good business. It looks like NXP wants to ball and chain developers
with their mbed program.
If there is only one instance where bit-banging needs to be fast, and it
isn't, then a different processor is necessary.
And, I'll add that your advice was grossly overvalued at 2 cents.
DaveS
Reply by ●January 29, 20122012-01-29
On Sun, Jan 29, 2012 at 12:05 AM, Bob T wrote:
> **
>
> Just my 2 cents.
> Port switching is really important in most 8-bit applications. If you need
> to bit-bang serial interfaces or a PWM, you selected the wrong chip, the
> selection is huge.
>
I guess I have to disagree. I need to generate 8 to 10 PWM waveforms to
control various things. The LPC2939 seems to be a great device to do this
as does the STM32F series. Some of these devices can generate 24 PWMs
simultaneously and it appears to me that some can even be synchronized.
These are exactly the chips I need to be looking at.
> If you are one of the guys that need six UARTs in a 64 pin package, get
> your self a PSoC and generate the chip.
I'm needing 2 can channels and a USB port as well. Maybe Ethernet in the
future. The aforementioned devices offer me that sort of functionality
without gluing it on later.
> Making bit banging a significant part of the selection process of a 32-bit
> micro is beyond me and sounds so much last millennium.
And yet sometimes its just what is needed. If that is the case, so be it.
> Making a decision like abandoning NXP because their support of open OCD is
> not up to par is down right ridiculous, at least for professional use it
> is. The difference between Open OCD and a professional JTAG debugger is a
> couple hundred $$ or Euros or whatever. Making the wrong decision about a
> chip selection in a professional environment starts at a penalty of tens of
> thousands and can easily go into the millions give a high volume, time to
> market....
Agreed and yet I myself have been frustrated with OpenOCD. I got burnt on
a project years ago whereby a big name brand emulator company decided not
to support the new line of a certain vendor and thus we were forced to port
the C code we had written using their language mutalations to another
language mutalation as well as switch emulator hardware. Nice little $10K
bill right there.
Since then I have vowed to use Open Source compilers (and tools) wherever
possible. Some of those JTAG debuggers you mention only work with the code
generated by certain compilers. A lot of emulator companies want tie in
between their software tools and their debugger. Sorry, I'm not playing
that game.
Thus while I don't use OpenOCD, I respect that someone wants it and I think
it shows dedication and commitment on the part of the vendor to be looking
out for the little guy as well as the guy who millions of dollars on the
line with his project.
> Now to the original question. How many CAN interfaces do you need?
2
This is the only reason why I might even consider the 2939, needing several
CAN interfaces. Overall, leave the ARM9 especially the 968 or 966 behind
and go with the flow, use a Cortex.
I will be.
> There has been one good suggestions, have a look at the M4 based devices,
> they outperform the 2939 already and the factor will just be more in
> future.
Sorry to name devices, but we are considering the STM32F405.
> As I said, just my 2 cents.
Thank you for sharing it. I don't agree with some of it, but it made me
think and maybe next time I will agree with what you mention and use it.
That is how we learn.
Kudos to all.
> **
>
> Just my 2 cents.
> Port switching is really important in most 8-bit applications. If you need
> to bit-bang serial interfaces or a PWM, you selected the wrong chip, the
> selection is huge.
>
I guess I have to disagree. I need to generate 8 to 10 PWM waveforms to
control various things. The LPC2939 seems to be a great device to do this
as does the STM32F series. Some of these devices can generate 24 PWMs
simultaneously and it appears to me that some can even be synchronized.
These are exactly the chips I need to be looking at.
> If you are one of the guys that need six UARTs in a 64 pin package, get
> your self a PSoC and generate the chip.
I'm needing 2 can channels and a USB port as well. Maybe Ethernet in the
future. The aforementioned devices offer me that sort of functionality
without gluing it on later.
> Making bit banging a significant part of the selection process of a 32-bit
> micro is beyond me and sounds so much last millennium.
And yet sometimes its just what is needed. If that is the case, so be it.
> Making a decision like abandoning NXP because their support of open OCD is
> not up to par is down right ridiculous, at least for professional use it
> is. The difference between Open OCD and a professional JTAG debugger is a
> couple hundred $$ or Euros or whatever. Making the wrong decision about a
> chip selection in a professional environment starts at a penalty of tens of
> thousands and can easily go into the millions give a high volume, time to
> market....
Agreed and yet I myself have been frustrated with OpenOCD. I got burnt on
a project years ago whereby a big name brand emulator company decided not
to support the new line of a certain vendor and thus we were forced to port
the C code we had written using their language mutalations to another
language mutalation as well as switch emulator hardware. Nice little $10K
bill right there.
Since then I have vowed to use Open Source compilers (and tools) wherever
possible. Some of those JTAG debuggers you mention only work with the code
generated by certain compilers. A lot of emulator companies want tie in
between their software tools and their debugger. Sorry, I'm not playing
that game.
Thus while I don't use OpenOCD, I respect that someone wants it and I think
it shows dedication and commitment on the part of the vendor to be looking
out for the little guy as well as the guy who millions of dollars on the
line with his project.
> Now to the original question. How many CAN interfaces do you need?
2
This is the only reason why I might even consider the 2939, needing several
CAN interfaces. Overall, leave the ARM9 especially the 968 or 966 behind
and go with the flow, use a Cortex.
I will be.
> There has been one good suggestions, have a look at the M4 based devices,
> they outperform the 2939 already and the factor will just be more in
> future.
Sorry to name devices, but we are considering the STM32F405.
> As I said, just my 2 cents.
Thank you for sharing it. I don't agree with some of it, but it made me
think and maybe next time I will agree with what you mention and use it.
That is how we learn.
Kudos to all.
Reply by ●January 29, 20122012-01-29
Sorry to belabour the point, but another example of not needing to bit bang
on the STM devices is the fact that the USARTs (Universal Synchronous
Asynchronous Receiver Transmitters) have RTS and CTS built right in !
I can't count how many times I had an interrupt set up on a serial buffer
full to bang the CTS bit off ! It appears I don't have to do that any more
! Finally !
It is 2011 after all and now that USB is taking over the world, someone
adds CTS and RTS functionality to the built in UARTs. Something about too
little, too late ???? But I appreciate the effort anyway.
on the STM devices is the fact that the USARTs (Universal Synchronous
Asynchronous Receiver Transmitters) have RTS and CTS built right in !
I can't count how many times I had an interrupt set up on a serial buffer
full to bang the CTS bit off ! It appears I don't have to do that any more
! Finally !
It is 2011 after all and now that USB is taking over the world, someone
adds CTS and RTS functionality to the built in UARTs. Something about too
little, too late ???? But I appreciate the effort anyway.
Reply by ●January 29, 20122012-01-29
I have one of the ST Discovery boards with the STM32F407 on it. Getting my
Linux development system talking to it via stlink was easy.
I'm presently using an LPC2148. Executable is now close to 256K, but I'm
pushing the limits time wise. The Cortex M3 at the same clock rate is
overall quite a bit slower. I hope to get a break soon so I can evaluate
the M4, STM32F4xx as a possible upgrade.
I have a pretty simple task multiplexer and by toggling a bit around
context switches, as I change the preempt clock, I can 'scope' how many
switches per second can be done with the tasks not doing anything. I'll
post some result when I get the time to run the tests.
DaveS
Linux development system talking to it via stlink was easy.
I'm presently using an LPC2148. Executable is now close to 256K, but I'm
pushing the limits time wise. The Cortex M3 at the same clock rate is
overall quite a bit slower. I hope to get a break soon so I can evaluate
the M4, STM32F4xx as a possible upgrade.
I have a pretty simple task multiplexer and by toggling a bit around
context switches, as I change the preempt clock, I can 'scope' how many
switches per second can be done with the tasks not doing anything. I'll
post some result when I get the time to run the tests.
DaveS
