Porting drivers to Digilent Max32

Porting drivers to Digilent Max32

Postby scott2 » Wed Dec 05, 2012 11:01 pm

Hey guest,

Right now I'm working on porting the drivers to the Digilent Max32 - their Arduino Mega competitor, which is 80MHz, 128K Ram, 512K Flash (Sweet, eh?). Unfortunately for me, it's PIC-based (so I can only roughly follow the Arduino/Maple drivers as an example).

So far I've gotten the the board to configure the codec chip over i2c, and am now working on setting up the timer-interrupts. I have some questions (and may continue to have some more as I get through this thing):

1) I'm not quite clear on this, but SPI on the Max32/Arduino (not the shield) acting as a slave or master?
2) For the timer, the idea is that the codec-shield feeds it's clock output to the Max32/Arduino's timer input pin, so the external clock is used to generate the interrupt for calling the SPI data-transfer function, right?
3) How did you decide the SPI clock-speed? I have it set to 8MHz like the Arduino at the moment, even though this board operates at 80MHz. Not sure if that matters.
4) As a next step, I'm guessing I should look at the getting the codec-shield to be able to generate timer-interrupts on the board/Max32/arduino, right?
5) Do you have any tips for debugging/developing the drivers given that I now have access to a logic analyzer? Aside from the clock/i2c/spi lines, are there any other internal registers I should be writing to gpios for debug?
6) What sort of timing issues were you looking for when you needed to make the NOP calls on for the maple driver?

Sorry about the barrage of questions - any help appreciated!
scott2
 
Posts: 15
Joined: Thu Sep 27, 2012 5:48 pm

Re: Porting drivers to Digilent Max32

Postby guest » Thu Dec 06, 2012 5:18 am

wow, do you ever sleep?

1. the microcontroller should be setup as spi master.
2. correct, the every n clock cycles the microcontroller transfers data
3. spi clock speed was a tricky one. on the arduino, 8MHz is as fast as it could go. i found that there were a bunch of tradeoffs for clean data transfer, and getting the ss pulse just right (which is a function of clock speed). im not sure it can go too much faster, as the level shifter has a finite bandwidth, and there is a series resistor to cut down on the line ringing. it can probably go to 20MHz. slower is better for noise, but takes more processing time to handle the data transfer.
4. yes, get some random io pin to toggle with the interrupt, and make sure its happening at a consistent rate.
5./6. the main thing that will help here is an osciloscope. the spi is being hacked to replicate the wierd data protocol that the codec demands. look at figure 30 of the wm8731 datasheet. it shows a small pulse on the ss line right at the beginning of data transfer. this is the key to getting it to work right. you can pause data transfer after this, and it doesnt care, but if that pulse doesnt happen at the right time, it ignores everything. the start of pulse isnt too critical, but the falling edge of the pulse must coincide with the falling edge of the first spi clock pulse. for the arduino, it just so happened that toggling the pin made this exactly aligned, but with the maple i had to throw a few nops in there to get it at the right point.

how wide is the spi data register on the max32? it would be handy if it was 32 bits, that way you could transfer all of the data in one pass.
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm

Re: Porting drivers to Digilent Max32

Postby scott2 » Thu Dec 06, 2012 11:24 am

Thanks for all of the answers!

Re~SPI:
(1) Yes - it turns out the PIC32 has a 32 bit SPI data-register. So this means I should be able to grab the L+R samples in one go, right?
(2) the SPI also has an interrupt vector (and unrelatedly also supports some sort of audio codec mode.......). Should I be looking to have the SPI generate the interrupt? Or still go with using an the external clock driving the timer-counter to interrupt.
(3) If you're interested in taking a glance over the PIC32MX SPI guide, here's the link to it: http://ww1.microchip.com/downloads/en/D ... 61106G.pdf - it seems to support some sort of "audio protocol interface mode" for talking with codec chips
(4) I'll take a new glance over the WM Codec datasheet and read up on it's protocol. I didn't realize it wasn't exactly using an SPI protocol...
scott2
 
Posts: 15
Joined: Thu Sep 27, 2012 5:48 pm

Re: Porting drivers to Digilent Max32

Postby scott2 » Thu Dec 06, 2012 11:44 am

Exciting! : So it seems that the data-transfer modes (which aren't exactly standard SPI) that the codec uses are still actually pretty standardized (these so called "DSP" "Right Justified"/"Left Justified" and "I2S" modes). The PIC32 SPI core has support for all of these modes. Now to see how difficult it is to get this off the ground...

So presumably - if this works - I don't need to worry about any of this other timer module interrupt stuff, which was driving the sampling before, right?


re~ "do I ever sleep" : not really. This is a small, but necessary component of my PhD project. x_x
scott2
 
Posts: 15
Joined: Thu Sep 27, 2012 5:48 pm

Re: Porting drivers to Digilent Max32

Postby guest » Thu Dec 06, 2012 3:14 pm

cool, it has i2s! that makes things way simpler.

you still have to know when to send the data, so the timer interrupt is required. UNLESS ... you want to rewire the codecshield board. if you made the codec the SPI master, then it would all work as it was intended to by the manufacturer. all of that other stuff on there is stuff i did to hack it to work with the arduino. its hard to say if it would improve performance any. you still need an interrupt, or DMA to transfer the data over, and that can probably be coordinated by the SPI interrupt or timer interrupt just as easily. having the codec as master is slightly easier.
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm

Re: Porting drivers to Digilent Max32

Postby guest » Thu Dec 06, 2012 3:18 pm

whats the phd on? im guessing its not "memory mapping in bad-ass guitar pedals".
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm

Re: Porting drivers to Digilent Max32

Postby scott2 » Thu Dec 06, 2012 3:41 pm

guest wrote:cool, it has i2s! that makes things way simpler.

you still have to know when to send the data, so the timer interrupt is required. UNLESS ... you want to rewire the codecshield board. if you made the codec the SPI master, then it would all work as it was intended to by the manufacturer. all of that other stuff on there is stuff i did to hack it to work with the arduino. its hard to say if it would improve performance any. you still need an interrupt, or DMA to transfer the data over, and that can probably be coordinated by the SPI interrupt or timer interrupt just as easily. having the codec as master is slightly easier.


Is there any reason to use i2s vs DSP mode?

Noted re~interrupt/DMS for dataxfer + running the codec as master.

phd - haha not memory mapping bad-ass guitar pedals (unfortunately). The project is a neuroengineering project on sensory substitution for deaf people :D
scott2
 
Posts: 15
Joined: Thu Sep 27, 2012 5:48 pm

Re: Porting drivers to Digilent Max32

Postby scott2 » Thu Dec 06, 2012 5:45 pm

Sad news - this specific chip doesn't support the SPI Audio protocol stuff :/ Looks like it'll have to be hacked... at least it has 32 bit data register...
scott2
 
Posts: 15
Joined: Thu Sep 27, 2012 5:48 pm

Re: Porting drivers to Digilent Max32

Postby guest » Fri Dec 07, 2012 12:03 am

sorry to hear it doesnt support the i2s. the maple is the same way. the next level up of the microcontroller they use has i2s, but not that one.

are you remapping audio input to another sensory channel? ive seen some good work done with the tongue as input for the blind. i wonder what that would be like for audio.
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm


Return to Audio Codec Shield

Who is online

Users browsing this forum: Bing [Bot] and 1 guest


cron