One day I realized that in order to implement my idea, I couldn’t get along with transistors and self-made RS triggers, and it’s time to start working with microcontrollers.
In microcontrollers, I unfortunately have an absolute zero, and I had to start googling and read a bunch of articles. After some time, when the difference between the Von Neumann and Harvard architecture and other basic things became clear, it was necessary to choose a microcontroller with which I would work.
Because of the simplicity of the opportunities I needed, I stopped at the
PIC , but a colleague put me on the right path in time and told me to dig in the direction of
STM and
AVR , since the cost price is not much more and the opportunity is much higher.
')
And soon I purchased the
STM32F4 Discovery Kit for STM32F407 debug board
.On the first day I rushed around the house with her and was happy how the LEDs blink and the gyroscope works. But it’s time to start writing programs yourself. After 30 minutes of googling, I realized that 95% of the solutions described on the Internet work under Windows, and the happy owners of Linux and Mac OS are walking in the forest. I spent 3 days in the evenings looking for solutions and as a result we have a complete manual on how to start programming under STM32 under Mac OS.
IDE
First you need to put the development environment. In our case, it will be Eclipse (Indigo R Eclipse IDE for C / C ++ Developers Mac Cocoa 64-bit). Follow the link
Eclipse download and install.
GNU ARM toolchain
You can download from the official site
http://www.gnuarm.com/files.html . But for some reason, when trying to run
arm-elf-gcc or
arm-elf-g ++, an error occurs -
Bad CPU type in executable . Why? I have not figured it out yet. Therefore, I give a reference to my fork repository
arm .
Let's pump it out -
git clone github.com/jsnyder/arm-eabi-toolchain.git
Now you need to put all the necessary packages -
brew install mpfr gmp libmpc texinfo
Next we go to the extorted directory -
cd arm-eabi-toolchain
And we perform:
mkdir -p $ HOME / arm-cs-tools / bin
export PATH = $ HOME / arm-cs-tools / bin: $ PATH
CC = clang make cross-binutils cross-gcc cross-g ++ cross-newlib
make cross-gdb
export PATH = $ HOME / arm-cs-tools / bin: $ PATH
make cleanST-LINK
Go
here download and install as written in the readme. Here you can read the debugger
ST-LINK .
Customization
Now we start to tie everything together.
Run Eclipse. Go to
Help -> Install New Software. Click the link
Available Software Sites . Find the
CDT Juno , tick and click OK. Now in the field
Work with choose
CDT Juno . In the list that appears, look for
GCC Cross Compiler , tick and then click
Finish .
Now we can create the project we need.
Go to
File -> New -> C ++ Project . Select
Executable Cross Compile Project , give it a name and click
Finish .
Now we have an empty project and need to configure it.
Choose our project, right-click and go to
Properties -> C / C ++ Build -> Settings .
In the Cross GCC Assembler -> General -> Assembler flags, write -mthumb -mcpu = cortex-m4
In the Cross GCC Compiler -> Miscellaneous -> Other flags we write -c -mthumb -mcpu = cortex-m4
In Cross G ++ Compiler -> Miscellaneous -> Other flags we write -c -mthumb -mcpu = cortex-m4
In the Cross GCC Linker -> Miscellaneous -> Linker flags we write:
-T "$ {ProjDirPath} /stm32_flash.ld" -mthumb -mcpu = cortex-m4 -Wl, -Map = linker.map -Wl, -cref -Wl, -gc-sectionsNow after compilation we will get a binary file in the required form. To do this, right in the settings, select the
Build Steps tab and in the Command field we write
arm-none-eabi-objcopy -I ihex "$ {ProjName}" "$ {ProjName} .ihex"Basic project
Here we download the basic project. It describes how the debug board can flash LEDs.
After you download and place all the files in the Eclipse project. You need to specify the paths to the plugin headers. Again, go to
Properties -> C / C ++ Build -> Settings.Here at the
Cross GCC Compiler and the
Cross G ++ Compiler in
Includes we add
"$ {workspace_loc: / $ {ProjName} / inc / STM32F4xx_StdPeriph_Driver / inc}"
"$ {workspace_loc: / $ {ProjName} / inc / STM32F4xx_StdPeriph_Driver / src}"
"$ {workspace_loc: / $ {ProjName} / inc / CMSIS}"
"$ {workspace_loc: / $ {ProjName} / inc / STM32F4xx}"
"$ {workspace_loc: / $ {ProjName} / inc}"and click OK.
Go
Look like that's it. I did not bind st-link and gdb to eclipse. Therefore, I will show how everything is done from the console.
In
Eclipse, we
build our project with the
Build button.
After making sure that the build is successful and there is a binary file too, we connect our board via USB.
Open the console (better iterm). In the first tab, run
st-link. Once installed, it should be available globally.
parikmaher say: st-util
2013-12-05T22: 48: 22 INFO src / stlink-common.c: Loading device parameters ...
2013-12-05T22: 48: 22 INFO src / stlink-common.c: Device connected is: F4 device, id 0x10016413
2013-12-05T22: 48: 22 INFO src / stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
Chip ID is 00000413, Core ID is 2ba01477.
Target voltage is 2879 mV.
Listening at *: 4242 ...
We see how the device is determined and the handler is hung on port
4242 .
In the adjacent tab, run the previously installed arm-none-eabi-gdb
parikmaher say: arm-none-eabi-gdb
GNU gdb (32-bit ARM EABI Toolchain JBS-2013.05-23-v2015.05-1-gd66a29f) 7.4.50.20120716-cvs
Copyright © 2012 Free Software Foundation, Inc.
License GPLv3 +: GNU GPL version 3 or later < gnu.org/licenses/gpl.html >
This is free software:
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host = x86_64-apple-darwin12.5.0 --target = arm-none-eabi".
For bug reporting instructions, please see:
< github.com/jsnyder/arm-eabi-toolchain >.
(gdb)
All perfectly. Now you need to connect to our device. You must run the
target remote command
: 4242(gdb) target remote: 4242
Remote debugging using: 4242
0x08000b70 in ?? ()
In the next tab where st-link is running, we need to see the GDB connection info
KARL - should read back as 0x03, not 60 02 00 00
GDB connected.
Well, it remains to the last. Need to roll our new firmware.
Go to the tab with GDB and execute the
load command
(gdb) load binary_path_.ihex
Loading section .sec1, size 0xc10 lma 0x8000000
Start address 0x8000b70, load size 3088
Transfer rate: 3 KB / sec, 3088 bytes / write.
And in the next tab of the debugger it will be seen that everything is successfully rolled
2013-12-05T22: 56: 04 INFO src / stlink-common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector: 0x0 Size: 0x4000
Flash page at addr: 0x08000000 erased
2013-12-05T22: 56: 05 INFO src / stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2013-12-05T22: 56: 05 INFO src / stlink-common.c: Starting Flash write for F2 / F4
2013-12-05T22: 56: 05 INFO src / stlink-common.c: Successfully loaded flash loader in sram
size: 16384
2013-12-05T22: 56: 05 INFO src / stlink-common.c: Starting verification of write complete
2013-12-05T22: 56: 05 INFO src / stlink-common.c: Flash written and verified! jolly good!
To see the result, in gdb run the command 'c' (continue). The board should blink like a Christmas tree.
Everything about what I wrote does not have a 100% understanding on my part. But this is a great starting point for beginners.
I hope this article will help someone.