Blue Pill where is ADC Registers setup in Library?

Hi Everyone.

I am using the official Github/STMicro Core.

In the Wiring_Analog.C and .H files there is some ADC setup but where is the actual Registers configured?

Below is the path on my pc.



In the HAL. Why do you need to know, for what purpose?


The Arduino ADC read is very slow and it seems like the ADC is switched off after every read.
So I wanted to change the way the analogRead is setup in the library.

But this is a HUGE task.If I could take the ADC setup and run it only once in Setup() and then NOT use analogRead() and then just clear the Status bit and Set the Start Conv bit but then I will have to deal with the DMA to get the analog value.

I found this in the Library but Arduino ide does not know what to do with this code and neigher do I.


I think I will try the Cube ide .. found a nice TFT video for the STM32F103C using Cube.

Iam using analogRead for 15 kHz signals and have no problems,

Sure, use Cube, it's brilliant. But it won't necessarily solve your problem. Which you haven't posted code for.

I have also used analogRead() on STM hardware and never had any response problem. Please post all your code.

With the official Github_STmicro core?

235 readings into a Array = 19241uS this is what I get.With Arduino.ide

The datasheet shows this, how is this possible?

ADC conversion time:
– STM32F103xx performance line devices: 1 μs at 56 MHz (1.17 μs at 72 MHz)
#define LCD_CS A3 // Chip Select goes to Analog 3
#define LCD_CD A2 // Command/Data goes to Analog 2
#define LCD_WR A1 // LCD Write goes to Analog 1
#define LCD_RD A0 // LCD Read goes to Analog 0
#define LCD_RESET A4 // Can alternately just connect to Arduino's reset pin

#include <SPI.h>          // f.k. for Arduino-1.5.2
#include "Adafruit_GFX.h"// Hardware-specific library
#include <MCUFRIEND_kbv.h>
MCUFRIEND_kbv tft;
//#include <Adafruit_TFTLCD.h>

#include <FreeDefaultFonts.h>
#include <Fonts/FreeSans9pt7b.h>
#include <Fonts/FreeSans12pt7b.h>
#include <Fonts/FreeSerif12pt7b.h>

// Assign human-readable names to some common 16-bit color values:
#define  BLACK   0x0000
#define BLUE    0x001F
#define RED     0xF800
#define GREEN   0x07E0
#define CYAN    0x07FF
#define MAGENTA 0xF81F
#define YELLOW  0xFFE0
#define WHITE   0xFFFF

const unsigned int numReadings = 235;
unsigned int myArray[numReadings];

long int startt = 0;
long int endd = 0;
long int elapsed = 0;
int yy = 120;
int myX = 0;

int analog = 0;

int  Digit1 = 0;
int  Digit2 = 0;
int  Digit3 = 0;
int  Digit4 = 0;
int  Digit5 = 0;
int  Digit6 = 0;
int  Digit7 = 0;
int  Digit8 = 0;
int  Digit9 = 0;

int value2 = 0;
int digCol = 0;
int A = 0;
uint16_t RxData[3];

void BCD_Conv (void)
  Digit1 = value2 % 10 ;      //12345678_9
  Digit2 = (value2 / 10) % 10; //1234567_8
  Digit3 = (value2 / 100) % 10; //123456_7
  Digit4 = (value2 / 1000) % 10; //12345_6
  Digit5 = (value2 / 10000) % 10; //1234_5
  Digit6 = (value2 / 100000) % 10; //123_4
  Digit7 = (value2 / 1000000) % 10; //12_3
  Digit8 = (value2 / 10000000) % 10; //1_2
  Digit9 = (value2 / 100000000) % 10; //_1

void setup(void)
  uint16_t ID = tft.readID();

  if (ID == 0xD3D3) ID = 0x9481; // write-only shield
  //    ID = 0x9329;                             // force ID
  tft.setRotation(0);//0=port ,, 1=lands flip ,, 2=port flip ,,3=lands

  int myX = 0;
  int myY = 0;


void loop(void)
  // tft.setFont(NULL);  //print value in system 7x5 font.

  startt = micros();

  for (unsigned int i = 0; i < numReadings; i++)
    analog = analogRead(PB1);
    myArray[i] = analog ;
  endd = micros();
  tft.setTextColor(YELLOW, BLACK);
  tft.setCursor(0, 0);
  elapsed = endd - startt;

  for (unsigned int i = 0; i < numReadings; i++)
    tft.drawPixel( myX , (myArray[i]) / 3 , GREEN);
    myX = myX + 1;
    if (myX == 235)
      myX = 0;
  // myX = 0;

You trust a TFT print? I would use serial to be sure...

The STM have a really fast clock. Your start and stop times 'startt' and 'endd' should be declared unsigned.

This is 300HZ signal.1KHZ signal is just a bunch of pixel does not see the sine wave any more.

long unsigned int startt = 0;
long unsigned int endd = 0;
long unsigned int elapsed = 0;

Still 19241uS.

try 128MHz

Seems like our Cores is not the same.
I did read on this Forum that (dont know where it is now) that the 32FDuino core is much faster.

Use google translate.
UP to 200kHz

A while back, I posted benchmarks for the STM32 bluepill using the official STMMicro core and the STM32duino core that was a community based projected derived from the Maple Mini core. The STMMicro core is an order of magnitude slower at about 63 uS per analogRead():

Yes it was this forum.

63uS x 235 Reads = 14805uS and get 19241uS so it is very slow.

Indeed. I don't recall exactly what prompted me to run the benchmark but it was almost certainly revisiting some project that stopped working after switching to the official core.

There are good reasons to use the official core, but the single sample ADC performance is horrible.

The STM official core was designed to support as many different STM processors as possible. The way it was done, is to wrap the HAL. That was a good idea, since after the initial effort, new processors are very easy to add, and improvements to the HAL apply to all Arduino wrappers. The HAL itself is a layer of abstraction that permits that versatility, but in doing so, can't always wrap all processor specific functions. If you are developing and you need those, I think the normal way would be to use LL library functions (which are processor specific, AFAIK).

Alternative cores that I used, don't have this problem, but suffer from lack of abstraction of processor type. Thus they are a maintenance headache, and each additional processor required extensive manual adaptations in spite of some very clever factoring and common code.

If you are really serious about developing for that hardware, you will use Cube or some IDE other than Arduino, that supports HAL and LL with example code for each peripheral to get started.

Working elements of the alternative cores were/are nowhere near as well documented as the STM core, in the sense that they boil down to the HAL and LL documentation, which is quite well covered. So, I abandoned them and used the STM Arduino core for general purpose stuff, and Cube IDE for more hardware intensive work.

Looks like the meat of the code is here:

And yeah, it looks awful - completely re-initializing the ADC each times it's called.
And despite using a supposed HAL, it's full of conditionals for different CPUs. :frowning:

IIRC, Leaf labs started their Maple project using stlib (predecessor to HAL?), and performance was so awful that they decided they had to write stuff from scratch. Then they ran into worries about licensing, and didn't even use the ST IO register definitions, which made their code pretty awful to port to anything new. :frowning:

Yes a lot of coding for analogRead.

Just to clear a few things for myself is the STM32duino the Roger Clark Core?

Is this Core compatible with e-SPI Library from Bodmer and MCUFriend from David Prentice?

I aslo found Arduino samples not working just to find out I must use the R Clark core and then find something that must use the STMicro Core.

Is it possible to run both Cores on the same Arduino ide?

Please supply links. Probably nobody knows, but someone might yield to curiosity and go have a look for you.

The other sentence you wrote after that is confusing, but guessing at the meaning, you must compile examples using the core that they shipped with, they're not likely to work with a different core.

However, most Arduino examples written for the AVR processors are so simple, that they should run on almost any core. Some might need slight modification such as pin name assignments.

When you have a problem, it would behoove you to post details and not just generalities like "not working".