[Solved] STM32 (blue pill) Pin vs NANO Pin equivalency?

There are none so blind as those who cannot see!  That chart I stared at for an hour has exactly what I'm looking for. The 3rd, 4th, and 5th lines under the legend say "PHYSICAL PIN, ARDUINO PIN. and PIN NAME.  Go easy on me. ? 

Paul VE1DX

Posted by: @ve1dx

I would have thought, given the popularity of the STM32 board, someone would have put such a table on the Internet. If they did, I can't find it.

That's they way I am with my glasses.  I'm looking all over the place for them only to realize that I've been wearing them the whole time. ? 

Posted by: @robo-pi

That's they way I am with my glasses.  I'm looking all over the place for them only to realize that I've been wearing them the whole time. ? 

So I'm not the only one! Since I saw the obvious, I have been verifying the pins using LEDs with 470-ohm dropping resistors, and things work as advertised.  The stock Blink works on the blue pill because you can say "BUILTIN" to define the LED, but with the STM32 series you have to use a different nomenclature:

int LEDpin_1 = PC13; // Physical pin 2
int LEDpin_2 = PC14; // Physical pin 3
int LEDpin_3 = PB0;  // Physical pin 18

I was using 13, 14, etc without the PC.   

Also, again I have to blame my eyesight and overlooking the obvious.  The boards for NANOs and STM32F103s are not the same physical size!  I assumed they were, so I was counting to the wrong pin number.  There's also not enough room near the pin holes to label them fully, so PC13 ends up being labelled C13, etc. Lots of little gotchas.  Perhaps you've gathered I'm a "learn by your mistakes" person.  Mostly it doesn't matter, but if you want me to change your transmission, for example, you might want to think twice!

Paul VE1DX

@ve1dx

Hi:

Isn’t the STM32 a lot more powerful (cpu cycles per second) than the nano?

I am not trying to be critical at all, I just want to understand.  I reach for a nano for most all of my projects...

Posted by: @ve1dx

I was using 13, 14, etc without the PC. 

Just as a note, these stand for PC = PORT C, PB = PORT B, etc.

You can also access these ports directly as entire bytes instead of using digtitalWrite commands.

Here's a page on PORT control using STM32 language.

Accessing-Reading and Writing to whole gpio ports of stm32 microcontrollers

Here's a page on PORT control using Arduino language.

Port Registers

DISCLAIMER: I have yet to use the Arudino PORT commands in STM32 programs.   So I can't speak to how they might work, or not work!   But I have used the PORT commands on the UNO and Mega boards and they work just fine there.

In any case, that's what the Px numbers are referring to.  Specific PORT pins.

Just more rambling:

There are entire communities that program the STM32 chips using the alternative language and IDE that was referenced in the first link above.   I never bothered to look into that much as I'm happy just using the Arduino IDE.

Anyway here's some difference in the syntax

Arduino Syntax

PORTD = B10101000; // sets digital pins 7,5,3 HIGH

STM32 Syntax

GPIOD->ODR = 0x0001;  //Write to port-d

As you can see in the above Arduino example, using PORTD you can set multiple pins (up to eight) in one line of code.   Otherwise you might need as many as eight lines of digitalWrite commands.

NOTE: This is considered to be "more advanced" programming and many people (especially in the Arduino world) frown upon using PORT commands as they claim that using digitalWrite commands are more easily readable and recognizable to most people.   There are also a lot of little quirky things you need to be aware of when using PORT commands.  Such as ORing a port with data so as not to disturb the state of pins you don't want to change, etc.   So it can get a bit complicated and thus earns it's label of being considered to be "more advanced" programming.  ? 

@robo-pi

Posted by: @robo-pi

NOTE: .........................................................many people (especially in the Arduino world) frown upon using PORT commands as they claim that using digitalWrite commands are more easily readable and recognizable to most people.  

This may well be true, but they can be easily wrapped up in functions for the same ease of use.  I have played around a little with direct PORT access before, and the one big advantage of using them is that the ports can be manipulated (turned on or off), simultaneously and very fast.  I quite like the idea of using them, as I want to design my own stepper driver using the technique some time in the future.

Cheers!

@tentoes

Posted by: @tentoes

Isn’t the STM32 a lot more powerful (cpu cycles per second) than the nano?

I am not trying to be critical at all, I just want to understand.  I reach for a nano for most all of my projects...

Yes, it is more powerful.

Just wanted to add, that there are 4 new nanno's available, and the every base version is slightly faster than the current one you may have?

Here is a review of the new models: Latest nano's

Also, one of the newest Arduino? products being released (not yet), is the: portenta-h7 and looks like a very good board, but expensive - The clones on eBay etc... should be much cheaper.

Cheers!

Posted by: @frogandtoad

I quite like the idea of using them

I like using them too.   But I did run into a problem on my robot which I still don't understand.

The problem was when I added the motor encoders using interrupts.  Previously I was using PORT commands to control the motor directions, etc.   But when I added the interrupt routines I couldn't get the thing to work.  I went through the programming a bunch of times but just couldn't see anything wrong with it.  Finally just out of pure frustration I decided to go back to using digitalWrite command in the motor control circuit and suddenly everything worked perfectly.

I'm still not clear on what it was about the PORT commands that wasn't working with the addition of the interrupt routines.   All I knows is that when I reverted back to using digitalWrite everything worked just fine.

Maybe someday I figure out what happened there?   In the meantime since everything was working with digitalWrite commands I just move onward.  Why complain about something that works?

But you're right, there are actually situations where you actually need to use PORT commands in order to be able to do things fast enough in certain situations.   Using digitalWrite commands actually take longer to execute.   It's not much, but in a high-speed situations it can become important.

@robo-pi

Posted by: @robo-pi

I like using them too.   But I did run into a problem on my robot which I still don't understand.

The problem was when I added the motor encoders using interrupts.

Unfortunately I can't help you with that at this stage, as I haven't used them with interrupts.  This would probably take some reading to figure out volatility and interactions with interrupts in the scheme of things.

Indeed, speed and simultaneous executing is a big benefit if you can employ their use in your design.

Cheers!

Posted by: @frogandtoad

Unfortunately I can't help you with that at this stage, as I haven't used them with interrupts.  This would probably take some reading to figure out volatility and interactions with interrupts in the scheme of things.

I too figure there must be a way to use them together.   It's no doubt due to something I'm simply unaware of.   But that knowledge wasn't coming to fruition quickly enough. So I just went back to the digitalWrite commands that seemed to work just fine.   Someday I'll figure it out. ? 

Posted by: @robo-pi

I too figure there must be a way to use them together.   It's no doubt due to something I'm simply unaware of.   But that knowledge wasn't coming to fruition quickly enough. So I just went back to the digitalWrite commands that seemed to work just fine.   Someday I'll figure it out. ? 

Here's a shot in the dark.  PORT is kind of unconventional.  I understand its power, and back in the day, I used similar commands with AND and OR to flip bits on 16-bit Hewlett-Packard systems in FORTRAN when memory and other resources were scant.  With speed and shortcuts sometimes come unexpected consequences. 

No doubt that's why digitialWrite is slower.  It's certainly doing overhead that the PORT command does not, and ISRs used to be tricky to write.  35 years ago I wrote them for IBM PCs (Intel processors) using Pascal, and it took a lot of time to get it right.   The Arduino IDE and compiler should have their Interrupt Service Routines optimized and debugged to death by now as interrupts are commonly used on microcontrollers.  However, it's possible no one else has reported that PORT doesn't work properly from an ISR. 

Here's an article from 1985 I wrote for Byte magazine on how to do it in the Dark Ages.  There might be a clue here.  If not, I get to brag about them publishing this! ? 

Paul VE1DX

Posted by: @ve1dx

No doubt that's why digitialWrite is slower.  It's certainly doing overhead that the PORT command does not, and ISRs used to be tricky to write.  35 years ago I wrote them for IBM PCs (Intel processors) using Pascal, and it took a lot of time to get it right.   The Arduino IDE and compiler should have their Interrupt Service Routines optimized and debugged to death by now as interrupts are commonly used on microcontrollers.  However, it's possible no one else has reported that PORT doesn't work properly from an ISR.

That is possible, and even likely that it is the actual PORT command that is failing to take care of business.  Now that you've mentioned this I can take a look at the code for the digitalWrite command and the PORT command and see how they differ.  You could be right!   

Posted by: @ve1dx

Here's an article from 1985 I wrote for Byte magazine on how to do it in the Dark Ages. 

Nice article!  Looking forward to reading it later when I have time to enjoy it. ?