c question

advice.

chip, on a

FAT32.

away the

card. I

4

are talking

specifically

FIFO, I assume

there's an

for loop,

around

need help,

would be

we'll

routines

Yep, you are just barely on to the beginnings of loop unrolling. Pretty well optimized by compilers many years ago.

?-)

Reply to
josephkk
Loading thread data ...

would be

we'll

Linux does NOT need MMU and paging HW. That is mostly an artifact of overly heavy Desktop environments like KDE. It will use it if you have it. Throw a decent amount of RAM at it and do not create a swap partition. You are done, no paging. I have built systems like this and systems that have a swap that is not used.

?-)

Reply to
josephkk

advice.

chip, on a

FAT32.

away the

card. I

4

are talking

specifically

FIFO, I assume

there's an

for loop,

in 256

of ram,

different loop

call it

What ever let you think that there was no experimental part of science?

?-)

Reply to
josephkk

A decent implementation ought to but some may not.

Increasingly the loop unrolling and cache management is done in hardware these days provided that you run through memory sequentially and start on a cache line boundary. Often it is the shortest tightest loop that wins although the optimum instruction order may vary.

Many modern CPUs have speculative execution with backwards conditionals treated as if they are always taken and forward lookahead cache loading.

Certain magic lengths will be quicker than others usually lengths of the form k.2^N bytes depending on the cache architecture. You can take a pretty good guess at these values by reading the specifications.

--
Regards, 
Martin Brown
Reply to
Martin Brown

The DMA does not set the transfer rate, the source device does that. Say you have a timer running at 10kHz and a DMA with 1MB/s max rate, the timer will use only 1% of the bandwidth with one byte per DMA transfer

That's the point of DMA in small device, making peripherals able to run with the CPU in sleep mode, running DMA transfers from peripherals to peripherals

It either runs indefinately, or you set the number of bytes you want to transfer

The buffer does not overrun

Check the Cortex technical reference, it's all in there

Cheers

Klaus

Reply to
Klaus Kragelund

in the

optics,

hunches)

most of the

at 25

channels

performance is

builds,

Perhaps you could rephrase the question. e.g. How fast can the DACs go? How does accuracy degrade with speed? Then, how do we feed them at that speed?

magnitude,

Sometimes it is asking the right questions of yourselves.

?-)

Reply to
josephkk

on an

use the

code

out of

diccussion.

the

know all

that.)

extra

not just

(speed)

it play

What is the limit of the DACs and the ADCs. Shoot for that speed.

Reply to
josephkk

I can buy ADCs and DACs up to hundreds of MHz, but the SD card can only be read at around 10 Mbytes/sec. The system max performance is going to be limited by how fast I can read the FAT32 waveform files and stuff the data into the FPGA. And of course, I have to control the transfer rate, like if the original data was acquired at 20 KHz or something.

--
John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    
 Click to see the full signature
Reply to
John Larkin

does.

paging is how the executable code gets into RAM.

--
umop apisdn 


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

Our Linux is small, about 5 Mbytes, and all our apps are not much bigger. We have 1 Gbyte of DRAM on microZED. Our Linux remaps every memory-resident program with the MMU, in pages, but it doesn't do virtual memory, in other words it doesn't swap pages out to disk/flash. It doesn't need to.

Some RTOSs run a flat memory model without MMU remapping, but each program has to be PIC (position independent code) or compiled to its absolute runtime address.

--
John Larkin         Highland Technology, Inc 

jlarkin att highlandtechnology dott com 
 Click to see the full signature
Reply to
John Larkin

Linux can operate out of ROM, too. However, you know perfectly well what JKKK was talking about.

Reply to
krw

About the SBC - If it has a usb 2.0, does it make sense to hang a SSD with USB2SATA converter on that port? USB 2 seems the current state of dev on SBC. I don't see anything about this, except for a make guy who made a laptop from a Razz Pi board.

Reply to
haiticare2011

KDE.

and do

Very much so. And paging to load programs is not needed if the whole thing fits comfortably in RAM. Throw 8 or 16 GB of RAM in a typical PC and even outrageous bloatware like MS Office snuggles down in RAM mostly.

?-)

Reply to
josephkk

file on an

We'll use the

ARM code

run out of

diccussion.

sure the

know all

that.)

extra

not just

(speed)

can it play

be read

limited by

FPGA.

data

You evaded the question. Speed comes at cost. Just how much faster were you contemplating and what price did you want to set? I have no doubt that you could do 16 channels of 12 bits at 1Gs/s or 16 bits at 50Ms/s both ways. Neither instrument would be cost acceptable for your current customer. It is up to you to decide just how much more you want to do to keep the current customer happy and attract other potential customers.

I had the impression that the DACs and ADCs with peripheral circuits for the project had already been targeted for performance and price. Stick with that and what numbers do you get?

?-)

Reply to
josephkk

If the SD is really that slow, why do you insist of using SD instead of a hard disk ? Size ? Vibration ? Power consumption ?

If a single disk performance is not enough, build a RAID 0 set with multiple disks in parallel.

Of course, you need to store your data into preallocated contiguous files to avoid as much of the seek times as possible and only having to deal with some track-to-track seeks.

If the DACs are connected to a 64 bit CPU and using any decent 64 bit OS, simply use memory mapped files, associate the file with a few terabyte array and start accessing that array sequentially and the OS page fault mechanism will bring in the data from disk as the array is accessed. Of course you need to do some read ahead to compensate for seeks etc.

Use an other pointer for getting data to the DAC. This second pointer is trailing after the first pointer. If the distance grows too large (larger than the physical memory), stop advancing the first pointer for a while, until the second is catching up.

No separate FIFOs needed, since both pointers access the same _huge_ linear array sequentially.

Reply to
upsidedown

We plan to use the microZed board, because it has the ZYNQ FPGA and all the support stuff, like ethernet and dram, all done for $200. And it has an SD card slot, no hard drives. All that will fit nicely into a small box.

It will be a lot like this:

formatting link

formatting link

formatting link

The advantage over some more conventional SBC is that the CPUs are tightly coupled to the FPGA fabric, on the same chip in fact.

Under Linux, our code will occasionally be suspended when the CPUs are needed for other things. Even if we had a cpu 100% of the time, it would be hard to write code to feed the dacs at a constant rate in the 1 MHz range. Hence the need for hardware FIFOs to feed the DACs.

--
John Larkin                  Highland Technology Inc 
www.highlandtechnology.com   jlarkin at highlandtechnology dot com    
 Click to see the full signature
Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.