Programming STM32-Discovery using GNU tools. Linker script

Previously we went through setting up a development environment for ARM Cortex-M3 microcontroller. We decided that two equal choices will do the same job – either CodeSourcery G++ Lite or Yagarto. Both use the same base of GNU tool-set. Developing with GCC tools To get a working binary, there is a series of tools involved during code development. Several tools are necessary to compile simple applications. These are compiler, assembler, linker and binary generator. Each of them does its task in a chain process. When you start compiling your project, a linker is usually invoked, which with correct parameters links libraries and object files. Once executable is generated, the binary image generator creates a binary image (.bin or .hex) uploaded to MCU. We won’t go into details right now as this will be more convenient to do in later code examples. Let us get directly to the code writing part, which is very important for linker and tasks before the main() routine.

Continue reading

Setting ARM GCC development environment

As we mentioned before, we are going to stick with free software tools. So we are going to use free and open-source GCC compiler to develop programs for ARM Cortex microcontrollers. As we will work from the windows environment, there are a couple of serious choices that are pretty similar. One is using CodeSourcery Lite edition or Yagarto Gnu ARM toolchain. Both tools work the same as they use the same GCC compiler and other tools. Both seem to be supported frequently. CodeSourcery claims that they are updating Lite Edition twice a year, while Yagarto is doing this more regularly depending on updates of separate tools. So your choice won’t affect your final result. When installed you can quickly check if everything works fine by opening command-line tool and writing a simple command that checks the version of ARM GCC compiler: arm-none-eabi-gcc.exe -v Both can be used with Eclipse IDE and require a makefile. The only difference – is a path to tools when compiling. Download any or both of these and install to your machine. Next step is to…

Continue reading

Do we need ARM?

ARM microcontrollers are very successfully positioned microcontrollers in the market. Billions of them are used in all areas where control, data processing, in interfacing is needed. ARM microcontrollers have evolved into a high-level product that provides high processing power with the minimum clock frequency and power usage. Practically all major manufacturers are developing their line or ARM processors that share the same standard core functionality, and variations between MCUs starts with peripherals and other external features. ARM microcontrollers are cheap and robust which makes them attractive to use in almost all applications. They are successfully taking the place of smaller microcontrollers like ARM or PIC. Hobbyists also are taking them over.

Continue reading

Using Standard IO streams in AVR GCC

In the previous tutorial, we learned how to transmit data over USART. By using simple functions, we can send or read bytes/arrays. We learned how to do this very efficiently with interrupts and buffers. But when things become more involved and our data messages have to be somehow formatted, our send and receive functions would begin to grow tremendously. Don’t waste your time figuring all out. AvrLibc has an excellent standard library stdio.h, which is specially designed to deal with formatted data streams. This library offers superior functionality but also takes a significant amount of code space and program speed. So before use, it makes sure your program isn’t time critical or won’t take more code space then AVR can hold.

Continue reading

Programming AVR USART with AVR-GCC. Part 2

In the last part of the USART tutorial, we discussed the most straightforward way of implementing USART transmitting and receiving routines. These are OK to use, but in more intense and power-critical applications, they are not practical and efficient. First of all, using loops to poll for transmitting buffer to be ready or wait for received byte consumes lots of processing power, what also leads to more power consumption. In reception mode, we can’t predict when actual data will be received, so the program has to check for received data indicating flag constantly and don’t miss it as next upcoming byte may clear it. So there is a better way of using USART – so-called Interrupt Driven USART. USART Interrupt sources If you look into the datasheet, you will find that USART0 in Atmega328 has three interrupt sources: Probably a natural question comes out: Why there are two interrupts for transmission? The explanation is simple. Let’s take TX Complete interrupt. It will occur when Transmit Shift Register has been shifted out and is empty. We have empty transmit buffer UDR0…

Continue reading

Programming AVR USART with AVR-GCC. Part 1

AVR USART tutorial will be a multi-part tutorial as this peripheral is a sophisticated device and needs special attention. USART Overview USART is an acronym for Universal Synchronous and Asynchronous serial Receiver and Transmitter. Instead of using this long expression, let’s stick to USART. So, at least one USART is found in most of AVR microcontrollers (except few of Tiny ones). Atmega328 microcontroller has one USART module that is highly configurable and flexible. Datasheet provides a list of supported features, including Full Duplex, Asynchronous and Synchronous operation, Master or Slave operation mode, variable frame size, even or odd parity bits, one or two stop bits, several interrupt sources, and even more. We won’t be able to cover all of them in the tutorial – we will take common cases and probably something that might look interesting.

Continue reading