Re: Blue Chip Technology + MagnumX?

John Devereux wrote:
David Hearn <dave@xxxxxxxxxxxxxxxxxxxx> writes:

Has anyone got any experience of Blue Chip Technology
(http://www.bluechiptechnology.co.uk/) and especially their MagnumX
single board computers?
(http://www.bluechiptechnology.co.uk/single_board_computer.php?sub_group_id=2)

We've been investigating the ColdFire MCF5475EVB for some quite simple
5 channel GPIO capture - but at quite high data rates. We've got the
266MHz ColdFire processor to do what we want but it just isn't quite
fast enough - it's missing some of the state transitions on the
channels. We're sampling at around 2 to 2.2MHz and we need more like
3.3MHz.

We were wondering whether a faster (2x?) processor would be more
likely to do the job. The 733MHz MagnumX board sounds like it might
do this, and it has 16 channels of GPIO (we only need 5 inputs at
present, unlikely to increase significantly). I'm aware it's moving
from the ColdFire/M68K processor to an x86 processor, but unless
there's a major difference in per cycle processing, that's not a
problem.

Our app is quite simple - loop until a counter expires, each iteration
store 1 byte pin state register and 32 bit counter value. We
currently can sample up to 60MB of data.

Can you not use DMA instead? And/Or perhaps an external FIFO.

Personally, I have no idea. I've never used DMA before (I'm traditionally a desktop app guy!) - so I'm not sure where I would start, or what I'd need to do. Essentially, we just want to move a 8 bit GPIO register containing pin status and a 32 bit register containing a counter value into RAM as fast as possible - at around 3.3MHz (sample every 300ns).

So - any experience of the MagnumX would be good - especially with
respect to the need for an OS (currently no OS, so no overhead on the
ColdFire - just simple ELF application). DOS would not be suitable as
we'd need to (easily) be able to access 60MB+ of RAM.

It sounds like this application depends more on the GPIO rate rather
than the CPU core clock speed.

Yes, I think this also affects the speed of capture - however, we found the following approx from memory benchmarks:

Sample 8 bit GPIO register, copy into RAM: 2.2MHz
Sample 32 bit slice timer register, copy into RAM: 2.15MHz
Sample 8 bit GPIO + 32 bit slice timer register, copy into RAM: 1.8MHz
Sample nothing (and store nothing) but otherwise same code: 4MHz

This to me suggests that the bottleneck is either memory or reading the registers.

We've also benchmarked how fast we can toggle the GPIO when configured for output (rather than input) and I think it was 50ns level state (so every 50ns the pin output toggled). The fastest we need to sample at is around 300ns. So unless input capture (via polling) is 6 times slower than output, I can't see that currently the GPIO speed is a problem.

Of course, when considering another architecture, we need to ensure that the GPIO speed is considered.

Thanks

David
.

Relevant Pages

  • Re: Blue Chip Technology + MagnumX?
    ... We've been investigating the ColdFire MCF5475EVB for some quite simple ... channel GPIO capture - but at quite high data rates. ... and it has 16 channels of GPIO (we only need 5 inputs at ... store 1 byte pin state register and 32 bit counter value. ...
    (comp.arch.embedded)
  • Re: Blue Chip Technology + MagnumX?
    ... We've been investigating the ColdFire MCF5475EVB for some quite simple ... channel GPIO capture - but at quite high data rates. ... store 1 byte pin state register and 32 bit counter value. ... may set a register to control timing and control). ...
    (comp.arch.embedded)
  • Re: Blue Chip Technology + MagnumX?
    ... We've been investigating the ColdFire MCF5475EVB for some quite simple ... channel GPIO capture - but at quite high data rates. ... store 1 byte pin state register and 32 bit counter value. ... Originally to save RAM, we only logged the pin state if it had changed, but this added a little processing into the loop, and also required the use of the counter to get timing values as the time for each iteration would change depending on whether the pin state had changed. ...
    (comp.arch.embedded)
  • [PATCH 01/13] core generic GPIO support for Freescale Coldfire processors.
    ... This adds the basic infrastructure used by all of the different Coldfire CPUs. ... without even the implied warranty of ... * GNU General Public License for more details. ... * The Freescale Coldfire family is quite varied in how they implement GPIO. ...
    (Linux-Kernel)
  • Re: `How to resume ce 6.0 from PXA 27x standby mode?
    ... Standby mode or the GPIO will be held in its sleep-mode states. ... >> First,standby mode unit retention bits in PSTR register are set ... >> and keypad wake up source is enabled in PKWR register and the ...
    (microsoft.public.windowsce.platbuilder)