Add BLACK 407ZET6 & ZGT6 Support

[BennehBoy]

Created without access to these 2 boards, will need testing.

Areas to check - Arduino pin assignments, ADC mappings

Test compiled successfully, and regression compilation/upload against BLACK 407VET6 is successful

I have kept the original 'physical layout view' intact within the Variant files, this means a slightly larger variant but it's done in the spirit of the original variant.

See Issue #393

[uzi18]

will try to test this stuff

[BennehBoy]

It would seem that at least 1 person is having no luck with this variant, I've asked for help with testing on the stm32duino.com forum. Fingers crossed until my boards ship - even if only to confirm that it is indeed non fucntional.

[uzi18]

@BennehBoy @fpistm just thinking about step back and compile with master/1.4.0 for test, 407VG should work with blink.ino for PF9/10 directly?

[BennehBoy]

Sure, why not.

EDIT... hang on you mean test blink on a VG board, or compile as VG and load to ZE? The latter won't work I think.

[uzi18]

My bad, have flashed with dfu-util wrong file (hex) with bin everything works as expected.
What is tested:

• LEDs D1/D2 works ok but have wrong names (D2/D3)
• Buttons K0,K1 works ok
• Button WK_UP does not work also when used as PA0 directly - should work also as standard button?
• Serial/Serial1 (J5) works ok
• SPI on custom pins (PA4-PA7) + W5500 works ok

In my opinion chips/boards names in menu need to be changed for black_f407xx a little (confusion), but this will check tomorrow.
So victory, thanks to @BennehBoy :)

@fpistm how to use also another spi: SpiClass SPI2?

[BennehBoy]

Ah, excellent.

You'll need to enable the pulldown resistor on K_UP to use it as a button:

pinMode (PA0, INPUT_PULLDOWN); //Button K_UP

I'll fix the LED refs later.

[fpistm]

Nice to see this is work.
To use another SPI, simply define it with the pins you want.
Hereafter for the SPI2:
SPIClass mySPI2(PB15, PB14, PB13);
Note that you can't use SPI2 as name as it is the SPI peripheral name used by the CMSIS.

About KUP, it seems it is not Pull down per defaut. --> edit @BennehBoy was too fast for me :)

[BennehBoy]

@uzi18 please could you confirm which LED blinks when LED_BUILTIN is used, is it the one labelled D1 or D2 on the board?

[uzi18]

indeed WK_UP is connected to +3v3, so pulldown is needed
Now button works, but reference with SYS_WKUP1 doesn't work.

LED_BUILTIN flashes with Led D2 on board.

please rename BTN_K_UP -> BTN_WK_UP

@BennehBoy something else to test?

about menu above:

• flash mem size should be like xE xG eg.: "1024k (xG)"
• boards like: Black F407Zx, Black F407Vx
  or explicity all 4 boards in menu line "board part number"

What do You think about @BennehBoy @fpistm ?

[BennehBoy]

Regarding the flash naming, the current solution is just a temp hackup until the ld preprocessor PR is merged - #404

After that it's much simpler.

[uzi18]

@BennehBoy something else need's to be tested?

[BennehBoy]

i2c if you are able
analogRead
SDIO

@fpistm - any thoughts on a test suite?

[fpistm]

Hi guys,

For the menu, when the ld preprocess will be available this will be the same question about it.
2 choices, having

• 2 menu (1 for each board) then no flash submenu
• 1 menu wit flash submenu
  maybe the best should be 2 menu to avoid any confusion.

About test plan, this is the minimal set I perform:

• 01.Basics
    * Blink
    * DigitalReadSerial 
  • AnalogReadSerial
• 02.Digital
  • tone melody
• EEPROM
    * put
    * get
    * clear
    * get
• TFT / Arduino
    * TFTBitmapLogo
• SD  
    * CardInfo
    * ReadWrite
• extEEPROM (using CI shield https://github.com/ARMmbed/mbed-HDK/tree/master/Production%20Design%20Projects/ARM-mbed/CITestShield)
    * eepromTest
    * eepromReadWrite
• LM75A Arduino Library (using CI shield)
    * BasicUsage
    * LibraryTest
• Firmata
    * Standard Firmata  
• GitHub Examples
    * Tests_basic_functions
    * SerialLoop
  • RTC
• Tools menu
   * Serial Interface
   * Upload method

• some tests with STM32duino libraries:
  STM32LowPower
  STM32RTC
  STM32RTC

And depending of the board, I test mems or peripheral available (HTS221, SDCard slot on SDIO, Ethernet,...)

[BennehBoy]

I think it might be useful to have some further details on some of those tests.

For those that are not standard examples or tools for example:

• sample sketches
• hardware details (eg which TFT & library)
• bare minimum tests against each scenario

Clearly this is non trivial if it's "in your head", but if you already have something to hand...

[fpistm]

This is only an example of which som I use as you request me.
Goal is to test that all basic features are up and running (I2C, SPI, Serial, Timer, ...)

All listed above is on Arduino menu except:
extEEPROM, LM75A and STM32Example which need to install them thanks library manager.

• hardware details (eg which TFT & library)

The TFT library from Arduino even if retired using TFT shield from Arduino. Anyway not all have this shield. goal of this test is to ensure SPI works fine as it use 2 SPI component (TFT and SD).

• bare minimum tests against each scenario

I guess you talks about what do and expected result. As many sketches are Arduino standard this is often well documented. Anyway, using Analog example I connect the pin to ground then to Vcc and check those limits values are ok or using a potentiometer.

[BennehBoy]

OK, fair enough 👍

[uzi18]

I could try to test timer (how?), i2c, and maybe analog.

[fpistm]

To test timer, I use Tone Melody sketch with a small beeper and also fading on a PWM pins.

I will share in coming month test bench scenarii when my automatic tests bench will be deployed.

[uzi18]

@fpistm Are there any api examples for timers?
Need to create output signal for phase angle control, it is must be synced with zero crossing detector, signal is PWM freq = 100Hz 0-100%
And also some periodic timers for callbacks.

[fpistm]

Currently, timer usage is very limited to fit Arduino basic API. An HardwareTimer class is on the pipe to provide full Timer usage.
Anyway you can use HAL or LL to configure it.
analogWrite() on a pin with PWM capabilities will generate a 1000Hz freq.

[BennehBoy]

@fpistm couple of questions...

Has the PeripheralPins.c conflict arisen because 388 was merged?

I have another variant I'd like to submit a PR for - but of course I was silly and made this PR against my master branch - what can I do, delete my fork, refork on base, create a branch, commit to it, and compare & pull? If so, will this commentary be lost? Is there a better option?

[uzi18]

nothing will be lost, you can always refer to this PR #402 just save link in bookmark

[uzi18]

@BennehBoy you need to pull from master, resolve conflicts and commit changes needed here.

[uzi18]

I see PeripherialPins.c did not change at all, just formatting of file.

[uzi18]

@BennehBoy try git merge -Xignore-space-change

[BennehBoy]

I think that only @fpistm can merge.

I still need to figure out what to do with my fork, I really should have created a branch for this PR.

[fpistm]

@BennehBoy, hereafter a short notice of how I will handle your case:
1 - Add official repo with stm32duino as alias (you can change alias name ;))
git remote add stm32duino https://github.com/stm32duino/Arduino_Core_STM32.git

Then you could list the remote of your local git repo:
git remote -v

Here result on my side, as you can see I have 3 remote. I guess you should have origin instead of ben here:

ben https://github.com/BennehBoy/Arduino_Core_STM32.git (fetch)
ben https://github.com/BennehBoy/Arduino_Core_STM32.git (push)
fpistm https://github.com/fpistm/Arduino_Core_STM32.git (fetch)
fpistm https://github.com/fpistm/Arduino_Core_STM32.git (push)
stm32duino https://github.com/stm32duino/Arduino_Core_STM32.git (fetch)
stm32duino https://github.com/stm32duino/Arduino_Core_STM32.git (push)

2 - Fetch it:
git fetch stm32duino

Assuming you are checkout on you master branch of your repo (fork of stm32duino).
3 - Create a local branch on your master to have a local reference on it.
git checkout -b PR402
You can add a second for saving:
git checkout -b PR402_sav
Go back to master:
git checkout master

4 - Reset your local master branch on top of the remotes/stm32duino/master

git reset --hard remotes/stm32duino/master
git checkout PR402
git rebase master

Then you will have an issue on variants/BLACK_F407VE/PeripheralPins.c
Fix it then:

git add variants/BLACK_F407VE/PeripheralPins.c
git rebase --continue

Then you will have again an issue on next commit, so do the same after do the fix:

git add variants/BLACK_F407VE/PeripheralPins.c
git rebase --continue

Well now your master is rebased on top of stm32duino/master.
So force push of your local master on your repo (assuming your remote is origin)
git push -f origin master

That all folks ;)

Then I will merge this one so you will be no more annoyed with PR with master.
Will merge only if you are confident, I will rework it with preproc ld later when I will be confident with it.

[BennehBoy]

@fpistm, thanks for the instructions - one day I may actually be able to drive this github thing 🤣

I'll make the changes tomorrow, it's late now and it's been a busy day.

[uzi18]

In my opinion it would be better to merge it by @fpistm
I think @BennehBoy did all changes in his master branch, but he can "git stash" all uncomitted changes so it will be moved to "clipboard" and can be pasted with "git stash apply" after merge from master

[fpistm]

This is only an example how to manage this. Creating a new PR is also possible then we will close this one.
There are several way to use git. Goal is to have those new variants that's all. ;)

[BennehBoy]

@fpistm, if you could merge this one now I think that would probably save us some time - I'm sure to mess up those instructions :)

I'll then rebase my fork and add the FK407M1 variant as a new branch.

Any required fixes on this variant can be dealt with in a new PR.

[uzi18]

thx @fpistm
interesting part: b14f4cc?w=1#diff-1c8d4019b583278860f5a7a2f09f58ecL1

[fpistm]

Fix #393