New board, same chip

[palmerr23]

Avik,

There's been a lot of fun tying down specs for what's becoming commonly known as the Black F407VET6 board across the various STM32 Arduino cores - the Maple-based one that Roger has been looking after, the new STM32DUINO (Freceric Pillon) and DanielEff's GenericSTM32.

While I've successfully tested many functions with koduino, there are a few port assignments mandated by onboard hardware.

I'd like to generate a variant for koduino and have already made some solid progress.

A few questions:

1. Are you open to specific board variants - only different in pin configs? I get the feel that your main focus for now is on chip-level variations.

2. Have you done away with Arduino-style pin numbering altogether? (That is being able to use something that equates to a board header pin as well as the PortPin notation) Variant_codegen.py seems to always output data in alpha-numeric order, no matter what order the data is in. Maybe I've missed something in the pin_map.csv file layout.

Thanks in anticipation.

Richard

[avikde]

Hi Richard,

1. I'm certainly open to variants for specific boards (though, like you say, the total number could get pretty big eventually). Another option that may work (if it's a matter of initial configuration) is to create a submenu that selects the pin setup (e.g. Tools -> Board -> F407, Tools -> Pin Setup -> Black F407VET6 in the IDE), and that could simply set a preprocessor variable that variant.cpp uses. For example, I use a similar menu to set to clock speed on the F303 (in case I want to overclock)--that option is read by system_stm32f30x.c
2. I typically use the pin names in the datasheet (e.g. PA3) since I find myself often needing to refer to which pins can do what from the datasheet. However, these are all defined as a uint8_t, so if you prefer, you could use "3" instead of "PA3" (using the F303 variant as an example). variant_codegen actually takes as input a spreadsheet that looks like this (so you can certainly change the order around!)
   

Thanks for your interest! The "f40_41x" variant (which I used for the F405) may or may not be useful for the F407.

[palmerr23]

Avik,

Thanks.

I'll follow the easy path for now and stay with a whole new variant. The menu idea sounds like a good way to go in the future.

Once I've got most things working (SDIO,, the Winbond flash chip and the TFT interface will come a little later), I will create a pull request.

Richard

[palmerr23]

Avik,

Are you going to use the AF columns for more than simply timer functions in the future?

BTW: In the create a variant instructions, it would be worth adding that you have to edit the variant name in variant_codegen.py

It took me a couple of goes, before I realised I was compiling code for another variant ('f446').

Also, as you're suggesting the f40_41x as a demo, it might be worth moving the ' "Teensy" Pin' column out of the way in that pin_map.csv file.

All going well, now I've worked out the magic!

Richard

[palmerr23]

Avik,

I've uploaded the current version of my Black VET6 variant to my repo https://github.com/palmerr23/BlackVET6_Koduino

I've been working from Windows, so haven't recompiled the libraries yet (much easier on Linux!)
spl.a has been borrowed from the F446 variant.

I'm starting to work on the koduino ADC code for it, now that I've got most ADC functions working for the new "CUBE" code https://github.com/stm32duino/Arduino_Core_STM32F4.

Which chip did you test the original ADC.c code with?

Some of the defines look chip specific, for instance the following in stm32f4xx_adc.h are quite different from those for F407:

#define ADC_ExternalTrigConv_T1_CC1                ((uint32_t)0x00000000)
#define ADC_ExternalTrigConv_T1_CC2                ((uint32_t)0x01000000)
#define ADC_ExternalTrigConv_T1_CC3                ((uint32_t)0x02000000)
#define ADC_ExternalTrigConv_T2_CC2                ((uint32_t)0x03000000)
#define ADC_ExternalTrigConv_T2_CC3                ((uint32_t)0x04000000)
...

If I know which chip you started with, it will be easier to insert the conditional code to handle others.

Richard

[avikde]

Hi Richard,
I didn't write those files, those are from the F4 standard peripheral libraries, v1.8.0 http://www.st.com/en/embedded-software/stsw-stm32065.html, which should have F407 compatibility. Where did you get the values for F407 that you're comparing to? I've used the same SPL files for an F405 and F446 (those are the only ones I have used from the F4 series).

[palmerr23]

Hi Avik,
I just realised, when checking my facts in the STM F4x5/7/9 Reference Manual, that I was reading the JEXTSEL list rather than the EXTSEL one for CR2 values!

The EXTSEL vaIues match exactly with those in your libraries. Problem solved. :-)

Once I get the first test working, the rest (borrowed from STM32Cube_FW_F4_V1.16.0\Projects\STM324x9I_EVAL\Examples\ADC) should follow quickly, if my experience with getting them working for the new STM32DUINO/F4 code is any guide.

Richard