I understand what you mean. This was also already my idea. This is how it looks like now.
drv_time.c
Code: Select all
const timerHardware_t timerHardware[] = {
{ TIM2, GPIOA, Pin_0, TIM_Channel_1, TIM2_IRQn, 0, }, // PWM1
{ TIM2, GPIOA, Pin_1, TIM_Channel_2, TIM2_IRQn, 0, }, // PWM2
{ TIM2, GPIOA, Pin_2, TIM_Channel_3, TIM2_IRQn, 0, }, // PWM3
{ TIM2, GPIOA, Pin_3, TIM_Channel_4, TIM2_IRQn, 0, }, // PWM4
{ TIM1, GPIOA, Pin_8, TIM_Channel_1, TIM1_CC_IRQn, 1, }, // PWM9
{ TIM1, GPIOA, Pin_11, TIM_Channel_4, TIM1_CC_IRQn, 1, }, // PWM10
{ TIM3, GPIOA, Pin_6, TIM_Channel_1, TIM3_IRQn, 0, }, // PWM5
{ TIM3, GPIOA, Pin_7, TIM_Channel_2, TIM3_IRQn, 0, }, // PWM6
{ TIM4, GPIOB, Pin_8, TIM_Channel_3, TIM4_IRQn, 0, }, // PWM13
{ TIM4, GPIOB, Pin_9, TIM_Channel_4, TIM4_IRQn, 0, }, // PWM14
{ TIM3, GPIOB, Pin_0, TIM_Channel_3, TIM3_IRQn, 0, }, // PWM7
{ TIM3, GPIOB, Pin_1, TIM_Channel_4, TIM3_IRQn, 0, }, // PWM8
{ TIM4, GPIOB, Pin_6, TIM_Channel_1, TIM4_IRQn, 0, }, // PWM11
{ TIM4, GPIOB, Pin_7, TIM_Channel_2, TIM4_IRQn, 0, }, // PWM12
};
drv_pwm.c
Code: Select all
static const uint8_t multiPPM[] = {
PWM1 | TYPE_IP, // PPM input
PWM9 | TYPE_M, // Swap to servo if needed
PWM10 | TYPE_M, // Swap to servo if needed
PWM11 | TYPE_M,
PWM12 | TYPE_M,
// PWM13 | TYPE_M,
// PWM14 | TYPE_M,
// PWM5 | TYPE_M, // Swap to servo if needed
// PWM6 | TYPE_M, // Swap to servo if needed
// PWM7 | TYPE_M, // Swap to servo if needed
// PWM8 | TYPE_M, // Swap to servo if needed
0xFF
};
static const uint8_t multiPWM[] = {
PWM1 | TYPE_IW, // input #1
PWM2 | TYPE_IW,
PWM3 | TYPE_IW,
PWM4 | TYPE_IW,
// PWM5 | TYPE_IW,
// PWM6 | TYPE_IW,
// PWM7 | TYPE_IW,
// PWM8 | TYPE_IW, // input #8
PWM9 | TYPE_M, // motor #1 or servo #1 (swap to servo if needed)
PWM10 | TYPE_M, // motor #2 or servo #2 (swap to servo if needed)
PWM11 | TYPE_M, // motor #1 or #3
PWM12 | TYPE_M,
// PWM13 | TYPE_M,
// PWM14 | TYPE_M, // motor #4 or #6
0xFF
};
It’s generally working (did not check with motors yet) but only once after flashing. I was always able to communicate via the GUI and make setting changes. But it will not come up a second time after a reboot or power toggle. The behavior when shorting the boot pins it will start the code went away since a couple if builds. During that time I have verified the setting changes I have done also get stored in the eeprom after the reboot. Also verified the code a couple of time directly after flashing and after first run, reset and power toggle but the only modified area is the first kb of the eeprom area. Actually my actual test code is reduced to the bare minimum remove all unused sensors, SPI, Ledring, etc. But I have the same behavior with minimum changes also. Led1 is getting on in this case and the Led2 (baseflight Led1) is not start flashing after initialization. If I don’t reboot or power of the Firmware is running for hours connected to the GUI without issues.
My personal plans are to use this with an PPM receiver (Deltang RX31). This is already working in the AVR328 based micro quad I referenced more early in this tread. Should be connected to PA0. I may connect the receiver to see if this is actually also working. I need to change feature PPM as the default since restart is not working.
Reading the datasheet it’s also not recommended to drive a load with pins PC13, PC14, PC15. Only 3mA output for all 3 pins together. But the designers of the board have done this (but it works). Anyhow I also tried to disable LED’s completely but this also does not change my main problem. Reading the datasheet for and back but cannot see any additional interference with other pins yet which may cause this behavior.
In the meantime I also found out the STM Flash Loader demo will be also able to start the code directly after flashing if you check the related box.