Re: Blue Chip Technology + MagnumX?

David Hearn <dave@xxxxxxxxxxxxxxxxxxxx> writes:

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).

Paul Carpenter beat me to to most of the points I would make. I would
just wonder whether you actually need the counter - if the samples are
being aquired reliably then perhaps the sample number can give you the
time?

Anyway, DMA uses special hardware facilities to move data around,
rather than doing it in software. Look it up in the data*** for your
coldfire chip. You should be able use the output of a timer to trigger
a DMA transfer from a PIO port to memory, at a programmed rate.

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

Have you turned on the cache?

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.


--

John Devereux
.