Has anyone done any work with any board using the LQFP100 STM32F103VET6?

LeafLabs Garden » Support » Maple Hardware Support

Has anyone done any work with any board using the LQFP100 STM32F103VET6?

(26 posts) (5 voices)

Started 4 years ago by corguy
Latest reply from mbolivar

« Previous 12

mbolivar
LeafLabs

Just FYI, the master branch is pretty old, so as I'm sure you've discovered, the diff between that and native-boot has a fair amount of extraneous crap that won't be relevant for getting the VE patch done.

I recommended diffing from mini-boot because it's the cleanest diff which still gives you the information you should need -- over time, as the branches have evolved, we've gotten progressively more general, so the changes between bootloaders has decreased between each new board's release.

I really am sorry that this is the state of affairs. All of these branches really need to be replaced with a single one where the appropriate header gets included for the board you're compiling for, just like libmaple. It just hasn't gotten done mostly out of inertia and lack of developer time.

In any case, please do keep us posted as you go.

Posted 4 years ago #
corguy
Member

Thanks for the tip, using the mini cut the diffs in half.

If you would like some help I'd be willing to take a shot at taking a
unified approach to adding support for the VET6. I've looked at the diffs
and I think I could do it as easy as hacking in support for the VET6. Using the same type of scheme as libmaple BOARD_maple_native, BOARD_maple_mini, etc seems to be workable. Let me know your thoughts as I have spent a sum of about 20 minutes looking at the code.

Posted 4 years ago #
mbolivar
LeafLabs

That would be awesome! Thanks for the offer to help!

I agree that libmaple's scheme should work fine here as well. The only "gotcha" I can think of is that the same libmaple style of different linker scripts for the medium- and high-density chips also needs to get ported over.

Posted 4 years ago #
corguy
Member

Sure thing, glad to do what I can.

I used your instructions and made all the modifications to libmaple today to support
the VET6 MCU and my board. I did not find anything of note that you did not cover. It
would have helped me to sit down first and list all my pins and what they are used
for, there was a lot of going back and forth and the whole process took longer than
it should have. But in the end I was able to compile libmaple for my VET6 board... now if I just had some hardware to run it on.

I'll probably take a look at the USB code next week at the office were I have multiple monitors to work with. Thanks again for your help, saved me a ton of time!

Posted 4 years ago #
mbolivar
LeafLabs

Glad to hear that everything went well.

By the way, the USB code is about to change pretty drastically. Today while you were adding VET6, I was rebasing a bunch of USB changes I've been making to the top of the tree. These will get merged in as soon as I've tested them out on OS X and Windows:

https://github.com/mbolivar/libmaple/tree/usb-touchups2

The new version isn't perfect, but notably, the CDC ACM API got ripped out into its own file, so if you want to e.g. use the USB peripheral for HID, you can add that in without stepping all over our stuff. The new stuff mostly follows the current libmaple styles and conventions, so it should be more readable than the old stuff as well.

Edit: In particular, this commit will affect you:

https://github.com/mbolivar/libmaple/commit/970d11c9e2c6664701230c60ea3e9e09407abd86

Posted 4 years ago #
corguy
Member

I may hold off on doing the bootloader mods then, I won't need the bootloader for several weeks anyway while I get the first board running.

What are the chances of getting the VET6 mods merged into the main code or am I "forked" forever?

Posted 4 years ago #
mbolivar
LeafLabs

Chances are good. Just send us a pull request on GitHub. Please read the docs on contributing to libmaple first:

http://leaflabs.com/docs/libmaple/contributing.html

Reading that will help save us both some time, since e.g. we only accept signed-off pull requests when they touch libmaple or wirish.

You can use git rebase -i to reword existing commit messages; git help rebase for more info.

Posted 4 years ago #
corguy
Member

Do you have a naming scheme or standard for naming "foreign"(non-maple) boards. I used maple_ as a prefix to my board name and in hind sight I thought that might not be good. It's not a big deal now but it might be when you have tens or hundreds of foreign boards and keeping track of them could become a problem. That is assuming you want all of them in the main code base.

What about something like (company or user or lastname) + MCU + version. So CORGUY_VET6_V000 would be mine. The Olimex (if it has not been merged in) could become OLIMEX-TORFBOLT_RBT6_V000. The ST discovery could be ST-ANTON_F100RB_V000. Seems like now would be a good time to give all that some thought.

I'm not going to issue a pull request until things are running well on the VET6 anyway.

Posted 4 years ago #
mbolivar
LeafLabs

coming up with a good naming scheme now does seem like a good idea.

something like manufacturer_boardname[_version] seems like a reasonable starting point. i'm not sure about the the user being part of the name. e.g. torfbolt is the maintainer of the new olimex board support (which just merged), so "torfbolt" (or "David Kiliani") should go into a MAINTAINERS file or something, rather than the name of the board, so that there's a handoff procedure if he ever decides to stop working on it.

as for version, i'd rather make that optional. i'm leery of too many versions of a board getting in and cluttering everything up. for instance, we don't keep the board files for our prototypes in libmaple.

in a related matter, there should be a way to provide support for a board just by defining the right functions and data structures, in the same way you get newlib syscall support just by defining the right stubs. my idea for doing this is here:

https://github.com/leaflabs/libmaple/blob/1873871aeaacad66d9c8b06211c7b32aaea5c829/wirish/boards.h#L141

we could just remove the warning altogether, and replace it with a #include "custom_board.h" or something (or just remove it altogether and let people make a custom header that does the right thing before including wirish.h). this would let people manage their own boards without modifying the libmaple source code, which is nice during development and allows people to distribute support for a board as just a pair of board files (assuming libmaple already supports the MCU).

thoughts?

Posted 4 years ago #
gbulmer
Moderator

I would like the ability to define new boards easily.
I'd be happy with
#include "custom_board.h"
while developing prototypes.
Is their an easy way to add to a 'Boards' menu?
I am thinking of something as trivial as name value pairs.
something like: board-name to be displayed in the menu, and custom-header-filename to be #included in source,
e.g. "Orone" ",,/Orone/orone.h"

Posted 4 years ago #
mbolivar
LeafLabs

There's nothing that easy yet for adding to the Boards menu, but it's a good idea, and shouldn't be too hard to implement. We've got some reasonably big news upcoming on the IDE front, so I won't commit to implementing that quite yet, but a mechanism like that for adding new boards easily is definitely a nice feature that we should add.

Posted 4 years ago #

RSS feed for this topic

« Previous 12

Reply

You must log in to post.