I have some time to experiment with STM32F4 over the next few weeks.
I wondered, is any of your STM32F4 library source available?
What state are your STM32F4 Libraries?
(37 posts) (9 voices)-
gbulmer
Moderatorsiy - I should have mentioned, I'd had a quick looked through the leaflab git repo, and not found anything.
But, LeafLabs wrote that the STM32F4 boards are progressing, so, to test or boot the STM32F4 board, there needs to be clock initialisation, and GPIO working (a bit). There may be more, like ADC, and Timers. So there should be some code some where.
I've looked at the ST micro code, and I could start there, but I'd prefer to apply my time to complement LeafLab's effort (if practical), rather than use the ST code, or re-invent stuff blind.
I'd start with the GPIO, which is different between STM32F1 and WTM32F4.
Posted 4 years ago # -
siy
MemberI think that absolute minimum for Maple board to remain belong to Maple family is the presence of bootloader. Unfortunately incompatibilities between F1 and F2/F2 series affect almost every part of bootloader - MCU initialization, GPIO, flash and USB. At least I got such conclusion after reading AN3427 where differences are described in details. Relevant pages for F4 MCU's at ST site don't list this application note directly, but list AN3364 which contains reference to AN3427, the AN3427 itself is present at pages dedicated to F2 family.
As for supporting LeafLabs efforts, I completely agree and would like to help (again, if practical), but to be in sync with LeafLabs efforts and avoid reinventing the wheel there should be known place to start from. While digging through repo I've found no such place. In fact looks like the libmaple code is significantly diverged in different branches and forks and in some of them can be found early stages of preparations to support different MCU families (https://github.com/mbolivar/libmaple/tree/wip-family-support). Unfortunately I've found nothing similar for bootloader.
My overall impression is that LeafLabs github repo is significantly outdated. I realize that small company may have not enough resources to maintain repository and continue development in parallel. But, perhaps it worth consider to pay some attention to repository and coordination of efforts of those who willing be involved in development and let community help LeafLabs. I believe that this will help LeafLabs with Maple development and leave them more resources for their own projects. In other words, I think small initial adjustment in resource assignment may significantly improve LeafLabs overall productivity.
Of course, all of the above is just my thoughts and they can be wrong just because I'm missing (or just don't know) something important.
Posted 4 years ago # -
gbulmer
Moderatorsiy - I may be coming at this from a slightly different direction, so I apologise if I seem to be disagreeing.
I believe I fundamentally agree with you.LeafLabs have written in this forum, several times over last year, that they are considering a different bootloader mechanism. Specifically they have described the intention to change the hardware design to something like the STM32Fx-DISCOVERY boards which have a second MCU to handle JTAG/SWD upload and debug.
I do not know what their actual plans are, so I'd prefer to avoid working on a bootloader which may become a dead end.I would hope that if they do go that way it is STLINK/V2 compatible. Making their bootloader be STLINK/V2 compatible, if practical, seems to be a "no-brainer", but that's just me. STLINK/V2's are only $24, so a 'naked' MCU board that needs one isn't too expensive in the short term. There are Open Source uploaders for the STLINK/V2 protocol already, and some commercial IDEs support it.
So I am using an STM32F4-DISCOVERY for development. I am using this to do development in advance of LeafLabs hardware availability. I think there is little I can do on a bootloader until LeafLabs hardware appears.
I would prefer to apply effort to a place which moves an STM32F4 Open Source library forward. My interest is enabling inexperienced programmers to use the hardware, so I am interested in a Wiring-style library. I think the CMSIS stuff is daunting for a beginner, though I could wrap CMSIS to reduce the initial effort to get stuff working.
Anyway, I've also looked at AN3427, and dug into comparing the peripheral manuals RM0008 and RM0090.
IMHO, to be generally useful, we need chip initialisation (clocks and SysTick etc.), GPIO, ADC and Timers (for PWM and time).
The peripherals have changed, but it doesn't look like a huge amount of work.For example GPIO has reorganised the configuration bits into new registers, but there aren't many new features, and I think we can choose sensible defaults so that people can get started using GPIO.
Similarly, though the ADC has many new features, and some of the old configuration has changed, the Wire-ish API didn't expose very much anyway, so IMHO implementing Wiring on top of the STM32F4 ADC will moderate amounts of work.
Finally, the timers have new features, but again, the Wire-ish API gave little access to the Timer features. A few of the timers support 32bit counting, which may require a small amount of new code, but for simplicity and compatibility, using them as 16 bit PWM appears to be straightforward.
SysTick will need a small modification too, to scale the new base clock.
Some of the other peripherals, like SPI, USART and I2C, are important, but don't feel like the same priority for initial testing and use.
DMA is very different, so I haven't even considered how much work there will be to get that going.So, it IMHO getting a basic, usable system might be a few weeks of work, and I can ignore the bootloader issue for now.
If LeafLabs have a clearly defined repository for the STM32F4, I think I could work out if I can contribute.
If we want to collaborate on this, starting a forum thread for each peripheral may make it easier to collaborate and focus.
Posted 4 years ago # -
siy
MemberMy accent on bootloader is not intentional, I realize that bootloader worth nothing without at least basic working libmaple. Main idea of my previous post is more general - I believe that by deeper involvement of community in development of libmaple and remaining parts of the environment, development process can be significantly improved. Moreover, I think that this also will lead to better general impression about Maple and community for newcomers and therefore will lead to faster growth of community (and this means even more resources for development). Several successful free software projects came through this path and in fact they are successful because of this approach. At present I think that there are even no need to spend much time on coordination of efforts, little deeper access for community to ongoing development will be enough to get more developers (i.e. resources). Probably I'm just trying to apply my experience from "big" software to embedded world, but I see no reasons why this approach may not work for libmaple.
Posted 4 years ago # -
gbulmer
ModeratorI believe that by deeper involvement of community in development of libmaple and remaining parts of the environment, development process can be significantly improved.
Agree, but this appears to carry risk and cost until it is working.
Moreover, I think that this also will lead to better general impression about Maple and community for newcomers and therefore will lead to faster growth of community (and this means even more resources for development).
Agree, if it can be achieved.
Several successful free software projects came through this path and in fact they are successful because of this approach.
What projects are you thinking of?
I prefer a somewhat open approach, because that matches my goals, but AFAIK, there has not been a well researched, evidence based analysis of what the key causes of successful Open Source project are. It is clear that some thrive, others remain restricted to their initial developers, and some wither. My impression is that it is a combination of leadership, ethos, process, quality and simply how interesting the project is.It is true that the initial Arduino development team (able to commit new code to the release) remained very restricted and static until recently. So is this a counter example?
I am not suggesting I want a 'closed' approach. I am only saying that I have seen no analysis which leads me to believe their is a simple recipe for success.
I have been in software development for 30+ years. I have worked on large internal systems, internet systems, banking systems, manufacturing systems, distributed systems, and large scale Enterprise Integration systems. I have also taught Software Engineering to post graduate level, and been responsible for software development processes, and staff training, for 10,000+ and 2,000+ staff software services companies.
I am not sure what you mean by "big" software. I have done multi-year projects with 100+ developers, and I think those are "big" software. I feel they are too different from making something like libmaple that it would be unhelpful to focus on their processes.
The things I will say are:
- the quality of the people makes more difference to the outcome than any other single factor that I have seen
- Agile development, with small, incremental, tested, useful, regular releases seems the best way to deliver useful and usable code for small and medium systems.
- for anyone who wants to run a project, and in the absence of any better project approach, read "How to Run Successful Projects: The Silver Bullet" by Fergus O'Connell (I have not read edition III which is much bigger than my old copy)Posted 4 years ago # -
I agree with gbulmer. (and have similar experience.
I personally think that making an assumption of "oh this board is only $x" or "that piece of hardware is only $y" is the wrong assumption for development and missing the goal of this board.
I also have a F4 discovery board, and have been toying with and impressed with it's massive capabilities. However, I think that there are/will be many hardware boards around to run these chips. The purpose of the maple is twofold - to give affordable and easy access to entry level hobbyists. I any of these are missed - then this board family will evaporate.
Posted 4 years ago # -
siy
MemberClarification: under "big" software I did mean software for regular, non-embedded computers. "Big" has no relation to the size of particular application or project.
Successful free software projects which can be used as an example, in my opinion, are following:
- Eclipse
- Several (perhaps, "countless", may fit better here) Apache projects (Apache Server, Tomcat, ActiveMQ, Wicket, Lucene, Ant, Maven, etc.)
- Linux
- FreeBSDOf course the list above is not exhaustive, just few first which came in mind.
I realize that there is a risk. And, of course, I understand how much depend on the development process (including size and quality of the core team). And definitely did not mean that everyone should have ability to commit changes. That's why I made accent on coordination of the efforts. I also agree that some kind of Agile process might be best way to go, but I also think that this is up to LeafLabs how to establish process and which one to choose.
I think that even without any changes in the process, just by making current code available to community, LeafLabs can get access to significant testing resources provided by community. Adding issue tracker to organize the feedback may help make these test resources useful without spending much time necessary to read bug reports in forum. These steps are simple, not require much resources and can't have negative impact to current development process. Next steps, which may affect development process, might be based on experience obtained after performing steps mentioned above.
Of course, all of the above is just my thoughts which can be wrong.
Posted 4 years ago # -
wyzarddoc
MemberI have watch opensource development for over 35 years - when it was just developers exchanging code on bulletin board modem systems. The successful open source project have a very well defined and organized method of exchanging information. I have both arduino and C/C++ programming abilities but I don't like using the command line compiling (sorry just not a linux purest). I have been very frustrated with leaflabs in the area of information dissemination. I don't want to spend days or weeks figuring out how to setup an Eclipse development environment by searching through this forum. To be successful leaflabs needs fixed topics on this forum for each board. Under each topic their needs to be a set of software standards, fixed topics covering - development using Eclipse, development using the arduino interface, development using the command line. Also fixed topics on setting up development environments for new users like myself. Libs and code should be fixed topics under each device also with an experimental, proposed and committed subsections for download by developers/users. Yes there will be a lot of redundant posts and code but the speed of dissemination will be increased to the max. In addition new leaflabs products will benefit by the development/conversion of previous work applied to new or proposed/experimental products. Leaflabs is experiencing the growth pains of success and I wish them the best.
Posted 4 years ago # -
gbulmer
Moderatorsiy - yes, those are very successful Open Source projects.
I agree that very good communication are part of their recipe.I believe the intention is the wiki, rather than the forums, would carry 'how to guides' for things like using Eclipse. I gave up trying to use the wiki because it was under a lot of spam attack.
LeafLabs did have a visible issues list for a while, but that seems to have gone away.
There was a list of outstanding issues/goals maintained by LeafLabs for upcoming releases on the wiki, but that no longer seems to be used.It is not clear to me that this forum constitutes a significant aspect of LeafLabs business. It is quite common for LeafLabs staff to respond less frequently than weekly.
I continue to try to contribute because I believe that affordable Open Source hardware, suitable for new users, is critically important.
(Full disclosure: I am not a member of LeafLabs staff)
Posted 4 years ago # -
I too am using a Discovery board as a STM32F4 platform for initial development. Bootloading using the default bootloader on the Arm is my preference for most guys to do infrequent firmware updates. JTAG support using an external adapter such as the ST-Link is not painful is the path for development/debugging. Requiring ST-Link support on board is not a good idea because it close out most board options.
In the short period I have been using Maple I have not been convinced by a commitment to stable peripheral libraries by Leaf Lab.
I will be basing my work on the STM release libraries as STM does have a vested interest in getting these close to OK and the call interfaces reasonable stable over time.
Greg
Posted 4 years ago # -
gbulmer
ModeratorGreg - I think I agree with you. Might you like to discuss collaboration?
In the short term, I am using the STLINK/V2 built into the STM32F4-DISCOVERY board.
I have been using Rowley CrossWorks. It works, and I have a working upload and source level debug with breakpoints.
I'll use a separate STLINK/V2 for debugging boards.My aim is to also use the manufactured-in, on-chip bootloader, which works over USB (and USART and CAN). I think 'native' USB bootloading supports the lowest cost boards, which is one of my aims.
I have started using the STM32F4 peripheral libraries, and they work fine at the simple level that I have experimented. As you say, STM have a vested interest in them working. My concern is they are daunting for a beginner, and so I think a Wiring-style 'veneer' is required to help new programmers get going.
I haven't tried the STM startup code yet.
Posted 4 years ago # -
Seems like my comments elsewhere on the forum relating to the state of the libraries are better targeted here. Seems like I am definitely not Robinson Crusoe.
Happy to share and I agree the wiring level is the most accessible abstraction with little efficiency loss if any possible.
At the moment I am trying to work out the minimum hook to the STM libraries and for starters I am working through the existing Maple stubs to get a feel for things. The current pin mapping struct doesn't cover the pin function richness of the F4 ... a bit of work to do but as everything is open then the investment of time may just be worthwhile.
My main problem with the STM libraries so far is I cannot see the code for the comments ;).
Greg
Posted 4 years ago # -
gbulmer
ModeratorGreg - I've had a Maple since June 2010, and was observing since late 2009. If being "Robinson Crusoe" means alone or unique in your views and understanding, then no, you are not "Robinson Crusoe"
I should say, that I think the LeafLabs Maple tool approach is preferable to the mbed, and I prefer the STM32F families to the Atmel Cortex (or MIPS32). I am interested in the NXP LPC4xx, but I think the extra Cortex-M0 is likely too hard for a beginner to use.
So AFAIK, Maple is the best basis for my interests.
It is also worth mentioning that in one of my interests, Micromouse robot competiton, STM32F is very popular. IMHO that counts for something when encouraging new programmers to use some specific hardware.My main problem with the STM libraries so far is I cannot see the code for the comments ;).
Yes!
It is so infuriating, that I have seriously considered writing a bit of yacc & lex (bison & flex) to tidy it up!Some of the comments are so banal that I think they are can only be trying to pass an automated tool check:
/* Write to ADCx CR1 */ ADCx->CR1 = tmpreg1;I was thinking of taking the comment from the line ahead of the code, and tacking it on to the right of the code so that it doesn't waste as much space, and doesn't distract the eye. I was also thinking of fixing some of the 'TypeDef' stuff.
Happy to share and I agree the wiring level is the most accessible abstraction with little efficiency loss if any possible.
Would you like to consider actively collaborating somehow?
If you do, drop me an email. You should be able to guess my address at gmail dot com.I must admit, that while I like Wiring a lot, I think tiny changes might improve it (I'd have to trial changes to feel confident; evidence beats intuition, even my intuition :-)
At the moment I am trying to work out the minimum hook to the STM libraries ...
What do you mean?
I am looking at the startup code, and worrying about Open Source upload.
If that is working nicely, I expect it'll be practical to integrate with Wiring.The current pin mapping struct doesn't cover the pin function richness of the F4 ...
Yes, and I think pins is an area where Wiring can be improved.
Posted 4 years ago #
Reply »
You must log in to post.