Instability with GPIO pins
Closed this issue · 4 comments
To start off, I'm still using an older commit from late last year, as I'm relying on the async i2c, so this might be the start of the issue.
I have been attempting to use the GPIO ports for 2 things mainly: the in-built buzzer (GPIOA, Pin_12, on the Naze32 Rev5), and the UART2 Port (which overlays on the additional PWM ports when in CPPM mode).
With the buzzer, I can operate it directly, although it is extremely quiet. My current guess is that the output pin is being used for something on the backend, and is messing with my output each loop. Is there anything using this pin by default, or do the GPIO pins get reset each loop or something like that?
With the UART2 Port, using it seems to cause the microcontroller to freeze intermittently. From what I can tell, having this port enabled causes my program to miss the IMU interrupt, or something along those lines. I am finding this hard to debug, but that is the best lead I have so far. Has there been any similar issues regarding the UART2 port?
I've been using UART2 to read from a Spektrum DSM satellite receiver without any problems. Flying this code on several vehicles, in fact. Unless you're working with the current version of the repository, there's not much I can do to help.
Okay, I think I figured it out: at some point I slapped an interrupt onto UART2, in order to work with the Spektrum DSM satellite receiver. Now that I've figured out how to read from that device without interrupts, I don' t need them on UART2 any more and will probably remove them in the next commit.
But, if you can point me toward the commit you're using (hashcode), I can probably send you a patch for that commit too.
Thanks for your assistance. I am currently using commit: b7a7594
If it is too much hassle to work out a patch, I definitely understand, the UART2 is definitely not critical for me, but it would be pretty nice.
Out of curiosity, were I to upgrade to the newer versions of the f1 library, can the i2c be read asyncronously? Or at least without blocking the thread? I can't seem to find any examples for this type of thing.
At this point, I'd just stick with the commit you're using. If I try to change anything, I'll probably break something else. Ditto the I^2C interrupt issue, which is why this repository is also hanging back with an older commit.
In general, my attempt to migrate this code into the Arduino framework was probably a bad idea. There's a right way to support STM32 boards in Arduino, like this one, which I've switched to using for my own projects. So I probably won't be maintaining or upgrading BeezySTM32 much more.