As I wrote above, when you scroll down you see the VB CPU on the board.
You better also buy a 12MHz oscilator to replace the one on the dev board after the first things work, so it is like on your controller
Using Maple IDE / lib for unsupported board
(35 posts) (4 voices)-
fma
MemberYes, already planned ;o)
Ok, I hacked the maple-ide source to add support for this dev board¹. Compilation works fine, but I will have to test a lot of things before I can be sure that everything is working fine...
Is there a way to automate such tests, or, at least, a method?
¹ except for the 12MHz clock. Where should I make changes?
Posted 2 years ago # -
gbulmer
Moderatorfma - "About medium vs high density, I think that the VBT6 is a high density, from maple point of view...."
The "maple point of view" is the VBT6 is a medium density device. ala42 is explaining that the VBT6 is in exactly the same family of parts as the Maples RBT6.
The device is classified by ST Micro, its manufacturer as a "Medium-density performance line" device, and has exactly the same peripherals as the STM32F103RB on a Maple.
The Maple Native carries a STM32F103ZE which is classified by ST Micro as a "High-density performance line" device. It carries more peripherals; more timers, more USART, and more SPI (which have more features than the Maple's SPI) and unique peripherals such as SDIO.
This page at ST lets you navigate the products by clicking on the part number:
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031/LN1565
Then you can get the appropriate datasheets and programming manualPosted 2 years ago # -
gbulmer
Moderatorfma - An initial test pass of changes might be to test every gpio pin.
You could write a for loop to put every pin to output. Then a loop to set every pin high, delay for, say, 100 mseconds, and set them all low. Then you could use an LED and resistor to observe each one 'blink' the LED.
That might take less than 10 minutes, and would indicate that the GPIO code changes have control of every GPIO pin, which might be a good start.
Posted 2 years ago # -
gbulmer
Moderatorfma - IMHO, it is frustratingly easy to make that mistake. I hope you didn't waste too much time.
I have sent feedback to ST on that page today:
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031/LN1565suggesting they highlight the different families, and ideally show how they are different using a similar style to:
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031
but with the number of each peripheral too.If anyone has the energy, and thinks it might make a difference, please feedback too :-)
Posted 2 years ago # -
fma
MemberMmm, after verification, it appears that the STM32F103VB (LQFP100) chip has a GPIO E port.
But in Maple IDE, when using medium-density flag, I only get GPIO A to GPIO D...
Should I hack the the code where GPIO E is defined, and moved it to the medium-density part? Or is there a better way?
Posted 2 years ago # -
fma
MemberOne more question: how should I name this dev board in Maple-IDE?
It seems to be developed by LC STUDIO. As they have other boards, which may be added too in Maple-IDE, I would like to use a good naming convention, allowing extensions.
What do you suggest has brand/model names?
Posted 2 years ago # -
gbulmer
Moderatorfma - If you are planning on making it a properly supported board, I take back my suggestion of just moving the GPIO E definition.
I had assumed, because the thread is called "unsupported boards" you wanted to get things working first. My mistake, sorry.For a properly supported board, you'll need to create another pre-processor macro name to test (with #ifdef), and wrap your source code changes in that. So copy the GPIO E definition into that, don't just move it. You'll also need board files, etc.
IMHO, if the board is clearly marked "LC Studio" and a name, use those.
(Full disclosure: I am not a member of LeafLabs staff)
Posted 2 years ago # -
fma
MemberWell, my first goal is to have something working, but if I can do something clean, which can be used by others, or, better, merged in Maple official IDE, why not?
What pre-processor macro name are you talking about? Something like MCU_xxx ? Or the STM32_MEDIUM/HIGH_xxx macro? I already added a new MCU_xxx var...
I'm not sure to understand what you mean by "copy the GPIO E definition into that". Do you suggest to add other gpio.xx files, to add missing definitions (there are also things to do in rcc.h), or to patch these files, and use the new STM32_xxx macro (something between MEDIUM and HIGH)?
It looks like there are a many place to change/patch things. Maybe the code would need some refactoring to allow a better integration of new boards/procs (in fact, it is already nicely written, and would only need a few modifications. But I think it should be done by main dev. team...).
Posted 2 years ago #
Reply »
You must log in to post.