Fixed minor bug in get tiles threadpool
Divided project in 3 different namespaces, introduced license info.
Current test project is "widgettest"
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@699 ebee16cc-31ac-478f-84a7-5cbb03baadba
Add Easystar 3D model, using 3DS format and textures. First model with textures in the SVN for testing of ModelView with textures.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@677 ebee16cc-31ac-478f-84a7-5cbb03baadba
The previous fix in r652 was _almost_ right. There was
still a one word (4-byte) overlap between _irq_stack_top
and the start of the data segment.
_irq_stack_end + _irq_stack_size leaves the '.' pointer at
the word immediatly after the stack. This commit corrects
this error and places _irq_stack_top on the last word
_inside_ the reserved space for the irq stack.
[Before]
$ ./tools/arm-2009q3/bin/arm-none-eabi-nm -n ./build/openpilot/OpenPilot.elf
...
20000000 A SRAM_BASE
20000000 B _irq_stack_end
20000400 d LED_GPIO_PORT <--- overlap
20000400 B _irq_stack_top <--- overlap
20000400 D _sdata
20000408 d ADC_GPIO_PORT
...
[After]
$ ./tools/arm-2009q3/bin/arm-none-eabi-nm -n ./build/openpilot/OpenPilot.elf
...
20000000 A SRAM_BASE
20000000 B _irq_stack_end
200003fc B _irq_stack_top
20000400 d LED_GPIO_PORT
20000400 D _sdata
20000408 d ADC_GPIO_PORT
...
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@668 ebee16cc-31ac-478f-84a7-5cbb03baadba
Standalone compilation, not included on the top level project.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@661 ebee16cc-31ac-478f-84a7-5cbb03baadba
Both EVents and ERrors were mistakenly being mapped to the
EVent IRQ channel.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@659 ebee16cc-31ac-478f-84a7-5cbb03baadba
This commit fixes all existing warnings.
All basic compiler warnings will now be treated as errors.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@658 ebee16cc-31ac-478f-84a7-5cbb03baadba
This fixes the COM interface over USB HID to the point where
it can establish and maintain solid communications with the UAVObject
Browser in the GCS.
Tested only on Linux. The USB HID interface is still disabled for now
until it is tested successfully by a wider group.
Edit telemetry.c and set ALLOW_HID_TELEMETRY to 1 to enable telemetry
over the USB HID interface and report your results in the forum.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@656 ebee16cc-31ac-478f-84a7-5cbb03baadba
- New Attitude module for AHRS (skeleton)
- New AttitudeSettings UAVobject
- New AttitudeActual UAVobject
- Regenerated UAVobjects
- Added new UAVobjects to OpenPilot and GCS builds
- New PiOS driver for OpenPilot AHRS (stubs only)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@655 ebee16cc-31ac-478f-84a7-5cbb03baadba
Since the EXTI and NVIC init routines automatically enable the IRQ when it
is configured, it is possible for the EOC interrupt to fire immediately
upon configuring the IRQ.
Since the handler for the EOC interrupt (EXTI15_10_IRQHandler) does a
xSemaphoreGiveFromISR, it is important to have the semaphore initialized
prior to enabling the interrupt.
Also, added missing include for altitude module.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@654 ebee16cc-31ac-478f-84a7-5cbb03baadba
The MSP (IRQ stack) was trampling across the data segment. This was
especially disastrous in the USB interrupts since they allocate and
fill buffers on the stack.
The root of this trampling was that no RAM was being reserved for the
MSP and a hard-coded value of (0x20000400) was used as the initial MSP
base address. This resulted in the first 1K bytes of the .data segment
overlapping with the IRQ stack. As can be expected, all sorts of badness
resulted when interrupts were firing and trampling over variables.
This change reserves the first _isr_stack_size bytes at the beginning of
RAM for the MSP. If an ISR call chain runs off of the end of the MSP,
a Hard Fault will be generated as the (now invalid) sp is accessed.
There are two stack pointers in the Cortex-M3 CPU. These are MSP (Main
Stack Pointer) and PSP (Process Stack Pointer).
Which stack is in use at any given time is determined by the following table:
Mode CONTROL[ASPSEL] Stack
---- --------------- -----
Thread 0 MSP
Thread 1 PSP
Handler x MSP
Out of reset, the CPU is in Thread mode using the MSP. The initial value
of the MSP is automatically loaded from address 0 (lowest word in boot
region -- typically FLASH) immediately prior to jumping to the reset vector.
When running at interrupt level, the Cortex-M3 always uses the MSP and the
ASPSEL bit is forced to zero.
FreeRTOS allocates a separate stack for each task upon task creation. These
task stacks are allocated from the heap. FreeRTOS sets the active stack to
the PSP whenever running in a task context (both in privileged mode and user
mode).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@652 ebee16cc-31ac-478f-84a7-5cbb03baadba
