STM32 micros just like any other micro provide hardware for serial communication. As we all know serial communication is a very important tool for debugging, connecting with external hardware like RFID, GPS, GSM modems, etc. and for performing other communication-related tasks. STM32s have several hardware serial (USART) ports. The number of ports available in a STM32 micro is dependent on device family type and the device itself. Typically there are at least 5 serial ports. Apart from the basic serial communication needs, STM32’s USART hardware also have support for LIN, one-wire, smart card protocols, SPI and IrDA. We can even utilize STM32’s DMA controller with USART hardware to achieve high speed automated data communication. Thus these hardware are truly universal synchronous-asynchronous receiver-transmitters.
In any standard serial communication, we need three wires – TX, RX and GND. TX pin is an output pin and transmits data serially to another device’s RX pin. RX pin is an input pin and is responsible for receiving data from another device’s TX pin. The two devices connected in this way must have same ground (GND). There are other pins like CTS and RTS which are used for hardware flow control. Additionally there’s also another pin called CK. It is transmitter’s clock output and used usually in SPI and other modes.
Depending on package, USART pins are arranged in the following pattern:
Personally I’m interested in LQFP packages, particularly 48 and 64 packages as they are mostly used in the most common STM32 development boards. I suggest locating USART/UART pins before working with them.
What is this Standard Peripheral Library (SPL)?
It’s just a collection of hardware libraries that provide an easy approach to any STM32 ARM programmer. It has support for every peripheral a STM32 micro has like CAN, USB, ADC, Timers, etc. In short it’s a hardware abstraction layer fully covering the STM32.
Why use the ST SPL?
- Reduce coding time by spending less time figuring out 32 bit register values and going through a near thousand page reference manual.
- Take the advantages of the built-in code library of MikroC which other compilers don’t offer.
- SPL is used by most STM32 ARM programmers and so it is a widely used tool with a large community.
- Most books and documents on STM32 ARMs are based on SPL.
- A compiler like MikroC doesn’t give full focus towards STM32. It has other ARM concerns like TI’s TIVA, NXP, etc and so MikroC’s built-in libraries are not 100% compatible with all ST hardware.
- Following the previous point MikroC (at least at the time of writing this article) doesn’t give library support for hardware like the DMA and so there’s incompleteness to some extent. It is also worth noting that depending on MikroC’s library also has the disadvantage of code size and efficiency. It is in general true for every compiler. However MikroC’s IDE is cool enough to do things with ease and that’s why I like it. Unless you are a Maple or Arduino fanboy, you’ll get my point.
- Modified ST Standard Peripheral Library (SPL) as supplied here: STM32 Standard Peripheral Library for MikroC. It works for STM32F10x micros only.
- MikroC PRO for ARM compiler.
- Flash Loader Demo or ST-Link Programmer Software.
- A STM32F10x Development Board.
- A USB-Serial Converter or ST-Link Programmer.
- Some basic components like a mini bread board, connecting wires/jumpers, a LED, a 220Ω 0.25W resistor and a push button.
- Optional debugger hardware.
How to use the Standard Peripheral Library?
First we need to prepare our MikroC PRO for ARM compiler for linking with SPL. I’m assuming that the compiler is preinstalled. First go to the compiler’s installation folder and look for the include folder. In my case, it is:
C:\Users\Public\Documents\Mikroelektronika\mikroC PRO for ARM\Include.
In this folder there’s a file named stdint.h. It’s basically a definition of variable types and other related stuffs. Rename it to stdint (backup).h and copy the new stdint.h file from the supplied folder to this location. We are done here.
Okay firstly the reason I wrote about the clock system instead of I/O ports or something else in this second post of the XMega series is simply because of the fact that without understanding clock configurations you won’t get what you want from your chip. Since XMega’s clock system is software-level configurable and complex at first, it makes itself the first priority module before anything else.
There are several clock sources that XMega micros can use as clock. These are both internal and external clock sources. As stated earlier, clocks are not set by fuse settings unlike traditional Mega AVRs, they are controlled by software and the outputs from these sources can be multiplied using the internal Phase Locked-Loop (PLL). Thus there’s a wide range of clocks available in the XMega and it’ll not be needed to shut down and reprogram the XMega just to change its clock – a great relief from meddling with fuse settings. Some port pins can also output the system clock frequency. Literally there’s no need to depend on external quartz crystals which are not available in all frequencies.
In any microcontroller there is at least one general purpose input-output port. STM32 is a not different breed and as expected it also has several GPIO ports. These ports are usually named GPIOA, GPIOB, etc. but unlike most 8/16-bit micros these ports are 16 bit wide. Thus, in general, every port has 16 IO pins. Port pins have several modes of operation and this is what that makes them both robust and complex at first. In development boards the IO port pin naming is cut short and so we’ll find PA0, PB12, etc. instead of GPIOA0, GPIOB12, etc. Even in the reference manuals this short naming is used widely. In the end every I/O pin is general purpose in nature.
Key points with STM32’s GPIO
- Upon any reset event all GPIOs are floating inputs. This prevents any accidental damage to GPIOs in the event of emergency.
- All GPIO registers are needed to be accessed with 32 bit words. This is mandatory.
- Reserved bits for any GPIO register are kept at reset values i.e. 0.
- For every GPIO port there are seven registers but the only the first four are the most important ones. The rest can be ignored most of the times.
- These important GPIO registers per port are CRL, CRH, IDR and ODR. The rest three registers for GPIO ports can be avoided at the beginning.
- For bit set and for bit clear, operations REGx |= (1 << bit) and REGx &= ~ (1 << bit) respectively are very handy and efficient. However MikroC compiler provides bit level access though its internal header file coding like this GPIOB_BSRRbits.BS15. We can use this method or the other one.
- Some IOs are 5V tolerant and are label “FT” in datasheets and other docs. The rest of the I/O pins are not that tolerant and so 3.3V operation should always be ensured. STM32 has a maximum VDD tolerance of 4V but this value shouldn’t be used in any situation for safe operation. Best is to avoid 5V use with GPIOs whenever possible. This will help in avoiding accidental damage to the micro due to common mistakes.
- Unused GPIO pins should be kept at reset state or tied to ground with 10kΩ resistors so that they remain either as floating inputs or safely connected to ground though it’s not a must.
- I/O pins can source or sink currents up to 25mA. Thus direct LED drive is possible with them. To drive loads that need more than this value, we must use external BJTs, MOSFETs, optocouplers, transistor arrays or other driver devices.
- I/O pins should not directly drive inductive or capacitive loads.
- Care should be taken to avoid driving outputs beyond 50MHz. This is the maximum I/O pin frequency rating.
- CRL/H registers essential set GPIO pin operating mode independently as according to the table below:
- CRL sets GPIOs from 0 – 7 while CRH sets from 8 – 15. All IO ports are 16 bit wide unlike common 8 bit micros like PIC or AVR.
This garage door opener built around the parts mostly available from Sparkfun uses the fingerprint scanning mechanism to open the door.
Garage door opener with fingerprint scanner
As a person without a car, I don’t need to carry keys around everywhere I go. Because of this, I’ve been locked out of my own house several times. It’s a pain to wait for someone with a key, so I thought I would do something about it.
This project is my way of solving this problem, while getting the chance to interface with an awesome fingerprint scanner (aka: FPS).
Also, this module isn’t restricted to just garage doors, for you can create different kinds of simple motorized locks to suit your needs.