A theoretical project?

Dave Paton

Specifically, a very high sccuracy function generator for low frequencies (1-100Hz). Right now, the design document on my desk·sepcifies a 14 bit(!)·synthesized signal with a differential output. From the little spreadhseet I put together, that means my cycle time per step at 10Hz is a leisurely 61uS +/-. Up at 100Hz however, it shrinks to a very tight 610nS, which I fear is too quick for an SX to do the push-pull-repeat dance it needs to do to get the data to the outside world, let alone actually calculating the values on the fly.

My question to the forum denizens is if any of you have done something similar? I know folks are using them for very short loop projects, but since it's been too long since I did interrupt based assembly, I'm curious if someone can whip out an envelope with a blank back and a pencil and tell me if it seems possible? The 100nS cycle time from the datasheet makes me think it might be possible, but I'm worried about there won't be enough cycles to do anything but push the dual-byte word out.

TIA

-dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.

Post Edited (Dave Paton) : 12/14/2004 5:34:46 PM GMT

Jon Williams

Even at 50 MHz? At that clock rate you have a 20 nS instruction cycle.· And can you use tables to hold your waveform data?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office

allanlane5

This does not compute.

"High accuracy for low frequencies" -- 1 Hz is 1 cycle / second. Yet you are cycling at 10 uS/step -- which is 100 KHz. What are you doing at 100 Khz that you repeat every second?

So these are NOT 'low frequencies' -- you are just repeating them at low rates.

The issue becomes, how accurate is the clock you are using to clock the SX? If you really-really want 14 bit accuracy (in amplitude) does that go along with 14-bit accuracy in time?

Lots of unanswered questions here.

Dave Paton

Jon-
My concern isn't the inter-instruction timing (20ish nS, blindingly fast), but the interrupt cycle timing, which the datasheet implied was >=100nS. Did I misread it?

Allan-
Well, the high accuracy is due to the 14 bit synthesis of·a sine wave. 2^14 is a whole lot of values....16,384 to be exact. At 1Hz, the generation frequency is thusly 16.384kHz (61.035uS cycle), which is easy. Up at 100Hz though, it's 1.6384MHz, which is tighter (610.35nS cycle), and is the basis for my concern, especially since I'll have to spit the data out to a DAC after reading it from external memory.

In reading over the post, I realise that I did omit a lot of details. The system will probably work like this:
SX grabs a value from external memory, pushes it off to an external DAC, and repeats until told to stop or change frequencies. I've also been asked to provide input attenuation, probably in the form of scaling the read value before it hits the DAC (a happy little unit I've used before). Control interface is TBD, but will likely be simple (bitwise depending on pin availability?)·and custom since there's another uC in the system that will act as an interposer between the SX and the real world (there are other housekeeping tasks it does as well).

The 6uS was a typo which has been corrected.

Because of the nature of the project, I don't need to hit the frequency intervals precisely, but I do need the wave to be accurate. IE, I probably can't hit 21Hz precisely, but I can probably hit 21.xxxHz reliably, which is just fine if I can maintain that frequency with minimal amplitude and temproal distortion components. 14 bit amplitude accuracy and 8 bit temporal accuracy have been deemed "good enough" by the non-engineering folks who did the requirements. I'll likely be using a crystal rather than a resonator or an RC system, but the stability of the system clock is a relatively easy to handle issue. I'm more concerned with how skimpy I'm going to have to make the program to get the code to fit.

Now if I did misread the data sheet, and the cycle time really is 20nS, then I can do things without much fuss, and I'm worried for nothing.

I'm not really thrilled about getting a requirements document for a project I'm not part of the design of, but in this case I'm paid to implement what's written.

Pleaese forgive any missed typos or addled logic...it's freezing in the office and the HVAC guy only just arrived. I'd really love to feel my fingers before I go home tonight.


-dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.

Paul Baker

look at the retiw instruction, it permits you to adjust the rtcc interrupt rate to whatever precise delta-T you need, and·the prescaler permits you to scale up or down the base rtcc overflow interrupt rate.

Dave Paton

I actually just noticed that as I was paging through the instruction listing. Now all I need to do is remember how to code in asm, forget it, and then relearn it for the SX.

I think I'll start with some SX/B stuff first. The water in the asm pool looks really cold right now, like my office. The HVAC guy still hasn't fixed the heater, and it's 25F outside!
Plan on seeing a lot more noob type posts in here form me as I ease myself back into the world of ASM...

-dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.

Post Edited (Dave Paton) : 12/14/2004 8:55:03 PM GMT

Paul Baker

I discuss methods of adding external ram ad nauseum in this post if your interested:
http://forums.parallax.com/showthread.php?p=465138

Paul -needs to reinstate his home internet connection ASAP, since he seems incapable of not posting in violation of his draconian IT department's acceptable use policy.

Dave Paton

Thanks Paul. That will make some interesting reading over my extended lunch hour (business is slow right now .

Thankfully my IT folks follow a don't ask dont tell policy. As long as we're not fishing for...um..images, or gambling, or doing things which are illicit or reprehensible at the office, or sucking up more than our share of bandwidth (no streaming radio), we're free to do as we please. I do however recall a previous amployer, who provided the engineers with high end workstations only on the condition that they were completely blocked (as in air-gapped, not just firewalled) from anything outside the LAN. It made updating design tools and grabbing datasheets a real PITA, so I feel for you.

Thanks

-dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.

Dave Paton

It looks like I'll be harking back to my 8052 days more than I thought for this. The timing figures I'm·looking at, and the cycle time I have to work inside,·make me believe that the only way to make this work is as follows:

-32Kx8bit serial EEPROM for NV waveform data storage (http://rocky.digikey.com/WebLib/Microchip/Web%20Data/24AA256,24LC256,24FC256.pdf)
-16Kx16bit parallel SRAM for runtime waveform storage (http://rocky.digikey.com/WebLib/Cypress/Web%20Data/CY7C09269A,%20CY7C09369A.pdf)
-parallel DAC for waveform output
-SX with enough pins to make it all work with 14 bit words (really 16 bit, but the top 2 are either going to be throwaways or used for 2's compliment output).


Any thoughts? This kind of speed and accuracy is new to me, being a hard core 8 bit guy. I'm sure I can do it, but sometimes having a little guidance is good. And yes, I realize the RAM is a dual port part, but it's hard to find 5V RAM in 16Kx16 sizes in single port chips. Really hard actually.

I'll post the initial SW flowchart soon for design comments.

Thanks

-dave
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.

Post Edited (Dave Paton) : 12/15/2004 8:31:18 PM GMT

allanlane5

One suggestion: to save I/O pins on the SX28, you might want to have an external 'page' select latch chip. The idea being you could load 8-bits of 'upper address' for your external RAM, then count through the 8 'lower address' bits with 8 pins of the SX (plus a pin for 'READ', plus the 8-pins needed for the data).

With this approach, it looks like you'll be building an 8-bit data buss off the SX, anyway.

Whoops, just saw you are doing 14-bit data.· I suppose you could do this with two reads of an 8-bit buss, especially if you can do it at 20 nSec.

Worst case, design an external counter-based addressing scheme.· Have two 'strobe' lines -- one for the high-byte, one for the low byte.· This way, you can have a small, private 16-bit bus between your SRAM latch and the DAC.· Strobe low to read the low byte into an 8-bit latch from the SRAM.· Strobe high to read the high byte.· Strobe the DAC to write the data out.· Strobe 'count' to increment an address pointer for the next two bytes.

Wait a little while, and do it all again.

Post Edited (allanlane5) : 12/15/2004 9:19:43 PM GMT

Dave Paton

Allan-

I've been mulling over various and sundry architectural shortcuts, including the high/low latch and the bussed transfer tricks, but I've just been told they also want software controlled attenuation, which I can do pretty easily with either basic math or bit shifting, but it requires that all the data be piped through the SX. With a 20nS cycle, I think I can get it all done, but it's going to be close at the highest frequencies We'll see. I still need to look into the timing and setup requirements of the internal timer interrupt code. I may wait until Monday to do that, since I'm still trying to get the boss to approve early research expenditures so I can start playing with real hardware (SX-Key/SX Tech board/dongle).
After looking at the intricacies of using that very nice but really annoying dual-port RAM, I think I'm just goint to make everything into 8 bit chunks and use a 32kx8bit for both storage (serial)·and runtime (parallel)·memories. It makes the pincount slightly easier to handle, and the code shouldn't change too much if I keep them on seperate ports. I'm debating the merit of putting the DAC on the same bus as the RAM, but I think it'll work out better if it gets it's own pair of ports, since it's not an addressable item and uses words instead of bytes.

-dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.

Post Edited (Dave Paton) : 12/16/2004 4:51:09 PM GMT