Show Posts
Pages: [1]
1  Using Arduino / Networking, Protocols, and Devices / Re: SPI speed not making sense, seems very slow (MEGA2560) on: October 13, 2013, 01:33:38 am
I answered my own question, and so no one else makes the same mistake,  this:





Now I see a change every ~19uS (which means the digital writes are much faster) which comes out to 52k changes per second at the DAC outputs when driving 4 channels on 2 SPI devices.  Much better.
2  Using Arduino / Networking, Protocols, and Devices / SPI speed not making sense, seems very slow (MEGA2560) on: October 13, 2013, 12:53:01 am
Hey All,

I'm trying to use the hardware SPI with also using the fastDigitalWrite (using constant pin names) to try and write to 2 devices on the SPI bus (2 MCP4922).  So basically, I am managing my CS for both SPI slaves.

What I do is:
-Set CS_0 low
-Or an uint8_t with another uint8_t
-transfer result on SPI
-or an uint8_t with another uint8_t
-transfer result on SPI
-Set CS_0 high, then set CS_0 low (DAC has 2 channels, so I need to toggle CS to latch 1st DAC 16-bit data)
-Or an uint8_t with another uint8_t
-transfer result on SPI
-or an uint8_t with another uint8_t
-transfer result on SPI
-Set CS_0 high

I do this all again with CS_1 (since I have 2 SPI devices I am writing to.

I set the clock divider to 2 so I would think that sets my speed to 8Mhz. or basically 8Mbps

From what you see above, I have 64 bits that need to be written out, and 8 digitalWrites.  At 8Mhz, I would think that would give me each of those 64 bits would take 0.125uS.  If I assume worst case for the digitalWrites that would be like 4uS I would think, so overall that's 8uS + 32uS or 40uS total.   The scope is showing me 250uS (I am alternating the DAC from high to low) to transition from high to low.  I don't understand why I am loosing 210uS. 

3  Products / Arduino Due / Re: Real Time Audio Output, what am I doing wrong? on: January 05, 2013, 09:37:58 pm
I did use the DDS code to try and really push the Due.  At lower frequencies, the output was as expected, but at the upper frequencies, the waveform was much more stepped.  That said, I was able to generate 8 sins at once and mix them together.  Though I will say, the more sins I added, the noise floor kept going up significantly.  Not sure what that was about.

I also agree the toolchain for the STM32F4 is not the easiest.  Given I know someone who already has it all figured out, that makes a SIGNIFICANT difference.  I've been installing the toolchain that I found from ARM themselves.  My only concern is making sure the floating point unit is getting used by the compiler, or, if I have to access it with ASM.  I mean, if I can't use the floating point unit, kinda makes using the STM32F4 pointless.

I also got the beaglebone in.  Have really done nothing with it yet since i feel it will be the most work.

Things are kinda on hold as I wait for more parts to build my gain/offset circuits in terms of pushing the DUE more. 
4  Products / Arduino Due / Re: Real Time Audio Output, what am I doing wrong? on: January 03, 2013, 05:24:19 pm
The GPIO seems to be pretty lacking on the one I was playing with.  Also, it's an older ARM core (unless there was a newer one they released I didn't know about) so it is a bit slower in operation.  My IO requirements at the moment are a TFT LCD display, SD card (which is obviously not a problem for the pi or the beaglebone out of the box), 2 ADC in at audio rate, 4  ADC in at LFO rate, 8 gate/trig in, 2 DAC out at audio rate, 4 at LFO rate, 8 gate/trig out. 

That's an exceptional amount of IO.  Not all used at once mind you.  I just think getting all that out of the pi would be difficult, but maybe there is just something I misunderstand.
5  Products / Arduino Due / Re: Real Time Audio Output, what am I doing wrong? on: January 03, 2013, 01:04:21 pm
Thanks to everyone for all the information, I have been studying a lot of the DDS examples I could find and I am definitely playing around with that method of generation as well.

I think it all comes down to if I want to work in integer math, or floating point.  I've spent considerable amount of time looking at three solutions; (1) DUE, (2) BeagleBone, (3) STM32F4Discovery.

I also have a Mega2560 but that isn't fast enough for the audio rate stuff I want to do.

Given I already have the DUE, I am still having fun working with it.  While my original plan seems to be difficult with it, I am finding I can still do a lot with it and will continue to use it for more simple specific ideas I want to do.  Without a doubt, it's the easiest to program as the toolchain is just simple.  While 44.1kHz output is possible with careful coding, I'm still concerned with the input ADC time in freerun mode (and how accurate it is with audio) and/or will that even be possible with trying to hit 44.1kHz.  If it isn't, then I will look at just using it as more of a sound generation project and just use CV frequency (LFO rate) inputs.

The STM32F4Discovery was recommended by a coworker.  Cost wise, it's like $15 and comes with a floating point processor.  I've looked at the cycle-times for floating point operation and they are pretty impressive.  It runs at about 2x the frequency of the DUE (although not sure the actual processing difference) and it appears the built in ADC is pretty powerful.  Also has built in DAC that can theoretically do up to 96kHz. ( with built in amplifier.  The Cortex chip itself has 3 ADC and 2 DAC as well apparently, and they seem to be easily able to handle 44.1k audio rate.  In fact, it appears I can multiplex with them and still get 44.1khz out of them, not too bad.  The tool chain is a little more work, but given I know someone what already has set this up on OSX, that's a huge advantage. Lastly it has DSP specific instructions like Multiply in one cycle which is pretty awesome.

The BeagleBone is definitely the most powerful of the 3 but the least developed on.  I would not use Linux.  In all my reading I've done so far, even with all the RT patches it's just not very fast or predictable.  That said, the next step is to use STARTERWARE from TI instead.  Of course, this will mean I will need a virtual linux image on my MAC to talk with their toolchain (or, until I can find OSX equivalent tools), but, it has the advantage of 700Mhz and of course Floating Point as well.  The cape I bought does 2x audio in and 2x audio out at 96kHz 24-bit.  This is more than enough for my needs.  In addition, there are 7 other analog inputs that can be used for things like CV voltage that I want to read.

It's hard to say there is a winner in all this because if you look at each of these setups, there is a lot of give and take.  The DUE has just been a blast to code with.  Without any personal hands on experience it seems like the ST is going to really be the sweet spot of price/performance if I want to build a bunch of these, but of course, having all that power on the BeagleBone is tempting.  

Duane, your RCarduino stuff is awesome.  Thanks for putting the effort forth in sharing all that information.  Without a doubt you helped me come up to speed MUCH faster, especially with the interrupt code you pulled together.
6  Products / Arduino Due / Re: Real Time Audio Output, what am I doing wrong? on: January 02, 2013, 09:54:47 pm
Thanks so much for the reply, I was thinking this was the case and I'd need to implement a table lookup.  I will walk down this path as well as consider the BeagleBone as well.  I REALLY like the DUE, but I am finding the choices for pinout are limiting what I'd like to do.  For instance, I'd really have liked to use the SMC to control a 16-bit LCD, but, the pinout chosen will not allow me to do that, one of the pins isn't even brought out.

Yet, I have to say, it's still VERY easy to code which I think was their biggest goal and certainly exceeds the other boards I have looked at.  With the BeagleBone or the ST solutions, I've pretty much have to build my complete tool chain myself mostly.  And given the issues with RT Linux not being as RT enough for me, I'd be looking at using the Starterware stuff for the Cortex M8.

Given I am in the development part of my project, implementing my code on both will be more interesting nevertheless. 
7  Products / Arduino Due / Real Time Audio Output, what am I doing wrong? on: January 02, 2013, 09:16:26 pm

I've been experimenting with interrupts as others have with producing audio coming out of DAC0.  If I do something simple like a ramp, I am having no problem at all.  However, if I try and use the sin() function, it seems that this function is taking way too long to allow me to do 44.1kHz audio.  I'm new to ARM programming and was under the assumption this is probably due to floating point math?  I'm trying to determine if I should just move on to something like the Beagle Bone that has a floating point processor if I don't want to be limited already when I am hardly doing anything but generating a sine wave.

The ultimate goal is creating a signal processor.  Given I'd like to do more advanced things like convolution and such, I am thinking the DUE just might not be powerful enough.


8  Products / Arduino Due / Re: Missing RAM Pins on: December 04, 2012, 06:41:57 pm
So I've been looking into the SMC as well for an LCD and for what I can gather, since I don't use the ADDRESS pins for address, it seems I could still use the SMC to write to my LCD.  It's using 8-bits.  I do need ONE address line to tell it which memory internally to work with.  Although I am not 100% sure.  Still porting code from a Mega2560 project.
9  Using Arduino / Programming Questions / LCD Shield on Mega2560 versus Mega1280... on: November 29, 2012, 05:33:16 pm
I recently purchased an LCD shield off of eBay where the seller forgot to tell me it worked with the Mega1280 and not the Mega2560.  I of course have a Mega2560.  I've spent some time reading about both and for the life of me I cannot figure out why it won't work?

All the Arduino literature I have found has said they are the same basically with the main difference in the chips being the amount of flash memory.

The only thing I heard anyone speak of about difference between both the 2560/1280 is that timing registers were not set the same way.  I am not specifically sure what the timing registers would be used for since this shield uses the analog pins as digital outputs and not as analog inputs.  But, I can think of no other reason why it wouldn't work.

Anyone have any ideas as to what could be different between the two that isn't apparent?

If you are curious which shield I am talking about, search for 2.6" TFT Arduino on eBay, it's 18.99 BIN.

Thanks for any help!!

Pages: [1]