Extra inputs for Devo Tx's

Yup, already got a working setup. The only thing needed beyond what you need for deviation is something to flash them with. Hardware is either an ST-LINK with one of any number of choices (openocd, st-util, gdb, probably others) or a 3.3V/5V USB<->serial adapter with stm32flash. I believe a JTAG will also work, but haven't done much research on that. Other options like Black Magic Probe will also work.

The serial interface is a bit of a kludge, as it needs to be connected to pins PA9 and PA10 for usart1, but I have a number of USB<->Serial tools for Arduino work so started with that. The other options are preferred since they let you debug code running on the µ-controller. Cheap st-link clones cost a bit more than these stick boards. A lot of the STM discovery boards have an embedded ST-LINK device that can be jumpered to work with other devices. Those can be had for just a bit more than the cost of a clone ST-LINK, and a lot less than a non-clone ST-LINK device, so I ordered the F4Discovery board.

I'm pretty sure the AVR (which is an Atmel thing) won't work with STM chips. Would have to kludge the wiring in any case.

It won't work with dfuse out of the box, or at least dfu-util doesn't see it as a dfu capable device. For that matter, it doesn't show up as a USB device at all. There are a number of dfu bootloaders available for that work like the Arduino stuff: they occupy the first ~2K of FLASH, you compile code for that offset address, and they'll load and start it. There's even one in the libopencm3 examples that works pretty much out of the box.

You sure you don't have some kind of USB<->Serial programmer? Those are needed for a lot of the older/smaller Arduinos. Worst comes to worst, you could use an Arduino script that echo'd bytes between the USB port serial line and a softserial instance.

Getting started with STM32 built-in USB DFU Bootloader

Richard96816 wrote: Getting started with STM32 built-in USB DFU Bootloader

The first thing they say is "Check for eligible STM32 products supporting this function in table 1 of application note AN3156." That application note is at www.st.com/web/en/resource/technical/doc..._note/CD00264379.pdf

The STM32F103 - used on the "minimum system development board", the similar maple mini clones and the Devo Tx's - isn't listed in that table. You can go downscale to the STM32F0 or upscale to the STM32F105, STM31F105 or STM23F3 or STM32F4 (Cortex M-4's instead of M3's in the F1).

mwm wrote:

Richard96816 wrote: Getting started with STM32 built-in USB DFU Bootloader

The first thing they say is "Check for eligible STM32 products supporting this function in table 1 of application note AN3156." That application note is at www.st.com/web/en/resource/technical/doc..._note/CD00264379.pdf

The STM32F103 - used on the "minimum system development board", the similar maple mini clones and the Devo Tx's - isn't listed in that table. You can go downscale to the STM32F0 or upscale to the STM32F105, STM31F105 or STM23F3 or STM32F4 (Cortex M-4's instead of M3's in the F1).

Maybe I've been reading too many Chinglish manuals lately. But the various app-notes that I've read all seem to say the whole STM32F1 'series' currently includes the ROM USB bootloader. A few earlier date coded chips (not F103s) were apparently not supported. Some in the F1 series are singled out for working differently, but they all seem to include the bootloader. I think.

Guess I better unwrap some of the boards I've been receiving recently and try them ... I have wondered why the Devos all seem to have 'unnecessary' pinouts for STlink connections.

www.st.com/web/en/resource/technical/doc..._note/CD00167594.pdf

Richard96816 wrote: Maybe I've been reading too many Chinglish manuals lately. But the various app-notes that I've read all seem to say the whole STM32F1 'series' currently includes the ROM USB bootloader. A few earlier date coded chips (not F103s) were apparently not supported. Some in the F1 series are singled out for working differently, but they all seem to include the bootloader. I think.

Guess I better unwrap some of the boards I've been receiving recently and try them ... I have wondered why the Devos all seem to have 'unnecessary' pinouts for STlink connections.

www.st.com/web/en/resource/technical/doc..._note/CD00167594.pdf

By my reading, they all have boot loaders, but exactly what the boot loader does depends on the µ-controller in question. The F103 chips only load via USART1. The F105 and F107 chips can load via USART1, USART2 and DFU.

AFAIK, the maple mini has a "user" button and BOOT0 isn't connected to anything. The maple boot loader (which is running from flash, not replacing the USART1 boot loader) checks for that to load to flash beyond it via DFU. The minimum system development board that I have is missing the user button, and instead has jumpers for BOOT0 and BOOT1. BOOT0 causes the chip to jump to the on-chip boot loader to load via USART1. Not sure how ST-LINK works in that - my st-link is still on the way. BOOT1 is supposed to make it load code to RAM instead of FLASH and run it, but I've not been able to get that to work. BOOT1 is also connected to an IO pin, so you get a user jumper instead of the button. I think I agree with the designer that the two boot jumpers is better for development than a user button.

Notes on the minimum system development board: check the forums at stm32duino.com - they have links to what little English information there is, including the canonical pin diagram. They also call them the "red pill" and "blue pill" boards, which I'm going to use 'cause it's easier to type. Finally, I've tweaked some of the libopencm3 examples to work on them; let me know if you're interested in them, but they are pretty straightforward - mostly moving the led pin to the right place.

PB's post on re-flashing the Devo 7e boot loader will probably work with ST-Link. (Worked fine for my 7e.)

www.deviationtx.com/forum/6-general-disc...-7e-bootloader#34250

The ST-Link is more powerful than the USB boot loader anyway, and not too expensive. So good enough. My 'generic board with yellow pins' does seem to have the USB ROM loader. When I enable Boot0 it shows up on USB, though my Linux box doesn't yet want to connect to it. There are posts of others successfully flashing them from Windows.

www.sunspot.co.uk/Projects/Arduino/STM32/STM32.html

As you say, there appear to be many paths to, and flavors of, boot loaders on the STM32s.

(I still have a suspicion that a 'bricked' Devo can be restored with a USB cable and a couple jumpers.)

Here's a neat little gizmo I just slapped together.

A cheap cellphone mount plus a hacked microquad controller equals camera gimbal.

Haven't done much else with my Devos. Got a little discouraged after buttoning up the Devo 8, powering it up,.................and realizing that I cracked the OLED display. Oops Luckily I ordered a couple spares a couple weeks back.

Richard96816 wrote: PB's post on re-flashing the Devo 7e boot loader will probably work with ST-Link. (Worked fine for my 7e.)

www.deviationtx.com/forum/6-general-disc...-7e-bootloader#34250

Just a warning in case it's not obvious: the devo boot loader has odd additions to it, so that it only works with the devo firmware (or PB's thing). So you may not want to use it as a boot loader on anything else.

On the other hand, I've been thinking about replacing the boot loader on one of my devo's so I can use the standard dfu to load files. Haven't gotten beyond just thinking about it, though.

Just got my st-link (well ST32F4Discovery, which has one built in that can be jumpered for external use). It works with my blue pill STM32F103 board, though I had to reset said board quite hard: Put it in system boot loader mode, then do a flash while holding down the reset button. Before that, it just reported an incorrect device id. Worked fine afterwards.

And after mucking about with Arduinos and this with stm32flash, the ability to run code on it in gdb, complete with breakpoints and reading/writing memory is going to be a big help. I'll have to see if I can get that functionality working on a Devo!

Sound module!!..................................................sort of.......


Ended up getting a WT588D-U .
It's working a little flaky at the moment. Running it in 1-wire "serial" (bitbang). I can't get it to trigger consistently. Tried in 3-wire mode as well, and both using the onboard reset and busy pins. Next I'm going to try powering it from an Arduino IO pin and power-cycling it after each sound (it starts up quick enough).

For the output, I just re-purposed the DSC jack as a headphone output. It's hooked to my PC speakers in the vid. I've got a couple sets of small powered speakers that I can work at least one of inside the Devo. Need to figure out a volume control though. The board is supposed to have a serial-controllable volume, but I've yet to get it to work.
The audio quality is crap. This module sucks...........

Epyon wrote: Sound module!!..................................................sort of.......


Ended up getting a WT588D-U .
It's working a little flaky at the moment. Running it in 1-wire "serial" (bitbang). I can't get it to trigger consistently. Tried in 3-wire mode as well, and both using the onboard reset and busy pins. Next I'm going to try powering it from an Arduino IO pin and power-cycling it after each sound (it starts up quick enough). ]
For the output, I just re-purposed the DSC jack as a headphone output. It's hooked to my PC speakers in the vid. I've got a couple sets of small powered speakers that I can work at least one of inside the Devo. Need to figure out a volume control though. The board is supposed to have a serial-controllable volume, but I've yet to get it to work.
The audio quality is crap. This module sucks...........

Off topic but where can I read about the OLED / get code for it?

Progress looks great!!

Cereal_Killer wrote: Off topic but where can I read about the OLED / get code for it?

Just search for "ssd1306", that's the driver chip most used. You can get displays that run I2c and/or SPI. Depending on the particular display (there are many, many clones) you may need to change the I2c address.
I'm using a library from Adafruit. Makes it real easy. learn.adafruit.com/monochrome-oled-break...library-and-examples
The library will work as-is with the 128x64 or 128x32 displays, I2C or SPI. I've also got a 64x48 (tiny!) display to run off the library by altering it a little. Also dabbled with the U8glib library.

Ok yes I've used those 128x64's before on multiwii. How do you get it to know what mode it's in tho? Does it work with the built in switches or just the arduino controlled PPM add-on switches? If it only works based on the added in channels I understand, if it's somehow reading the factory switches I don't get it...

Cereal_Killer wrote: Ok yes I've used those 128x64's before on multiwii. How do you get it to know what mode it's in tho? Does it work with the built in switches or just the arduino controlled PPM add-on switches? If it only works based on the added in channels I understand, if it's somehow reading the factory switches I don't get it...

Yeah, just reading the Arduino-connected switches ATM, but hope to read the Devo's piezo output to trigger additional sounds. Basically setting a Timer alarm on the Devo activated by a switch, then reading the output pulse (alarm tones need set unique enough to differentiate). I took a crack at it a couple nights back, but failed, could've been the insomnia though.

Sounds like the techniques I used to read PWM values on an Arduino might be useful to you. I investigated three of the pretty thoroughly (pulseIn wasn't worth the effort), and wrote up the results on my blog:

rc.mired.org/2015/10/rc-blog-entry-on-my-programming-blog.html