only one CS line is asserted. No checks are enforced on this by the SPI code
as I cant see a clean way of it being aware of the CS lines. We could add
another CS mode those which is driver managed per transfer and has a GPIO i
line for each device.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2579 ebee16cc-31ac-478f-84a7-5cbb03baadba
Beginning of unifying the input types into PIOS_RECEIVER.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2568 ebee16cc-31ac-478f-84a7-5cbb03baadba
exists, no need to store pointers to it, but put the structure for the first LL
object in the ObjectListStruct
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2560 ebee16cc-31ac-478f-84a7-5cbb03baadba
UAVObjects, but pass it in from the macro definition. Saves memory for each
objects.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2559 ebee16cc-31ac-478f-84a7-5cbb03baadba
SYNTAX: Makefile.cmd [build | clean | help]
- build: builds all flight targets including uavobjects, bootloaders and firmware
- clean: cleans all flight targets including bootloaders and firmware
- help: this help
Currently set are OpenPilot, AHRS, PipXtreme targets and their bootloaders.
It could be done even better but it seems that Windows users don't like command line.
Extra batches which could help (not committed) are:
flight-build.cmd:
---------------------------------
@echo off
rem
rem Build all flight targets
rem
Makefile.cmd build
---------------------------------
flight-clean.cmd :
---------------------------------
@echo off
rem
rem Clean all flight targets
rem
Makefile.cmd clean
---------------------------------
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2551 ebee16cc-31ac-478f-84a7-5cbb03baadba
The floss-jtag-revb has an on-board EEPROM which can be used to
hold a serial number. This greatly simplifies using OpenOCD
debug environments with more than one JTAG attached to the same
PC.
See the FLOSS JTAG revB section of this page for instructions on
how to configure the EEPROM on Linux:
http://wiki.openpilot.org/display/Doc/Software+Development+on+Linux
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2540 ebee16cc-31ac-478f-84a7-5cbb03baadba
It is not yet fully functional as a top-level Qt-Creator project file (some dependencies need to be fixed).
So Qt-Creator users, please use the following sequence to build all for the 1st time:
1) Run qmake in ground (generated gcs Makefiles lack uavobject targets - known problem);
2) Build in uavobjgenerator;
2) Build in uavobjects;
3) Run qmake in ground again (IMPORTANT - now correct gcs Makefiles will be generated).
Now you may build openpilotgcs. If uavobjects are added/removed, you need to repeat all steps after uavobjects.pro modification.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2536 ebee16cc-31ac-478f-84a7-5cbb03baadba
This meta-project allows qt-creator users to open
and configure a single project and to build all
required software to produce a GCS. This includes
regenerating all uavobject output.
NOTE: To use this meta-project, you MUST perform these
steps once for each SVN checkout:
- Open <top>/ground/ground.pro in qt-creator
- Select the "Projects" tab
- Under Build Settings/General heading, click "Show Details"
- Activate "Shadow Build"
- Set your Build Directory to <top>/build/ground
<top> = The full path to the base of your svn tree which should
contain "flight", "ground", etc.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2531 ebee16cc-31ac-478f-84a7-5cbb03baadba
This will be used by a master project for qt-creator to
allow it to automatically generate the uavobject output
for qt-creator users.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2530 ebee16cc-31ac-478f-84a7-5cbb03baadba
