Simplest free/cheap IDE for STM32F7 discovery board - Page 1
Forum section: electronics / general

author: bigdawg
author_rank: Regular Contributor
timestamp: September 02, 2015, 03:26:11 pm
content: Hi guys, I got the new STM32F7 (http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?icmp=pf261641_pron_pr-massmarket_jun2015&sc=stm32f7discovery-pr) board the other day and I am thinking of playing around with it, but since this is my first foray into the ST micro boards; I dont know which IDE is best/simplest to use. I went online, and found that there is system workbench for STM32 (http://www.openstm32.org/System+Workbench+for+STM32); however, its not user friendly at all, and it looks much harder to flash the firmware onto the board than the other boards I have worked with in the past like TI tiva or Arduino etc. Plus, I have looked up the forums, and it doesnt seem like many people are using it at all.I'll be glad if someone can suggest some alternatives for the IDE which have some tutorials/videos I can refer to, and hopefully get a firmware for a simple blink or PWM control of motor going.

author: newbrain
author_rank: Super Contributor
timestamp: September 03, 2015, 09:19:10 am
content: Hi all, first post here, but I have been lurking for some time.I felt I could contribute to the topic, so here I am...I have used STM32 Nucleo and Discovery boards for some of my projects, and I also have a and F7 Disco, so I went through an evaluation process similar to yours.Here are some pieces of advice, take them as personal, experience based, opinions:0- If these are your first steps in ARM/STM32 programming, you have chosen a (IMO) very good product, but a steep learning curve: the F7 Disco is a very complex board, with lots of sophisticated peripherals (both on chip and on board), and limited access to I/O pins (just the Arduino connectors). Arduino is a different world.1- Take your time to learn the platform. The amount of information available is daunting: the Reference manual for the processor is 1655 pages. You must know it by heart, including the errata (half joking, but read the MCU datasheet, and I was bitten by one of the errata).2- STM32F7 does away with the classical STD Peripheral libraries, so it's either hand written code for register access or HAL. I'd go for HAL for anything more complex than a blinky.3- Use STM32CubeMX to generate clock and peripheral initialization code. Doing it by hand is possible (and definitely a good learning exercise to be done at least once or twice), but tedious and error prone: life is too short. The generated code can be easily included in a project of your favorite IDE.Now, to the environments:0- I use both Windows and Linux, but the better IDEs are, for whatever reasons, Windows only. My STM32 coding is 99% under Windows.Free:0- Go Commando. Use you preferred editor, gcc, makefiles, openocd. You'll show how tough you are, and pull a lot of hair (the rest will grow white...). Advisable only if you have lot of time, patience and some experience, but you'll learn a lot...maybe too much.1- The free version of professional packages for ARM are, in general code size limited (32kB). With a complex board as the F7 Disco, it's easy to hit this limit when you start using on-board peripherals. I don't dislike Keil (and it's unlimited, free for STM32F0 cores!)2- The greatest part of free IDE are Eclipse based. Eclipse is a powerful piece of SW, but I find it very complex and often not so intuitive (I'm also professionally exposed to it).3- System Workbench is Eclipse based, with all the advantages and disadvantages, but it was the first (AFAIK) to explicitly support the F7 (no surprise, coming from ST itself). It's also well integrated with CubeMX. For free, I find it a reasonable choice. I did not have any great problem with flashing.4- CooCOX CoIde is a (very) pared down Eclipse IDE. Easy to use with F0-F4, some glitches and frequent crashes (at least for me). Unfortunately, no F7 support roadmap and glacial updates (at least lately). It can be coaxed to compile for F7 (just use F4, same instruction set) but no flash or debug support (IIRC), so I would not advise to use it (at the moment).5- Em::blocks (now EmBitz) is lean and liked by many. It has almost complete F7 support (still a bit buggy, check the forum). I'm not so keen on its look and feel, but it might be viable and it's worth a try.6- EmIde: last version is more than one year old, so no F7 support.7- Coming from Arduino, you might want to consider mbed, similar in many ways, different in others. Not for me, but YMMV. F7 Disco is supported.Commercial:0- Most IDE have a time trial or code size limited version. Try them!1- Professional IDEs are really out of reach for a hobby. Definitely worth it for work, mostly due to real support. If you're just "having fun" consider what you might get with the same amount of money (>2000€) in terms of test and measurement instruments...2- Crossworks: 150$ for a non-commercial license, if you intend to ever sell your code/product it's a steep 1500$ for a commercial one! No explicit F7 Disco board support package, but F7 is supported (though not 746). Worth trying, but the fixed editor keybindings (I have got Emacs finger-bindings) and lack of editor automation are a sad omission.3- Visual Studio+Visualgdb. 74€+taxes for the embedded version. Full F7 Disco support, regular updates to GCC and other tools (openocd), 30-day trial. The product works very well, gives you either "do it for me" or detailed control on the build process and includes all libraries and board support packages (not only ST), very good debug support. This is very much a question of taste: Visual Studio Community Edition 2015 is free (and not crippled in any significant way) and it's a very complete, stable and well supported IDE. It comes from Microsoft, though, and this can turn away someone.What do I use?For some time, I have been using System Workbench (it works!) and trying all of the above environments. I recently bit the bullet and bought Visualgdb. I do not regret the money spent.Links:Keil:https://www.keil.com/arm/demo/eval/arm.htm,http://www2.keil.com/stmicroelectronics-stm32/mdkCoIde:http://coocox.org/Em::blocks:http://www.emblocks.org/web/Crossworks:http://www.rowley.co.uk/arm/index.htmVisualgdb:http://visualgdb.com/mbed:https://www.mbed.org/Hope this helps!

author: bigdawg
author_rank: Regular Contributor
timestamp: September 03, 2015, 05:13:30 pm
content: Quote from: newbrain on September 03, 2015, 09:19:10 amThanks a lot for such a detailed reply. I came extremely close to thinking that maybe this board is so new that none of the experienced people havnt had a chance to play with it much and hence no reply here.Quoteyou are absolutely right; this board has so many peripherals, but that makes it a lot complex for novices like me.QuoteI have looked at that reference manual, and its longer and more detailed than for any other MCU I have ever worked with. I have started to look through the HAL library manual (http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00189702.pdf) just so thatI can select a digital pin and write a blinkly program for it. even something as simple as that is complex since the actual pin numbers on the arduino connector are not the same (GPIO) numbers in the HAL library.I am too inexperienced to even begin to write a code "by hand" so I'll have to rely on the library for now. In this regard I feel like NXP, TI boards have a less steep learning curve than this one; but than again, this one is probably more high performance than any of those cortex M3/M4 ones.Quotenot even an optionI cannot even begin to imagine how I am supposed to do all of that so I'll stick with more "low key" options!QuoteI have installed system workbench already so maybe I'll give it another look since you seem to use it without problems. I see very polarised reviews for mbed; some people seem to love it whereas other folks say its worse than leprosy. would you say that it has a lesser of a learning curve? and can I still use those HAL libraries with mbed?QuoteI'll check visualgbd too, I didnt even know anything about it but after your reply I'll definately check it out.BTW, as a side question, are there any tutorials/books etc available to get people started on STM32 boards/processors? I came across this book:http://www.cs.indiana.edu/~geobrown/book.pdfbut unfortunately it seems like those libraries have changed.Is it just me or do people work professionally in embedded technologies think too that other companies like TI, NXP, atmel etc have way more support/dumb things down enough for a beginner to start using their stuff much easily than STM? anyways, I have this board and I really like its features so I guess I might as well stop complaining and start learning

author: newbrain
author_rank: Super Contributor
timestamp: September 03, 2015, 08:55:29 pm
content: Some additional considerations:- I would not like to give the impression that I'm and expert in the embedded field. I work with SW (a lot) and HW (seldom), but there are real professionals in this forum.- That said, I've been playing with micros for almost 40 years now (designed and built my own 6502 board in '77, and wrote its monitor) ...so I do have some experience (and yes, you can get off my lawn).- I've checked again Crossworks after answering, and it's much better than I remembered. Definitely worth a try, if the cost and license do not bother you. I still prefer VS+vgdb, though.- I might have forgotten other options and possibilities, let's hope someone else chimes in. The MCU and the board are still fairly new, so things are changing day by day.- HAL and mbed. Long story short, mbed like Arduino platform has its uses. It's easy to move the first steps, and there's a community behind it (less than with Arduino). I'm left wanting for more with both (even forgetting about their poor excuses for an IDE...). mbed is multi-vendor (good) but online only (bad). HALisused by mbed STM32 target, see e.g.serial_api.c, albeit I fear that trying to use both at the same time would not be a good idea. Also, the openness of mbed is a bit under discussion (not that Arduino is free of problems...).- I have no experience with TI's or NXP's platforms. Some time ago I was given a free F429 Discovery at a demo event, and with Nucleos 10$ a pop, I got addicted...a nice pusher job, was that. Now I crave the heavy stuff (F7...).- Simpler libraries based upon HAL exist, ST provides BSPs for all of the Eval/Nucleo/Disco boards, with loads of example code for all the peripherals. Alternatively, you could check something like this:http://stm32f4-discovery.com/- I can't help you with books. Ilikereading datasheets and programmer's references...now, don't look at me like that!- If you're not doing this for work (but even then...), find the way that gives you the most fun. These days we have so many free or cheap options for both SW and HW, that is not difficult to find something for one's tastes. Internet religion wars (Microsoft/Linux/Apple, mbed/HAL/bare metal etc.) are a waste of time and energy. Use what you feel comfortable with, and change with no regrets.- Yes, that board is really sweet (but for the very few I/Os)!

author: Bassman59
author_rank: Super Contributor
timestamp: September 03, 2015, 09:14:49 pm
content: Quote from: bigdawg on September 02, 2015, 03:26:11 pmTry using Eclipse with theGNU ARM Eclipseplug-in. It includes some skeleton projects for the ST parts.I ditched Atmel Studio 6 in favor of it for the SAM3U design I'm doing.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 04, 2015, 01:16:44 pm
content: Quote from: newbrain on September 03, 2015, 08:55:29 pmthanks for a brief overview of mbed; I'll read up on it.- I have no experience with TI's or NXP's platforms. Some time ago I was given a free F429 Discovery at a demo event, and with Nucleos 10$ a pop, I got addicted...a nice pusher job, was that. Now I crave the heavy stuff (F7...).QuoteI guess I'll have to start reading those too. In all honesty though; you are right, short term one can get away with not reading much from those references; but long term its a better idea to start reading them especially if I am going to stick by the m7 platform (which I am).QuoteOh yeah I am not at all doing it for work! I am a chemist by profession, and electronics is just a fall/winter hobby which keeps me busy over the weekends when I am too lazy to go outdoors and hunt/fishI really appreciate all your help.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 04, 2015, 01:17:54 pm
content: Quote from: Bassman59 on September 03, 2015, 09:14:49 pmI'll check that out bassman, thanks for the suggestion!

author: Brutte
author_rank: Frequent Contributor
timestamp: September 04, 2015, 08:47:05 pm
content: This micro (btw is F7 still a micro?) is too complicated to start with. You can blink it but won't understand why it blinks or why it does not when it was supposed to blink. I'd suggest picking something you are able to RTFRM.Quote+1.Some things that are worth adding: It is "Eclipse CDT" and not (raw) Eclipse and you would have to install this and other goodies as Eclipse is just a general purpose IDE (I have started php recently, by the way).First thing you should do is to install GCC for x86 and do some "Hello Eclipse\n". When you get familiar with all the perspectives, views, options and debugging configurations then it is time to go with micros. Not the other way. IMHO.

author: MT
author_rank: Super Contributor
timestamp: September 07, 2015, 11:22:15 pm
content: Quote from: newbrain on September 03, 2015, 09:19:10 amThe F429 reference manual is 1728 pages........and yet you have to wade trough the programmers manual of 245 pages just to turn on systick registers! The whole STM scenario is just hilarious!

author: Bassman59
author_rank: Super Contributor
timestamp: September 08, 2015, 04:31:57 am
content: Quote from: Brutte on September 04, 2015, 08:47:05 pmThat is true, although the guy who did that plug-in wrote a very comprehensive set of installation instructions, so the CDT is installed as are the ARM "packs" which are some kind of magic.

author: newbrain
author_rank: Super Contributor
timestamp: September 08, 2015, 07:19:05 am
content: Quote from: MT on September 07, 2015, 11:22:15 pmRejoice!There's no Programmer's Manual for the F7, as yet, at least.But the core is F4 compatible, bar the bit-banding IIRC, so your 429 knowledge doesn't go to waste...I don't know if other platforms are simpler, I did not find any overwhelming problem with STM32Fx, and actually started with a 429 (but I find the ATmega documentation less readable and understandable, as an example).Quote from: Bassman59How could I forget this one?Still, it does not seem to include F7 support (at the moment at least), no mention of it on the site, in paticular the bundled openocd is 0.9.0 from may, which did not include the patches for F7 flashing. But, I might try it to see how it goes...Quote from: BrutteYes, and no. The blink example, using the HAL is remarkably consistent across all the Fx cores.So I agree that you might not understand everything that's going on at first (e.g. clock chains, power settings etc.) but the GPIO is similar to all the others I have seen, starting from the 6522: it's even easy to drive directly register-wise. Starting without the HAL? No way!As said, I'm not acquainted with other 32bit (ARM) platforms, only several 8bit ones.Then, one can work their way up, start using e.g. an UART (the on-board ST-Link provide a handy USB-UART bridge), simple timers then PWM, interrupts, DMA and so on. A long journey, no doubts about it!It does not work any differently because there's a truckload of peripherals on the board, but for the fact one is mostly limited to the Arduino connectors as free I/Os.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:15:15 pm
content: Quote from: MT on September 07, 2015, 11:22:15 pmlol we had a long (3 day) weekend here, and I was goong through the reference manual thinking someone at STM could have made this thing a bit simpler. I mean I have worked on a LPC board before with 800 page manual, but this thing is just a beast.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:19:36 pm
content: Quote from: Brutte on September 04, 2015, 08:47:05 pmBrute, I have worked with other ARM boards like NXP's LPC 1769 and TI boards so this isnt completely new to me although this is my first STM board. I just feel like if I compare STM to other companies, than ST has probably the best bang for the buck, hardware price wise, although they really are bad when providing a IDE or documentation for running a simple blinky. And for whatever reason, they dont have std peripheral library on this board (only HAL) so they complicated it even more.

author: bigdawg
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:23:47 pm
content: Quote from: newbrain on September 03, 2015, 09:19:10 amNewbrain, I was finally able to run the blinky using HAL libraries and using the system workbench as IDE. I got a few errors while trying to compile the program and flashing it (I think it was GCC not found), but apparently the firmware flashed just fine if I disregarded those messages and went to subsequent steps.Thanks for all the help! I'll attach some screenshots here once I get home today so other people in future know which errors you can safely ignore

author: Gabri74
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:48:52 pm
content: Quote from: newbrain on September 03, 2015, 09:19:10 amFor your information, Keil uVision works well under Linux on Wine with this limitations/bugs:- debugger/programmer does not work because it needs specific Win$ dlls and there's no generic gdb-server target- there's some kind of UI polling on the main page, so if you are doing nothing, CPU usage is quite high. But if you leave a dialogopened (e.g. the file or about dialog) CPU usage drops to 0%- if you have a valid Win$ license, it will work in Linux too- Version 4.74 works flawlessly, but version 5.x has some problem downloading and installing MCU packagesI've also created a couple of entries in the tools menu to launch a Vim window for editing and to create sim-links under/tmp/ for the build targets to be used by OpenOCD

author: newbrain
author_rank: Super Contributor
timestamp: September 09, 2015, 08:24:18 am
content: Quote from: bigdawgBravo! Glad to hear you managed it. I've some doubt it did not find GCC, if you got it compiled!Quote from: Gabri74 on September 08, 2015, 04:48:52 pmThis is very interesting information, though I'm not going to try it, having both OSes natively or virtually available (too many computers, and MCUs, too little time...), and given the problems with debugging. It is, however, incredible how far Wine has come.PS: I think you meant Keil$ rather than Win$ (si fa per scherzare...).

author: bigdawg
author_rank: Regular Contributor
timestamp: September 09, 2015, 02:39:51 pm
content: Quote from: newbrain on September 09, 2015, 08:24:18 amI am attaching a couple of error pages which popped up; I disregarded them and the program compliled and flashed correctly. This may just be a bug in the IDE or I did something. either way, it works

author: ale500
author_rank: Frequent Contributor
timestamp: September 09, 2015, 04:08:39 pm
content: In the Project's preferences page -> C/C++ Build -> Environment you can add the path to the arm-eabi-none-xx executables.

author: EmBlocks
author_rank: Contributor
timestamp: September 10, 2015, 02:07:37 pm
content: Quote from: newbrain on September 03, 2015, 09:19:10 amI'm not aware that there are still bugs in the F7 implementation.Side note:EmBlocks/EmBitz is the only free IDE which is supporting live variables (watch variables on running target). Keep your mouse still on a global variable and you will get a tooltip with a 250mS update of the variable/expression. Also the watches and memory viewing window is supporting live updates.

author: newbrain
author_rank: Super Contributor
timestamp: September 10, 2015, 08:02:56 pm
content: Quote from: EmBlocks on September 10, 2015, 02:07:37 pmThanks for the update, and sorry to have spread incorrect info, I appreciate the correction! That was when I last checked, admittedly, some time ago, when I first received the Disco board.To my partial excuse, I at least advised to check the forums.And yes, live variables are a godsend.

author: EmBlocks
author_rank: Contributor
timestamp: September 11, 2015, 08:40:24 am
content: It was not really intended as a correction, but maybe there were still bugs that I did not know.

author: janoc
author_rank: Super Contributor
timestamp: September 11, 2015, 09:23:18 am
content: Quote from: newbrain on September 03, 2015, 08:55:29 pmI have investigated mBed recently for a project I was doing with the STM32F0/F3 parts, but I have found it quite lacking. Youcan haveoffline compilation now (there is an option to export your project and you load it into your IDE locally), but the major issue I have found is the lacking support for the more advanced things, such as the functions of the timer peripherals on STM32s. They support some basic stuff, but anything more advanced and you are on your own. In that case I found it simpler to just ignore the entire mBed and write my own code for everything.For the larger chips you may want to consider some alternatives to the standard peripheral libraries and HAL from ST - e.g. a full RTOS like ChibiOS or libopencm3. RTOS is an enormous advantage if you are planning to use things such as USB, because it comes with a full USB stack and pre-made things like serial over USB ready to go. Just make sure to check the licenses - they will likely be okay for a hobby project, but for something you want to sell it may not be appropriate (or you may need a commercial license).Re IDEs:IDEs are often a matter of taste, so what follows may not apply to everyone because you likely don't have the same needs and background as I do (20 years of sw engineering). So things like having to edit a makefile or using gdb from the command line are not an issue for me. I am also doing mostly hobby/small scale stuff - if you are building smartphones or phone system switches, your experience will likely differ. But perhaps it helps someone.Personally I have found the proprietary toolchains and IDEs to be a waste of time for me. They are almost always a crippled combination of the (otherwise free) gcc and something like Eclipse, NetBeans or IntelliJ (which are also otherwise free). The only advantage are the bundled examples and code/project wizards which could save you some time when you are starting a new project from scratch.I have found it more useful to spend a bit of time and build my own template projects for common things using standard tools - cmake, make, gcc and learn how to debug code using gdb and OpenOCD (+ frontends like Eclipse). In this way I can develop embedded code in the same way as any other stuff I would for a PC, using the same tools. Thanks to cmake I am not locked in to a particular IDE and toolchain, the same project can be compiled and debugged using Eclipse, Visual Studio and e.g. emacs if I wish and it is trivial to automate many things in a very clean way directly from the build. I am using this for both my ARM and AVR projects. The only case where I am relying on a vendor IDE is anything to do with PICs because I don't have a choice due to their proprietary tooling.Considering platforms - if you aren't using one of the commercial IDEs and are going to go the free gcc + free IDE (e.g. Eclipse) route, I strongly suggest you consider Linux for development, even if it is only on a virtual machine. It ismuch muchsimpler to build your own up to date version of gcc (e.g. because you want to use that fancy new chip that had support added in the last gcc version), openocd (for JTAG/SWD debugging) and many of the support libraries in Linux than in Windows. Most of those tools come from Unix and have Unix-style build systems - i.e. makefiles and such. There are also many dependencies, these usually are readily available for Linux but for Windows you have to jump through many hoops. That can be an enormous pain to make work, having to muck with stuff like MinGW or Cygwin. Then there is also the issue of drivers - Linux makes it easy to talk to all kinds of homegrown hardware, whether over USB or other connections. With Windows you are going to deal with the need to install drivers/prepare .inf files constantly, even if it is for a silly thing like serial over USB. Not to mention that newer Windows versions require that the drivers are signed by Microsoft.BTW, if you have to be on Windows, there is the "ChibiStudio" (http://chibios.org/dokuwiki/doku.php?id=chibios:product:chibistudio:start). It is Eclipse preloaded with the ARM-specific plugins, the CDT plugin and bundled with all the other tools you may need to develop with ChibiOS on Windows (gcc, openocd, etc.), so everything works out of the box.

author: EmBlocks
author_rank: Contributor
timestamp: September 14, 2015, 10:38:04 am
content: Quote from: janoc on September 11, 2015, 09:23:18 amI don't think that this is a matter of how long you are working in this business but, as you already mentioned, a matter of taste and what kind of person you are.I'm now busy for more than 30 years in the SW/HW engineering. I started with only CLI systems (CP/M etc) and used a lot of Unix command tools when I was working in an ASIC development department. Because I'm more visually than linguistic (I always make drawings to explain problems to others and even to myself) it was a big relief when the GUI tools made their entrance. I never did get a wet pants by knowing the most complex piped command line instructions or scripts, like in the early days when there where competitions among colleagues.But, I don't like the tendency tools are getting bigger but not correspondingly have more features. The first windows 3.1 Keil tools fitted on a couple of 3.5" floppies, now you need a i7 and a lot of memory to keep Eclipse and all those other Java based tools happy.

author: janoc
author_rank: Super Contributor
timestamp: September 15, 2015, 09:38:40 am
content: Quote from: EmBlocks on September 14, 2015, 10:38:04 amMy point was not to start a debate on whether or not to use a GUI/IDE or command line tool for something.It is about finding the right tool for the job and perhaps exposing few tools that aren't that well known or the first thing coming to mind when starting a project.Unfortunately, I know many engineers who won't touch a tool because it isn't Visual Studio or they would have to actually configure the build themselves using a file (think Makefile, CMake, etc.) instead of using the retarded "click a mouse to set hundreds of options" project system many of these IDEs have to manage compilation. Ever tried hunting down an incorrectly set switch in a larger/complicated build? Or having to add/modify settings for multiple projects/configurations at once? The result is a very error prone and carpal tunel inducing click-fest. And good luck if you are multiple people collaborating on a project and sharing the build files using a version control system - it becomes a merging nightmare extremely quickly, especially if the IDE uses binary files for the projects.All this is unfortunate, because there are plenty of good tools around that are either free or inexpensive and often better at the task than the big bucks commercial ones. It only takes open mind and willingness to invest a bit of time to learn them.

author: Brutte
author_rank: Frequent Contributor
timestamp: September 15, 2015, 11:02:11 am
content: QuoteThe indisputable advantage of GCC is that once you learn toolchain for one architecture then it is (mostly) the same when building for other.. Typically Ctrl+C/V does the job. Be it x86, PPC, AVR8, MIPS, ARM etc. Not only source code but whole ecosystem (make, ld, IDEs, gdb, nm).Of course I do not want to discourage proprietary IAR, Keil or Microsoft products here (I have never used those). I am sure the products and support is of first class but once there is a need to skip from one architecture to the other (which is not uncommon with embedded) then the whole learning curve starts from ground zero. Be aware of that before making the choice.

author: mark03
author_rank: Frequent Contributor
timestamp: September 17, 2015, 03:58:07 pm
content: For anyone going the gcc/gdb/makefile route on STM32, I want to give a shout-out to the Black Magic debug probe (http://www.blacksphere.co.nz/main/blackmagic) as an alternative to OpenOCD or STLink. It cleverly emulates the GDB remote debugging protocol so you can program flash, step through your application, etc. much the same as if you were debugging code on your PC. The firmware is an open-source project, and it looks like they have just added support for STM32F7. The author funds development by selling ready-to-go boards, but if you are a starving student you can also twiddle some solder-bridge jumpers on a Discovery board and use another STM32 programmer to install the Black Magic firmware in place of the as-shipped STLink.

author: janoc
author_rank: Super Contributor
timestamp: September 17, 2015, 09:38:04 pm
content: I was looking at Black Magic, but what is exactly the advantage over a generic JTAG/SWD dongle or STLink?I wasn't able to find that from the description on the website - from a quick look over the capabilities, that is pretty much all the same as what OpenOCD and a JTAG/SWD dongle can do

author: MT
author_rank: Super Contributor
timestamp: September 17, 2015, 10:13:14 pm
content: ST link is for ST devices

author: EmBlocks
author_rank: Contributor
timestamp: September 18, 2015, 06:01:12 am
content: Quote from: mark03 on September 17, 2015, 03:58:07 pmOpenOCD and STlink from texane are GDB stubs (GDB server) which are using a separate hardware dongle. These applications are sitting in the middle between GDB and the Jtag probe:GDB -> GDB server (GDB remote protocol) -> Jtag hardware (proprietary protocol)Blackmagic has integrated the GDB stub inside the probe so you communicate directly with it from GDB with the GDB remote protocol:GDB -> Blackmagic (GDB remote protocol)I prefer the first setup because you can extend GDB with nice features between GDB and the stub because of the fast communication (often through localhost) while the second one is more basic. I once looked at it when I was asked if EB could support this probe. I skipped it because it uses special way of communication setup which EB didn't support and because it was hard to implement the live variable feature (peeking at variables on running target) in this probe.

author: janoc
author_rank: Super Contributor
timestamp: September 18, 2015, 09:53:48 am
content: Quote from: EmBlocks on September 18, 2015, 06:01:12 amWhat does that mean? You tell gdb to open the USB device directly somehow? Or is there some driver in-between anyway? (like OpenOCD driving an FTDI dongle).

author: bigdawg
author_rank: Regular Contributor
timestamp: September 18, 2015, 01:09:16 pm
content: Quote from: MT on September 17, 2015, 10:13:14 pmThats what I am using and have not run into any issues with it so far. It would be interesting to know hear about any specific advantages of using black magic.

author: mark03
author_rank: Frequent Contributor
timestamp: September 18, 2015, 03:35:55 pm
content: Quote from: janoc on September 18, 2015, 09:53:48 amWhen you plug it in it enumerates as a CDC serial port, which plain old GDB can talk to using its remote debugging protocol, defined eons ago.I am not sure there is any advantage over OpenOCD. I just like the elegance, and having not installed OpenOCD before, that looked a bit messy and I was glad to avoid it. At the time, SWD support was also pretty new in OpenOCD; I think it is more mature now?

author: janoc
author_rank: Super Contributor
timestamp: September 18, 2015, 08:35:49 pm
content: Quote from: mark03 on September 18, 2015, 03:35:55 pmAha, I see. Makes sense.Quote from: mark03 on September 18, 2015, 03:35:55 pmOpenOCD is not hard to install, there are even pre-built versions for Windows and Linux around. Or just download one of the many free IDEs - they universally ship with OpenOCD preconfigured.SWD works just fine today, I am using it with STM32 micros. If your dongle supports it (some cheap FTDI-based ones don't because of the I/O buffer configuration - SWD needs bidirectional signalling) and is supported by OpenOCD, then no problem. It works the same as JTAG as far as debugging is concerned.

author: MarkM
author_rank: Regular Contributor
timestamp: September 22, 2015, 03:41:33 pm
content: I'm going to have to check out Eclipse with the ARM plugin, thanks! I read somewhere about using a high cost IDE that has a 32k limit and using a separate compiler. What do you think?

author: janoc
author_rank: Super Contributor
timestamp: September 22, 2015, 07:51:54 pm
content: Quote from: MarkM on September 22, 2015, 03:41:33 pmNo idea. Most of those proprietary IDEs are derived from Eclipse/Netbeans/Idea anyway, so if you get used to normal Eclipse, you should not have big problems switching, if required.

author: futaris
author_rank: Newbie
timestamp: September 24, 2015, 03:11:39 am
content: I use eclipse and gnu arm embedded on my STM32F1xx and STM32L1xx.Once you have a bare project for whatever processor, you should be fine.That being said, there is uClinux for the STM32F7 discovery board, if you want a full featured OS, rather than bare metal:https://www.emcraft.com/stm32f7-discovery-boardhttps://github.com/EmcraftSystems

author: MarkM
author_rank: Regular Contributor
timestamp: September 26, 2015, 07:20:53 am
content: I ended up setting up Eclipse with GNU ARM for STM32 goodies. Pretty sweet! I also got the Arduino IDE 1.6.5r5 running with it. I have multiple maple mini clone boards working in both Eclipse with the ST-Link V2 programmer and USB with the Arduino IDE. Not sure if it was just me or not, but it took me awhile to get Eclipse working with everything like it was supposed to. :/ I've never been so happy to see an LED blink.

author: janoc
author_rank: Super Contributor
timestamp: September 26, 2015, 11:23:03 am
content: Yeah, Eclipse can be daunting if you have never used it before. But I guess that's the same for any major IDE. The good news is that once you have things set up, you won't need to touch it for a long time.

author: Rolo
author_rank: Regular Contributor
timestamp: September 26, 2015, 01:16:02 pm
content: Quote from: MarkM on September 26, 2015, 07:20:53 amDid you follow a "how to" ? I would like to make the same step but I'm dazzled by all the info there is. Can you give more details on how you did this ?I have a ST-Link V2 programmer and some Maple Mini clone boards I'm programming in mbed right now. Would like to step up to having a local installed IDE and tools.Thanks !

author: gmb42
author_rank: Frequent Contributor
timestamp: September 26, 2015, 05:11:47 pm
content: Plenty of examples just a Google away, e.g.MCU on EclipseorChibiStudiothat's a one stop solution or even the mbedpagefor offline tools

author: MarkM
author_rank: Regular Contributor
timestamp: September 26, 2015, 07:49:37 pm
content: Here's a link to the GNU ARM Eclipse plugins. Just start with the overview in the links and read everything. It ended up taking me like 2.5 hours to just get it to work, but I was having other issues with the laptop. They also have a bunch of IDE settings they recommend as well.http://gnuarmeclipse.github.io/It looks really cool so far, but I haven't had the chance to get into it anymore. Good luck!

author: cncjerry
author_rank: Unknown
timestamp: September 30, 2015, 03:15:18 pm
content: Eclipse with ARM on mac. I fought thru all this, and yes, those boards are complicated as all get-out. The learning curve is as steep as you can imagine, pretty much vertical, but it is short if you have experience with other STM micros. Having Arduino experience won't help much. The debugger doesn't work well, be prepared to exit Eclipse often and restart.Once you get the eclipse+arm going, go here:http://stm32f4-discovery.com/and read thru his code. Lots of simple examples and it all works. Plus he has a ton of experience with the F4 boards and answers his board and emails very quickly. He's been a big help. I gave up on the F4 board three times at least before finding his site.By the way, the F7 is a kick ass board but I doubt it is worth the effort over the F4 right now. I've found the I/O to be slow on these boards, specifically any TFT, LCD, etc display, so the extra horsepower is wasted on apps with UI.