stm32cubeIDE and C++ - Page 1
Forum section: electronics / general

author: LootMaster
author_rank: Regular Contributor
timestamp: October 12, 2020, 07:46:39 am
content: So me and my buddy are about to embark on a programming journey.And we were debating if we should go C or C++, and it was decided C++ was better for this powerful H7 platform.Anyways, what are the things to watch out for and not do in memory limited systems?A sort of embedded C++ guidelines that many companies operate with after learning the hard way the pitfalls of C++.Thx.No long ranting videos please.

author: MosherIV
author_rank: Super Contributor
timestamp: October 12, 2020, 07:53:26 am
content: Aoid the STL in C++Make sure rtti is turned off.Do not use C++ exceptions.Do not go over board with too many objects objects, especially if they have lots of variables in them.

author: rstofer
author_rank: Super Contributor
timestamp: October 12, 2020, 02:48:03 pm
content: What specific features of C++ does your project require? Why can't those needs be met by C?Have you noticed that most low level programming, like the Linux and Windows OSes, are written in C? There's a reason for that.I'm not going to rant against C++ for embedded programming on systems with limited resources but I would personally limit its use to application programs, not systems level programs. I don't want to see malloc() in the binary regardless of the dialect. Dynamic memory allocation seems like a bad idea on a system with limited resources.The C language was developed in 1973 to write Unix Version 4. Not much has changed!

author: LootMaster
author_rank: Regular Contributor
timestamp: October 12, 2020, 04:02:13 pm
content: What about virtual functions.I had link I lost with a well organized list/bulletin point.Of what not to do with C++ in typical low memory systems. 1-2Mb

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: October 12, 2020, 04:23:58 pm
content: Here we go again:STL is fine if you fully understand it. Std::array is safer than c arrays. STD:: vector uses the heap so it's bad for most peopleVirtual functions are fine, quite a low cost and help abstraction a lotReferences are extremely useful.STD::: algorithm is another great toolTemplates are hard to debug and that's true of header only libraries in general. But they can save a lot of development timeRAII is a lifesaver. Use it where you can...I would just like to say, I'm a C programmer and a C++ developer. Most criticisms of c++ are from the perspective of pre c++11 knowledge. The language is a tool, you really have to know what you're doing. But C++11/14/17/20 will save you time in the debugger in my experience.Oh sometimes you have to use dynamic memory [ TCP/IP stacks for example] and C is perhaps the worst language for it hands down. Don't get me started on type safety in C

author: Kjelt
author_rank: Super Contributor
timestamp: October 12, 2020, 08:52:42 pm
content: Quote from: JOEBOBSICLE on October 12, 2020, 04:23:58 pmNo you can always work without dynamic memory allocation and in a small embedded device I would opt to do so and allocate a block of static memory per module and do your own bookkeeping. Thats the way you can have 24/7 365 day systems running for decades without memory leaks.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: October 13, 2020, 07:38:40 am
content: Allocating from a pool of memory or from the heap has exactly the same problems associated with it. Memory must actively be freed.Don't kid yourself, they all achieve the same thing and have the same problems

author: Jeroen3
author_rank: Super Contributor
timestamp: October 13, 2020, 08:07:11 am
content: Quote from: JOEBOBSICLE on October 12, 2020, 04:23:58 pmThis. it has been discussed before many times.Basically boils down to this: Those who don't know fear C++ for embedded.I definitely would want to be using something properly scalable and testable on a H7 applications processor.https://www.eevblog.com/forum/microcontrollers/c-vs-cpp-for-stm32/https://www.eevblog.com/forum/beginners/what-is-the-most-relevant-programming-language-for-ee/

author: newbrain
author_rank: Super Contributor
timestamp: October 13, 2020, 08:34:39 am
content: A sample point for usingmodernC++ on small systems.TLDW: pong game, written in C++14/17, compiled to x86 32bit, and translated to 6502 amounts to about 1 kB final binary.

author: Kjelt
author_rank: Super Contributor
timestamp: October 13, 2020, 09:12:30 am
content: Quote from: JOEBOBSICLE on October 13, 2020, 07:38:40 amIf you have enough memory you do not have to free anything. You only need dynamic allocated memory when you have less memory available than needed in your project and then you can ask yourself if that is a wise decision and who is going to make sure that not all the modules are allocating their too large share of memory at the same time. Or what should a module do when its allocation of memory is not granted and the other side is not going to wait ? Data gets lost then.This dynamic mallocing is for very large embedded products tens of MBs of RAM or more, yep go ahead have fun.But in systems with < +/- 1MB or RAM , this is next to not using an RMA analysis, one of the most made mistakes in small embedded design and most made by next generation GUI SW engineers that are not used to counting the bytes they use.So my statement is that for reliable small 24/7 embedded product you statically allocate memory per module at the start and that module is responsible for maintaining that memory.QuoteNo problems in the teams I worked in and that used this approach, even IP stacks. Some heavy discussions but after failing some of my rainy day testscenario's they always saw the point in the end.

author: Kjelt
author_rank: Super Contributor
timestamp: October 13, 2020, 09:15:24 am
content: Quote from: Jeroen3 on October 13, 2020, 08:07:11 amI agree that now in 2020 C++ can surely be used in emb. development and is used at many places.But the opposite statement is also true with the new generation of SW engineers.Those who only know C++, fear C for embedded.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: October 13, 2020, 09:49:45 am
content: Quote from: Kjelt on October 13, 2020, 09:12:30 amWhy would you allocate from a heap in the first place, why not use statically allocated buffers? Limitations of your TCP/IP stack?If you're never relying on memory being freed then of course you'll have no problems. But a lot of devices really need to use dynamic memory due to variable sized packets coming in.I can only speak of a few TCP IP stacks I've used, you normally pass around a heap allocated buffer through the stack until it reaches your application where it needs to be free'd after using. There's really a lot of danger in this for no reason but C language limitations

author: Kjelt
author_rank: Super Contributor
timestamp: October 13, 2020, 02:50:23 pm
content: Quote from: JOEBOBSICLE on October 13, 2020, 09:49:45 amI never said I allocate from the heap, i just declare them in the module statically ofcourse.QuoteNo, because you must obey or set an maximum transmission unit (MTU) anyway to set a limit to incoming data.If you want to support jumbo frames you also have to set a limit. Just allocate memory for how many packets you are able to support.If you do not then I can disable your device with a single call.QuoteC++ can't fix this even languages with garbage collectors are vulnerable because there is no hard deadline when the garbage should be disposed of (one of the nice vulnerabilities hackers like to take advantage of, nice (parts of) passwords to be found in the garbage.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: October 13, 2020, 03:20:35 pm
content: Quote from: Kjelt on October 13, 2020, 02:50:23 pmOkay what you're doing is just normal static allocation.TCP/IP stacks always do dynamic memory allocation from a pool. Yes that's pool is fixed size but if you don't free that packet buffer then you're in trouble. What TCP/IP stack are you using that doesn't do this?C++ does fix it, and the same with rust. It's called destructors, when a smart pointer is used it will free the memory once the variable goes out of scope. This feature alone can get rid of a huge amount of bugs

author: Kjelt
author_rank: Super Contributor
timestamp: October 13, 2020, 03:45:19 pm
content: Quote from: JOEBOBSICLE on October 13, 2020, 03:20:35 pmModified IP stacks from LWIP and Interniche, yes standard they do this but in my previous company (even 2 companies) they did not allow dynamic memory allocation in their products. So we modified it.QuoteSo when does a variable or pointer goes out of scope ? When is it exactly freed? You don't know because you did not write the code and depend on the software supliers implementation.When you per accident did not free the memory, is there a mechanisms that frees it automagically and who decides when it is time to free it ?With static allocation you have two choices, stop when the memory is gone or what is used the most continue and overwrite the oldest (circular buffer).It all has to do with control, our product was large enough that teams have their own modules to be responsible for.If we have an issue we only overwrite our own data and not that of another teamYou as a team who supports a module has to take care of your own piece of memory, and not be the victim of another team who has a lack of memory tidiness.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: October 13, 2020, 04:06:46 pm
content: Quote from: Kjelt on October 13, 2020, 03:45:19 pmAFAIK there isn't any modern c++ TCP/IP stacks but if one was written and smart pointers were used then it'd be a lot safer than what we have right now.The definition of when a variable goes out of scope is well defined. And memory is freed when a smart pointer goes out of scope. That's exactly the point of them. They're simple and easy.And yeah unless you use the wrong type of smart pointer then you can't go wrong. Of course I strongly advocate for having enough ram to avoid dynamic memory but realistically a lot of projects will use it due to TCP/IPI think you're mistaken with what your lwip port does, are you telling me your code base doesn't use pbuf_free? I struggle to believe that. You would have had to rewrite almost every lwip module

author: asmi
author_rank: Super Contributor
timestamp: October 13, 2020, 05:12:58 pm
content: It's the same old debate - people who don't know C++ and had last seen it a decade or more ago will tell you to use C. Others who actually know and use features of modern C++ (C++11 and above) will tell you to use C++. Those who say that C++ is only good for OOP just don't know modern C++, so their opinion is best ignored.

author: Feynman
author_rank: Regular Contributor
timestamp: October 17, 2020, 01:10:37 pm
content: I'm also an advocate for C++ in embedded systems. It's not perfect for sure, but C++ adds so many useful compile-time features (no performance downsides!) that help you to develop better code more quickly. With C++ you don't have to go the excessive OO way (I guess that's what many typical C programmers are scared of). You still have the option to program more or less the same way as in C, but cherry-pick some useful compile-time features of C++.The tool chain has to support those features, of course. But unfortunately many tool chain vendors are very slow in adopting those "new" features.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 17, 2020, 04:57:39 pm
content: Ok here my is current plan, I am a big proponent of working within the confines of CubeMX, because its easy. Yeah, its a bit messy, theres a lot of stuff that is just eye pollution and confusing. I do have the book from Carmine Noviello wherehe tries to explain to meall this stuff.You already have a set structure in place and I don't know what the hell I'm doing so might as well go along with ST, so the best "work flow" for me, would be a "work flow" that you can use C++ , lightweight already made register calls(LL), and somehow in case of .ioc (Cubemx) modification, it wont take too much time to jump right back in where I left off. (Most of you know that anything that is not between those special brackets gets deleted)… Now that setup would be the best of all worlds.I like the LL and how its basically already made register drivers with names that are obvious enough to save time, I like how all the stm32h7xx_it.c file gets built and interrupts are a magical GUI thing well organized in a single spot. Etc...So from the start, absolutely anything and everythingthat can bein LL, make it LL, make a C++ project from the tick box,change main to .cpp, find some indentation or code for CubeMX not to delete code between such signs if I change .ioc ( still have not searched for this trick).For some peripherals, there is no LL library available, only HAL, USB and FMC for example, wich is ok since USB is too complicated, praise be to ST I trust them.But if Imight be able tonot trust them, I wont, I'll try. That'sifthe peripheral is not as complex as a USB application. An example would be the FMC, flexible memory controller, I use this peripheral. In a pretty precise and simple fashion, well, this peripheral has no LL option. ( I guess its pretty rare to implement a 32 bit FMC in a 240 pin H7 DUAL CORE with addresses and such). Maybe this is a candidate for a custom register call that will require some tedious 4-5 hour research in the PDF but worth it.So what ya think of this plan? Sounds smart? Use LL all the time and C++. I mean, LL can even work with DMA transfers, according to my research.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 18, 2020, 02:03:36 am
content: https://www.eevblog.com/forum/microcontrollers/c-vs-cpp-for-stm32/50/Ok it all sounded like opinionated positions exept for this man. I really laughed when I saw Otatario say C++ awesome..blah blah.. our RTOS uses sometimesASMbecause C++ cant.... ROFL … I somehow don't relate to that.mark03 ( I'll go with this guy)We are going with C++, don't try and convince me alrite, I know... Please leave me alone intense bully C++ person, I agree with you.I just want a good best practice guideline.After looking into the LL files, DMA on the H7 looks more complicated with LL than HAL. How bad can HAL be? There is only 1 family with MDMA?

author: cv007
author_rank: Frequent Contributor
timestamp: October 18, 2020, 08:22:05 pm
content: You will just have to start trying things and see how it works out, adjusting as you go (plans change). With a more complex mcu, you will most likely end up with c++ being the 'top' layer and for the most part just have to make peace with the c layers/drivers you need to use. Over time you can 'take over' a peripheral if needed.For simple peripherals like gpio, you can make your own driver (I test ideas with the online compiler, this is one of them)-https://godbolt.org/z/GjrGrfbut that is 1 peripheral in dozens, and happens to be a simple one (but without exti included). Taking over a more complex peripheral for example is another ballgame, and although can be done it can be time consuming to get it right.I would also work my way into the C++ Standard Library in small increments, getting a good idea of what is happening. You will be better off working your way from the bottom instead of pretending you have the capabilities of a pc. I don't use the library simply because I don't have it (avr), or for the arm mcu's I have I forget I have it. You do still have the same language toolbox as the library writer.C driver quiz-I was just browsing the stm32h7 drivers on gituhub to see how complicated some peripherals may be, and also to see what the difference is between a gpio LL and HAL driver as an example. See if you can spot the problems-Code:/*** @brief Toggle data value for several pin of dedicated port.* @rmtoll ODR ODy LL_GPIO_TogglePin* @param GPIOx GPIO Port* @param PinMask This parameter can be a combination of the following values:* @arg @ref LL_GPIO_PIN_0* @arg @ref LL_GPIO_PIN_1* @arg @ref LL_GPIO_PIN_2* @arg @ref LL_GPIO_PIN_3* @arg @ref LL_GPIO_PIN_4* @arg @ref LL_GPIO_PIN_5* @arg @ref LL_GPIO_PIN_6* @arg @ref LL_GPIO_PIN_7* @arg @ref LL_GPIO_PIN_8* @arg @ref LL_GPIO_PIN_9* @arg @ref LL_GPIO_PIN_10* @arg @ref LL_GPIO_PIN_11* @arg @ref LL_GPIO_PIN_12* @arg @ref LL_GPIO_PIN_13* @arg @ref LL_GPIO_PIN_14* @arg @ref LL_GPIO_PIN_15* @arg @ref LL_GPIO_PIN_ALL* @retval None*/__STATIC_INLINE void LL_GPIO_TogglePin(GPIO_TypeDef *GPIOx, uint32_t PinMask){WRITE_REG(GPIOx->ODR, READ_REG(GPIOx->ODR) ^ PinMask);}and in the hal version-Code:/*** @brief Toggles the specified GPIO pins.* @param GPIOx: Where x can be (A..K) to select the GPIO peripheral.* @param GPIO_Pin: Specifies the pins to be toggled.* @retval None*/void HAL_GPIO_TogglePin(GPIO_TypeDef *GPIOx, uint16_t GPIO_Pin){/* Check the parameters */assert_param(IS_GPIO_PIN(GPIO_Pin));if ((GPIOx->ODR & GPIO_Pin) == GPIO_Pin){GPIOx->BSRR = (uint32_t)GPIO_Pin << GPIO_NUMBER;}else{GPIOx->BSRR = GPIO_Pin;}}One would think the gpio drivers would be nailed down by now as all their mcu's are basically the same for gpio (as far as I can see).

author: cv007
author_rank: Frequent Contributor
timestamp: October 20, 2020, 09:10:00 pm
content: >C driver quiz-Not many takers.Answer- LL version is not atomic, HAL is not correct (sets/clears a group of pins based on whether the group is all high, does not toggle individual pins).Looking through the stm32 github, most mcu's do it correctly, a few do not. Not sure why they have different versions for essentially the same peripheral.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 20, 2020, 09:57:21 pm
content: At a quick glance, The typedef is the same and so is GPIO_SetOutputPin.I expect it to be the same.Don't look at the toggle... Look at the set.Led toggling is fun but goes old quick...I don't know why: I don't like it not seeing your countryflag?

author: ttt
author_rank: Regular Contributor
timestamp: October 25, 2020, 08:23:49 am
content: Maybe as an interesting side note: I use the STM32CubeIDE, Visual Studio Code and cmake/ninja at the same time to makeC++ convenient to use.Why and how?VS.Code is IMO a better environment for developing than Eclipse with all the plugins it provides nowadays.STM32CubeIDE remains useful for configuring the MCU correctly. But as you know the downside is that as you change the hardware config using the IDE (pin config, clocks etc), it rewrites all your init code. Essentially resets your project. Annoying as hell.Another problem is that continuous integration is a PITA to do with Eclipse based projects. Using CMake/ninja for that is a better choice as I can use github hooks to tell my Jenkins server to build, test and publish builds automatically on every change.So what I do is simple: I have a top level CMake/ninja project which compiles my C++ code _and_ the C code from the STM32CubeIDE project. I use that to compile and debug my C++ code from within Visual Studio Code (with CMake/C++20 support).My stm32CubeIDE project sits inside the C++ project and is only touched/opened when I need to change the hardware config. As my hardware gets mature I rarely need to touch this part.In my main() I just call into a C++ entry point.See here:VS.Code/CMake project:https://github.com/tinic/pendant2020STM32CubeIDE project:https://github.com/tinic/pendant2020/stm32I've used this approach for a couple of years now and it has made me way more productive.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 25, 2020, 09:06:34 am
content: Ridiculous...You have nointegratedSFR view in VS.code.. You can reach that point of "no more HW change" in ST's IDE as well. and proceed with C++You are going at this as if the arsenal of SFR's is something to be "dealt with later"...The optimal workflow is to have many screens (2 or 3) and one of these screens has usually the RM(reference manual).And the SFR viewregister namesis perfectly coherent with the datasheet, and vice versa.I am guessing for rudimentary things with GPIO and SPI with F1 or M0 small packages... it could work.Might as well go with one size fits all for all projects...Why go against ST's free IDE? Is this just for the sake of being different again? They paid 7 million dollars for this bullshit software and I'm gonna use it.http://blog.atollic.com/learn-how-to-use-version-control-systems-the-basics-video-tutorial

author: lucazader
author_rank: Regular Contributor
timestamp: October 25, 2020, 10:13:12 am
content: @LootMasterYou can very easily find and point vs code at an svd file to provide full sfr views while debugging with vscode.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 25, 2020, 10:34:14 am
content: Yeah and it looks like shit (no yellow,no R/W permission, no detail) not to mention so does STM32Cube IDE provide this? And both are free.Here's the result of a project on Dual core, I can change debug configs and have access to SWO without much trouble.All well organized right out of the box.Can you do this? What is that you gain that I dont already got out of the box? Speed?hmmm...well...that is a feature that is good to have once you actually made it work...edit: OK, show me the video or link that shows me how to install all the BS needed for a complete easy workflow. I'll see for myself. I installed the ST's IDE with mouse clicks.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 25, 2020, 01:31:41 pm
content: It looks like a PITA?Anyways the comment pretty much sums up my feelings...I have not seen much lag when stepping or transitioning from dev to debug. Wich is the area I am expected to gain... ? It aint THAT slow.I can have a run and debug mode... A bunch of gimmicky graphs with SWO and interrupt statistics...Basically, 100% of my needs are met...And it was a 1 click install.O yeah... I can have 2 projects open at a same time..One of these can be dual core...I mean...Yeah...You made a STM32F1 48pin send an SPI and zero DMA etc...The IDE worked for you...Now...Make the IDE work for the MOST COMPLEX SITUATION...

author: LootMaster
author_rank: Regular Contributor
timestamp: October 25, 2020, 02:18:38 pm
content: https://community.st.com/s/question/0D53W000005pvjR/stlink-on-nucleoh743zi2-to-be-converted-to-jlink-in-order-to-use-with-VScode...This trendy thing like VScode and Linux and Apple is not gonna cut it...Put that VScode to sleep ttt…It cant make work a V3 on a dual core H7...I guess its for simple appsI am a strictly STM32 guy. A strictly windows guy.For the reason above... I dont go with the Linux and non-standard (if po$$ible).Go WITH the flow.

author: Kjelt
author_rank: Super Contributor
timestamp: October 25, 2020, 03:01:05 pm
content: Quote from: LootMaster on October 25, 2020, 02:18:38 pmThat flow changes every few years.Try rebuilding the LL stm32f1 flow project from 2008Or a cube project from 2017I can understand many want a stable flow where they can rely on for the coming years.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 25, 2020, 03:08:37 pm
content: I can manage something counter flow, but only if it was made in France and is free (Scilab).Nothing but French software on this computer and French airplanes in the sky.Keep the trendy far far away from me.Hmmm...2008...The Obama days...

author: Harjit
author_rank: Regular Contributor
timestamp: October 25, 2020, 04:33:22 pm
content: You didn't ask about this option but you might want to consider Rust. All indications are that it is making significant inroads in system programming and might take over the embedded world, too.

author: ttt
author_rank: Regular Contributor
timestamp: October 25, 2020, 05:08:48 pm
content: Hey, you do what you wantI suppose if you don't do a lot of automation you will likely not run into many issues. The rest is about how comfortable you feel in your environment.I've followed the 'simple' path for many years only to get burned by proprietary IDEs again and again. Running into this again right now with Silabs Simplicity Studio for a Bluetooth part. Just getting to a point to where I can run C++ code without ending up in a reset handler up took a major effort. And the debugger integration is horrible. Which will bring me back to the method I use now: working around half baked IDEs.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 25, 2020, 08:55:06 pm
content: I hope your next customer brings in an H7 discovery board for you to work on, you'll be put in the right flow direction pretty quick.

author: lucazader
author_rank: Regular Contributor
timestamp: October 25, 2020, 10:18:21 pm
content: Quote from: LootMaster on October 25, 2020, 08:55:06 pmWe use h7's at work all the time, which is why i prefer using vscode.But man you use what you want. im not gonna hold your hand or walk you through how to do development.As soon as anyone questions why you do something round here you jump down their throat.And as soon as you get stuck you post on here and then hassle all the other members when they dont help you with the exact steps you need, and only provide a link to some resources that do.So thanks so much for you input to the community!

author: LootMaster
author_rank: Regular Contributor
timestamp: October 26, 2020, 02:03:00 am
content: You use a ST-link V2 and not a dual core tho... Admit it.Look, you werewrongok...Beause I cant use what I want, I can only use what works (I have many V3's mini bought and a dual disco HW).And your VS code in company is few and far between...Look... People seemed to have gotten stuck also...I could install it and test it for myself...Oh, I guess this is also a quest to make it work.https://github.com/Marus/cortex-debug/issues/228"There is no way to debug latest STM32 Discovery boards in VS Code because ST-Link V3 is not supported by debugging extensions. Appropriate GDB server has appeared recently: EBLinkhttps://github.com/EmBitz/EBlink. Could you please add EBLink GDB Server support?''So in conclusion, I cant do "what I want".But I aint mad or anything, I am trying to separatefacts on the groundfromopinions about comfort, and that's what I did for the community.

author: lucazader
author_rank: Regular Contributor
timestamp: October 26, 2020, 02:28:25 am
content: The only reason you cant "do what you want" is a lack of experience.You saying everyone is "wrong" rather than actually looking at how and why they do it because its not how you do it, that's the Wrong part here.There is more than one way to do everything.The reason people use vscode and a portable build system like make or cmake is they are then not tied to an ide build system so they can change to the latest and greatest when something new and great comes along, like vscode.Our company used to use atollic, but switched over so that we could have a CI/CD pipeline with a unit testing framework that can automatically run tests.And again you are incorrect assuming about our setup.We use stlinkv3's as well as jlinks for our debugging, works great! takes about 5 mins to setup on a new computer.But i doubt this will sink in for you.So enjoy your stm32cubeIDE! Its definitely one way to do things! If it works for you, great.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 26, 2020, 02:41:31 am
content: Ok I'll give it a try then... See...I have no problem admitting that I may be wrong...No problem at all.I'm just wondering why this guy was having so much problems and nobody helped him?? Maybe he has "his own special issue".https://community.st.com/s/question/0D53W000005pvjR/stlink-on-nucleoh743zi2-to-be-converted-to-jlink-in-order-to-use-with-VScodeIf its a good thing, maybe I'll use. Its true that it looks clean and its true that jumping from code to debug always takes like 4-5 seconds and its annoying... Also, there is a lot of view and windows I never ever use... Including those interrupt statistics... and especially those ugly looking graphs.Now...I gotta go install a bunch of pre-requisites, please excuse me, this may take a while.

author: LootMaster
author_rank: Regular Contributor
timestamp: October 26, 2020, 07:07:30 am
content: I'll give it a serious try. If I can manage to get a grasp of it with all the miscellaneous installs.Would not want to be left out with something not popular, slow, and less aesthetic.I tried the black eclipse but I just dont like it as much as what I saw with VScode, some of the things are poorly visible.Eye health is more important than gimmicky debug feature...When I first got TrueStudio I was like O cool graphs... then like...Ok

author: LootMaster
author_rank: Regular Contributor
timestamp: November 08, 2020, 12:11:36 pm
content: "Our company used to use atollic, but switched over so that we could have a CI/CD pipeline with a unit testing framework that can automatically run tests."Thats pretty badass, and it did not work well in IDE?... Maybe in the futureIs this an emulation that is done via debugger trickery or a simulation inside your cmputer? Me I dont care for computer simulations ... but the debugger trickery sounds cool.So the Vscode option is dead in the water for me... I tried following a video guide... And got stuck.You can only choose makefile for non dual core, for instance STM32H753...In my case, its greyed out...Seems like only dual core suffers from this??? All is most recent updates.BUT, VisualGDB can work...But I gotta payBut it looks pretty good. Whats yout take on that? Its the same as VS only supported and payed (I guess thats not a bad deal)...In terms of your "unit tests", I guess you ware wanting the debugger to insert "code emulations" to see how your system responds? Do you think this answer would satisfy you?Maybe you just havent tried hard enough in eclipse? Or is this a dead end...? I have learned to take the advice of Matthias Norlander not too seriously... He is motsly there to "smooth things over"... The question is still out there...Is eclipse satisfying for proper unit tests??https://community.st.com/s/question/0D53W00000JOlG2SAL/unit-tests-in-stm32cubeideI think code emulations are good for pretty simple things...At some point, I believe its better to "let run" and collect instrumentation...but in the event that you are really using your model precisely and know the ins and out and debugging that way...I dig that, thats pretty awesome but at the same time a whole other ballgame...I guess...You can have some sort of formula to follow around that you slightly tune everytime...Now that would be deep...Yeah...Thats beyond my paygrade.I mean, just the intricate nature of it all seems like more trouble thn its worth and reserved for critical systems.You know, it used to be that Atollic would advertise all the possibilities of test suites/automation/misra, and all now it seems even all that time and investment all those claims are gone I wonder what happened?

author: LootMaster
author_rank: Regular Contributor
timestamp: November 08, 2020, 02:40:25 pm
content: so yeah, ttt I saw your project. I dont understand at all your project inside project...But I see In your case, a 48 pin f4. And you started with a "makefile".I personally cant go with something that takes hours to figure out just to install and even when scouring YT for help I fail...I have heard also issues of slowdowns and memory leaks wth VScode.At least with this IDE I have somebody I can scream at (ST).I also saw they will , in the next few months, implement C++17 features, this was an statement from Markus Girdland (Ex-Atollic)... Yeah people are payed to maintian and upgrade and all the rest....I feel reassured.Meanwhile this click install following a 28 page PDF lead me to this... The debugger seems to not trip over itself and the ITM options are there...Pretty cool... Could I implement some sort of Github thing and some "automation" if I really wanted? Probably? Would it be as difficult as going with VScode? Probably the same?I gotta hand it to you tho, the dark look is better on VScode.

author: LootMaster
author_rank: Regular Contributor
timestamp: November 08, 2020, 03:27:05 pm
content: https://visualgdb.com/tutorials/tests/arm/Yeah...I see why you pros now want the c++ and the unit test.THIS IS THE WORKFLOW THAT WILL ATTRACT THE HR LADIES.

author: LootMaster
author_rank: Regular Contributor
timestamp: November 08, 2020, 09:16:01 pm
content: https://blog.mbedded.ninja/programming/general/unit-testing/Unit testing on embedded systems can be much harder than “typical” software unit tests. Low-level embedded C/C++ code can have many hardware/MCU peripheral dependencies, which may not be available when unit testing (e.g. if you want to run the unit tests on a standard computer). These dependencies require mocking, which can be very difficult.If the particular embedded code in question doesn’t rely on any hardware peripherals (like a message decoder or mathematical function), you don’t usually need the embedded system to perform the tests on. This is great, since you can run them on a normal computer, and save you all the time and hassle of setting correct test conditions on a microcontroller.-----------------------------------------------------------------------------------------You guys are in a special category, and STM32's IDE does not cater to such niche.My method for doing this would be a special signal generator I would prefer that than figuring it out with cpp and mocking...

author: Kjelt
author_rank: Super Contributor
timestamp: November 08, 2020, 09:26:28 pm
content: Are you now talking to yourself ?

author: LootMaster
author_rank: Regular Contributor
timestamp: November 08, 2020, 09:31:48 pm
content: My opponents are gone...I was proven correct what can I say...

author: Kjelt
author_rank: Super Contributor
timestamp: November 08, 2020, 09:49:11 pm
content: Quote from: LootMaster on November 08, 2020, 09:31:48 pmThe first part you are right , the second

author: LootMaster
author_rank: Regular Contributor
timestamp: November 09, 2020, 02:38:27 am
content: https://www.google.com/search?bih=634&biw=889&hl=fr&sxsrf=ALeKk01LwS5LKJhvJu3BRnJib0nYh_h5YQ%3A1604889161455&ei=SaqoX7-uG7q1ytMPwveV6Ag&q=embedded+unit+test+worth+it&oq=embedded+unit+test+worth+it&gs_lcp=CgZwc3ktYWIQAzoECCMQJzoGCCMQJxATOggIABCxAxCDAToFCAAQsQM6AggAOgQIABBDOgcIABCxAxBDOgIILjoFCAAQywE6BwgjELECECc6BwgAEAoQywE6BAgAEAo6BAgAEA06BggAEBYQHjoGCAAQDRAeOggIIRAWEB0QHjoFCCEQoAFQ78IBWIiQAmCukwJoAnAAeACAAfMDiAHFF5IBCDIyLjYuNC0xmAEAoAEBqgEHZ3dzLXdpesABAQ&sclient=psy-ab&ved=0ahUKEwj_9vyCtvTsAhW6mnIEHcJ7BY0Q4dUDCA0&uact=5Its an interresting issue, for those on the very bleeding edge of embedded SW dev.Not well suited for a basic smart watch but more the high $$ medical/aero/industrial market.Goes to show how deep the rabbit hole goes to really be "a hard and true expert of Lockheed Martin paygrade".

author: JojoS
author_rank: Contributor
timestamp: November 10, 2020, 08:42:10 am
content: I'm using Mbed-os, there I have already a C++ API. For STM32, the HAL/LL is used and when some functionality is missing, I can add code that is generated by CubeMX and I use a C++ wrapper to make it more versatile. I don't like a code generator for the whole app, C++ components are much more conveniant.Mbed can create a makefile that could be used in CubeIDE, but I prefer using the Mbed build system in VSCode. The build system is going to change to CMake, that will make it easier compatible with other IDE.Debugging in VSCode works with the Cortex-Debug extension. STLink V3 can be used also via Black Magic Probe in hosted mode.

author: westfw
author_rank: Super Contributor
timestamp: November 10, 2020, 09:39:14 am
content: QuoteC++ programmers will then claim that "you're not really programming in C++"Quote1-2MB. Oh, we are so spoiled these days.QuoteGood luck with that. newlib (even the nano) version pulls in malloc() from sprintf(), for example. (Hmm. Do we consider it "allowable" for well-known, well-proven libraries to use malloc() for short-term storage?)In addition to networking stacks, USB stacks and filesystems frequently use dynamically allocated structures, for good reasons.QuoteThose who don't know embedded, don't fear C++...(someone said virtual functions were "cheap." I've seem evidence to the contrary...)

author: LootMaster
author_rank: Regular Contributor
timestamp: November 10, 2020, 12:50:12 pm
content: @ westfwThanks for telling the truth...I hate it when C++ fanboys try to smooth things out.I can tell from their zeal, glasses and pants in the video conferences that these people are 100% CS and did not start like me, with CMOS4000 and 74HC some 12 years ago.Me and Elon are pretty much the same, our personnalities are more suited for C.

author: LootMaster
author_rank: Regular Contributor
timestamp: November 10, 2020, 03:51:01 pm
content: Quote from: JojoS on November 10, 2020, 08:42:10 amAnd you use this to developp industrial equipement with certification etc??Can you point me to a video guide for this on Win10?Can you confirm it works with dual core projects?

author: JojoS
author_rank: Contributor
timestamp: November 11, 2020, 11:11:51 am
content: Quote from: LootMaster on November 10, 2020, 03:51:01 pmNot yet, I have evaluated it for some of our products and see it will fit very well. I'm not in that department for these components, but we have used a proprietary OS for many years and I know about long term stability and the requirements.I follow the development of mbed-os for about 10 years now and the last years it has grown a lot with the releases of V5/V6. The development process is controlled by an ARM team and is very professional. The CI process is hard and new features are accepted only with a lot of tests. This is quite different to Arduino with core development spread amongst many 3rd partys.Quote from: LootMaster on November 10, 2020, 03:51:01 pmThere are some videos on YT, but Mbed is changing fast and for the current V6 release I haven't found some official clips. But the complete history for Mbed5/6 is on github, so the old installer for windows is still working:https://os.mbed.com/docs/mbed-os/v6.4/quick-start/index.htmlUsing the Mbed Studio is a simple way to start, using the mbed-cli is more versatile, but requires more knowledge when you want to integrate the tools into an IDE.The Windows installer runs on Windows 10, but you should deselect the components toolchain, git and python and install current versions manually. After installing the tools, you should have the command 'mbed' working in the cmd. Then you can start withhttps://github.com/ARMmbed/mbed-os-example-blinky, it contains instructions to build.Then you will be amazed how much stuff is compiled for a simple blinkyBut its part of the philosophy, the whole system is compiled to ensure everything fits together. Consequent builds are faster because they build only the modified sources (unless you change something in the configuration files). I have set up a linux machine now also, because it compiles significantly faster on the linux fs. Even in WSL that could be used also.The large number of files should not scare you, the OS has grown for many years and the build system based on python needs some upgrade. CMake looks like a solution for better modularity and it is already being worked on.Quote from: LootMaster on November 10, 2020, 03:51:01 pmno, I have used STM32H7 and see these controllers are powerful but much more complex. For some there are already different revisions and revision dependent fixes in the HAL. But there is already support for these dual cores in the OS. As they are quite new, I would do careful testing before using them in critical missions.