@Paul_Atkin1, I’m on a non-AIO. From what I gleaned from the code, I need to set the BUZZ_PIN parameter because HAL_BUZZER_PIN isn’t defined (see AP_Notify.cpp line 138). Also, what do you think about making M5 and M6 the safety switch instead? The Holybro Pix32 GPS module I’m using has the safety switch and LED like the Here.
i did not play with safe switches as on my small models i do not need that.
AIO or non-AIO does not matter, the pinout and F7 spec is the same. look at my hwdef - i have 7 PWMs in there. you can of course redefine them as you see fit. it is the whole beauty of chibios customization.
again, for the buzzer - in this file
see this section:
buzzer
PD15 TIM4_CH4 TIM4 GPIO(77) ALARM
that`s it.
I’ll have to go back and look at the setup. I wired the buzzer to the usual +5 and Bz- pads. I need to see if you can repurpose T7 (UART7 TX) to be another PWM.
yes you can.
you wired buzzer correctly - my hwdef wil lplay it, as bz- pad is the pd15.
uart 7 tx is a PE8. you will need to see what timer you can use on it and experiment to find a combination that does not affect rest of the assignments.
to do it - you open this file -
and see what pe8 can be associated with:
“PE8:EVENTOUT” : 15,
“PE8:FMC_D5” : 12,
“PE8:QUADSPI_BK2_IO1” : 10,
“PE8:TIM1_CH1N” : 1,
“PE8:UART7_TX” : 8,
so, the only timer you get is the TIM1_CH1N"
current motors are on the
PB1 TIM1_CH3N TIM1 PWM(1) GPIO(50)
PE9 TIM1_CH1 TIM1 PWM(2) GPIO(51)
PE11 TIM1_CH2 TIM1 PWM(3) GPIO(52)
PB0 TIM3_CH3 TIM3 PWM(4) GPIO(53)
PC9 TIM3_CH4 TIM3 PWM(5) GPIO(54)
PA3 TIM5_CH4 TIM5 PWM(6) GPIO(55)
i think it will work fine.
PE8 TIM1_CH1N TIM1 PWM(8) if you need to add it as a 8th one.
at the end of the file you need to alter
define BOARD_PWM_COUNT_DEFAULT 8
should work. test it.
OK. Let me diff it and see how it goes.
i edited response above, i guess you already knew all that, but, just to make sure…
so, btw, what will create a conflict and will kill motors - is if you decide to use PE8 TIM1_CH1N TIM1 in the input role. that will create a conflict across whole set of TIM1 assignments.
that is why rcin is set as
PC7 TIM8_CH2 TIM8 RCININT FLOAT LOW
as it requires some pin on the timer that does not interfere with timers on motor`s PWMs. and, sort of, eats up a valuable RX pin from the USART6 that, ideally, would be better left alone as a fully functional universal USART. but, in practical reality - we use this pin for RCIN, and the TX of USART6 is set to push out frsky telemetry and this way it all works more or less adequate. but, probably, could have been done better, as we still have a useless LED pin, and some others.
OK. I moved past that. I’m looking at how to make use of the actual LED port. I know that WS2812 is not supported, and there is discussion as to why; no reason to repeat. However, that LED module from Matek has PWM in for simple control. I’m looking at that now.
That Matek 2812-BH module has an STM8S003F3 onboard with some sort of custom firmware. At some point, I wrote a Toshiba LED to WS2812 translator to run on an Arduino. May recode this module.
1 Like
I tried one of these I2C LED from Amazon. In bench testing it works on the Kakute F7 with 3.7 dev.
@Paul_Atkin1
I have BZ- wired to the BZ- pad on the buzzer module and +5/G wired too. Nothing. What should happen? Do I need to get the buzzer pin param?
hmm. that +5v only power up from the lipo power. if you used my hwdef i posted, upon booting up it should sing usual arducopter tunes. also, when you power up model - in the bootloader, it should whistle non stop as bootloader is not altered to bring up that pin`s state. if you get no audio at all - may be you soldered buzzer in the opposite way?
when booting process is completed and arducopter code runs, both pins should be at 5v level. are they?
buzzer`s ‘+’ leg should be sitting on the 5V pin. not on the BZ- pin.
frankly, not sure what to think. review your hwdef.
buzzer
PD15 TIM4_CH4 TIM4 GPIO(77) ALARM
#PD15 BUZZER OUTPUT GPIO(80) LOW
#define HAL_BUZZER_PIN 80
#define HAL_BUZZER_ON 1
#define HAL_BUZZER_OFF 0
make sure the 'hal_buzzer_pin and etc old buzzer lines are commented out.
pos or neg voltage been which pins? i’m showing 11v with the neg test lead on bz- and pos on the + bat lead.
11v? 
ok, i am not sure how is it possible.
start with measuring between ground and +5v and BZ-. what does it show?
on non-AIO it goes as: M5 M6 G SDA SCL Buz- 5V LED G
you put buzzer with ‘+’ leg into 5V pin, other (G) leg on the Buz-. it cannot have 11v there as it is not getting it, the FC. so i am not sure what is it. those both pins should be at same +5V level if FC is alive. when it needs to produce a sound, the voltage on the Buz- pin drops down. holding multimeter`s positive wire on the Buz- durig bootup should show how voltage fluctuates when sounds supposed to be played.
unless output circuit of the BZ- pin got fried. i got it fried on the the kakute f7 i damaged when i powered up digital signal analyzer sensor from other power source than kakute, by mistake. it burned down one usart and this buzzer cascade. rest of the chip was somehow left intact. but i do not think your FC would be damaged if you did not do anything extreme to it.
not sure where that was coming from. this module from Matek does not function
http://www.mateksys.com/?portfolio=dbuz5v
but if I wire in a loose buzzer between +5 and BZ- and yep, it works. What is different between the way Betaflight drives a buzzer and Ardupilot? That must be it. That Matek LED module has the same controller.
i see a key mention here:
“Buzzers that need an analog or PWM signal do not work and will make clicking noises or no sound at all.”
Which makes sense now. Betaflight is simply on/off with the buzzer where Ardupilot is PWM. That would explain why Matek’s buzzers don’t work. The larger led/buzzer module or the standalone buzzer module have the STM8S003 MCU which must be looking for a high/low and now PWM.
ok, now i get it. the buzzer i spoke of is this:
it is a package with large and small ones. small ones work on 5V level only. larger ones can be set on the PWM pin that goes from 0 to +3.4V and G leg goes to G. it is what i have on the KakuteF7Fix hwdef - as that FC got its BZ- cascade fried.
so, if you need a PWM… BZ- pin will not produce it. LED pin can be set this way, or M5/M6 pins. just alter their definitions from a regular PWM into ALARM.
Hello,
In an attempt to build an Arcucopter with ChibiOS on a Kakute F7 board, I encounter two issues I’m stuck with.
First issue, the external compass is not seen by Ardupilot (connection via SCL/SDA). A device ID is not discovered/found for this external compass (0 in full parameters) while the internal compass is correctly discovered.
Second issue is about motor setup and rotation direction. Using the motor test (in mission planner) screen, motors always rotate in the same direction although I change rotation direction in the ESC setup (via BLHeli32 passthrough). This second issue startles me as I do not understand how changing the ESC setup does do any effect on the motor test rotation ??
Kakute F7 doesn’t have an internal compass.
Is the change in direction seen when you run the motors from the BLHelisuite Motor tab?
HI Dave, then my compass issue was a false alarm. I see the external compass then. Thanks!
I remain with the problem of motor rotation direction that does not change, independently of what is configured in BlHeli. That is odd, to say the least. The only thing I did not try yet is to swap two wires because that would require to undo my whole build and resolder…which I’d like to avoid. Any idea what I could stil ltry ? (my ESC is a 4 in 1 Tattoo 35A BLHeli32)
Does anyone know whether the Kakute f7 supports CANbus? I am interested in using it with 3.6 and UC4H. However, none of the documentation I’ve seen shows that the Kakute f7 has a CAN interface. The Kakute f4 does appear to have one. However, I would prefer to buy the f7 version because it appears more capable. I am new to UC4H and CAN, but I am interested in giving it a try.