http://forums.leaflabs.com/topic.php?id=55 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:16:20 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=55#post-4358 Sun, 17 Apr 2011 15:22:56 +0000 gbulmer 4358@http://forums.leaflabs.com/ <p>samtel - we have answered your identical posting at <a href="http://forums.leaflabs.com/topic.php?id=739" rel="nofollow">http://forums.leaflabs.com/topic.php?id=739</a> </p> http://forums.leaflabs.com/topic.php?id=55#post-4343 Sat, 16 Apr 2011 05:55:15 +0000 samtal 4343@http://forums.leaflabs.com/ <p>Hello experts,</p> <p>I acquired the Maple (5) as a result of the Arduino not enabling me the speed and resolution I needed.<br /> Another major reason was the fact that the STM32F103 is capable of dual simultaneous sampling that, in my application, is critical.<br /> The speed performance and resolution of the Maple is sufficient (although I wish I could have the Arduino Reference command), but I was surprised to find out that the Maple with the compiler I have (IDE 0.0.9) did not implement the STM dual regular simultaneous ADC mode.<br /> Is there a way to implement that dual mode with Maple 5? Is there a newer IDE that can do it?</p> <p>Thanks,<br /> Sam </p> http://forums.leaflabs.com/topic.php?id=55#post-262 Wed, 16 Jun 2010 23:04:19 +0000 beckel 262@http://forums.leaflabs.com/ <p>For anyone interested in some better numbers...</p> <p>a single adc_read() takes 6.47 microseconds</p> <p>a single analogRead() takes 6.76 microseconds </p> http://forums.leaflabs.com/topic.php?id=55#post-261 Wed, 16 Jun 2010 21:49:41 +0000 beckel 261@http://forums.leaflabs.com/ <p>I was thinking about this today and realized there is just no way it should be taking 44 ms for 6 reads. Even the Arduino is faster than that. When I went back and looked at the code I realized that I was taking the second timer sample after printing a serial message x-( I feel like an idiot. </p> <p>I modified that to work correctly and I was timing in those 6 analogReads at 0 ms. Obviously I need to be measuring in microseconds but it looks like libmaple does not yet have the <a href="http://www.arduino.cc/en/Reference/Micros">micros()</a> function that Arduino has. So, I ran the 6 analogReads in a loop 100 times (totaling to 600 analogReads) and was seeing b/w 3 and 4 milliseconds. Assuming this is, at best, about 3.5 milliseonds for the 600 reads, that comes to 5.83 microseconds per analogRead(). This means a single channel reads at a frequency of ~171.5kHz and a 6 channel frequency of ~28.5kHz which is probably more than enough to start my application (These numbers are pretty rough due to truncation btw). For this reason, I probably won't get around to improving the ADC reads any time soon but I will definitely be implementing a continuous read functionality when it comes time to optimize. </p> http://forums.leaflabs.com/topic.php?id=55#post-256 Wed, 16 Jun 2010 09:52:43 +0000 beckel 256@http://forums.leaflabs.com/ <p>Thanks Perry. Your response is very informative. I think my general plan of action will be to try to improve the speed of the current implementation as best as I can. I will try direct calls to adc_read() and then try to lower the sample time. I can attempt to discern whether I have lost any accuracy due to the latter measure and let you know. </p> <p>I would like to try to implement some of the other modes into libmaple but most of them are probably just too specific. The <em><strong>Multichannel (scan) Continuous Conversion Mode</strong></em> looks like a good balance of simplicity and usefulness. You are right though, coming up with a simple API is really the hard part. I am not in too much of a rush to optimize this part of my application though so I might not attempt this until I am more familiar with the native STM32 lib and how the ADC section works.</p> <p>I will keep you posted. </p> http://forums.leaflabs.com/topic.php?id=55#post-255 Wed, 16 Jun 2010 08:53:03 +0000 efox 255@http://forums.leaflabs.com/ <p>that would be awesome if the current adc functions can be improved or allow a bit more flexibility. I think I looked at the adc functions a few weeks back, and I think the ADC is not interrupt driven, which would be nice (i could be mistaken). I was going to try and work on that once I've had enough with the timers and truly understanding the nvic.</p> <p>This is why open source is awesome. Collaboration ! woooot !!</p> <p>Keep us posted beckel. </p> http://forums.leaflabs.com/topic.php?id=55#post-254 Wed, 16 Jun 2010 03:07:11 +0000 perry 254@http://forums.leaflabs.com/ <p>Hi Beckel,</p> <p>You're pretty much correct--ADC reads can be sped up by a significant factor. The basic wirish analogRead() is quite slow, is blocking, and uses only a single conversion mode on a single ADC. The conversion time was also increased to 55.5 cycles/sample for a more reasonable default minimum input impedance of ~40K.</p> <p>There are two ADC units that can be set up to continuously convert on multiple channels simultaneously, and they can also be set up to do DMA into a buffer and notify you when samples are ready.</p> <p>None of these modes have been implemented yet for lack of time, but they're on the long list of things to do. I haven't come up with a good API for setting up and using these modes yet, but you're welcome to take a crack at it. I'd be happy to help you out, or accept patches if you can get them working.</p> <p>In the meantime, it looks like you've already found the magic number to lower the sample time. If you lower the sample time, make sure your input impedance on those channels is lower than ~.4k, otherwise your samples will be incorrect. There's a formula in the ST application notes that will tell you the minimum input impedance.</p> <p>Additionally, you can eschew the use of the analogRead() function and call directly into adc_read() from libmaple. This will save you one level of indirection and argument checking and get you slightly more speed.</p> <p>Regarding the prescaler, as far as I can recall without checking the docs, the ADCs can't be clocked any faster than 14MHz.</p> <p>I'd like to get to implementing the more advanced features in the next few months, but the hard part is coming up with reasonably user-friendly APIs for accessing all the features without requiring too much prior knowledge or programming experience. Any input or advice would be appreciated too!</p> <p>feel free to ask if you need anything else,<br /> -perry </p> http://forums.leaflabs.com/topic.php?id=55#post-251 Tue, 15 Jun 2010 23:24:22 +0000 beckel 251@http://forums.leaflabs.com/ <p>Okay, so I have been doing a lot of reading over lunch about STM32's ADCs and I have a <strong>bunch</strong> of questions. Unfortunately, I haven't had time this week to do much experimenting so my actual data isn't too good, so I am going to just try to outline what my problem is and try to get some direction.</p> <p>The application I am creating is a pretty straight-forward DSP problem. I need to continually read multiple analog channels [~(6-10) of them], perform some processing, then create some output. For an initial test, I tried to read each of the channels separately by calling analogRead() on the six separate pins. I measured the speed of these 6 reads and it clocks in at 44 milliseconds. This seemed way too slow to me [BTW, I measured this the easy arduino way using 2 calls to millis()]. After studying the libmaple source and reading <a href="http://www.st.com/stonline/products/literature/an/16840.pdf">this application note from ST</a>, it appears to me that libmaple is using single conversion mode. The application note list something like 10 or 11 different modes and I am guessing one of the others would be optimal for my application but here is where I am split...</p> <p>First off, I am wondering if I can get more speed out of this mode for the time being. I would rather just get on with development so I can get more familiar with this chip then tackle the problem later. I am guessing the slowdown isn't entirely just attributed to fact that analogRead() uses the single conversion mode, correct? For starters, the ADC is determined by a prescalar. So can that be pushed any faster? Also, I noticed this section of code in adc_init():</p> <pre><code>/* Up the sample conversion time to 55.5 cycles/sec, see note above */ /* TODO: fix magic numbers */ ADC_SMPR1 = 0xB6DB6D; ADC_SMPR2 = 0x2DB6DB6D;</code></pre> <p>I think I read that this has something to do with the amount of samples that are taken for a measurement?? but what I cannot determine is how these numbers were derived and if the sampling process can be sped up or not. Actually, a good explanation of the adc_init() function would be helpful in general.</p> <p>So, should I try to improve the single conversion process for my application? If so, at what level can I improve the speed without sacrificing too much accuracy. Could this possibly have anything to do with which pins I am using? Are the 2 ADCs configured differently? </p> <p>OR</p> <p>should I just go straight to trying to implement one of the other modes, possibly a dual or continuous scanning mode? If so, any suggestions on that.</p> <p>OR</p> <p>Is my problem way simpler than I am making it?</p> <p>Thanks in advance and so sorry about the belabored points and the length of this post. Please correct my misunderstandings where possible.</p> <p>Also, this post may be in the wrong forum... </p>