LeafLabs Garden » Topic: How to improve the maple mini's ADC sample rate to 1MHz?

LeafLabs Garden » Topic: How to improve the maple mini's ADC sample rate to 1MHz? http://forums.leaflabs.com/topic.php?id=74213 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:23:57 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105116 Wed, 25 Dec 2013 11:53:27 +0000 gbulmer 105116@http://forums.leaflabs.com/ tomxue - Very well done for cracking using the dual-ADC! Also thank you for sharing your results. "ADC_PRE_PCLK2_DIV_2 may not be the key factor" I was only suggesting simplifying and removing anything that might trigger a problem. When I wrote "I currently believe that the ADC is unlikely to be working reliably for all bits of the conversion because it is out of spec.", the key points were "reliably" and "all bits". First, 18MHz isn't enormously bigger than 14MHz. Several people have reported 'overclocking' the STM32F, for example: <a href="http://forums.leaflabs.com/topic.php?id=31" rel="nofollow">http://forums.leaflabs.com/topic.php?id=31</a> used 128MHz. It invalidated the warranty. AFAIK there was little testing done on peripherals. So 18MHz for the ADC clock does sound possible, though 36MHz sounds too good to be true. (STM32F303 can do 5msps, but that is likely different electronics) There are many ways to make Analogue to Digital Converters. Some ADC architectures do generate the high-order, most-significant bits before the least-significant bits, so I can easily believe that it gets broadly reasonable results. In fact some of the latter STM32F families have ADC's which can yield lower resolution, fewer bits, results more quickly than full-precision conversions. (I couldn't find anything about that on STM32F103 in RM0008, though I have a feeling I have read something somewhere, maybe someone else can gives us a pointer?) So I am willing to believe the results look plausible, and the errors are either systematic (and may reproduce) or are mostly confined to the least-significant-bits. If that is good enough, then carry-on, keeping in mind that weird results may indicate the ADC's might generate errors, or do some testing to characterise the behaviour. My comment on libmaple was unclear, sorry. libmaple has two parts, the C++ 'wirish' part which looks like some of the Arduino libraries, and the 'low-level' C part. I was trying to ask if you had used only the low-level C, without using direct register access. In that case, it'd be much easier to get dual ADCs working. However, you were way ahead :-) "the environment light's strength can not be adjusted easily" I expect you have this solved, however this comment might help other people; if it is AC-lighting then it might not be good enough, as the light intensity will drop in synch with the mains voltage. A constant DC voltage driven light may make things much easier. The 'integration time' could be kept small, but still provide time for the ADC, by scanning the sensor multiple times and ignoring some of the pixel values. For example, if the sensor were scanned at 2MHz, but only alternate values were sampled and converted with the ADC, then conversion might work okay. Of course, that might not be possible if you're using the sensor to capture very rapid motion. Many Thanks for sharing. I am especially happy because I am considering using a similar sensor for a potential project in the New Year !-) (Full disclosure: I am not a member of LeafLabs staff.) tomxue on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105115 Wed, 25 Dec 2013 02:05:11 +0000 tomxue 105115@http://forums.leaflabs.com/ I made the maple mini's two ADCs work normally under "Dual regular simultaneous mode"! Please check my code below: <a href="https://github.com/tomxuetoy/Maplemini_HighSpeedADC/blob/65e68d12b5938149069851c03ab55259db74c4a4/HighSpeedADC.cpp" rel="nofollow">https://github.com/tomxuetoy/Maplemini_HighSpeedADC/blob/65e68d12b5938149069851c03ab55259db74c4a4/HighSpeedADC.cpp</a> The key factor I missed is below, RM0008 page 219: "<code>Note: In dual ADC mode, to read the slave converted data on the master data register, the DMA bit must be enabled even if it is not used to transfer converted regular channel data.</code>" So even if that I don't use DMA, but I still need to set the DMA bit in register ADC_CR2. By setting the DMA bit, I get the correct data at once. The run result is followed in my above code. tomxue on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105113 Tue, 24 Dec 2013 21:22:28 +0000 tomxue 105113@http://forums.leaflabs.com/ Hi gbulmer, thanks for your help! I am sorry to post the long code and cause inconvenience. Now I can not remove them any more. I will just give Github link from now on. The evidence I believe that my sensor amd maple mini (under 72MHz and ADC_PRE_PCLK2_DIV_2) works well is that: if I use a phone flashlight to irradiate the sensor, then the X value maple mini reads will go high accordingly. Closer makes bigger value, untill 4095. And I shield part of the sensor, then some of the sensor data will become smaller accordingly. While in the whole process, Y value is always zero. You are totally right that I do not need to read two ADC simultaneously, and I can read them one by one. And even that I don't have to use so high speed. But in my office, on my desktop, the environment light's strength can not be adjusted easily. So slower ADC speed will cause the sensor value got to 4095 easily. And the biggest reason may be that I hope to use this chance to learn something, maple is powerful and I hope to grasp it better. I tested that to comment out <code>adc_set_prescaler(ADC_PRE_PCLK2_DIV_2)</code> in my code, and cause the ADC speed to be slower and X sensor data bigger but Y snesor data is still all zero. So that means ADC2 does not work at all and ADC_PRE_PCLK2_DIV_2 may not be the key factor. For your last question, maybe my understanding is not right. My current code uses libmaple. It could work (X and Y sensor have right value generated) with only analogRead(), I did that but without using libmaple. I will make it work with single ADC and let the project go forward. While I will use my rest time to dig further to make this dual regular mode work, it is amazing and I do not want to give up. gbulmer on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105112 Tue, 24 Dec 2013 15:21:53 +0000 gbulmer 105112@http://forums.leaflabs.com/ tomxue - the github link is much better. If it is the same code, it is better to delete the code within your post. (Long pieces of code make the thread harder to read, and long lines in the code make the page wide, which is unplesant to read.) "I connect my sensor and roughly test it, with adc_set_prescaler(ADC_PRE_PCLK2_DIV_2) it looks like working fine, at least the data it reads via ADC seems right." I currently believe that the ADC is unlikely to be working reliably for all bits of the conversion because it is out of spec. Are you certain that the data is good? What are the tests and evidence that most of the 12 bits are working? I have experimented with a lower-cost part from TAOS using an Arduino, which digitises 100x slower than Maple. The TSL202 can be read at a very wide range of speeds. AFAIK, the rate at which the sensor performs best is set by the brightness of the light it is sensing and the integration time. So to get everything working, and reliably reading analogue values, you could even use dimmer light. The sensor has two independent sections. AFAICT they do not have to be read simultaneously, so one half could be read, then the other half. So, it is the specific use-case which is driving the need to do ADC conversion at 1Msps, and not the sensor. I haven't used both ADC's. There are threads discussing it. The two halves of the sensor do not have to be sampled at exactly the same time. So the code can achieve an effective ADC rate of well above 1Msps by sampling the two signals with two ADCs. I've never run the Maple at 56MHz. I'd have to go digging through the manual and do quite a lot of experiments to do that. I believe changing the primary system clock to 56MHz will effect a lot of other subsystems, like SysTick, the timers, USB etc. So it isn't something I have experimented with, or plan on experimenting with. I don't know if anyone here knows how to do that. I'd suggest posting on the ST.com STM32F forum to get help. Have you got code using libmaple (no direct access, only <code>analogRead</code>, and no <code>adc_set_prescaler</code>) working? tomxue on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105110 Tue, 24 Dec 2013 11:15:09 +0000 tomxue 105110@http://forums.leaflabs.com/ Hi gbulmer, thanks again for your help! I connect my sensor and roughly test it, with <code>adc_set_prescaler(ADC_PRE_PCLK2_DIV_2)</code> it looks like working fine, at least the data it reads via ADC seems right. The sensor I am using is TSL202, its spes is here: <a href="http://www.mouser.com/ds/2/588/TSL202R-E-198539.pdf" rel="nofollow">http://www.mouser.com/ds/2/588/TSL202R-E-198539.pdf</a> As you can see, I need to generate 129 clocks (by GPIO) and for each clock the chip will generate an analog signal which I need to detect via ADC. And the total period (called integration time, including 129 clock jumps and 129 ADC read time) should be as small as better in my case. In my hardware, I will apply two sensors, one is X axis and another one is Y axis. So I turned my code to use "Dual regular simultaneous mode", but I met new problem. Please check my code (deleted from post by gbulmer) below. Or you may find it here (better format): <a href="https://github.com/tomxuetoy/Maplemini_HighSpeedADC/blob/master/HighSpeedADC.cpp" rel="nofollow">https://github.com/tomxuetoy/Maplemini_HighSpeedADC/blob/master/HighSpeedADC.cpp</a> <pre><code>Starting loops: Stop loops: Elapsed Time: 30545 us (for 25800 analog reads) 1.18 us (for 1 sample) 305.45 us (for 1 sensor) pixelVal_x = 153 141 142 141 139 142 143 140 142 141 141 141 141 142 145 143 143 142 143 142 145 142 143 134 134 143 145 144 143 143 143 147 143 143 143 143 143 143 143 143 143 143 143 142 143 143 143 142 143 146 146 143 143 145 145 143 143 146 143 147 145 145 147 149 158 143 146 146 146 142 147 142 147 142 145 145 149 145 145 141 148 143 146 143 146 145 148 145 138 143 145 145 148 145 147 150 148 143 151 146 147 143 146 143 149 143 147 146 147 144 148 142 149 143 147 143 146 144 146 142 146 143 147 143 147 143 147 148 pixelVal_y = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCLK2 = 72000000 ADC1->regs->CR1 = 393216 ADC2->regs->CR1 = 0</code></pre> As you can see, the ADC2 channel doesn't work at all. Due to I need to operate GPIO each time I read ADC value, so I might not apply DMA mode (Am I right?). What is wrong with this code? Thanks! And still I don't know how to change the system clock from 72MHz to 56MHz, could anyone please help? And for the typo in the above post, "millisecond should be us", it seems that I cann't edit the post any more. I'm sorry and please notice. Edit (gbulmer): The printed values of pixelVal_x caused very, very long lines, which I've editted. However, I have caused the code to differ from the layout of results. Apologies. gbulmer on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105104 Sun, 22 Dec 2013 12:35:14 +0000 gbulmer 105104@http://forums.leaflabs.com/ tomxue - I don't understand what is happening. Edit: I think I understand what is happening. 1. "0.96us/sample" is faster than theoretically possible at 72MHz, it should be no better than 1.167us, and 2. 100000 samples should take a little longer than 1.167us/sample anyway because it should contain a bit of time for: starting then retrieving the value from the ADC conversion, the while loop overhead, and about 100 USB and 100 SysTick timer interrupt service routines. Edit: Okay, I've got it, the code does <code>adc_set_prescaler(ADC_PRE_PCLK2_DIV_2);</code> That sets the ADC clock to 36MHz (I think, or 18Mhz). The STM32F will run the ADC to convert the sampled value, but it is likely unreliable or inaccurate because it is beyond the ADC's specification. You might find that it does work for some bits, but I have no idea exactly what it will do. You'll need to do some experiments to find out how well it works as I don't think anyone has done those and shared their results already I'd suggest, don't use adc_set_prescaler, or set the CPU clock to 56MHz, and use a prescaler of 4. (You might try 'overclocking', and running the CPU at 80MHz, which has worked for some folks, then a prescaler of 6 would give a 13.3MHz ADC clock which seems safer than 18MHz ADC clock) Edit 2: The number of instructions executed by analogRead and the low-level alternative is deterministic; it always takes the same number of cycles. So there is little benefit to doing something 10000 times. In one way, timing many iterations is misleading. An unknown number of interrupt service routines will have executed during a large number of iterations. Gross timing of many iterations will include that unknown interrupt service time. If it is significant, because there were many, many interrupts, but they are relatively consistent in number during the gross-timing period, then the gross-timing will be inflated a significant amount, but appear to contain little jitter. IMHO this can be misleading. IMHO, it would be better to count using SysTick ticks directly, or a hardware timer. Let's call that <code>ticks()</code>. Then it is possible to get the time consumed by the timing mechanism: <pre><code>// ... start = ticks(); stop = ticks(); uint32 overhead = stop-start; // calculate overhead for ticks() calls</code></pre> Then it is possible to time analogRead() directly: <pre><code>// ... start = ticks(); uint16 val1 = analogRead(analogPin); stop = ticks(); uint32 analogRead_time = stop-start-overhead; // calculate analogRead ticks</code></pre> Also the lower level version, e.g.: <pre><code>//... start = ticks(); regs->CR2 |= ADC_CR2_SWSTART; while (!(regs->SR & ADC_SR_EOC)) {} uint16 val2 = (uint16)(regs->DR & ADC_DR_DATA); stop = ticks(); uint32 low_level_adc_ticks = stop-start-overhead; // calculate ADC ticks</code></pre> Then it is relatively straightforward to see how long the code takes, and also see which measurement contains background interrupt service routine overhead. My results are: analogRead: Elapsed Time: 160 ticks (for 1 analog read) [2.2us] low-level: Elapsed Time: 115 ticks (for 1 analog read) [1.6us] Using <code>adc_set_sample_rate(ADC1, ADC_SMPR_1_5);</code> and without <code>adc_set_prescaler(ADC_PRE_PCLK2_DIV_2)</code> Summary: 1. The "0.96us/sample" result may be invalid because the ADC is being operated beyond its 14MHz clock specification. It'll take more tests to discover how inaccurate it is. 2. The result will be inaccurate (and slower) because the timing will include many USB and SysTick interrupts. What is the use-case that needs the fastest possible conversion? You might be better using 'Dual ADC' mode, which should give a conversion rate significantly faster than 1us. What is the electronics that is driving the low-impedance signal to make it possible to sample at such a high-rate? Have you considered using an STM32F303-based board? That has multiple 5msps ADCs, if the signal is good enough. It might be helpful to replace "milliseconds" with "microseconds" in the printed messages to avoid confusion. tomxue on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105103 Sun, 22 Dec 2013 07:20:18 +0000 tomxue 105103@http://forums.leaflabs.com/ Hi gbulmer, thank you very much for this great help! I made some change to my code based on your suggestion, and got big improvement of the speed. Currently, just for ADC conversion, the speed I can achieve is about 0.96us/sample. Please check it below, and notice that the code is followed with the test result. You may also find it here: <a href="https://github.com/tomxuetoy/Maplemini_HighSpeedADC.git" rel="nofollow">https://github.com/tomxuetoy/Maplemini_HighSpeedADC.git</a> I will keep the source code updated and open to everyone. The main change achieved is by modifying the function: move the unchanged parts out of the loop. This helped a lot. And I changed from millis() to micros(), this causes more accurate result. But for USBSerial, if I make it execute begin() and end() within the loop(), then my serial port monitor will lose it. For Windows' device manager, I can see that it refreshes frequently. The big problem is that currently I still use the default 72MHz. I don't know how to modify the ADC clock to 14MHz or to change the system clock to 56MHz, how? And I wonder if I change the system clock to 56MHz, whether it will influence other part, e.g. SPI or I2C? If you check my code, you could see that I need to control some GPIO to jump before and after one ADC conversion. Can DMA also do this kind of work? That means DMA needs to control ADC plus GPIO jump automatically, is it possible? <pre><code>#include <wirish/wirish.h> #include <libmaple/adc.h> #define COMM SerialUSB // use this for Maple // #define COMM Serial // use this for Arduino unsigned long start = 0; unsigned long stop = 0; unsigned long counter = 0; unsigned long limit = 100000; int outPin = 18; int analogPin = 3; int val = 0; void setup() { // the following line is needed for Maple pinMode(analogPin, INPUT_ANALOG); pinMode(outPin, OUTPUT); // adc_init(ADC1); //rcc_clk_enable(ADC1->clk_id), Must be the first adc command! // adc_init(ADC2); // // adc_enable(ADC1); //ADC_CR2_ADON_BIT = 1 // adc_enable(ADC2); // // adc_calibrate(ADC1); //Optional // adc_calibrate(ADC2); // 采样率优化的关键寄存器参数 adc_set_prescaler(ADC_PRE_PCLK2_DIV_2); adc_set_sample_rate(ADC1, ADC_SMPR_1_5); // the following line is needed for Arduino // COMM.begin(57600); } void loop() { COMM.println("\nStarting loops:"); counter = 0; // digitalWrite() preparation work gpio_dev *gpiodev = PIN_MAP[outPin].gpio_device; uint8 pin = PIN_MAP[outPin].gpio_bit; // pin = 4 when outPin is 18 // analogRead() preparation work const adc_dev *dev = PIN_MAP[analogPin].adc_device; adc_reg_map *regs = dev->regs; adc_set_reg_seqlen(dev, 1); regs->SQR3 = PIN_MAP[analogPin].adc_channel; start = micros(); while (counter++ < limit) { // digitalWrite(outPin, HIGH); gpiodev->regs->BSRR = (1U << pin); // gpiodev->regs->BSRR = 0x10; // val = analogRead(analogPin); regs->CR2 |= ADC_CR2_SWSTART; while (!(regs->SR & ADC_SR_EOC)) ; val = (uint16)(regs->DR & ADC_DR_DATA); // digitalWrite(outPin, LOW); gpiodev->regs->BSRR = (1U << pin)<<16; // gpiodev->regs->BSRR = 0x100000; } stop = micros(); // COMM.begin(); COMM.println("Stop loops:"); COMM.print("Elapsed Time: "); COMM.print(stop - start); COMM.print(" milliseconds (for "); COMM.print(limit); COMM.println(" analog reads)"); COMM.println(" val = "); COMM.println(val); COMM.println(" PCLK2 = "); COMM.println(PCLK2); COMM.println(" pin = "); COMM.println(pin); // COMM.end(); } // Force init to be called *first*, i.e. before static object allocation. // Otherwise, statically allocated objects that need libmaple may fail. __attribute__((constructor)) void premain() { init(); } int main(void) { setup(); while (true) { loop(); } return 0; } /* Case 1: simplified analogRead() + simplified digitalWrite() Elapsed Time: 107186 milliseconds (for 100000 analog reads) Elapsed Time: 107185 milliseconds (for 100000 analog reads) Case 2: simplified analogRead + without GPIO control Elapsed Time: 96064 milliseconds (for 100000 analog reads) Elapsed Time: 96065 milliseconds (for 100000 analog reads) Case 3: original analogRead + without GPIO control, Elapsed Time: 199089 milliseconds (for 100000 analog reads) Elapsed Time: 199085 milliseconds (for 100000 analog reads) Case 4: simplified analogRead() + simplified (and precalculated) digitalWrite() Elapsed Time: 108584 milliseconds (for 100000 analog reads) Elapsed Time: 108583 milliseconds (for 100000 analog reads) Case 5: simplified analogRead() + original digitalWrite() Elapsed Time: 243624 milliseconds (for 100000 analog reads) Elapsed Time: 243621 milliseconds (for 100000 analog reads) Case 6: original analogRead() + original digitalWrite() Elapsed Time: 324387 milliseconds (for 100000 analog reads) Elapsed Time: 324394 milliseconds (for 100000 analog reads) */</code></pre> gbulmer on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105100 Sat, 21 Dec 2013 11:38:43 +0000 gbulmer 105100@http://forums.leaflabs.com/ tomxue - There are several causes for the ADC conversion time. The fastest ADC sample and conversion rate is 14 cycles, that is 1.5 ADC clock cycles to sample, and 12.5 ADC clock cycles to convert. 1. Maximum ADC clock is 14MHz, divided down from system clock. The ADC's clock divider is limited to a few division factors. Dividing a 72MHz system clock by 6 (the nearest divider) gives a clock of 12MHz. 14 cycles at 12MHz is about 1.17us If you want 1MHz conversion rate, then you need to change the system clock to 56MHz. 2. There is quite a lot of instructions being executed within <code>analogRead()</code> which are being repeated for every <code>analogRead()</code>, but which may need to be done only once. If you want to get closer to the raw-speed of the ADC, you'll need to understand the source of <code>analogRead()</code>, and <code>adc_read()</code>, so that you can strip away the parts which are constant for your application. You could get an estimate of the amount of time spent in extraneous code by commenting out the lines in <code>adc_read()</code> <pre><code>regs->CR2 |= ADC_CR2_SWSTART; while(!(regs->SR & ADC_SR_EOC)) ;</code></pre> and running your measurements again. I guess it is a significant chunk of 0.5us. 3. There are two interrupts running which will consume time. One interrupt is the SysTick timer, which provides the timing for millis(). It is quite short, and only triggers each millisecond, so is probably adding less than 1% error. The other interrupt is for USB. It this is a bit bigger than SysTick, and you might want to experiment with switching it off using: <code>USBSerial::end()</code> before running the measurements, then on again, using: <code>USBSerial::begin()</code> You might also use two nested loops of tests, to get some results without the added overhead of interrupts. Maybe run test that last 50-100us. Store their results into an array, and at the end of your tests print them out, and throw away the outliers, which will contain interrupt time. To get a clock to measure the ADC conversion time, either use the micros() clock instead of millis(), or look at the source of micros() and use <code>systick_get_count()</code> directly. That is counting at 72MHz, so it will give you a lot more precision. To use the systick count, instead of micros, copy and modify micros(): <pre><code>res = (ms * US_PER_MS) + (SYSTICK_RELOAD_VAL + 1 - cycle_cnt) / CYCLES_PER_MICROSECOND;</code></pre> to: <code>res = (ms * US_PER_MS) + (SYSTICK_RELOAD_VAL + 1 - cycle_cnt);</code> NOTE: The rate at which a signal can be sampled and converted is not only constrained by the sample and conversion speed of the ADC. The sampled signal needs to be able to drive enough current to charge the ADC's sample and hold. To reach a sample time of 1.5 ADC clocks (which gives a total sample and conversion rate of 14 ADC clock cycles), will require a low-output impedance signal source. Table 47 of the STM32F103xB data sheets says that the output impedance needs to be better than 0.4K, which is quite low. If the signal source has a bigger impedance, then the ADC's sample and hold circuit won't track the signal. Summary: - 1.17us is the ADC conversion time for a 72MHz system clock, only use 56MHz if it is essential to reach 1us - there is code, which may be refactored out of the critical path, in <code>analogRead()</code>, which likely improves speed by, maybe, 0.5us - USBSerial interrupts may be stealing time, making the measurements look worse, so use shorter tests or disable it - Make the tests much shorter than 1ms, and use <code>micros()</code> or <code>systick_get_count()</code> to time with enough precision. - If the signal being sampled has an output impedance bigger than 0.4K, then the ADC sample and hold won't track it anyway; using the ADC at a high sample rate won't do any good. It is possible to use two ADC's to sample the same signal, called Dual ADC mode, which could double the conversion rate, though it is still constrained by the signals output impedance. There are a few threads on this forum discussing how to do that. (Full disclosure: I am not a member of LeafLabs staff.) tomxue on "How to improve the maple mini's ADC sample rate to 1MHz?" http://forums.leaflabs.com/topic.php?id=74213#post-105093 Sat, 21 Dec 2013 02:42:53 +0000 tomxue 105093@http://forums.leaflabs.com/ Hi, I used the code written by StephenFromNYC and modified it to try to achieve the highest ADC speed of maple mini, but failed. The code is below. My board is maple mini. <pre><code>#include <wirish/wirish.h> #include <libmaple/adc.h> #define COMM SerialUSB // use this for Maple // #define COMM Serial // use this for Arduino unsigned long start=0; unsigned long stop=0; unsigned long counter=0; unsigned long limit=100000; int outPin = 18; int val = 0; void setup() { // the following line is needed for Maple pinMode(3, INPUT_ANALOG); pinMode(outPin, OUTPUT); // adc_init(ADC1); //rcc_clk_enable(ADC1->clk_id), Must be the first adc command! // adc_init(ADC2); // // adc_enable(ADC1); //ADC_CR2_ADON_BIT = 1 // adc_enable(ADC2); // // adc_calibrate(ADC1); //Optional // adc_calibrate(ADC2); adc_set_prescaler(ADC_PRE_PCLK2_DIV_2); adc_set_sample_rate(ADC1, ADC_SMPR_1_5); // the following line is needed for Arduino // COMM.begin(57600); } void loop() { COMM.println("\nStarting loops:"); start=millis(); counter=0; while (counter++ < limit) { //digitalWrite(outPin, HIGH); val = analogRead(3); //digitalWrite(outPin, LOW); } stop=millis(); COMM.println("Stop loops:"); COMM.print("Elapsed Time: "); COMM.print(stop-start); COMM.print(" milliseconds (for "); COMM.print(limit); COMM.println(" analog reads)"); COMM.println(" val = "); COMM.println(val); COMM.println(" PCLK2 = "); COMM.println(PCLK2); } // Force init to be called *first*, i.e. before static object allocation. // Otherwise, statically allocated objects that need libmaple may fail. __attribute__((constructor)) void premain() { init(); } int main(void) { setup(); while (true) { loop(); } return 0; }</code></pre> For the above code, if I apply those lines below, there will be nothing from my Serial Port monitor. So I have to comment them out. Why? <pre><code>// adc_init(ADC1); //rcc_clk_enable(ADC1->clk_id), Must be the first adc command! // adc_init(ADC2); // // adc_enable(ADC1); //ADC_CR2_ADON_BIT = 1 // adc_enable(ADC2); // // adc_calibrate(ADC1); //Optional // adc_calibrate(ADC2);</code></pre> My Serial Port monitor shows: <pre><code>Starting loops: Stop loops: Elapsed Time: 190 milliseconds (for 100000 analog reads) val = 2119 PCLK2 = 72000000 Starting loops: Stop loops: Elapsed Time: 189 milliseconds (for 100000 analog reads) val = 2138 PCLK2 = 72000000</code></pre> As you can see, the ADC read speed is around 1.9us/sample. But it could reach to 1us at most, how to achieve it then?