Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

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

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Postby stevech » Wed May 25, 2016 4:47 am

RogerClark wrote:Re: Using Alternative pin config's
I'm not sure if we need to use this feature

It's the essence of the ARM I/O architecture!!! It's how you tailor the MCU to what you need to do - since there are more on-chip I/O devices than package pins. Esp. in the 64 pin packages!!!

It's NOT a reason to avoid the use Cube. I've done Cube based projects where I elected to use I/O function A on certain pins, and B on others, and juggle these to get the peripherals I need connected to pins. It's not sensible to hard-code I/O to pins when, say, you have 4 UARTs on the chip, but you have a 64 pin package and need only 2 UARTs and you have SPI, SDIO 4, I2C, FSMC, etc. Next project, you have different I/O needs. Yes, with a fixed-board type mindset, this is copper and solder. But no, the same board can have pins' alternate functions mapped as needed by software. Just look at any serious ARM based board and you'll see the colorful crib sheet card showing what I/O thing can be used on one or more pins, at the software's choice.

In this one
https://www.pjrc.com/teensy/pinout.html
there are about 3 alternatives on most pin - software selected.
On STM32F4's there are 6 or more. So if project #1 needs I/O collection A on certain pins, but the same board is used on project #2 which needs different I/O collection, it's just software, not solder, not a new board.

Alternate pin choices by software is so fundamental to today's processors that cram so many I/O devices on the chip, and only a die or 144 pin packaged chip can get every I/O device connected to a pin, simultaneously.

Without Cube, managing the alternate pin choices becomes a lot of hand coding beyond journeyman level. And Cube inputs from you the register config for each chosen peripheral. That's ESSENTIAL, in these complex chips. Then Cube spits out the driver init and ISR and DMA handling code that would have taken you weeks/months to learn and many days/weeks to code.

I sincerely apologize if I''ve misunderstood the opening statement, in this post, in which case, I'd delete my post, here.

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

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Postby mrburnette » Wed May 25, 2016 1:09 pm

stevech wrote:
RogerClark wrote:Re: Using Alternative pin config's
I'm not sure if we need to use this feature

It's the essence of the ARM I/O architecture!!! It's how you tailor the MCU to what you need to do - since there are more on-chip I/O devices than package pins. Esp. in the 64 pin packages!!!
<...>



Yes, configurable pin functionality is available on many uC's ... I personally have worked with the Cypress PSoC units which utilize network switched architecture on analog and digital fabric.

However, I do not think this paradigm is appropriate in an Arduino world since "we" generally publish a board architecture pinout showing the uC configuration. Having this pinout willy-nilly changed by the end-user would make IMO for a completely unsupportable Arduino implementation.

The above being said, I do think that it would be possible to reach a consensus on a few variations for custom boards; for discussion purposes, A, B, C. This would allow for the creation of homemade boards that were biased in I/O to a particular need... identical layouts but with different silkscreening of the pin functions. It seems to be a sensible solution.

Otherwise, the end-user would be required to start at defining the pinmaps themselves, editing the appropriate pin-map files, creating their own diagrams and so forth. But, from a forum and "core" perspective the pin usage needs to be nailed.

Ray

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

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Postby stevech » Wed May 25, 2016 9:21 pm

mrburnette wrote:
stevech wrote:
RogerClark wrote:Re: Using Alternative pin config's
I'm not sure if we need to use this feature

It's the essence of the ARM I/O architecture!!! It's how you tailor the MCU to what you need to do - since there are more on-chip I/O devices than package pins. Esp. in the 64 pin packages!!!
<...>

However, I do not think this paradigm is appropriate in an Arduino world since "we" generally publish a board architecture pinout showing the uC configuration. Having this pinout willy-nilly changed by the end-user would make IMO for a completely unsupportable Arduino implementation.

The above being said, I do think that it would be possible to reach a consensus on a few variations for custom boards; for discussion purposes, A, B, C. This would allow for the creation of homemade boards that were biased in I/O to a particular need... identical layouts but with different silkscreening of the pin functions. It seems to be a sensible solution.

Otherwise, the end-user would be required to start at defining the pinmaps themselves, editing the appropriate pin-map files, creating their own diagrams and so forth. But, from a forum and "core" perspective the pin usage needs to be nailed.

Ray


Experts can generate board-to-pin maps for a suite of boards. But forgoing auto-generated code from Cube/HAL is a huge mistake. Impractical to reinvent AND debug all that is in the HAL. Very naive to think reinvention for a subset is practical. It took Paul of Teensy fame 2 years of probably 100 hour weeks to get what Teensyduino has and that is a subset of the I/O on the chips that is the next Teensy. Few people have the time and devotion to do what Paul has done. Hence, Use ST's HAL is the answer. The Maple-to-Phoenix-risen needs to move beyond the old/minimal ARM I/O suite of that era's ST.

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

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Postby mrburnette » Thu May 26, 2016 1:30 am

It took Paul of Teensy fame 2 years of probably 100 hour weeks to get what Teensyduino has and that is a subset of the I/O on the chips that is the next Teensy.


I gave my Teensy away. Probably still have the second one around in a box somewhere. Nice little board but I objected to having to patch the IDE and that darn pop-up download tool is so cheesy... like muenster :shock:

Paul is a decent enough dude, I've communicated with him a few times. But Paul is a hardhead, no compromise , do it my way kind of human... I can relate; but we clash.

Point of this whole Paul discussion? Honestly, I do not know.

But forgoing auto-generated code from Cube/HAL is a huge mistake. Impractical to reinvent AND debug all that is in the HAL.


My opinion is unchanged... IF the current github is going to have different models of ST's STM32Fx" microcontrollers, then those boards should be capable of being programmed by the ArduinoIDE by board selection. Evolving feature and core support is OK, IMO. Now, I personally could care less of how the core materializes... by humans, by automated tools, or by a million monkeys.

I suspect 95% of this forum knows that ST has professional tools and that other IDEs can be used, but bashing the ArduinoIDE as inferior is crude ... the comparison is an "apples and oranges" comparison. The trick, is to backport the essence of the professional IDE(s) created code back into open source core code to support the Arduino riding on top of GCC.

Ray

User avatar
ekawahyu
Posts: 87
Joined: Wed Apr 13, 2016 6:17 am

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Postby ekawahyu » Thu May 26, 2016 6:03 pm

I believe that we are all here together for various reasons, writing the underlying code for Arduino STM32. But, I guess there must be at least one same reason why we are all here. We are all expert in digging the STM32 code to the lowest level and that is not the main reason why we want to work on the support for the Arduino IDE. Arduino does not have the best IDE, but you may go and choose Eclipse as you wish. In my opinion, if you are capable enough to touch the lowest level, then you would probably choose other tools other than Arduino IDE. So, what is your reason doing this? What is your target in doing this?

Here is why I am here:
  1. I have spent a lot of time in the past toying around with STM32F0, F1, F4 using their Standard Peripheral Libraries. I have ported codes to it like simple shell and various hardware driver support with a nicely written Makefiles. ST-Link, JLink, USB-ARM-OCD, you name it, I have them all supported for the flashers. All that sudden, the SPL has been discontinued and I had to move on with the HAL? That is hours of work in replacing SPL to HAL for multiple cores! So I found STM32duino.com and I thought if I could contribute something to work with all of you, then I can understand how the HAL work quicker then doing it myself.
  2. I have been fascinated with the growth of Arduino community and I also notice some haters. Some said that Arduino is not a "normal" programming language, has no multiple tabs, has no support for multiple source code writing, but that is Arduino! With its simplicity offered, still more people joining the club and write more library for it. I have to agree with Ray in this regard. Keep it simple because Arduino is Arduino. It is not for experts, it is for beginners. The way we do it for digital I/O is correct by naming it PA, PB, etc instead of keeping it as Arduino with numbers. I think we should do the same for analog pins.
  3. STM32CubeMX is just the tool for us to generate code faster for the lower levels. I have to disagree to provide only *.ioc for others instead of the full generated code out of it. For the last two weeks, I have been generating code with the exact same *.ioc but the generated code were not the same from time to time. What would happen if ST decided to move on to something else in the future and stop their support on STM32CubeMX? The same cycle would happen again, just like no more support for the SPL and we are all left with only *.ioc in our repositories.
  4. I design electronic boards for younger kids for their Makerspace. I use STM32 because it is affordable most schools can buy, and less expensive compared to getting only AVR on Uno. It has built-in DFU, no programmer is needed. If they decided to go advance, ST-Link is low cost and I already put Makefiles here and there to build, off of Arduino IDE. They could program and debug in Eclipse IDE for the exact same source code and the .ino

With that being said, I think we should keep the full libraries (probably as separates git submodules?, or whatever). We just need to build each variant against Drivers and Middlewares at their new location. That's all. Providing a script to download libraries from ST is not an option. Because, I am afraid those HAL repositories on ST website might be disappeared some time in the future, just like the SPL did.

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

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Postby mrburnette » Thu May 26, 2016 7:05 pm

ekawahyu wrote:<...>
We are all expert in digging the STM32 code to the lowest level and that is not the main reason why we want to work on the support for the Arduino IDE. Arduino does not have the best IDE, but you may go and choose Eclipse as you wish. In my opinion, if you are capable enough to touch the lowest level, then you would probably choose other tools other than Arduino IDE. So, what is your reason doing this? What is your target in doing this?
<...>


Well, I publish for newbies and intermediates here. ArduinoIDE is free, easily learned, the environment is self-configuring, it is multi-platform, and it works. Most of my little projects are simple and only take a few hours out of a rainy weekend. For the most part, the code is free-standing and only require the standard libraries.

The argument I hear is almost identical to the "AVRfreaks.net" and "forum.arduino.cc": AVR freaks is all out to the hardware programming. Arduino.cc is about using the ArduinoIDE to do this & that.

Listen, I understand that STM32 development can be done in multiple ways and I understand that members hereuse different Programming tools and have favorites and they wish to discuss them. But when the sun goes down, the day's work should have been toward making the Arduino cores better: more compatible, more versatile, faster, smaller, etc. There is so much work to do here. Do I have to write a mission statement?

Everyone has ideas, experiences, and talents and a goodly number of you work in the uC field and are professional programmers. Taking that talent and knowledge and applying it to the job at hand - STM32 under Arduino - will surely make the core files better than what we have today.

But, this is not my forum and I do not pay the hosting bill, or do the backups, or maintain github... Roger does all that but in my discussions with him, I know he wants to keep an ArduinoIDE focus. Not a gag order to not discuss other tools, but a direction on continued development for cores to run under Arduino.

Regards,

Ray


Return to “CubeMX and HAL”

Who is online

Users browsing this forum: No registered users and 1 guest