electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
go to the radio page Live at electro-music.com radio 1 Please visit the chat
poster
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
dsPICs, let's talk about them
Post new topic   Reply to topic Moderators: State Machine
Page 2 of 3 [52 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: Previous 1, 2, 3 Next
Author Message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Mon Jan 07, 2013 12:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

dsPIC33F interrupt PDF files..... (argh)

I'm looking at these and it seems that one of them has a description that indicates it is appropriate for 4 different devices listed by part number. I now know to ignore that file and that's great, but there are 5 PDF files that I've found and they all contain similar information (though some of it can be a bit different from PDF to PDF):

Interrupts
Interrupts (Part II)
Interrupts (Part III)
Interrupts (Part VI)
Interrupts (Part V)

Only (part II) seems to say which devices it is for, the others have a rather vague description, like "small pin count". Part V seems to be for a device with only 4 DMA controllers, but it doesn't list the devices by part number

I'm assuming that there is no (Part I) PDF since I can't find it anywhere.

Anyone here have some superior knowledge on how to decode what I would need if I have just one device type? Like is there some special magic decoder web page on the Microchip website that helps in that regard?

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24075
Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320

PostPosted: Mon Jan 07, 2013 12:46 pm    Post subject: Reply with quote  Mark this post and the followings unread

Looks like you found family reference manuals for interrupts?

Does the device specific PDF mention what chapters from the family reference you need?

It seems to do this for PIC24 ... but it's all very messy IMO Rolling Eyes

_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Mon Jan 07, 2013 1:50 pm    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:
Looks like you found family reference manuals for interrupts?

Does the device specific PDF mention what chapters from the family reference you need?

It seems to do this for PIC24 ... but it's all very messy IMO Rolling Eyes


As for #1, yes, I did indeed.

As for #2, of course I didn't. That would be too much like right. And now that I did, it says Part III for my device.

As for #3, maybe Microchip should rename themselves MessyDocs...

And yes, I do remember you telling me to look in the device specific doc for other stuff. I claim "Old Timer's Disease" (as my Chinese wife says) which is not to be confused with Alzheimer's Disease.

Rolling Eyes

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24075
Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320

PostPosted: Mon Jan 07, 2013 2:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

JovianPyx wrote:
which is not to be confused with Alzheimer's Disease.


Ah no that'd be CRS Confused

Glad you found it now .. oh .. I use µShit informally or was that for that other µ company grown too large .. CRS strikes Shocked

_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Tue Jan 08, 2013 9:04 am    Post subject: Reply with quote  Mark this post and the followings unread

CRS ... what is that? Can't Remain Stupid? Cool

oh wait Can't Remember Sh!t

heh, well, I do like the Micromess parts mostly. So far I haven't needed an option that they've notated as "doesn't work".

BTW, I had an experience with a crApple iPad yesterday that was wholly exasperating. My personal web server at home is password protected and the damned Safari wouldn't forget the password until I found the thingy where I could force deletion of all of the browser data. So crApple ain't much better than the Microjunk companies...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Tue Jan 08, 2013 10:31 am    Post subject: Reply with quote  Mark this post and the followings unread

Wanted to ask a question, just recently ran across the RoninSynth Arduino shield. A dsPIC33fj128gp802 on a shield, so you can use the AVR as the front end/UI and feed note and patch data to the dsPIC firmware. They brought out all the dsPIC's pins to headers and have a separate ISP header.
I was thinking that this might be a decent development setup? It's geared more towards the Arduino user: pre-built synth firmware and Arduino lib (all open source). One down side for a dev board is the funky Arduino header spacing, doesn't play well with proto boards (not a biggie, planned to build it on a proto board anyway)
Another troubling thing is the 4MHz xtal, Can they be running at 40MIPS with that and the PLL? (haven't dug into their code yet)
After following Jovian Pyx's great thread on the Harpie build ( \o/ ), ordered some GP802s (Thanks! Microchip!) so I'm itching to build.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Tue Jan 08, 2013 11:32 am    Post subject: Reply with quote  Mark this post and the followings unread

yogi wrote:
Wanted to ask a question, just recently ran across the RoninSynth Arduino shield. A dsPIC33fj128gp802 on a shield, so you can use the AVR as the front end/UI and feed note and patch data to the dsPIC firmware. They brought out all the dsPIC's pins to headers and have a separate ISP header.
I was thinking that this might be a decent development setup? It's geared more towards the Arduino user: pre-built synth firmware and Arduino lib (all open source). One down side for a dev board is the funky Arduino header spacing, doesn't play well with proto boards (not a biggie, planned to build it on a proto board anyway)
Another troubling thing is the 4MHz xtal, Can they be running at 40MIPS with that and the PLL? (haven't dug into their code yet)
After following Jovian Pyx's great thread on the Harpie build ( \o/ ), ordered some GP802s (Thanks! Microchip!) so I'm itching to build.


My first thought here was to use the AVR for a MIDI controller (or other appropriate UI) to support a DSP synth in the dsPIC. I bet that's possible and offloading the MIDI controller that way leaves the power of the dsPIC to sound production. The dsPIC also has a stereo 16 bit DAC. You can at least use a UART connection between the two chips for communication, but I would suggest using SPI under DMA control.

As for the 4 MHz xtal, I've not used such a low xtal, but there are many options regarding the PLL. It will take careful reading of the oscillator docs (heh - make sure you look at the device specific PDF to find out which oscillator PDF to use Rolling Eyes ). In my little world, what I did was to ask a veteran dsPIC guy what he used - which was both hardware selection AND device bits. In my case, this is 20 mhz xtal. One option might be to replace the xtal if that's possible... One thing about the oscillator bits and xtal selection is that the exact xtal mhz used will force certain DAC sample rate selections. With 20 mhz, the top sample rate is 89.xxx khz which is just a tad lower than the spec'd max of 100 khz. Not a big deal. Bottom line: I suggest when you mess around with the PLL stuff, write yourself a simple hello world program that flashes a LED to test this. Set it up so that it should flash at once per second (or use a pin that you can test with an oscope) to measure the time. That way, you can be sure that the bits you used are correct.

I am going to drop the code here that I have for the 20 mhz xtal. With this information you might be able to figger out how to get the most out of your 4 mhz by looking at what bits are required (but will have different values for 4 mhz than my 20 mhz code).

Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; *** IMPORTANT ***
;
; THE FOLLOWING INSTRUCTION SEQUENCE WORKS TO PLACE THE dsPIC INTO HSPLL MODE
; RUNNING AT 40 MIPS.  HOWEVER, IT WILL NOT RUN AFTER A PROGRAM OPERATION BY
; JUST SETTING MCLR TO Vdd.  YOU MUST POWER CYCLE TO START THE PROCESSOR.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; From Tom Wiltshire - to get dsPIC running at 40 MIPS with 20 MHz xtal
;.....................................................................
;       Set up Oscillator, PLL, DAC and all Pre/Postscalers
; We use the HS osc with external 20MHz crystal
;.....................................................................

; Code required for 40 MIPS.  If this is commented, it runs at 32 MIPS
        MOV     #0x0002, W0
        MOV     W0, CLKDIV

        MOV     #0x001E, W0
        MOV     W0, PLLFBD
        ; HS Osc with Xtal              = 20MHz
        ; PLL Prescaler (N1) = /4       = 5MHz
        ; PLL Multiplier  = x32         = 160MHz (Fvco)
        ; PLL Postscaler(N2) = /2       = 80MHz (Fosc, for an Fcy of 40MHz)

        ; Fvco is  used as ACLK         = 160MHz

  ;   DAC Prescaler = /7                = 22.8MHz    DAC Clock division /256 = 89.285 KHz sample output rate
  ;   Clocks per DAC update       = 448
  ;   DAC Prescaler = /8          = 20.0MHz    DAC Clock division /256 = 78.125 KHz sample output rate
  ;   Clocks per DAC update       = 512
  ;
        ; Disable auxillary oscillator and use primary osc instead

        MOV     #0x0780, W0
        MOV     W0, ACLKCON
        ; Aux Clk divide = /1
        ; Primary osc is aux clock source

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; test oscillator LOCK bit

PLL_lock_test:
  BTST OSCCON, #LOCK
  BRA Z, PLL_lock_test


Note the last two instructions are VERY important, they force the processor to wait until it's at 40 MIPS before anything else happens. I do this stuff just before setting the stack limit.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Tue Jan 08, 2013 12:46 pm    Post subject: Reply with quote  Mark this post and the followings unread

JovianPyx wrote:
My first thought here was to use the AVR for a MIDI controller to support a DSP synth in the dsPIC.

Yes, very close to your setup with the Harpie. But then there are issues with developing on two IDEs; for both the dsPIC and the AVR/Arduino. Not huge. The developers' aim is/was towards Arduino users, so not sure how many 'new' DSP designs will come from them. What they have at the moment sounds interesting, but being able to have a selection of synths would be sweet.
In their design the dsPIC is connected via spi, which allows multi shields to run off the Arduino, till you run out of pins to use as SSelects. (Not sure how a 10 shield Arduino stack would work out, though)

JovianPyx wrote:
write yourself a simple hello world program that flashes a LED to test this. Set it up so that it should flash at once per second (or use a pin that you can test with an oscope) to measure the time. That way, you can be sure that the bits you used are correct.

Thanks, very good idea. Also thinking about maybe a socket-ed xtal but not sure how that would effect the osc circuit; would like to be able to run their firmware stock, but be able to upgrade too.
Thanks x2 for the code snippet, I'm very new to the dsPICs ; been mucking around with 16Fs & 18Fs for the longest time, dragging my feet with the newer lines. But after your FPGA and dsPIC projects, I'm very inspired to push my comfort zone.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Tue Jan 08, 2013 1:11 pm    Post subject: Reply with quote  Mark this post and the followings unread

yeah, regarding multiple IDEs - not fun... That's why I decided to "waste" a dsPIC for the Harpie MIDI controller - while that's not a different IDE situation, to use a "cheaper" or less powerful device, it would be another instruction set I would have to learn because I do everything in assembly language.

Also, the code I posted is actually code I got from Tom Wiltshire. I added some additional comments to the comments he already had written.

Whatever you do - it is important to HAVE FUN Smile Smile Smile

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Wed Jan 09, 2013 2:55 pm    Post subject: Reply with quote  Mark this post and the followings unread

So been poking around the Ronin dsPIC firmware;
Here is the PLL setup:
"
#ifdef OSC_INTRC
CLKDIVbits.DOZE = 0;
CLKDIVbits.DOZEN = 0;
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPOST = 0;
CLKDIVbits.PLLPRE = 1;
PLLFBDbits.PLLDIV = 63;
ACLKCONbits.APSTSCLR = 0b011;
#endif
#ifdef OSC_4MHZ
CLKDIVbits.DOZE = 0;
CLKDIVbits.DOZEN = 0;
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPOST = 0;
CLKDIVbits.PLLPRE = 0;
PLLFBDbits.PLLDIV = 78;
ACLKCONbits.APSTSCLR = 0b011;
#endif
#ifdef OSC_25MHZ
CLKDIVbits.DOZE = 0;
CLKDIVbits.DOZEN = 0;
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPOST = 0;
CLKDIVbits.PLLPRE = 8;
PLLFBDbits.PLLDIV = 62; //62;
ACLKCONbits.APSTSCLR = 0b011;
"
All 3 ifdef for the clock sources work out to Fvco=160MHz, ( Fvco= Fin*(PLLDIV+2/PLLPRE+2)).
But DAC setup does not seem to work!?!? Fs=(Fvco/DACDIV)*256, working backwards from Fvco
Here we see DACFDIV set to x3
"
DAC1CONbits.DACEN = 1; // Enable DAC
DAC1CONbits.FORM = 1; // 16 bit signed
DAC1CONbits.DACFDIV = 0b0000010; // No clock division
DAC1STATbits.LOEN = 1; // Enable left output
DAC1STATbits.ROEN = 1; // Enable right output
DAC1DFLT = 0; // Default to 0 output
"
So either the source is outdated or I'm not getting it, could be a setup bit (?) for the DAC in addition to DACFDIV or are they running the DAC from the AltClock? Went thru the uChip Family Ref for the Clock and the DAC, but will have to go through again (mak'in my brain hurt!!Smile )
JovianPyx, the code was very helpful, Thanks to Tom are also in order! It took me a while to recall the name; Electric Druid.com is one of my fav Bookmarks!
EDIT-The math works out better with: Fs=(((Fvco/2)/DACDIV)/256), but I don't know if I have this right. Using this, DAC sample rate=104KHz, which is still too high, but closer. Could be, just me mangling the equations :0

EDITx2- So just to keep my nonsense in one place:
I think, given the above code, this might be correct:
Fs=((Fosc/APSTSCLR)/ DACFDIV)/256.
This is based on the datasheet's fig. 9.1 showing 'Fosc' going into the SELCLK mux and the assumption that SELACK defaults to 0b0, selecting Fosc (Fvco/2, reguardless of PLLPOST setting?WRONG) as the SELCLK mux output (haven't found the SELCLK bit set/reset anywhere in the source code).
This assumption is in conflict with FRM Sec 33.4.2 which uses Fvco, so does DS Fig.9.1 mean Fosc=Fvco, or Fosc=Fvco/2WRONG, or am I reading too much into a typoYES I AM.
'APSTSCLR = 0b011' sets Aux Clk Divisor to 16
'DACFDIV = 0b0000010' divides ACLK by 3 (I.E. 2+1 as per FRM),
So Fs=1.6MHz/256=6.5KHz using the aboveFORGET THIS, or Fs=3.3MHz/256=13KHz using Fvco instead of Fosc THIS IS THE CORRECT WAY .
USE AT YOUR OWN RISK! Not sure whether to use Fvco THIS IS IT AS PER CE154 LOOPBACK TEST CODE or Fosc=(Fvco/2) or Fosc=Fvco, both/all are in range for the DAC, but without knowing the Ronin's target Fs. I wish that this was detailed better in the Datasheet and the FRM. Razz
I THINK I'M DONE BEATING THIS DEAD HORSECool

Last edited by yogi on Thu Jan 10, 2013 6:37 pm; edited 2 times in total
Back to top
View user's profile Send private message
YoSynthi



Joined: Aug 29, 2006
Posts: 26
Location: UK

PostPosted: Thu Jan 10, 2013 4:13 am    Post subject: Reply with quote  Mark this post and the followings unread

@JovianPyx

You've already been very generous in making code available for your FPGA synths, but this thread seems to imply that you've also made code available for your dsPIC synth too. I can't see it on your site, or am I looking in the wrong place?

I've got some dsPIC chips that I'm itching to start using, and your work would be an excellent springboard, or kick up the backside, or whichever metaphor you prefer.

The 'Sometimes I Repeat Myself' tune that you did with the Harpie keeps going round and round in my head. It's a real "ear-worm"! (In a good way).

Thanks for the inspiring results so far,

YoSynthi.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Jan 10, 2013 7:39 am    Post subject: Reply with quote  Mark this post and the followings unread

At this time, I can't release the code for the Harpie, I hope (probably desperately) to make some sort of commercial thing out of it and other designs. The job market has dried up and taken a leap sideways and I need to have some kind of income, even a small one.

In another thread, I had intended to create a monosynth with MIDI controller built into it using a single dsPIC and post the code for that. I got side-tracked by the Harpie project and still have not completed it. Harpie became a sort of monster with 3 dsPICs that talk to each other. For now, I have to concentrate on moving the Harpie from a prototype to a viable marketable item. It may not pan out and if it turns out that it's just not going to sell, I will likely then release it or perhaps sell boards for the internals. I have several ideas regarding that.

I have tried to post about my trials and tribulations because I have to believe I'm not the only one playing Blind Man's Bluff with this stuff. All too often on other forums I see questions asked and either no answer or insufficient answers. In terms of DIY, my own opinion and experience says "never give up" and "RTFM". RTFM can sometimes be the hardest thing, especially when the documentation is confusing. I don't fault Microchip really, they put everything in the manuals that is needed, but it can often be an adventure to get all of the information I need together to write some code. Much/most of this is due to the fact that Microchip did a good job of cramming so many useful and well integrated peripherals into a single CPU. This means that there are just going to be a truckload of option bits and device registers to deal with.

At some point in time, I do want to put together and post details of a small project to act as a "hello world" synth which could be examined for at least one person's approaches. The problem I have with this is my own desire for high performance, so I will have to be careful not to expect so much and remain confined to a single dsPIC IC.

EDIT ADD: I may just post some of my own hello-world code. It was from this kind of code that I developed useful musical things. These code bits will show pretty much the absolute minimum stuff that has to be done to get a peripheral device to do it's job.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
YoSynthi



Joined: Aug 29, 2006
Posts: 26
Location: UK

PostPosted: Thu Jan 10, 2013 9:34 am    Post subject: Reply with quote  Mark this post and the followings unread

I perfectly understand your considerations, and it seems entirely reasonable to look for some return on all the work you've clearly put in. Good luck with whatever you decide to do with your projects.

Whatever happens, you've certainly encouraged me to start exploring some more. I can already testify to the thrill of getting sounds out of a PIC, and I'd forgotten how enjoyable assembler coding can be (am I weird?) I'm now keen to turn my attention to the more capable dsPICs, but like most people, I just wanted to hit the ground running, and make the best of what others have already done.

If I end up getting anything like the results you've obtained so far, I'll be very pleased indeed.

YoSynthi.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Jan 10, 2013 10:15 am    Post subject: Reply with quote  Mark this post and the followings unread

Of the things I found nice about the dsPIC:
- Stereo 16 bit DAC (basically, good enough for most stuff)
- 40 MIPS possible
- useful built in peripherals, such as UART and SPI

What I don't like is that the ADC systems (both 12 and 10 bit) are inappropriate for audio. They are great for pot reading and some kinds of CV inputs.

Synthesizers seem possible to me. One thing I hate is playing the multi-tasking game. That's why I copped out and designed the Harpie with 3 dsPICs. I could use 2 dsPICs for as high a performance level as I could get reliably. One dsPIC was dedicated to MIDI controller and voice assignment. I managed this over an SPI channel that sends from the MIDI controller to 2 "voice engine" dsPICs. Because DMA is very efficient the way it is implemented on a dsPIC, it is wise to learn how to use it. I will admit (like I have to? Rolling Eyes ) that I've always explored by doing the simplest things first and building my application on that working code. Yes, I write a lot of code that isn't always useful later on (in total), other than it works and it's simple and I comment the hell out of everything.

Eventually, I see how to make things more efficient, but in my little experience, it seems to be trying a lot of things ... Cool

It keeps me off the streets.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
elmegil



Joined: Mar 20, 2012
Posts: 2177
Location: Chicago
Audio files: 16

PostPosted: Thu Jan 10, 2013 11:08 am    Post subject: Reply with quote  Mark this post and the followings unread

JovianPyx wrote:

It keeps me off the streets.


And a good thing, too.
Back to top
View user's profile Send private message
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Thu Jan 10, 2013 11:34 am    Post subject: Reply with quote  Mark this post and the followings unread

YoSynthi wrote:
I perfectly understand your considerations, ....Whatever happens, you've certainly encouraged me to start exploring some more.
YoSynthi.

DITTO and DITTO!
Scott, all you've done is very appreciated!
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Jan 11, 2013 12:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

I have been flogging this stupid SPI SRAM thing for quite some time now. So far, I have created a program that can read and write to a 23K256 SPI SRAM. But it uses no DMA and transfers data to and from the RAM using programmed I/O. The program can do transfers to and the from the RAM on a "on-demand" basis, that is, when I need to read, I issue a read request and I get the data. Likewise when I want to write.

All well and good, but I would like to get the highest performance possible - so DMA would seem to be the answer. I would like the DMA to work also on an "on-demand" basis, that is, not continuous, just one write transfer or one read transfer and only when the program requests it.

After much banging and swearing, I've put together about the simplest test program I can. For the moment, all I want to see is a single byte get transferred out the SPI port and into the air for all I care. I have a scope probe on the SCK pin and if I see 8 clock pulses, I know it worked.

First I tried to use the simplest method to get the SPI peripheral to transmit, that is, I stuffed the buffer register (SPI1BUF) with a zero. Then the program waits in a waste-time loop and does this repeatedly forever. This gives a repeated nice little burst of 8 clocks that I can see on my scope. Kinda shows that SPI is working...

My DMA channel is set this way:

Code:
 
  MOV #0x6001, W0
  MOV W0, DMA0CON        ; Note that CHEN is off here, we turn that on later

  MOV #0x000A, W0          ; SPI1 requestor
  MOV W0, DMA0REQ          ; write the interrupt req select bits


  MOV #SPI1_WRITE_BUF, W0
  MOV W0, DMA0STA          ; set the buffer address where write data is stored (command and address for SPI SRAM)

  MOV W0, DMA0STB          ; for the hell of it, put the same address in the B register (even tho we don't use ping-pong)

  MOV #SPI1BUF, W0
  MOV W0, DMA0PAD          ; Peripheral device Address

  ;MOV #3, W0               ; set transfer count to 4 (yes, the register value is N-1 where N is the transfer count)
  MOV #0, W0               ; TEST SINGLE BYTE TRANSFER
  MOV W0, DMA0CNT          ; set DMA count register


  BCLR IFS0, #DMA0IF
  BSET IEC0, #DMA0IE

  BSET DMA0CON, #CHEN      ; enable DMA channel 0



From what I am reading, I can use one of 2 methods to start a DMA transfer, one is to stuff the buffer register (which I've done and it appears to work) and the other is to use what is called "DMA manual transfer mode". As I understand it, this is to be done by setting the FORCE bit in the DMA interrupt request register.

Here is the main loop portion of my test loop code:
Code:

test_loop:
  BCLR SPI1STAT, #SPIROV       ; be nice to the overflow bit
  BSET DMA0REQ, #FORCE             ; force a single cycle of write 
;   MOV W0, SPI1BUF                  ; another way to force an SPI transfer and DMA request
 
dma_1:
  CALL tim
  GOTO test_loop 

tim:
  MOV #0x03FF, W0
tim1:
  BCLR SPI1STAT, #SPIROV       ; be nice to the overflow bit
  DEC W0, W0
  BRA NZ, tim1
  RETURN

__DMA0Interrupt:               ; interrupt vector for DMA read transfer from SPI SRAM
  BCLR IFS0, #DMA0IF
  BTG PORTA, #LED              ; toggle the LED at each interrupt
  RETFIE


The above code causes no clocks to spew from SCK.

If the BSET DMA0REQ, #FORCE is commented and the MOV W0, SPI1BUF below it is uncommented, I get bursts.


Ideally, I want to set up an outgoing 4 byte data transfer in a buffer, point the DMA controller to that and then hit the FORCE bit. After that, it's a matter of either setting up an interrupt or polling the interrupt flag to know when the transfer is done. This would reduce the CPU I/O tending work to minumum. Except that when I hit the FORCE bit, nothing happens.

I've looked at errata, I know my device is revision code 0x3003 (which is revision A4). No mention of this SPI problem exists in errata.

I've also looked at the example code for an SPI loopback, but it operates in continuous mode, not one-shot. I require one-shot to facilitate the "on-demand" nature of what I need to do. However, in the example code, they use the FORCE bit to start the process (after which the DMA requests are initiated because the DMA channel has it's request set to SPI. In continuous mode, this works, but I see no examples of on-demand SPI transmission as I would like to do).

Soooo.... any help out there ??

EDIT ADD:

Just for grins, here is the SPI1 set up I'm using:
Code:
  BSET TRISB, #RB7         ; pin is input   (SDI)
  BCLR TRISB, #RB8         ; pin is output  (SPI clock)
  BCLR TRISB, #RB9         ; pin is output  (SDO)

  MOV #0x001F, W0
  MOV W0, RPINR21        ; tie SS high

  MOV #0x0007, W0
  MOV W0, RPINR20        ; SDI is input on RP7 pin 16

  MOV #0x0708, W0        ; set both RP9 (high byte) and RP8 (low byte)
  MOV W0, RPOR4          ; SDO is output on RP9 pin 18,  SCK is output on RP8 pin 17

; SPI clock
  MOV #0x001E, W0             ; 1:1, 4:1   timer 0x0010   10.00 MHz
  MOV W0, SPI1CON1

  BCLR SPI1CON1, #CKP         ; 0 = Idle state for clock is a low level; active state is a high level
  BCLR SPI1CON1, #CKE         ; 0 = Serial output data changes on transition from Idle clock state to
  BCLR SPI1CON1, #MODE16      ; 8 BIT MODE :: 16 bit mode not set.
  BSET SPI1CON1, #MSTEN       ; set Master Mode Enable
  BCLR SPI1CON1, #DISSCK      ; disable clock pin not set
  BCLR SPI1CON1, #DISSDO      ; disable output pin not set

  BCLR SPI1CON1, #SMP         ; 0 = Input data sampled at middle of data output time (for master mode)
                              ; active clock state (refer to bit 6)
  BCLR SPI1CON1, #SSEN        ; 0 = SSx pin not used by module. Pin controlled by port function


  BCLR SPI1STAT, #SPIROV      ; clr Receive Overflow Flag
  BSET SPI1STAT, #SPIEN       ; set SPI Enable

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima

Last edited by JovianPyx on Sat Jan 12, 2013 7:44 am; edited 3 times in total
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Jan 11, 2013 2:56 pm    Post subject: Reply with quote  Mark this post and the followings unread

For those interested ... I've posted a very basic question about this on the Microchip forum. Hopefully, that will shed some light on why this is not working. I shall convey such information back to here.
_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Fri Jan 11, 2013 9:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

You know, I was reading FRM sec 38 most of today. So I have just enough knowledge to spell DMA Wink
Going through your code, I'm not seeing DMA0IE being set. just a thought
EDIT- For one byte, not sure if the IRq is needed, but the FORCE bit is simulating a IRq request to the DMA. All example setup code shows it enabled, which makes sense; if you'r using DMA, you need IRqs to service the buf. A one byte DMA transfer is probably not too common.
Another idea: setup for 4 bytes, manual start the SPI Tx and see if the other 3 bytes are sent via DMA. Let you know if the prob is with the DMA setup.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sat Jan 12, 2013 7:42 am    Post subject: Reply with quote  Mark this post and the followings unread

Well the missing interrupt enable is now in the code and I've edited the post above to include it as well. Still doesn't work. I added that later so that I could toggle an LED in the ISR.

I also edited in the ISR code.

I also want to try the 4 byte thing with manual stuffing of first byte, but I really hate to do that.

EDIT ADD: The documentation would seem to indicate that the 4 byte thing won't work. The interrupt request comes from the SPI module to the DMA channel. This technique can be used for continuous operation as I've seen in example code. The interrupt will occur only after all of the bytes are transferred - and it should startup using the FORCE bit technique. I will test continuous mode this way and leave the DM0CNT register set to zero (for one byte transfer) just to see if that works. I don't see a reason for it not to work with one-shot, but so far, I've been without luck...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Sat Jan 12, 2013 1:52 pm    Post subject: Reply with quote  Mark this post and the followings unread

JovianPyx wrote:
Well the missing interrupt enable is now in the code and I've edited the post above to include it as well. Still doesn't work. I added that later so that I could toggle an LED in the ISR.

Yea, the IRq from the DMA is not much use here, not using an ISR. was just a shot in the dark.
OK, you can manual start the SPI for one byte, so the SPI basic start up works. The DMA setup seems correct also,
MOV #0x6001, W0 ;0110 0000 0000 0001- DMA0CON
;BYTE md , RAM->Peri, RegI++, one-shot-noPP
MOV #0x000A, W0 ; SPI1 requestor ; SPI1 TxDone 000 1010
MOV #SPI1BUF, W0 ;SPI1BUF 0x0248

But I'm not sure of the impact of one-shot mode. As I understand, once the block transfer completes, CHEN is reset. So in this context, you would only get one SPI tx using FORCE on the first pass thru Main; without re-enabling the channel before the next bitset of the FORCE bit. You might try adding:
BSET DMA0CON, #CHEN ; enable DMA channel 0
to the end of the tim loop before return.
But If you'r not even seeing ONE SPI Tx with FORCE bit, makes me think the issue is between the SPI and DMA. Enabling the SPI IRQ, could that be required for the FORCE bit? not sure how that would make a dif here?

JovianPyx wrote:
I also want to try the 4 byte thing with manual stuffing of first byte, but I really hate to do that.

My thought was to verify transactions between the SPI and DMA. By using the 'conventional' way of starting the SPI (which works), you could see that the SPI-DMA automatic side of the block transfer is working. This would demonstrate that the DMA setup is functional.
If I got this right: SPI should set an IRQ after each byte transfer, this is captured by the DMA. So for a 4 byte block, the SPI will gen 3 IRQs and then the DMA will gen a system IRQ. Setting FORCE simulates the first IRQ to the DMA, which only respond to requests.
With one shot, the SPI should send 4 bytes then quite; with Cont, should see a stream of clock transitions, the same 4 bytes from the buf.
Seems simple, but the devil's in the details Smile
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sat Jan 12, 2013 2:09 pm    Post subject: Reply with quote  Mark this post and the followings unread

Thank you yogi profusely.

Dammit. I had my doubts about CHEN being turned off by one-shot operations, but I thought to myself - just try it... so I did and it worked. Then I seached the DMA PDF for CHEN and here is what I found:

38.6.7 One-Shot Mode
One-Shot mode is used by the application program when repetitive data transfer is not required. One-Shot mode is selected by programming the Operating Mode Select bits (MODE<1>) to ‘x1’ in the DMA Channel Control (DMAxCON) register. In this mode, when the entire data block is moved (block length as defined by DMAxCNT), the data block end is detected and the channel is automatically disabled (i.e., the CHEN bit in the DMA Channel Control (DMAxCON) register is cleared by the hardware).

I know I read that. It just didn't stick.

Basically, I simply added an instruction to set CHEN to 1 just before setting FORCE to 1 and now I get exactly what I should get on the scope.

I'll now mess with it to get what I really want, but this is a start.

EDIT ADD: It works without using an ISR (Which is what I need anyway). I took the ISR away and don't enable the interrupt and it still spews clocks like it should.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Sat Jan 12, 2013 4:17 pm    Post subject: Reply with quote  Mark this post and the followings unread

OH, Very Cool! So Very glad I could help!! Smile
I know what you'r talking about; just to go through this issue I had the DataSheet, The DMA section and the SPI section of the FRM all open, and jumping back an fourth between them!?!?! There are so many details with these devices, it's maddening trying to pick out only what you need know.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sat Jan 12, 2013 4:31 pm    Post subject: Reply with quote  Mark this post and the followings unread

I will at least post the complete SRAM diagnostic. It will be designed to write random data to all 32768 bytes, then re-seed the random generator and read it all back to check that it is stored accurately. This program should then be useful as a template for other on-demand requirements using SPI (or any periph).

I know what you mean - when I do stuff with dsPIC, I open a separate browser window just for that stuff and often have 5 tabs open with different PDF files that are related. Interrupts in one PDF, DMA in another, the peripheral in a third, errata in a 4th, etc. I do hate it, but honestly, I don't know if I could do a better job than they did. dsPIC is a great chip because it will do so many things, but for each thing it does there has to be a document...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
yogi



Joined: Jun 26, 2008
Posts: 29
Location: Maryland

PostPosted: Sat Jan 12, 2013 5:28 pm    Post subject: Reply with quote  Mark this post and the followings unread

JovianPyx wrote:
I will at least post the complete SRAM diagnostic. It will be designed to write random data to all 32768 bytes, then re-seed the random generator and read it all back to check that it is stored accurately. This program should then be useful as a template for other on-demand requirements using SPI (or any periph)....

That would be great! I need to get off my butt, and breadboard a test board now. Very Happy
I have a question, what are the effects on the audio output if you have the DAC set for say Fs of 50KHz and the updates are at a slower rate? I assume the DAC will fill in with the val stored in DACxDFLT reg when it's FIFO empties. That will amount to 'noise' in the audio? I ran across several posts on the uChip forum about noise with the DAC, and was thinking this could be a problem with high sample rates if it's not handled right.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: State Machine
Page 2 of 3 [52 Posts]
View unread posts
View new posts in the last week
Goto page: Previous 1, 2, 3 Next
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use