Fairly awful camera work, but it may be of interest to libmaple integrators.
Jitter on the signal feeding the ESC's usually causes a crunchy or ticking sound. The PWM outputs seem to have removed this.
STM32 Discovery
(97 posts) (24 voices)-
ridgebackred
Memberanton,
Is https://github.com/anton19286/libmaple/blob/discovery/examples/discovery-flyer.cpp
flying on the Discovery board and your quadcopter?Posted 4 years ago # -
robodude666
MemberAmazing work guys!
Where are you getting the STM32VL-Discovery board from? The board on Mouser is a bit simple looking; it uses a lower-end MCU with less GPIO and less flash/ram. There appears to be a board on DigiKey however. Is that the board?
The STM32VL-Discovery's STM32F100RB only has 128KB, 8KB ram, and roughly 48 GPIO. That's not enough for what I'd need it for, but may be a handy board to have and gives me something to do while waiting for the Maple Mini or Maple Native to finally ship. And heck, it's only $12!
Second question, how are you guys programming it in a non-windows environment? Does the board have a similar DFU bootloader, and the maple's existing scripts work with it, or do you need an external programmer? The datasheet on the discovery board says there's a built-in ST-Link programmer. Is it compatible with OpenOCD? Also, can this ST-Link be used for programming other STM32 or LPC Cortex-M3 ARMs?
Cheers,
-robodude666Posted 4 years ago # -
ridgebackred
Memberrobodude666- I think Mouser has the wrong picture online. DigiKey's photo is correct.
I use a Windows environment with a utility program from ST for loading programs.
The built in ST-Link programmer is SWD interface only. I have used what I assume is OpenOCD under the covers when debugging with Atollic-lite. I have not used OpenOCD stand alone with the board. I've programmed other STM32 devices with the Discovery over the SWD interface. I have not worked with the LPC line.Posted 4 years ago # -
robodude666
MemberI'd imagine Mouser has the wrong picture too, but their datasheet they link to has different specs and is dated differently than the one ST has on their site. The DigiKey page has the same datasheet as ST though.
From what I've gathered, SWD support for OpenOCD is still in development. I ran across this stm32flash script that seems to work with the built in serial bootlaoder.
Posted 4 years ago # -
ridgebackred
MemberYour not too dumb Uhrheber.
Getting to the Discovery board with libmaple is three hacks deep.
1) Download antons Discovery branch of libmaple.
2) Use the command line to complile or set-up Eclipse as described in the wiki How To Guides.
3) Use the ST supplied program (Windows only, I think) to transfer 'main.bin' to the Discovery board.Posted 4 years ago # -
ridgebackred
MemberEdit: 3)Use the ST supplied program (Windows only, I think) to transfer 'discovery.bin' to the Discovery board.
Once the environment is setup it is a stable development platform.
Anton has merged libmaple 0.0.11 into the Discovery branch.
Most of my Discovery examples were written for 0.0.9 refactor. (possible bitrot alert!)Posted 4 years ago # -
Thank you, ridgebackred.
You should've mentioned that I also need a compiler :-)
It works now, but was a pain in the ass to install.
I like Linux, but sometimes it's a bitch.
I must've stepped into all possible traps.
Nevermind.The original stlink for Windows works, the
one from http://code.google.com/p/arm-utilities
doesn't write the flash.Thanks
UhrheberPosted 4 years ago # -
becker
Member> The .. one from http://code.google.com/p/arm-utilities doesn't write the flash.
Actually it does, you just have to be careful when using it.
The STLink USB firmware is very buggy. This causes several problems. It takes 5-10 seconds for the Linux kernel to decide that repeatedly resetting it won't make it behave. Then you have to wait another 5 seconds or so before it responds to commands, then close and re-open.
The older versions of stlink-download automated part of the waiting, but not the full procedure. So after plugging it in, you both had to wait, and run it once with a throw-away command.
The other issue is that it many commands attempt to do only what they say, without changing the status. For instance the chip has to be stopped to read CPU registers, but the "reg" command doesn't enforce this. Similarly you have to explicitly stop the chip before erasing or writing the flash. So your Makefile ends up looking like
$(STLINK-DOWNLOAD) /dev/stlink status
$(STLINK-DOWNLOAD) /dev/stlink debug reset erase=all flash:w:$<This is fine for people that understand the chip details, but in retrospect not the best approach.
I've updated the program to re-open until the status command works, and added a few new commands.
The "erase" command does 'debug reset erase=all'.
The "program=<filename>" command does 'debug reset erase=all erase=all flash:w:<filename>'Hopefully these will make stlink-download easier to use.
Posted 4 years ago #
Reply »
You must log in to post.