HUB Instruction indeterminate timing issue

Richard Morrison

I'm considering a data acquisition system using a Propeller plus external serial DAC and ADC's for use in a scientific instrument application - data rates of say 100-200 ksps at 12-16 bits resolution (which would obviously need to be coded in Assembler). I would like to dedicate a significant portion of the Propeller's main memory space to set up a data table and devote one half of this for the DAC waveform and the other half to store my ADC readings. My plan would be to use one COG to manage the digital-to-analog conversion, a second to handle the ADC and a third to manage USB transactions to a PC using (say) an FTDI chip to both down- and upload data to/from main memory. WAITPEQ or similar instructions would be useful for signalling purposes between COGs.

However in most such applications it is necessary to maintain precise timing between samples or readings. Given the mechanism via which the Propeller's COGs gain access to main memory this approach seems problematic - since execution times will range from 7 to 22 clocks for each HUB instruction like RDWORD or WRWORD. Am I correct ?? Is there any clever way to manage this problem through software to ensure one maintains a precise sampling frequency or is there simply no way around this but to opt for use of an external memory ?? If the latter then the 64 I/O version of the Propeller with the extra B port looks like a very attractive option as the additional address and data buses required would eat up most remaining I/O resources. Any thoughts ?

Bean

Richard,
From what I understand of the way the hub works the variation in the number of clocks required is because if the hub just passed the cog's time-slot, the cog will have to wait for the cog to come the whole way around again (22 cycles). If the hub is right at the cog's time-slot the cog will get access very quickly (7 cycles).

By properly interleaving hub access instructions with other cog instuctions you should be able to sustain 7 cycle hub access times.

Someone please correct me if I am wrong on that...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com


COMING SOON "SD DATA LOGGER" www.sddatalogger.com

"I reject your reality, and substitute my own." Mythbusters
·

Richard Morrison

Bean

I think you are probably correct in what you say - I guess I need to look closely at the HUB timing diagrams to see how this works. Like many others on this forum my knowledge of Propeller assembler is going to need to come up to speed to implement my application !!

Richard

Andy Lindsay (Parallax)

I would look into writing assembly for a cog to capture the measurement at the correct time. It can do so by watching the cnt register, which increments at each clock tick. At the designated clock tick, the edge for capturing the ADC measurement would be generated and the measurement could be read immediately thereafter (or after some delay) and stored in cog ram. At a couple hundred ksps, there should be enough time (even though it's variable duration) for the cog to transfer the measurement to main memory. Then, the cog will use the assembly version of waitcnt to wait for the next time an edge needs to occur.

Another possible approach is to use the counter modules for timing. There are two per cog, and each consists of three registers: cnta/b, phsa/b, and frqa/b. They can be configured for a variety of background tasks including pulse trains at fixed intervals. Since that's happening in the background, the same cog can wait for the edge (waitpeq) and then store the measurement. It is also possible for separate cog to watch for that edge, and take a measurement a certain number of clock cycles later...

Richard Morrison

Andy

thanks for that information - very helpful. I was forgetting that of course the COG memory is available without the restrictions that apply to the hub. If worst case for the transfer to main memory is 22 cycles then I guess the RDWORD or WRWORD instruction itself would take only 275 nsec at 80 MHz, so at the data rates I am suggesting this won't be a problem. Great !

The 2 counters available on each COG are indeed extremely powerful and we have seen several neat examples of their use here already (Frequency Synthesizer, Sigma-delta ADC, DAC's etc) already. Does anyone know whether some documentation has been posted on all the different possible counter modes. If I recall correctly the CTRx[noparse][[/noparse]30..26] mode field (loadable via a MOVI instruction) sets the counter mode and that the counters have PLL, NCO and Duty Cycle variants but I think there are some other modes as well.

Richard

Mike Green

You can double buffer information using two COGS. One COG fills a buffer in COG memory using a small assembly language routine, then, using a semaphore, releases a second COG using the same program to fill up a second buffer. The first COG then copies the buffer to HUB memory and waits for the semaphore to begin again. The capturing of the data can be very deterministic with the two COGs using the cnt register to sample the ADC at the "right" times. If HUB memory is not big enough, you could use one or more SPI ferromagnetic memories (RAMTRON FM25L256) to store the samples. It'll take data at up to 20MHz serially according to the datasheet.

Andy Lindsay (Parallax)

Richard,

Here is a link to a post with what I'm pretty sure is the most up to date counter module documentation:

http://forums.parallax.com/showthread.php?p=581519

It's in the CTR.spin·attachment.

Andy

Post Edited (Andy Lindsay (Parallax)) : 5/16/2006 5:49:04 PM GMT