28x1 eeprom i2c interface problem

[Pacer]

Hi All,
I'm relatively new to PIC programming, and am having some difficulty writing some code to perform a specific task.

I have used a picaxe 28x1 to write some array code to a 24lc256 eeprom using i2c protocol. The code is in blocks of 255 hex values, which I want to use to output from the PIC into a DAC which then outputs a waveform (Direct Digital Synthesis). The code I'm struggling with is I want to be able to read the hex values sequentially from the eeprom, and output them in a similar fashion to the output pins of the PIC, then to repeat indefinately.
So what I need to know is:
Can this be done? and if so how?
Also,
Assuming the above is possible, How do I change the outputted waveform frequency?

Thanking you in advance of you answers.

 

[ylp88]

What kind of frequencies are you trying to achieve? i2c is a relatively slow bus and so you may have problems if you require high frequencies which need to you read and write a lot of data across the bus very quickly.

Otherwise, it should be a relatively simple process of using the READI2C command fro read your values back from the EEPROM chip and then passing that data on to the DAC using WRITEI2C or placing the data onto the output pins of the chip (I'm not sure whether you are using a parallel or i2c DAC). You can use a simple FOR loop to advance sequentially through the addresses. Frequency can be altered by adding a delay between each sample point (you may want to filter the output to perform "interpolation" between your sample points), but as I said before, depending on your requirements, you may have troubles achieving higher frequencies.

ylp88

 

[westaust55]

provided you are not looking at high frequencies as alluded to by ylp88, then what you suggest is quite possible.

knowing more about the DAC connections as ylp88 has requested will help define the solution.

More information all round would be very helpful in permitting others to better comment/assist.


You mention blocks of 256 bytes for the waveforms. Is each waveform totally contained within one 256byte "block" or across many "blocks"?

You suggest you already have some data in EEPROM. Then ask how to modify the wave forms. Need to know more before anyone can help further here.
Do you want a set of predefined waveforms (eg square, sinusiodal, modified sinusiodal, stepped, trapezoidal, some other formats?

Are there different frequencies involved?

What time resolution do you seek for each byte sample?
Keep in mind it will take a few instructions in a loop for EEPROM read to DAC write, so the program looping would be around 5ms or so. This suggests the sample rate would be of the order of 20 samples per second. Result would be fairly low frequency capability.

It is possible to read multiple bytes of information from an EEPROM at one time. Many examples use 8 bytes - the limitation is more on the number of variables are available to temporarily hold the data.

Scratchpad RAM within the PICAXE 28X1 is 128 bytes. If waveforms were short i duration may be possible to pre-load into Scratchpad RAM which would be faster than i2c comms bus reads.

If you have already tried some code, suggest that you post it so that all on this forum can have a read and offer possible solutions. (there is usually more than one solution to a problem).

 

[Pacer]

Thanks for your reply ylp88
The frequencies I want to generate are relatively slow, only upto a few hundred hertz, as its just going to be a simple waveform generator. The resultant signal following the parallel DAC, I intend to use an amplifying op-amp buffer to smooth and amplify the signal.
Just let me try and understand the code part of what you are saying, I read each byte from the eeprom by using the readi2c command place this byte into the pic register, say b0, then send this to the output pins. I'm still unsure what command I need to perform to then fetch the next byte in the table into b0, and so on. Do I have to write the code to fetch each byte seperately upto the 255th byte? Sorry quite new to all this, so still trying to get my head around alot of the code

 

[Pacer]

Thanks Westaust55
Yes, each waveform is made up of only one block in the eeprom, each consisting of 255 bytes of data. I've already programmed multiple waveforms into the i2c eeprom (sinewave, squarewave, etc).

Would you recommend reading the eeprom in say 8-byte chunks, store in the PIC, output these to the DAC then refresh with the next 8-bytes from the eeprom, or is it possible to retrieve it in 2 hits, of 128-bytes into the scratchpad?
I've not attempted any code yet, just trying to get my head around it first.

Any code ideas would be greatly appreciated.

 

[moxhamj]

It is going to be pretty slow. You need to wait a bit between each cycle. The pause statement waits maybe a millisecond, so to get the resolution with the frequency you might wait 100ms for one frequency and 101ms for another. So the max frequency might be tens of hertz.

I've pondered for some time using a whole pile of 64K ram chips I have lying around. 8 bit data and 13 bit address. They can be programmed slowly using a picaxe (which would need an expansion port using HC595s or HC373s - see other posts on these). You could fill the ram with any arbitrary waveform, then output it at any frequency.

It is one of those projects that never happened. Picaxes were invented too late and PCs with soundcards can do the job faster/better/cheaper.

 

[ylp88]

which would need an expansion port using HC595s or HC373s - see other posts on these

For an application such as this, it would be conceivable to not need shift registers or latches, rather just use a binary counter instead, since it is likely that you will be addressing sequentially, rather than requiring random access to "arbitrary" locations. This should typically allow for faster read rates.

Aside, in this application it might also be possible to use the PICAXE to load the data sequence into a SRAM chip and then just clock the data to move straight from RAM to the DAC (and clocking the address), rather than passing the data from RAM to the PICAXE and then onto the DAC (semi-pseudo-DMA... ) - PWM it even.

As for the sampling rate, even at the Nyquist rate, you are probably looking at only single-digit kilohertz at best, if not in the order of tens to hundreds of hertz, as Dr_Acula said above.

ylp88

 

[moxhamj]

Good point ylp88 - if you are going to clock the data out fast it will need some counter chips, and if you have to have those then may as well use them to load the data as well. Counter chips have resets so if you reset them and keep track of the number in software and count up then the numbers will match.

And yes, clock the data straight out of the ram into the DAC. And the DAC need not be fancy - I've built ones using 20k and 10k 1% resistors in a R/2R configuration. But a chip would be better.

 

[westaust55]

Trying to pre-load the data from EEPROM to RAM in two 128 byte blocks will cause a delay while the second block of data is read over to continue the waveform generation – so likely not a good idea for 256 bytes of data.

If not going to try some form of DMA as suggested by others, yes it would be worth reading the data from the EEPROM into the PICAXE 8 bytes at a time to save having 256 separate EEPROM reads.

If you do end up using the 74HC595 shift register/latch to pass the data from the PICAXE to the DAC, then with the 28X1 and 40X1 it is possible to use the SHIFTOUT command (PICAXE manual 2 page 159) which reduces the code - other PICAXE’s require the data to be “bit banged” out.

Frequency wise, using the PICAXE, I believe the frequency will be quite low. Certainly not a “few hundred Hz” and feasibly not even many 10’s of Hz. The PICAXE has TUNE and SOUND commands where the real work is done in machine code but your program will be using the BASIC interpreter which is much slower.

Once you have selected you specific hardware for the DAC (dedicated DAC chip or a resistor ladder as Dr Acula referenced) and whether you will interface via a shift register (74HC595), 3-state latch (74HC373) or other method, people can better help you with the program side.