I wanted to share with you a board that a couple of us have been working on for the last few months. We put it together to be an easy-to-access ARM Cortex-M4F flight controller. We also got a little frustrated with the STM peripherals library, so we've been building out a c++ object peripherals library that's open source with a nice, flexible expat license. Let me know if you have any comments, questions, or suggestions!
Library: https://github.com/ashima/embedded-STM32F-lib
Board info (and lots of other random stuff): http://ashimadevices.com
Here's some info on the board. In the image, above, there are two prototypes we made, top has a XBee and the programmer / power board attached. The bottom has the two boards separated and the XBee removed.
Physical Specs:
main board - 64mm x 35mm; 15g; 3.3v in (5v tolerant I/O)
programmer / power board - 27 mm x 35 mm; 7g; 6-20v in / 3.3v and 5v out
Processor: 168 MHz 32-bit Cortex-M4F (FPU); 1Mb Flash; 192K SRAM; 5v tolerant I/O; 14 timers; CRC and RNG units; 96 bit unique ID; RTC calendar; I2C, SPI, USART I/O; USB; 3 ADC, 1 DAC
IMU: MPU 9150 - board centered with colocated mag, gyro and accel; BMP180 pressure (MS5611 ready, but these parts have been hard to source)
Support components: A high-speed 4-bit SDIO micro-SD card slot for logging. 8 Kbytes of EEPROM on the board. For testing and quick board state assessment, we included 3 user and 4 status LEDs. There's also a 1W audio amp in lieu of a buzzer.
Comms: XBee module (or XBee compatible) ready
Programming: The USB interface is broken-out via the power board specifically to allow development and programming.
Control: We put a host of the usual I/O on the board. Here's a break out diagram:
Comments
I've attached a somewhat nicer plot of the mag read-out (with fit).
Also got slightly shouted at by Ian (my buddy that actually did most of the board design) for not making it clear that stuff is still "moving" on the board as we develop it, so the mag and the XBee may get further away from each other in future revs :)
The crystal is on there just to get good clocks. The STM32F4 Discovery board has two crystals on it, for example.
The mag location was an issue in design. The transmitter shielding (and a bunch of the other static stuff on a vehicle) do distort the field, and so direct absolute mag field measurements are not possible (or rather, the field is spatially distorted). The expectation in design and the result in testing is that this distortion can be calibrated-out. There are noise issues, also - so filtering is definitely needed. The attached figure is something we quickly banged up to show this, but the distortion of the field into an oval is what you get (excuse the non-consistent lengths on the axes). This was from dumping the mag as we waved it around, downlinking the data off of the XBee (so with the transmitter running) just to provide a real quick illustration.
The design issue with all of this ends up being not having a great deal of real estate given how tiny the board is and the desire to get the MPU centered.
Never saw anyone put a crystal on their STM32F407.
Noob question please, how does the Mag fair so close to the transmitter?