arm7 atmel vs others

In article <slrnc3bt5a.js.jmarin@pyy.embedtronics.fi>, 
jmarin@pyy.embedtronics.fi says...
> On 2004-02-20, Alaric B Snell <alaric@alaric-snell.com> wrote:
> >> Unless you know the input does not change very fast, this could produce
> >> errors.  But yes, I agree that it seems odd that you can't read the
> >> pin.  I'm not sure how the OKI parts work in this case.  
> >
> > Can one not use the pin select registers to switch the pin from CAPture 
> > to GPIO before sampling? Should only take a single extra VPB write 
> > cycle, if you have the direction register already set up in advance?
> 
> If we change the pin from CAPture to GPIO, read the pin state, an edge
> occurs, and we change back to CAPture, we have lost an edge again..
> The margin is very small, but as long as it's there, the edges WILL
> occur during that time ;)  Plus, I think the CAPture logic will not
> work reliably if we switch the input to GPIO which (I believe) floats
> the internal CAPture logic input.  Plus, it's more overhead ;-)

I guess that's why I always like to have a few extra GPIO pins.  Just
run the same signal to the CAPture pin and a different pin to read the
level.  Then  there's no need to reconfigure the capture pin and
you shouldn't miss any events that happen within the capture timing
limits.


> 
> > I seem to remember that you need a pullup or pulldown or something on SS 
> > when in master mode - because in multi-master situations, the device can 
> > only be master when it's not being told it's slave, or something. No, I 
> > have no idea how multi-master SPI is done, perhaps with all the SS lines 
> > running to a central arbitrator or something? Not sure how prospective 
> > masters would 'claim' mastership... Anyway.
> 
> Well, if you configure SS as GPIO, there's no way of pulling up the
> internal SPI SS signal.. they should have pulled it up internally
> when the pin is configure as GPIO.
> 
> Actually, the SS is an output in master mode, so there should be no problem
> using it for GPIO while SPI is running.  It just seemed that we couldn't
> get SPI working at all because it first comes up in slave mode and the SS
> pin was an input (which was floating).  Sometimes, on some chips, the SPI
> would start working and when we were able to config it as a master, it
> then worked until the next reboot.  (This is how I remember it, I haven't
> worked on this myself..)  The reason we wanted to have SS as GPIO is that
> we are using a FLASH chip which terminates an operation when /CS goes high
> (and SS goes high after every single byte).
> 
> Anyway, we "fixed" the problem in this design by using a software SPI
> implementation and having all the pins as GPIO..
> 
> Well, enough of this... ;-)  Back to studying LCD's and LCD controllers..
> 
>   -jm
> 
Mark Borgerson

In article <slrnc3ce2r.js.jmarin@pyy.embedtronics.fi>, 
jmarin@pyy.embedtronics.fi says...
> On 2004-02-20, Jukka Marin <jmarin@pyy.embedtronics.fi> wrote:
> > Actually, the SS is an output in master mode, so there should be no problem
> > using it for GPIO while SPI is running.
> 
> This is garbage.  On Motorola parts (like HC12), SS is an output in master
> mode and goes low during SPI operations.  On LPC210x, SSEL is always an
> input - even in master mode.  If it goes low, LPC thinks there was an SPI
> collision.  If you config the SSEL pin as GPIO (to be able to use it as an
> SPI chip select), the SPI logic sees the input floating and will not work
> properly.
> 
>   -
Actually, on a lot of Motorola CPUs,  you can configure the inactive
and active levels of SCLK to be either high or low.  At those times
when I need to add a few extra clocks (past the 16 configured in the
SPI),  I often set the SCLK properly (e.g. low between samples), and the
GPIO for the same pin to a high level.  I can then generate extra clocks
by simply switching the configuration from SPI to GPIO and back again.

It does tick me off sometimes that ADC manufacturers design parts that
need 18 clocks to return a 16-bit value.  ;-)


Mark Borgerson

On 2004-02-20, Mark Borgerson <m-a-r-k@oes.to> wrote:
> I guess that's why I always like to have a few extra GPIO pins.  Just
> run the same signal to the CAPture pin and a different pin to read the
> level.  Then  there's no need to reconfigure the capture pin and
> you shouldn't miss any events that happen within the capture timing
> limits.

Yep.. we just ran out of pins, although this was a small and simple device.
I guess I'm too used to MMC2114 and all its I/O pins.. :-I

  -jm

In article <slrnc3cpgj.js.jmarin@pyy.embedtronics.fi>, 
jmarin@pyy.embedtronics.fi says...
> On 2004-02-20, Mark Borgerson <m-a-r-k@oes.to> wrote:
> > I guess that's why I always like to have a few extra GPIO pins.  Just
> > run the same signal to the CAPture pin and a different pin to read the
> > level.  Then  there's no need to reconfigure the capture pin and
> > you shouldn't miss any events that happen within the capture timing
> > limits.
> 
> Yep.. we just ran out of pins, although this was a small and simple device.
> I guess I'm too used to MMC2114 and all its I/O pins.. :-I
> 

Been there,  done that.  Had to add a latch and address decoder to the
last project because I ran out of output pins.   Luckily,  I had a chip 
select and  a lot of spare address space, so it only took a 74LCX32 and 
a 74LCx574.

I think there's a rule that I/O requirements always equal pins available
plus 1.  If you add more pins,  the customer feels cheated if they
don't get used!


Mark Borgerson

Yes I figure 8051s, AVRs amd even MSP430s had better look out for
LPC2100 and the forthcomming ARM7s from Atmel. I do think the single
oscilator and divide down to 32Khz for RTC on the LPC210x is a bit
weird though!.

IAR is getting cheaper with the times -healthy competition from
Imagecraft, Rowley Crossworks and to a lesser extent hombrew GNU tools
has caused this.

www.iar.com shows a LPC2106 eval board, USB JTAG and 32Kbyte IAR
integrated compiler/JTAG debugger for under 500 USD.

IAR is probably the largest 8-32 bit compiler company in the world
-yes with an office in Denmark even ;) This has allowed IAR to develop
the docking windows IDE of the EWARM compiler 4.10A, very soon these
docking windows will be used in EWMSP430 3.10A. OK it still lags
MSVC++, but as one that used the DOS IAR 6811 compiler it has come on
a long way.

IAR does 8-32K limited compilers for those on a budget -and has
healthy discounts for educational use.

Jason Moore CEng
Embedded Software Engineer IAR UK

On 2 Mar 2004 14:54:27 -0800, jason_ceng@yahoo.co.uk (Jason Moore)
wrote:

>Yes I figure 8051s, AVRs amd even MSP430s had better look out for
>LPC2100 and the forthcomming ARM7s from Atmel. I do think the single
>oscilator and divide down to 32Khz for RTC on the LPC210x is a bit
>weird though!.
>
>IAR is getting cheaper with the times -healthy competition from
>Imagecraft, Rowley Crossworks and to a lesser extent hombrew GNU tools
>has caused this.
>
>www.iar.com shows a LPC2106 eval board, USB JTAG and 32Kbyte IAR
>integrated compiler/JTAG debugger for under 500 USD.

Does the weaker dollar/stronger euro not maybe have something to do
with this ? Or is the euro price also down ?

>IAR is probably the largest 8-32 bit compiler company in the world
>-yes with an office in Denmark even ;) This has allowed IAR to develop
>the docking windows IDE of the EWARM compiler 4.10A, very soon these
>docking windows will be used in EWMSP430 3.10A. OK it still lags
>MSVC++, but as one that used the DOS IAR 6811 compiler it has come on
>a long way.
>
>IAR does 8-32K limited compilers for those on a budget -and has
>healthy discounts for educational use.

If one wants an IDE with every compiler, then all this added stuff is
usefull. I personaly prefer a command line tool, with the same editing
environment for all my different compilers. If IAR makes it easy to
use gcc and other compilers with their IDE, it might be worth a look.

Regards
   Anton Erasmus

"Anton Erasmus" <junk@junk.net> escribi&#4294967295; en el mensaje
news:bebc40l7ns6iut6g7up2cfepet1a212nfb@4ax.com...
>
> If one wants an IDE with every compiler, then all this added stuff is
> usefull. I personaly prefer a command line tool, with the same editing
> environment for all my different compilers. If IAR makes it easy to
> use gcc and other compilers with their IDE, it might be worth a look.

 Eclipse (http://www.eclipse.org) integrates with the GNU tools like a
charm. It even parses and interprets 'make' output, and corrects Java, C &
C++ on the go. The user and tools base is growing stronger each month (in
particular, the UML tool is starting to look very nice).

 Regards.

--
PabloBleyerKocik /"Develop for it? I'll piss on it!"
 pbleyer        / Bill Gates response on developing
  @embedded.cl / software for the NeXT.

rickman <spamgoeshere4@yahoo.com> wrote in message news:<40305018.F8CCF807@yahoo.com>...
<snip>
> 
> BTW, no one was comparing off chip Flash.  The comparison is on chip,
> wide Flash vs. on chip, narrow Flash with cache.  
> 
> 

Well I guess YOU are comparing off-chip flash to on-chip flash. The
OKi and ATMEL flashes are in package flash but not on-chip flash. Both
are multichip modules. Exactly the same as off-chip flash, well they
are off chip. The Philips Flash in on the same die, not multiple
chips, one chip. This is on-chip flash.

Cheers, Schwob

Schwob wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<40305018.F8CCF807@yahoo.com>...
> <snip>
> >
> > BTW, no one was comparing off chip Flash.  The comparison is on chip,
> > wide Flash vs. on chip, narrow Flash with cache.
> >
> >
> 
> Well I guess YOU are comparing off-chip flash to on-chip flash. The
> OKi and ATMEL flashes are in package flash but not on-chip flash. Both
> are multichip modules. Exactly the same as off-chip flash, well they
> are off chip. The Philips Flash in on the same die, not multiple
> chips, one chip. This is on-chip flash.

You might want to explain that to OKI.  They seem to think they are
selling a monolithic part.  

But you are right about Atmel.  However, this does not matter in the
discussion because the speed of flash is not slow because it is on chip
or off chip.  It is fundamentally slow.  

The real issue is that Jim seems to think that having a higher bandwidth
to the flash will always be faster than using a cache.  Obviously this
is not a valid assumption.  Code that is small and has a lot of
discontinuities beyond a single flash read will run slow since the
entire word is not utilized wasting bandwidth.  But a cache can run fast
regardless of the discontinuity as long as the misses are few.  So it is
a trade off between code continuity and code locality.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

rickman wrote:
<snip>
> The real issue is that Jim seems to think that having a higher bandwidth
> to the flash will always be faster than using a cache.  Obviously this
> is not a valid assumption.  Code that is small and has a lot of
> discontinuities beyond a single flash read will run slow since the
> entire word is not utilized wasting bandwidth.  But a cache can run fast
> regardless of the discontinuity as long as the misses are few.  So it is
> a trade off between code continuity and code locality.  

  A small correction is needed here. I did not use the term Cache - my
comparison was based on FLASH memory WIDTH, and how that matters.

  I was pointing out that, given the finite speed of FLASH, a sensible
engineering solution is to make wider FLASH.
  Code will jump, of course, but large chunks are contiguous and those
certainly benefit from having wider data paths, to allow relatively 
slower FLASH keep up with the core.
  It's rare code that is 'nothing but jumps'....

  Cache size, depth, and whether to have separate code or data cache,
is a whole different topic.

  Another benefit another poster mentioned, was that with wider flash the
16/32 bit opcode differences in Thumb/ARM opcodes, the speed impact of
bigger opcodes is less, (but they can 'do more') so SW might benefit 
from being recoded in such wider path chips.

  Of course, if your chip has a cache, and such recoding shifts from
'fits in cache' to 'no longer fits in cache', then you will
go backwards :)

  Point is to realise how the HW works to get its speed, and how to best
make use of that bandwidth - and also when comparing devices, to check
finer details like memory width.

-jg