Re: [Paparazzi-devel] First step with stm32f4_discovery_RTOS

[Prof. Dr.-Ing. Heinrich Warmers]

Hi Felix Stewart and Hector,
in the winter semester  2009 same students  implemented the FreeRTOS and  Ecos RTOS  on the large olimex  LPC2148  PCB.
The result was  RTOS was faster but difficult  to compile for different  micro controllers . ECOS (http://www.ecoscentric.com/middleware/hccusb.shtml)  was the more professional  OS. for the use with GNU CC. This  had a make system, a debugger support  (USB, SD  LAN also)  and  is posix compatible that all  UNIX tools are running.
On the other hand Free RTOS is used by the openpilot project.

Regards
Heinrich

Jake Stewart schrieb:

Felix and Hector,

I'm glad RTOS support is comming.  Right now I'm working on the iNemo code to adapt it to the STM32 VL Discovery board.  Things are going well.  ST emailed me a workaround to get the code to compile, so now I just have to reconfigure it to use the Discovery rather than their normal $250 MEMS eval kit.  This should give me essentially their eval kit minus temperature and pressure for ~$45 instead of $250.  More importantly, as soon as I can cobble it together I can use their iNemo suite to play with my IMU and calibrate it, then get it to relay the computed AHRS data to the STM32F100 that PPZ will run on.  I think I'm doing pretty well with it and should finish this week.  If there's no problems getting PPZ going then I might have the whole system up and running by the time my servo connectors arrive from China.

I also looked at ChibiOS and FreeRTOS.  ST is using FreeRTOS to run their iNemo stuff.  The latest version of FreeRTOS runs great on the F103 and has project files for Atollic/eclipse and IAR.  Not sure if ST is using the latest FreeRTOS, but it compiles and runs fine.

Perphas there should be a discussion on what RTOS to support in PPZ.  It's no skin off my back to use ChibiOS since I won't have to mess with the iNemo side of my project once it's working.  However, the ease with which I was able to setup and use FreeRTOS, and the fact that it's ready to go for both the F100 and F103 in my project (and a lot of other processors), leads me to believe it would be a good choice. 


Notes on the F4 Discovery:

It's a bit larger than the VL Discovery... 97x66mm vs 84x43mm.  Make sure you've got enough room/payload for it. The VL is pretty small, but it's still about 3X larger than the LISA/M.

The F4 is setup pretty much the same way as the VL.  It also has a F103 processor to run the ST-Link.  I looked in the user manual and it also has the same solder bridges on the bottom.  You can take care of your JTAG/programming/debugging worries by using the onboard st-link.  There is linux support for the st-link supposedly, you might have to search for it a bit though.  You can also flash that F103 with Versaloon and use it with OpenOCD.  There is a pre-compiled Versaloon binary for the F103 both with and without a bootloader.  If you can't find it I can help you or send it to you.

If you want to program the F103 there are a couple ways... You can just remove the solder bridges from the "Default" box on the bottom and connect the bridges in the "PRG-32" (might just say "reserved" on the F4) box.  That's kind of tedious if you want to switch back and forth though.  So here's what I did... On the bottom of the board connect wires to the left side of the 2nd and 4th solder bridges (from the top) in the PRG-32 (or reserved) box.  Run those wires straight across to the same pins on the other 4-pin header (on the right side).  Now on the top find those header pins and remove the two resistors connected to those pins. (They are R11 and R12 on the VL Discovery)  The resistors are just to the right of the 2nd and 4th pins on that header (SWD on the VL).

If you do it my way the right 4-pin header programs your target MCU just like before, and the 4-pin header on the left now programs the F103.  You will loose your st-link capability from doing this modification.  There is no way to flash the ST-Link firmware back onto the F103 once you change it.  However, this shouldn't be a problem since you can just use the st-link in another Discovery board to program either processor on the modified board.  You just remove the jumpers from the CN3 header and connect a cable from the SWD 4-pin header to either of the 4-pin headers on your modified board.

Notes: I don't know about connecting the 1st and 3rd pins on the solder bridges.  It didn't need them, so I don't wire them up.  Pin 1 is labled VCC or VDD but never has any voltage on it, you can ignore this pin entirely.  Pin 3 is GND.  It's already connected to the board GND, so I don't mess with it's solder bridge.  That's why you only need to worry about the 2nd and 4th pins.  So in the end you'll need a 3-wire cable to connect the board for programming.  You'll also need another 1 wire cable to connect 5V from the link board to 5v on the target board.  You could also probably just power them both through the USB instead though.  The first time you flash the F103 you'll need to use the ST-Link utility.  It will give a write/read protection error, so you need to go into Target -> Option Bytes and disable read out protection.  Now it will flash correctly.

If nothing else, you might want to flash that F103 in your final project with a small firmware to put the MCU into sleep/standby/low-power mode.  I haven't checked if current consumption is reduced by something like this, but I imagine it would be.  There's no way to know what the st-link firmware does with the MCU when it's not in use.


-Jake


  

----- Original Message -----
From: Felix Ruess
Sent: 01/31/12 06:04 AM
To: address@hidden
Subject: Re: [Paparazzi-devel] First step with stm32f4_discovery

Hi Hector,

that is very good to know! I wanted to add the option to use an RTOS
under paparazzi for a long time already. I had originally looked at
FreeRTOS but recently tended more to ChibiOS. I haven't had the time
to really try them out or to do a proper comparison. But there were a
few minor things that let me lean towards ChibiOS.

It would be really great if you could help out here and provide some insights.

Cheers, Felix

On Tue, Jan 31, 2012 at 2:38 PM, Hector Garcia de Marina
<address@hidden> wrote:
    

Hi Heinrich,

this is the actual board and operating system that I am employing for the
development of my next autopilot.
You can reach me in the ChibiOS forums if you need any help.

Héctor.



On Tue, Jan 31, 2012 at 1:14 PM, Prof. Dr.-Ing. Heinrich Warmers
<address@hidden> wrote:
      

Hi,
i found this project:

http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm32f4_discovery
The pcb has the accelerator chip on board.

Heinrich

Hector Garcia de Marina schrieb:

Actually,

you can use the
http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_FT2232H_Mini_Module.pdf
as well. I has been using it for both JTAG and Serial Port , as it is
employed in Lisa-L, it works well with OpenOCD.

Already, gcc provides a pre-built tool-chain for ARM baremetal systems
(cortex m0-4), including multilib for cortexm4f. So you do not have to build
them anymore if you do not want to do it.

Héctor


On Tue, Jan 31, 2012 at 11:52 AM, Prof. Dr.-Ing. Heinrich Warmers
<address@hidden> wrote:
        

Hi Stewart,
yesterday i got the olimex stm32 (26 Euro). I think this is also a
candidate for low cost autopilots with paparazzi even for quadrocopters.
You can by a jatag interface  ( OpenPilot Foss Jatag)   for 30 Euro
(http://www.opstore.eu/en/2-openpilot) This is based on the work of  Piotr
Esden-Tempski with the extension that more than one adapter can be used on
the same usb connection. I think this is also working with the paparazzi
hardware (Lisa). A tool chain is the GNU 4.6 CC  in combination with open
cd.
I am  angry of the politic of ST to sell MEMS sensors. Often the chips
are only available for  less than two years. In 2007 an accelerator sensor
in dual line package for the Mikrokopter pcb and in 2010 the rate sensor for
the hbmini autopilot, razzor and adreimu..


A low price hardware for the STM  is OpenPilot CopterControl Board
http://www.innov8tivedesigns.com/product_info.php?cPath=125&products_id=894
89$
I hope to hear more of your work. Good luck.
 regards

Heinrich Warmers


Jake Stewart schrieb:

Thanks Felix, I was hoping someone could clear that up.  I'm not quite to
that stage yet, but I'm reinvigorated to know that there's the possibility
of help if I get stuck.

To explain a bit more about my project... I liked the idea of using ST
chips for the IMU since they were cheap and had free samples available.  ST
had also been starting to hype their "iNemo" sensor fusion and AHRS
platform.  iNemo is supposed to run on STM32F103s, at least at first.  That,
combined with the fact that LISA uses a STM32 processor, got me thinking
that a STM32 + ST accel/gyro/magnetometer combo was the way to go.

So I decided I better learn the STM32 and got a couple VL Discovery
boards.  When I got the Discoveries I was pretty impressed with the units,
and thought I'd do well to explore the capabilities.  What I found out was
that the Discovery actually has both F100 and  F103 processors.  The F103
runs the "ST-Link", which is STs USB programming/debugging link.  What's
cool about the Discovery units is that there are two 4-pin headers on the
board.  If you jumper one side you use the st-link to program the onboard
F100.  If you remove the jumpers then the other 4-pin header allows you to
use your discovery to connect to any other ST processor and flash/debug it.

After reading about a hack to program the F103 using another discovery
unit, requiring soldering two wires to one side of two SMT solder bridges, I
figured out how to tie the right pins together on the bottom so that you end
up with one header to program the F100 and one header to program the F103.
 Now I could easily flash and debug either processor on the board.  So now
the Discovery becomes a nice little dual processor dev board with USB.
 Unfortunately, the F103 is not connected to very much, and what it is
connected to is a little less than clear to me.  The processors are
connected together by at least two lines and the F103 is connected to a USB
port.  I also know that none of the I2C lines are connected and the F103
does not have a digital crossbar.

What I ended up doing for the moment was to pull up two I2C pins and
solder little wires to them.  I think I've come up with an easier and better
method now that involves tacking some small wires to the processor,
scratching out a couple existing traces, and tying those I2C lines to the
existing header pins.  It's somewhat tedious, but making a nice autopilot
board for under $10 seems worth it to me.

Anyways, the master plan is to have the F103 tied to the IMU and running
ST's iNemo sensor fusion / AHRS firmware.  The F103 will be dedicated to the
sensor fusion and processing the "true extended state Kalman filter" that ST
is hyping.  It will also do some USB tasks, communicate with the F100, and
do whatever else it's limited connections will support (hopefully flashing
the F100 and helping put settings into it from the USB).

So essentially I have the hardware side worked out and now I get to enjoy
the real fun of beating my head against the wall trying to program the
thing.  But, I don't see any insurmountable problems standing in the way.

Right now my problem is that the code ST has released only compiles on
IAR 5.x.  I wrote and asked them for Atollic/eclipse support and they told
me that only IAR is supported for now.  I wrote them back and told them that
IAR is NOT supported, only an old version of IAR that you can't get anymore
is supported.  IAR 6.2+ has some major CSMIS problems which seem to have no
good workaround since ST doesn't seem to have any CSMIS files out that
actually work with current versions of IAR.

So I need to figure out how to compile the code on some toolchain that I
can actually get my hands on.  I just don't know enough about these
toolchains to figure it out at the moment.  Seems like there's a lot of
workspace/project file settings to configure, and I don't really know what
I'm doing.  The free version of Atollic doesn't have the graphical setup
features of the pro version, so it seems like I have to do a lot of digging
through XML files and the like to get things running.

At the moment I can flash the iNemo DFU firmware onto the F103 and the
iNemo code also.  The DFU firmware (USB firmware upgrade tool) works just
fine.  I can actually use the USB connection to flash whatever I want onto
the F103.  Of course, the iNemo code is written for their $250 IMU
evaluation board and I need to change a few settings to work with my pinout,
and strip away the rest of the code related to their other sensors.

My limited success with the iNemo code has kept me mucking about with it,
but I'm about ready to try and get the PPZ code running on the F100 and
worry about iNemo later, if I even really need it.

Is anyone else interested in working on this project with me?  The
potential benefit of the project is the development of an ultra-cheap PPZ
hardware platform.  It also will offload the effort of AHRS and sensor
fusion to ST.  Hopefully they can then do all the math and worry about
supporting their chips.

ST is also now producing a cheap ($35) little IMU designed to plug into
their sensor eval board (STEVAL-MKI108V2).  It uses the latest L3GD20 and
LSM303DLHC MEMS sensor chips. (L3GD20 is the replacement for the L3G4200D).
 The L3GD20 is claimed to be immune to audio frequency noise and vibrations.

STEVAL-MKI108V2
http://www.st.com/internet/evalboard/product/252687.jsp

So the end product of the project will be a PPZ hardware platform
consisting of:
STM32VLDiscovery - $7 (new ST suggested retail price)
STEVAL-MKI108V2 9DOF IMU - $35
Fastrax UP501 GPS - $28
---------------------------------
= $70

I think a $70 hardware platform would be an amazing price breakthrough
and really lower the barriers to participation in the PPZ project.  Cost
alone might draw new people to the project, but existing members with a
significant investment might also consider the benefit of redundancy.
 People with existing systems could add a completely redundant backup to
their system for a reasonable price, and new people could have a redundant
system (excluding radio link) for only $140.  That could be a great safety
improvement.

I'm hooked on doing the project and if anyone else wants to help out it
might not take me a year to get it working.  I'm happy to modify the
discovery boards for anyone who wants to get involved without bothersome
soldering. Just shoot me an email.  I'm planning to get more Discovery
boards shortly and should have some modified ones ready to go before long.

The only real disadvantage I see to this project is that it will require
a rather complicated main wiring harness to connect everything up since it's
not a custom board.  Fortunately, I think a IDE hard drive cable (or
similar) will work pretty easily and we'll just have to put the right
connectors to the right wires to end up with a decent connection system.
 I'll be happy to make those also as soon as it is figured out how the pins
best map with the PPZ code.


-Jake






----- Original Message -----
From: Felix Ruess
Sent: 01/27/12 05:16 PM
To: address@hidden
Subject: Re: [Paparazzi-devel] Introduction, Q's about STM32 development

Hi Jake,

just a quick note: I don't think that creating new board files for the
STM32VLDiscovery board would be much work (if you already know
paparazzi). Also flash should just be enough, depending on what
subsystems/modules you include. Flash usage is roughly around 120kB on
my setup here..

Cheers, Felix

On Sat, Jan 21, 2012 at 4:15 PM, antoine drouin <address@hidden> wrote:


Hi Jake



The idea is that the door kicks open and the rope falls to the ground
where it is drug a short distance where particles stick >to the collector,
then the motor kicks in and winds the sample back up into the pod.  Then the
plane returns to base. > Using variations of that system should make it easy
to snag lots of samples from remote locations for cheap.  Obviously >the
danger is that the sample rope gets tangled and the plane gets dashed into
the ground at 30+ mph.


how far do you need to go fetch your samples? Have you though about
doing it with a quadrotor?

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

          

--
Héctor


________________________________
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

        

--
Héctor



_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

      

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
    

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel