SPI interface Take 2

why would that be?

is te ADC so dumb it cant clock and buffer?

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
Loading thread data ...

No?

formatting link

Read it. The sound chip is a system with several A to D and D to A converters,its own internal CPU which has an oscillator to drive its clock and input and output buffering and its internal DMA as well.

And that's 'what every X86 motherboard has' these days., Or better.,

shhesh.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

Yes as a matter of fact. ADCs are typically *very* dumb. They are designed to optimize the analog aspects. Some have more logic than others, I can't recall one having a crystal. If they have an oscillator it is only for internal purposes and not to control the sample rate. And of course there will be the exception that proves the rule.

The point is why would the ADC need a clock? There are tons of them running around the digital circuits. One with an SPI interface will need a way to inform the CPU the sample has been taken. Polling the interface would be very inefficient. An extra pin could be used ...or... the CPU can just tell the ADC when to sample by taking the data.

--

Rick
Reply to
rickman

A DMA controller IS a stripped down CPU, you **** and it works by polling.

If its an IO control port and data port its talking to.

Interrupt is always one processor talking to another: At dumb level there is only 'polling'

Really, get an education.

The whole point of smart peripheral chips is that the smart peripheral chip 'does the polling' and then issue an interrupt to the CPU to ecahngege data with it.

From the very first UART that didn't need you to waggle the serial pins directly, peripheral chips have had their won CPUs and clock, and RAM.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

They are not ADC chips. As you say, they are sound systems with... wait for it... DMA (not a CPU). So of course it will need a clock. Look at figure 1 if you are not sure. The CPU shown is the x86 (or ARM) behind a bus.

Can you stick to the context? This discussion is not solely about audio.

--

Rick
Reply to
rickman

Well, it depends on what the ADC's main purpose is. When it was designed to sample a voltage at random moments determined by an asynchronously running program, e.g. for telemetry or process control, it probably is like you describe.

But, as I have tried to point out before, today there exists another category of ADC, designed for sampling a signal at a preset rate.

For those it is very common to have a crystal and to operate automatically, moving out the data into a buffer or via a serial connection to a DSP or similar processing hardware.

Because everyone uses these today, they are available in very high levels of integration. For example, a single chip that does A/D (and D/A) with built-in buffering and USB protocol. Same for PCI(e) etc.

Also in much faster versions, like >100MHz sampling rate. For software defined radio, for example.

Reply to
Rob

For the simple reason that when connected to a computer, if the computer has to do the timing it leads to crap audio and a huge CPU overhead, which is why sound chips are a lot more than A to D and D to A converters - a hell of a lot more.

If you want to do multiple samples at Khz rate, get a sound chip or three, or have a bank of arduinos to do the smarts.

I am doing stuff with real time audio processing and I went through all these hoops, and the answer was an x86 motherboard with a sound chipset not an Rpi.

A sound chip will sample, rate convert and buffer, and use interrupts on buffer full/empty/hi/lo states..

You may not get them exactly on time, but they will be identically spaced as to when they were taken, and none will be lost unless the latency exceeds the buffer size, which you can program as well.

using a bare A2D chip was a total waste, unless it was coupled to something like an arduino to drive it as THE priority task, buffer teh samples and spit them out via USB etc.

But why bother, when you an get pre-owned motherboards with full sound chipsets in cases with power supplies for almost nothing?

Or get one of these for yer Pi

formatting link

PI doesn't have sound really. Just steals cycles from somewhere else. Probably the GPU.

There are tons of them

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

You can curse as much as you like, it won't make you right. You can call it a "stripped down CPU" if you want. But it has little in common with a CPU. I know, I have designed CPUs, DMAs, even microprogrammed DMAs. A DMA circuit can be as simple as a small number of counters.

A DMA circuit does *not* work by polling. It has a hardware interface that either receives a handshake signal which is monitored at *all* times or it just runs as fast as it can until the block transfer is complete. Polling implies reading a register. I have not seen a DMA circuit do anything remotely like that.

Some computers have more intelligent controllers which *are* like simple CPUs. They are often called "channel controllers". Unlike a DMA circuit they execute a program and potentially could poll. But polling is an inefficient use of bus bandwidth which is often a bottleneck.

DMA doesn't normally read control ports as there is no intelligence to understand the meaning of the bits.

What? Absurd.

Ok, I think I'm done with this discussion.

What does that have to do with the topic I thought we were discussing?

What???? One of the very early UARTs was the WD1402A from Western Digital. It contained a pair of shift registers, two holding registers, some small counters and some random logic... nothing like a CPU which has memory and executes a *program*. Here is a short paper on the UART.

formatting link

Everything digital is not a small CPU.

I really am done discussing this off topic stuff. Go ahead and reply, I won't be responding to this anymore. ok? :)

--

Rick
Reply to
rickman

I'm sure that is a nice board, but it won't do the job I need.

--

Rick
Reply to
rickman

That depends entirely on your definitions. Its all just logic circuits in silicon, and if its clocked I call it a CPU. A shift register is a CPU executing a single very simple hardwired program that's all.

Its got ram, its got IO ports, and it has its instructions.

CPUS don't HAVE to have von neumann architrectures you know. Or stacks.

Well since you know SO much mnore than anyone else here, one wonders why you bothered to ask stupid questions in the first place?

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

I have looked at code and the cpu documents and I did not see that ability.

>
Reply to
hamilton

What is it that triggers the DMA actions?

--

Rick
Reply to
rickman

On SPI then chain several ADCs together and check data sheet for the device, most suppoirt linking together so 6 x 12 bit ADCs each produce a

16bit frame for data, but is read by SPI controller as a long 6 x 16bit (96bit) transfer. This is a common technique used by many SPI devices. Then it is a matter of how you decode the data.

But as we have no idea which ADC how many channels have simultaneous sampling involved, bit depth, sampling rate on each channel, sampling length most of this is handwaving.

Either be clever with your hardware design and user application or write a specific driver for the SPI ADC in your configuration.

There is a fairly recent MagPi article of device driver for GPIO reading at around 6MHz (untimed or synchronised) that will give you an idea of how to do it.

Alternatively do it with dedicted micro like Arduino and transfer to Pi by whatever means you can achieve as blocks of data. The only part that needs to be guaranteed is that the sampling of data is done at exact intervals with no gaps or repeats. Once you know data is in block like that you can assume they are timed correctly blocks of data for processing.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
 Click to see the full signature
Reply to
Paul

You definition seems to be at a tangent to the universe.

I have dealt with many embedded systems, and FPGAs and ASICs and designs thereof and many complicated devices that have no RAM or registers just data paths the vast majority of devices do NOT contain CPUs or simple hardwire programs. I am sure the 8 x 8 x 8 Video scaler chips I used on one project were NOT CPUs, NO RAM or registers.

By your definition a LED flasher chip is a CPU but it is only a counter and clock source.

Also even a chip like 74xx00 (4 x 2 input NAND gates) is a CPU as it has I/O ports.

No the most common are Von neuman and Harvard, but others exist primarily in mainframes and some dedicated processors for things like graphics and network processing. SOME newer devices (in last 10 years mainly) do have processors in but not all. Example being most camera, network, graphics and USB device chips. Many other chips exist that are DUMB and NOT have any form of CPU.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
 Click to see the full signature
Reply to
Paul

Yes, these are all interesting ideas. But, it seems rather silly to have to add an Arudino to an rPi just to do I/O. In fact there is some irony in that many MCUs have exactly the right sort of DMA driven ADC hardware that is needed for this sort of thing. In the end it is likely easier to get the MCU to do the processing of the collected data than it would be to get the rPi to do the collection.

I wasn't able to find the MagPi article on fast GPIO. I found lots of led and switch interfaces, but nothing that might be useful for this. Can you point me to the article you refer to?

--

Rick
Reply to
rickman

MOST !!! Show just ONE !

so 6 x 12 bit ADCs each produce a

Reply to
hamilton

On Wed, 17 Sep 2014 17:15:15 +0100, Paul declaimed the following:

Since CPU derives from Central Processing Unit -- referring to the part of a computer /system/ that performed the actual system processing, I wouldn't even include most of those examples. Graphics/USB/Network are what I would refer to as an IOP (Input/Output Processor), especially if DMA were involved...

Yes, the controller in a network interface may have all the functionality (perhaps an 8-bit processor while embedded within a 32/64 bit computer) but it is not "central" to the purpose of the computer.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

Issue 24 - Piscope, Linux Kernel driver for adding a high speed (up tp

13MHz) Vidoe ADC 6 bit
--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
 Click to see the full signature
Reply to
Paul

Thanks. I found it and downloaded it. I'm having trouble reading the source code in the magazine format, lol. A PDF file is not a text editor. I also don't understand some of the stuff he talks about, like when he says,

"The GPIO bit samples may not be synchronised with the clock. This can cause bits to be read from the same sample twice or be missed. This can be improved by setting the clock as close as possible to the frequency of the GPIO readout."

I'm not sure what he means by "the frequency of the GPIO readout". Regardless I am concerned that he talks about this being "improved" by setting the clock, not that it can be dealt with. This sounds like he is depending on the reads to stay synchronized somehow rather than having a synchronization technique.

I'll have to look at it more tomorrow. Thanks

--

Rick
Reply to
rickman

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.