https://stackoverflow.com/questions/...32-programming

There are two common strategies that I'm aware of:

1.) Make sure you have a good SW component architecture, including a well-defined interface towards HAL/driver components that only take care of access to HW port registers. Devise a separate verification method for low-level HW-access components, which avoids unit-testing tooling. To establish such a verification concept, make sure to:

• avoid any processing logic in HAL/driver components as far as possible.
• avoid any HW dependencies and any non-portable code in the remaining parts of your SW.

Now you can take the HW-free parts of your code to some PC architecture (x86 or whatever) and do all your unit testing with conventional UT tools. Of course, your UT will miss any errors that are related to the differences between STM32 and your PC. Note that usually this is not too big a problem because HW-specific features have been "pushed" into the HAL, and in the other parts of the code, you are only looking for logical errors that have nothing to do with the HW/architecture.

I know that this part of the answer talks round your subject instead of providing the solution you were asking for. Nevertheless, this is what many projects do.

2.) Develop yourself an STM32 integration for your unit-testing framework, or buy a commercial unit-testing tool that supports your HW architecture. STM32 is very popular nowadays, so many commercial tools (Tessy, VectorCast...Continue Reading

OpenPilot/LibrePilot. Still one of the cleanest flight controller architectures out there...

LibrePilot System Architecture
Eric Price
June 30, 2017

Abstract

LibrePilot is an Open Source Avionics Solution for Unmanned Aerial Vehicles (UAV), Model Aircraft and other robots.
It implements sensor fusion as well as fully configurable Steering, Control, Guidance and autonomous Navigation and runs on a fight controller circuit board. It interfaces with remote control receivers, GPS, IMU, Barometer and other sensors and controls a number of actuators such as brushless engines, navigation lights, buzzers, servos, etc...

Arduino 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 enable development of higher performance open source UAVCAN nodes for drone use (https://www.rcgroups.com/forums/show...)-step-by-step).

Reasons for targeting this design:

• Open source design with published schematic

• Based on STM32F303CC processor with FPU

• Available for purchase

• Integrated CAN transceiver

I've forked the upstream Arduino STM Core repo (https://github.com/stm32duino/Arduino_Core_STM32), then checked out tag 1.4.0, creating a branch named mgeo_variants. I added the folder for variant SPARKY_F303CC and modified boards.txt and platform.txt to add the variant.

I also added a second variant NUCLEO-F405RG, not relevant to this post but found in the branch.

George

Github repo (forked, checkout tag 1.4.0, branch = mgeo_variants)
https://github.com/geosmall/Arduino_...rky_V1_variant

Variant folder from repo branch:
https://github.com/geosmall/Arduino_.../SPARKY_F303CC

Board Info:
https://github.com/TauLabs/TauLabs/wiki/Sparky

Schematic:
https://github.com/TauLabs/TauLabs/b...parky_v1.0.pdf

Availability:
https://www.readytoflyquads.com/spar...ght-controller

I'm trying to put together a minimum Input Capture hardware timer example using Interrupts to measure an input pulse stream (single pulse stream for now, with 6 total inputs to eventually be captured for my intended application.

I'll document my efforts here in this thread.

George

Background
I'm hoping to gain enough understanding of this core and STM32 timer control to port this flight controller application (http://www.brokking.net/ymfc-32_main.html). This was originally developed around a slightly earlier version of Roger's libmaple based STM32duino core (http://www.brokking.net/YMFC-32_downloads.html). It makes use some lower level bit manipulation of TIM2-4 for interrupt based input capture of pulse inputs as well as hardware PWM control of outputs. The application uses TIM2 and TIM3 (input capture of pilot commands from an RC receiver) and also TIM4 (PWM outputs to quadcopter motor controllers).

Typical input capture interrupt handler (toggles the input capture edge direction within interrupt to get enough input channels (6 pulse capture inputs are needed):
...Continue Reading

Over the past few weeks I've been doing a good bit of hardware debugging on a Nucleo-F103RB and also F103C8 bluepill. I've tried various debug configurations from Eclipse/OpenOCD/ST-Link, Eclipse/BMP and BMP/GDB command line with mixed results. Lately I've been working with Segger J-Link/Ozone/RTT and have been pretty happy with this setup and my productivity.

For Nucleo boards Segger provides a utility to (reversibly) reprogram the on-board ST-Link into a J-Link OB (https://www.segger.com/products/debu...link-on-board/). It does come with some licensing restrictions but has been working for my hobby dev use, and is free. For the bluepill I also have a J-Link EDU I bought some time ago, it works fine as well. This setup has been working out well for hardware timer debugging work I've been doing with STM Core (http://www.stm32duino.com/viewtopic.php?f=48&t=4186). I find that single stepping through the startup code and watching the function calls and register status helps me quickly understand what new-to-me code is doing behind the scenes.

The Nucleo J-Link presents a debug hardware serial path that lets you receive debug log info over a hardware serial port in addition to the Ozone debugger info windows. This is very handy but means you give up a hardware serial port. There is an additional (and better) alternative that Segger provides in RTT, or Real Time Transfer (https://www.segger.com/products/debu...time-transfer/). RTT provides very high transfer...Continue Reading

The application I'm working toward porting samples a few analog channels at a 100-1000Hz or so. After reading this post in this thread viewtopic.php?p=47977#p47977 I've been investigating use of the LL library to sample ADC channels. I've read through the examples provided in the F1 CubeMX package and ported a couple of examples to this core. Not too bad once you get your head around it. The code attached below appears to be working as expected. I'm including these examples here in case others have the same interest.

Also, LED output is also managed with LL calls, samples are triggered from blue user button firing an EXTI interrupt callback in user code via attachInterrupt(). Examples were tested on a NUCLEO-F103RB with the analog pin floating. Core version tested at v1.4.0.

Example ADC_test_LL.ino, uses polling for ADC conversion complete:

...Continue Reading

From STM32F405xx / STM32F407xx datasheet (https://www.st.com/resource/en/datasheet/dm00037051.pdf):

The STM32F405xx and STM32F407xx devices maintain a close compatibility with the whole STM32F10xxx family. All functional pins are pin-to-pin compatible. The STM32F405xx and STM32F407xx, however, are not drop-in replacements for the STM32F10xxx devices: the two families do not have the same power scheme, and so their power pins are different. Nonetheless, transition from the STM32F10xxx to the STM32F40xxx family remains simple as only a few pins are impacted.

From UM1724 User manual, STM32 Nucleo-64 boards (https://www.st.com/content/ccc/resou...DM00105823.pdf):

Remove SB33, SP38 and populate C22, C25 with 2.2uF low ESR 1206 SMD ceramic caps.

Work in progress

I had some trouble locating the original PDF version of the Hitec Flash 4/5 Transmitter manual so I am posting it here for others to download. You can find a copy on the Hitec web site but it is a poor quality scanned version.