Add Sparky V1 Variant, modify boards.txt

[geosmall]

Summary

Pull Request to add Sparky V1 Variant. First documented here http://www.stm32duino.com/viewtopic.php?f=49&t=4542

This PR fixes/implements the following bugs/features

• [ x] Feature 1 - Add Sparky V1 Flight Controller board as new Variant.

Motivation for making this change:

I would like to propose a new STM core variant based on Sparky V1 Flight Controller. This would enable support for open source drone flight controller development and sharing. It would also enabledevelopment of higher performance open source UAVCAN nodes for drone use.

Reasons for targeting this design:

• Open source design with published schematic
• Based on STM32F303CC processor with FPU
• Available for purchase
• Integrated CAN transceiver

Validation:

See http://www.stm32duino.com/viewtopic.php?p=53147#p53147

[fpistm]

Hi @geosmall
thanks for this variant.
Please, Could you rebase it on top of the master.
Maybe a new more generic name could be used in the boards.txt: "Flight Controllers" ?

[geosmall]

Hi @fpistm
I've resolved conflict in boards.txt, Travis CI shows a check fail I am not sure how to resolve (I must admit to being a GitHub novice).

There are so many STM32 based flight controllers out there, I targeted this specific board as it is open source and documented so I would propose specific nomenclature to avoid confusion.

[fpistm]

Thanks @geosmall
CI build is failed because it's build under Linux which is case sensitive.
In boards.txt the variant is not correct this should be: SPARKY_F303CC

[fpistm]

Thanks. See my comments.

[geosmall]

Hi @fpistm ,

I've updated to the requested changes, now appear to be failing an AStyle check, unsure how to best resolve.

Thanks,
George

[fpistm]

Thanks @geosmall
About astyle check, you have to use astyle to format your code.
The astyle config used for the core is available here:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/CI/astyle/.astylerc

Simply install astyle:
https://sourceforge.net/projects/astyle/files/
then launch it like this:
astyle --project=.astylerc <your target dir/file>
or use the python script I provide to ease astyle usage on git root repo:
python CI/astyle/astyle.py
note you can use -p option to specify astyle install dir.

[fpistm]

Still duplicated pins to comment and apply astyle formatting

[fpistm]

If this can help, I've rebased and format your PR:
https://github.com/fpistm/Arduino_Core_STM32/tree/pr-432

Note: I do not comment duplicated pins line.

[BennehBoy]

Haha, I'm amused that Astyle is catching you out also @fpistm

[fpistm]

Haha, I'm amused that Astyle is catching you out also @fpistm

I know this will require some support/question but I think is a necessary evil 😈

[geosmall]

Ok I am a bit familiar with AStyle and will work to directions above. Thanks for the help :)

On peripheral pins, let me make sure I'm thinking it correctly:

Some exposed board pins may be used for more than one function when considered across multiple sketches. For example PA2 might be used as analog input in one sketch (using ADC1_IN3), as PWM input measurement pin in another sketch (using TIM2_CH3), and as hardware USART TX output in a third sketch (using USART2_TX). So it would be expected for PA2 to have multiple uncommented options in PeripheralPins.c. Does this sound correct? This is why I have some pins with duplicate uncommented out definition lines.

Does this sound correct?

Thanks,
George

[fpistm]

Across all array this is not a problem. One pins can have several feature (I2C, UART, SPI, TIM,...)
When I talk about duplicated pins, I talk about the same pin for a dedicated features.
Ex: PA_7 for Timer:

  {PA_7,  TIM1,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_TIM1, 1, 1)}, // TIM1_CH1N
  {PA_7,  TIM3,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM3, 2, 0)}, // TIM3_CH2
  {PA_7,  TIM8,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_TIM8, 1, 1)}, // TIM8_CH1N
  {PA_7,  TIM17,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM17, 1, 0)}, // TIM17_CH1

The core will search if PA7 has TIM capabilities then it will get the first one defined. PA7 with TIM1. All other will be ignored but consume memory space for nothing.
By commenting, you are able to choose which TIM use with PA7, ex to use TIM8

  //{PA_7,  TIM1,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_TIM1, 1, 1)}, // TIM1_CH1N
  //{PA_7,  TIM3,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM3, 2, 0)}, // TIM3_CH2
  {PA_7,  TIM8,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_TIM8, 1, 1)}, // TIM8_CH1N
  //{PA_7,  TIM17,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM17, 1, 0)}, // TIM17_CH1

[geosmall]

Ah, ok thanks will fix that.

[geosmall]

I believe I have completed the requested changes and successfully passed CI checks.

[fpistm]

Still 2 lines changed while they should not.
Else it is ok.

[fpistm]

Sorry @geosmall
I would like to merge and view 2 small issues which required to be fixed.
Thanks in advance.

[geosmall]

Thanks for merging @fpistm , and thanks for the patience (first GitHub PR :)

[fpistm]

Welcome.
All contributions are welcome. This is a community project ;)