-
Hi, I use a custom portable environment based on Eclipse, ARM-GCC and OpenOCD. As it is portable, I can move it from one computer to other.
I also use MBED as it is very easy to use although the cloud compiler lacks debug capabilities.
For ST32 MCUs, a 32k code limit is nonsense. That's why I created my own environment instead of using Atollic some time ago.
Now, Atollic has no code limit so it will be much more interesting.
On a side note, a 32 bit application can strongly benefit from a RTOS. It is included in MBED, but you can also use one free RTOS. In my case I use chibiOS/RT (open source license):
http://www.chibios.org/dokuwiki/doku.php
As a bonus they provide ChibiStudio: a complete toolchain for the supported MCUs that include most ST32 ones. I don't use it because I was not available, years ago, when I started with ST32.
-
Both ST and NXP/Freescale are pretty good to start with. The one thing that ST was lacking years a go was a nice free non stripped down IDE. Freescale had them beat in that regard (and not too mention that the API was much better than ST's). The IDE from Freescale was bug not free, but it still was better than what ST had to offer. However, ST bought Atollic and now this is not an issue (previously, you could get Atollic, but you had no debugger).
I don't understand this. I used Atollic a long time ago before they crippled it with code size limit, (Now it is no code limit again although too late for me) and it always had debugging capabilities. At least, using ST MCUs with STLink.
In fact, when I set-up my own ARM toolchain I used the Atollic debugger to communicate to GDB. Some time later they locked their debugger and I switched to OpenOCD. -
Both ST and NXP/Freescale are pretty good to start with. The one thing that ST was lacking years a go was a nice free non stripped down IDE. Freescale had them beat in that regard (and not too mention that the API was much better than ST's). The IDE from Freescale was bug not free, but it still was better than what ST had to offer. However, ST bought Atollic and now this is not an issue (previously, you could get Atollic, but you had no debugger).
I don't understand this. I used Atollic a long time ago before they crippled it with code size limit, (Now it is no code limit again although too late for me) and it always had debugging capabilities. At least, using ST MCUs with STLink.
In fact, when I set-up my own ARM toolchain I used the Atollic debugger to communicate to GDB. Some time later they locked their debugger and I switched to OpenOCD.
Hmmmm...There was some limitation on Atollic that prompted us to switch entirely to just do it on Linux. That was a few years ago, so details are a little lost. -
The free version of Atollic has always had standard debug features (program stepping, breakpoints, memory inspection, etc), but more advanced features, mainly aimed at applications using an RTOS, had only been available in the premium version prior to the ST acquisition.
-
Have not worked with it yet (intend to) but have you seen platform io?
https://platformio.org/
May not be suitable for the pro's, but looks very interesting for the hobbyists... -
Have not worked with it yet (intend to) but have you seen platform io?
https://platformio.org/
May not be suitable for the pro's, but looks very interesting for the hobbyists...
I just stopped here: https://platformio.org/pricing
Paid debugger? No thanks.
Subscription based pricing? No, and GTFO.
I know, I usually suggest a paid product (hence not relevant in this thread), but once I paid, I'm done!
-
Oops, I totally missed that...
-
I have a question. Can I program this: https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino/311156408508?epid=532038167&hash=item48725e00bc:g:onsAAOSwETJaNPe2, with Atollic True Studio?
Has someone tried? Is debugging working?
Thanks.
-
Has someone tried? Is debugging working?
It will not work. This board does not have a debugger, it will only work with Arduino IDE and its bootlaoder. -
As ataradov says, to program it you'll need an external debugger such as an ST-Link (e.g. the one in Nucleo boards) or a J-Link or a Blackmagic probe.Has someone tried? Is debugging working?
It will not work. This board does not have a debugger, it will only work with Arduino IDE and its bootlaoder.
A small correction, though: the Blue Pill does not come with the Arduino (or stmduino) bootloader, but with the default ST one.
To flash the Arduino one, or any other of your choice, you'll need an USB to serial adapter, and this ST utility, there are detailed instructions here.
Personally, I prefer to use an external debugger, either ST-Link or BMP, given the additional debugging facilities.
-
Just search "ST-Link V2" on eB** and you will find what you need to program & debug the cheap STM32 boards.
Drivers are included in Atollic TrueStudio bundle.
Michel. -
I had the same question as the OP.
Than I found out that Atollic was bought by ST just recently. I spoke to a guy from atollic about it on Embedded World. He was surprised about it as well when he suddenly became a ST empoyee. Anyway with this change TrueStudio V9 is now provided to you for free, without any limitations.
He also told me that in the future it will be merged with AC6, to give the best of these two worlds in one packet.
For me that makes TrueStudio the best free option, as it is maintained by ST themselves.
If you don't like eclipse, maybe embitz?
And it's even possible to use the Arduino IDE, but that certainly is not the best. -
I have a question. Can I program this: https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino/311156408508?epid=532038167&hash=item48725e00bc:g:onsAAOSwETJaNPe2, with Atollic True Studio?
Has someone tried? Is debugging working?
Thanks.
1) you can write and compile the code with Atollic
2) For debugging, you need st-link debugging adapter to connect the SWD pins of the uc to the computer. Official one is 21€ at digikey, chinese clones are available cheaper but at that price, there is no point of taking risks.
3) It is possible to program the f105 using the internal bootloader and usart (you need usb-ttl serial adapter), but this is for programming only and does not provide any debugging facilities (you can just print to the same usart in your code). For that, read the AN2606 and use any serial adapter to connect the required usart to your computer, set the boot0 and boot1 straps and use the st provided software or free stm32flash to program the compiled binary. -
My 2 cents:
- AC6 (Eclipse) / CubeMx
- bought this book : https://www.carminenoviello.com/mastering-stm32/ , 870 pages instead of 5k
- Nucleo board with display shield
-
My 2 cents:
- AC6 (Eclipse) / CubeMx
- bought this book : https://www.carminenoviello.com/mastering-stm32/ , 870 pages instead of 5k
- Nucleo board with display shield
I bought the book too. It's a pretty good introduction to the stm32 family. And if you're intent on putting together an eclipse based IDE yourself, it'll get you there. However, I found a number of errors, some that will leave you dead in the water 'till you resolve them.
But, now that you can get the full up, no restrictions, Atollic IDE, why bother doing it yourself? There's no reason to pull your hair out trying to put together an Eclipse based IDE on your own, Atollic's IDE is Eclipse based, easy to install, and pretty seamlessly integrated with the debugger and various other tools. I particularly like the ability to output very low overhead printf based debug output to a window using something called instrumentation trace macro cell (ITM).
Way easier to set up and get going than putting it all together yourself. -
There is a need to build one yourself. If you don't wan't to use the buggy gcc version 6.3
-
I bought the book too. It's a pretty good introduction to the stm32 family. And if you're intent on putting together an eclipse based IDE yourself, it'll get you there. However, I found a number of errors, some that will leave you dead in the water 'till you resolve them.
[/quote]
Hi,
Did you mention the errors you found somewhere on a forum? I'm interested. I've problem to make working a software interfacing a Nucleo board with a GPSDO using UART.
Thanks
Denis -
I did some development with Blackmagic Probe, 1bitsy and libopencm3. VS Code was used as the ide. The 1bitsy is a nice GCC setup for STM32F415
Sent from my iPhone using Tapatalk Pro -
Quote
Hi,
Did you mention the errors you found somewhere on a forum? I'm interested. I've problem to make working a software interfacing a Nucleo board with a GPSDO using UART.
Thanks
Denis
There were a number of issues. here's a post I made about them on the book's website/forum.:
Thank you, thank you, thank you! I've been pulling my hair out for a week now trying to get a Nucleo-F767ZI up and running on a Windows 7 machine. Almost every attempt at a compile resulted in a slew of errors. Primarily indicating that numerous variables, macros, or functions could not be resolved. This despite the fact that all the relevant .h files were where they needed to be. Confusingly, sometimes a program would actually compile successfully.
****************** Here was the problem, as you pointed out. *******************
On page 103 the toolchain path should end in
“/gcc-arm/bin” right now it ends just with “/gcc-arm” couldn’t figure out why my project wasn’t compiling for about a week.
****************************************************************************
Making this change, appending /bin, for both the compiler and the build paths fixed it! On the toolbar select, Window/Preferences/MCU then select and set, in turn, the following settings with /bin at the end:
Global ARM Toolchains Paths
Global Build Tools Path
Global OpenOCD Path
I don't know how I would have figured this out on my own. If the compiler needs to know the path down to the /bin level how does it funtion at all without this information? Attempts to compile a project should just fail completely, not partially compile. Either the compiler is found or it's not, how does it just sort of work? An incorrect path to the compiler is not something I would have guessed caused the problems outlined above.
Some observations. The latest edition of the book I have indicated that Liviu Ionescu had not implemented project templates for the STM32f7xx families. In fact, the current GNU ARM Eclipse release does have the templates. There are issues, though. Liviu Ionescu includes a file _initialize_hardware.c which runs at startup and does a lot of the required hardware initialization. Following, the instructions in the book (page 132) that has you delete 5 files and then replace them with CubeMX generated files. However, the CubeMX generated main.c file contains much of the hardware initialization that's already in the _initialize_hardware.c file. Since that file is not one of the deleted files the compiler will throw a lot of errorrs due to multiple definitions. Either delete the _initialize_hardware.c file or remove the offending initialization stuff from the CubeMX generated main.c file.
In the /openocd/scripts/target directory there are .cfg files for the processor family you're using. In my case, the required stm32f7.cfg file is there. However, the /openocd/scripts/board directory is missing the companion st_nucleo_f7.cfg file which references the stm32f7.cfg target file. You can fix it by renaming the st_nucleo_f4.cfg file to st_nucleo_f7.cfg after you edit it so that this line: source [find target/stm32f4x.cfg] reads source [find target/stm32f7x.cfg].
HAL: Before getting this all fixed, I spent a lot of time tracking down various declarations back to their origins, trying to find out why stuff was not being resolved. I came to realize HAL is a labyrinthian maze of indirection! Some of this stuff is five or more levels deep just to find out the value is 0 or 1. I can't imagine ever getting a gut level feel for the processor if I make extensive use of HAL. I can see using it for initialization of a lot of stuff, but I'd really like a lower level interface to the hardware.
-
I have a question. Can I program this: https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino/311156408508?epid=532038167&hash=item48725e00bc:g:onsAAOSwETJaNPe2, with Atollic True Studio?
Has someone tried? Is debugging working?
Thanks.
NUCLEO-F411RE is ~$14 at digikey and that is an st-link and an STM32F411 with arduino pinout
1) you can write and compile the code with Atollic
2) For debugging, you need st-link debugging adapter to connect the SWD pins of the uc to the computer. Official one is 21€ at digikey, chinese clones are available cheaper but at that price, there is no point of taking risks.
3) It is possible to program the f105 using the internal bootloader and usart (you need usb-ttl serial adapter), but this is for programming only and does not provide any debugging facilities (you can just print to the same usart in your code). For that, read the AN2606 and use any serial adapter to connect the required usart to your computer, set the boot0 and boot1 straps and use the st provided software or free stm32flash to program the compiled binary. -
@ GDK_ATL
Fortunatelly I installed AC6 (SW4STM32) instead of following the book's toolchain installation. So far no such problems.
Nevertheless, it is very difficult to debug a program with IOs, as debugging introduce errors and bad timings you don't have in run mode.
I also noticed plenty of errors in step mode, where the debugger jumps incorrectly to portions of code. -
@ GDK_ATL
Fortunatelly I installed AC6 (SW4STM32) instead of following the book's toolchain installation. So far no such problems.
Nevertheless, it is very difficult to debug a program with IOs, as debugging introduce errors and bad timings you don't have in run mode.
I also noticed plenty of errors in step mode, where the debugger jumps incorrectly to portions of code.
"errors" or the known side effect of trying to step through C code with optimization turned on? -
Speaking of Nucleo boards, there is a firmware update tool available from Segger that turns the onboard ST-Link into a J-Link OB. AFAIK J-Link have better GDB support if you use open source tool chains.
-
Speaking of Nucleo boards, there is a firmware update tool available from Segger that turns the onboard ST-Link into a J-Link OB. AFAIK J-Link have better GDB support if you use open source tool chains.
Isn't it supposed to have some annoying nag window that pops up every time you use the debugger, though?
-
I have never seen any nag windows so far. Maybe it is because I am using the UNIX version under macOS that lacked various windows.Speaking of Nucleo boards, there is a firmware update tool available from Segger that turns the onboard ST-Link into a J-Link OB. AFAIK J-Link have better GDB support if you use open source tool chains.
Isn't it supposed to have some annoying nag window that pops up every time you use the debugger, though?