STM32CubeMX :: STM32F030F4 support

Development of new Cores using the STMCubeMX and HAL
stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Fri Apr 08, 2016 4:33 pm

mrburnette wrote:
ST's HAL is all C. No C++. All I/O drivers are in C for compatibility assurance.
I once read, but cannot now find the reference, that come outfits have a strict no-C++ rule for embedded uC code. I believe it was because of the difficulty to formally profike memory usage ... so, maybe I read this in regard to military/space applications.

In the Cypress PSoC environment, C++ is disabled by default. Of course, one can enable it, but Cypress does not recommend that approach.


Ray

Update: I did find several references where 'suggestions' about not using C++, but no absolute ban...
C++ software development for DO-178 safety-critical applications
August 1, 2010

Use of the C++ programming language may cause concern, delays, and rework when it comes to DO-178B compliance.
By DAVID BEBERMAN AND JOE WLAD
While use of the C++ programming language has increased in the past decade, choosing this language could hinder efforts to comply with certification standards, such as RTCA/DO-178B, unless developers take great care.
The lack of standard guidance and rules leads many certification representatives to review an applicant closely who is using C++, which can result in project delays or rework.
Others...
Used correctly, C++ can be OK on embedded.
IMO, correctly means
No run time class instance creation. Only statics.
No use of String and other classes that do dynamic memory allocation and need garbage collection/coalescing.
ISRs in C. Name-mangled C++ functions have a hard time using shared variables.

Best to leave C++ for embedded to be used only with non-I/O things.
And avoid using the heap due to dynamic class or object creation/deletion.

User avatar
mrburnette
Posts: 2034
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by mrburnette » Fri Apr 08, 2016 11:14 pm

stevech wrote: <...>
Used correctly, C++ can be OK on embedded.
IMO, correctly means
No run time class instance creation. Only statics.
No use of String and other classes that do dynamic memory allocation and need garbage collection/coalescing.
ISRs in C. Name-mangled C++ functions have a hard time using shared variables.

Best to leave C++ for embedded to be used only with non-I/O things.
And avoid using the heap due to dynamic class or object creation/deletion.

Poisons are used in medicines but "used correctly" is the important phase! Arduino core libraries are nicely done as are some 3rd party libs:ex, Adafruit & Teensy.

My point is newbies coming from the PC/Server world have to immediately become restrained in programming uC in C++... it is a learned art.

Ray

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Sat Apr 09, 2016 5:26 am

I talked at some length at a party with a fellow who has done only Microsoft web designer tool use, and a bit of C#. I showed him what embedded programing is like, with some hardware I'm working with. I explained what it's like to use C/C++ and not C# or web page tools. He just didn't know such existed. He's had lots of the Kool Aid. Until I told him, he'd never stopped to think about how much code goes into, e.g., a modern washing machine's controller(s), nor how hard it is to do real time things like that. And I mentioned how all that code has to be 99.99% correct else Manfucaturer X has a big financial issue with recalls or field service truck rolls due firmware errors.

We have a new high end washer/dryer. They have Bluetooth. Oh my. Remote reprogramming and diagnostics.
My Keurig 2.0 coffee maker has a plug to connect a PC for reprogramming or other stuff (future).

User avatar
Vassilis
Posts: 323
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Sat Apr 09, 2016 10:45 am

I sent a new PR to Roger.

- The UARTClass now supports Serial1, Serial2 and Serial3. The SerialUSB (Serial port over USB) is not implemented yet.
- Added the STM32F103C8 variant.
- I removed the additional properties I had put in UARTClass.cpp file because the STM32F030 works ok with or without them.

User avatar
RogerClark
Posts: 7544
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Sun Apr 10, 2016 11:33 am

Thanks

I accepted the PR.

I've pulled the repo to my local machine and it compiles OK for me

As I wanted to test the Serial, I've tried to add BlackMagic Probe as an upload method, so I've modified my boards.txt so that it had an upload menu for the BluePill board

It looks like this works, however, I've not managed to get my BMP to work. I think its either a wiring issue or possibly I'm running a customised version of the BMP I modified to support the nRF51822

So I better download Rick's original BMP firmware and try that instead of the special version.

But I've run out of time today :-(

Cmustard
Posts: 8
Joined: Sat Apr 09, 2016 3:17 pm

Re: STM32CubeMX :: STM32F030F4 support

Post by Cmustard » Tue Apr 12, 2016 7:09 pm

Wow..

I was sifting through the 1100 odd pages manual to find the right registers to pull for the IRlib.
And that's where I realized where the CubeMX adds value.
These STM32 buggers have soo many options that we need to settle for a given set of "defaults" or "alternating defaults"
Actually in a similar way as with the Arduino pin functions have given and limited set of variances.

This is where I'm in Steve's corner.
Probably there needs to be a group of people making the basic pre-decisions following architectural rules of thumb.
like e.g. how likely is it that a "hobby" project needs 2 I2C busses.
I'm just saying, the STM32 can handle it but should the hobbyist too ?

If you're a pro you probably are not wanting to go the arduino route, it's most likely plain HAL work using Keil or some other IDE.
makes sense ?

Cheers,
Paul

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Tue Apr 12, 2016 7:47 pm

Right.. All these cortex M's have so many on-board peripherals and relatively few pins. Not like ye ole AVRs.

This is when a GUI tool makes so much sense. Especially if you work with several boards, several MCUs.

I'm on a project that uses STM32F4's in die form. No IC package. So I work with a 100 pin CubeMX session even though there is no package when you use a die.

I learned that for any STM32Fn--, say STM32F4xx, all the peripherals that are in the reference manual for the largest package (say, 100 pins), are in the die used on all STM32Fn's. They just can't wire up all. They choose which to omit for, say, a 64 pin package.

And for any one package, the on-chip pin mapper multiplexers lead you to a compromise since not all peripheral devices can be simultaneously mapped to relatively few pins (not so, with a die). And again, there are more peripherals on the die than are wired to the pin mapper mux for any given package. Interesting, I had thought they reduced cost by limiting selection of peripherals. Since they don't have to test those that aren't wire-bonded to pins, I guess that does reduce cost.

User avatar
ahull
Posts: 1672
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by ahull » Tue Apr 12, 2016 10:26 pm

stevech wrote: I learned that for any STM32Fn--, say STM32F4xx, all the peripherals that are in the reference manual for the largest package (say, 100 pins), are in the die used on all STM32Fn's. They just can't wire up all. They choose which to omit for, say, a 64 pin package.
Interesting, so in all likely hood the DAC is present on the STM32F103C8T6, just not readily accessible... I wonder if we might be able to munge up an alternative pin map to expose it.... :?: :idea:
- Andy Hull -

User avatar
RogerClark
Posts: 7544
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Tue Apr 12, 2016 11:22 pm

stevech wrote:I learned that for any STM32Fn--, say STM32F4xx, all the peripherals that are in the reference manual for the largest package (say, 100 pins), are in the die used on all STM32Fn's. They just can't wire up all. They choose which to omit for, say, a 64 pin package. .
Do you mean the registers exist?

I know that all the GPIO reg's for F103Z series are in the F103C series, but its hard to know whether anything else exits

You can't test the DAC but you can try things like the Timers

User avatar
Vassilis
Posts: 323
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Wed Apr 13, 2016 6:56 am

I have almost finished the SPI library (basic funcions). It has been tested only on F103 MCUs.

Post Reply