rooty/LibrePilot
1
0
Fork 0
mirror of https://bitbucket.org/librepilot/librepilot.git synced 2024-12-10 18:24:11 +01:00
Code Issues Releases Activity
aea1b4b544
LibrePilot/flight/CopterControl/System/pios_board.c

837 lines
24 KiB
C
Raw Normal View History

OP-265 Flight reorganization of UAVObjects and Modules up a directory git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2415 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-14 02:38:19 +01:00
/**
******************************************************************************
* @addtogroup OpenPilotSystem OpenPilot System
* @{
* @addtogroup OpenPilotCore OpenPilot Core
* @{
*
* @file pios_board.c
* @author The OpenPilot Team, http://www.openpilot.org Copyright (C) 2010.
* @brief Defines board specific static initializers for hardware for the OpenPilot board.
* @see The GNU Public License (GPL) Version 3
*
*****************************************************************************/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
board_hw_defs: factor out board-specific hw config definitions Board specific HW configuration is now collected in a single .c file for each board. This HW configuration is #include'd into the FW, BL and BU builds for each board. These new .c files are found in: flight/board_hw_defs/<board_name>/board_hw_defs.c Parts of this information were previously duplicated between the BL and FW builds. This commit cleans up the duplication. Using a #include on a .c file is a bit ugly but it allows us to ensure that all of the symbols in the board_hw_defs.c file are *ONLY* used in the PIOS_Board_Init() function for each software build.
2012-01-23 01:41:41 +01:00
/* Pull in the board-specific static HW definitions.
* Including .c files is a bit ugly but this allows all of
* the HW definitions to be const and static to limit their
* scope.
*
* NOTE: THIS IS THE ONLY PLACE THAT SHOULD EVER INCLUDE THIS FILE
*/
#include "board_hw_defs.c"
OP-265 Flight reorganization of UAVObjects and Modules up a directory git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2415 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-14 02:38:19 +01:00
#include <pios.h>
#include <openpilot.h>
#include <uavobjectsinit.h>
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
#include <hwsettings.h>
#include <manualcontrolsettings.h>
Initialize GCSReceiver object if it is being used
2011-08-27 22:57:09 +02:00
#include <gcsreceiver.h>
OP-265 Flight reorganization of UAVObjects and Modules up a directory git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2415 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-14 02:38:19 +01:00
board_hw_defs: factor out board-specific hw config definitions Board specific HW configuration is now collected in a single .c file for each board. This HW configuration is #include'd into the FW, BL and BU builds for each board. These new .c files are found in: flight/board_hw_defs/<board_name>/board_hw_defs.c Parts of this information were previously duplicated between the BL and FW builds. This commit cleans up the duplication. Using a #include on a .c file is a bit ugly but it allows us to ensure that all of the symbols in the board_hw_defs.c file are *ONLY* used in the PIOS_Board_Init() function for each software build.
2012-01-23 01:41:41 +01:00
/* One slot per selectable receiver group.
* eg. PWM, PPM, GCS, DSMMAINPORT, DSMFLEXIPORT, SBUS
* NOTE: No slot in this map for NONE.
sbus: provide a stub based on Spektrum driver (for CC only)
2011-06-13 02:04:49 +02:00
*/
board_hw_defs: factor out board-specific hw config definitions Board specific HW configuration is now collected in a single .c file for each board. This HW configuration is #include'd into the FW, BL and BU builds for each board. These new .c files are found in: flight/board_hw_defs/<board_name>/board_hw_defs.c Parts of this information were previously duplicated between the BL and FW builds. This commit cleans up the duplication. Using a #include on a .c file is a bit ugly but it allows us to ensure that all of the symbols in the board_hw_defs.c file are *ONLY* used in the PIOS_Board_Init() function for each software build.
2012-01-23 01:41:41 +01:00
uint32_t pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_NONE];
OP-265 Flight reorganization of UAVObjects and Modules up a directory git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2415 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-14 02:38:19 +01:00
com: reduce buffer sizes on com interfaces on CC Now that the COM layer fragments to the underlying buffer sizes, the COM layer buffers can shrink below single message sizes.
2011-12-30 19:07:25 +01:00
#define PIOS_COM_TELEM_RF_RX_BUF_LEN 32
com: reduce buffer sizes for com layer This saves a few hundred bytes of RAM in a typical configuration.
2011-12-28 03:12:20 +01:00
#define PIOS_COM_TELEM_RF_TX_BUF_LEN 12
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
CopterControl: Fix GPS buffer sizes
2011-08-25 15:37:38 +02:00
#define PIOS_COM_GPS_RX_BUF_LEN 32
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
com: reduce buffer sizes on com interfaces on CC Now that the COM layer fragments to the underlying buffer sizes, the COM layer buffers can shrink below single message sizes.
2011-12-30 19:07:25 +01:00
#define PIOS_COM_TELEM_USB_RX_BUF_LEN 65
com: reduce buffer sizes for com layer This saves a few hundred bytes of RAM in a typical configuration.
2011-12-28 03:12:20 +01:00
#define PIOS_COM_TELEM_USB_TX_BUF_LEN 65
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
#define PIOS_COM_BRIDGE_RX_BUF_LEN 65
com: reduce buffer sizes for com layer This saves a few hundred bytes of RAM in a typical configuration.
2011-12-28 03:12:20 +01:00
#define PIOS_COM_BRIDGE_TX_BUF_LEN 12
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
console: add support for serial debug consoles Serial ports now have a new HW setting called DebugConsole which can be used to dump internal state to a serial port for debug. To enable this feature, you need to: - make fw_coptercontrol_clean - make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES - configure one of the serial ports as DebugConsole in the GCS - save settings - power-cycle your board Things to note: - The console is at 57600,8N1. - This is not currently configurable via the GCS. - You can only have a single console enabled at a time.
2012-10-11 06:06:28 +02:00
#if defined(PIOS_INCLUDE_DEBUG_CONSOLE)
#define PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN 40
uint32_t pios_com_debug_id;
#endif /* PIOS_INCLUDE_DEBUG_CONSOLE */
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
uint32_t pios_com_telem_rf_id;
usb cdc: make HID/CDC configurable in hwsettings
2011-09-14 23:04:15 +02:00
uint32_t pios_com_telem_usb_id;
com: reduce buffer sizes on com interfaces on CC Now that the COM layer fragments to the underlying buffer sizes, the COM layer buffers can shrink below single message sizes.
2011-12-30 19:07:25 +01:00
uint32_t pios_com_vcp_id;
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
uint32_t pios_com_gps_id;
com: reduce buffer sizes on com interfaces on CC Now that the COM layer fragments to the underlying buffer sizes, the COM layer buffers can shrink below single message sizes.
2011-12-30 19:07:25 +01:00
uint32_t pios_com_bridge_id;
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
hid joystick: emulate a USB HID joystick using RC Transmitter Adds a new RCTransmitter setting for the USB HID interface which emulates a USB HID joystick. The scaled RC receiver channels from any RCVR protocol are passed through to the various emulated joystick controls. The main use for this feature is to allow you to use your own RC transmitter with any RC simulator on a PC. This is known to work with CRRCsim but should work with any simulator that supports joystick input.
2012-08-06 03:45:27 +02:00
uint32_t pios_usb_rctx_id;
Add BMA180 to CopterControl 3D. Had to reduce the stack space by 256 bytes. Some can be reclaimed by making the BMA180 allocate its fifo dynamically but I'll do that later when it uses FreeRTOS queues for the FIFO.
2012-01-24 06:45:40 +01:00
/**
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
* Configuration for MPU6000 chip
Add BMA180 to CopterControl 3D. Had to reduce the stack space by 256 bytes. Some can be reclaimed by making the BMA180 allocate its fifo dynamically but I'll do that later when it uses FreeRTOS queues for the FIFO.
2012-01-24 06:45:40 +01:00
*/
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
#if defined(PIOS_INCLUDE_MPU6000)
#include "pios_mpu6000.h"
static const struct pios_exti_cfg pios_exti_mpu6000_cfg __exti_config = {
.vector = PIOS_MPU6000_IRQHandler,
Update drivers for CC to the new EXTI system and SPI calls
2012-01-24 06:29:17 +01:00
.line = EXTI_Line3,
.pin = {
Set up the SPI interface to the l3gd20
2012-01-20 21:14:57 +01:00
.gpio = GPIOA,
.init = {
.GPIO_Pin = GPIO_Pin_3,
.GPIO_Speed = GPIO_Speed_10MHz,
Give the BMA180 a dynamically allocated device structure and also make it properly bind to a SPI and slave number. Temporarily reducing spi bus to slowest possible speed.
2012-01-24 21:38:00 +01:00
.GPIO_Mode = GPIO_Mode_IN_FLOATING,
Set up the SPI interface to the l3gd20
2012-01-20 21:14:57 +01:00
},
},
Update drivers for CC to the new EXTI system and SPI calls
2012-01-24 06:29:17 +01:00
.irq = {
Set up the SPI interface to the l3gd20
2012-01-20 21:14:57 +01:00
.init = {
.NVIC_IRQChannel = EXTI3_IRQn,
.NVIC_IRQChannelPreemptionPriority = PIOS_IRQ_PRIO_HIGH,
.NVIC_IRQChannelSubPriority = 0,
.NVIC_IRQChannelCmd = ENABLE,
},
},
Update drivers for CC to the new EXTI system and SPI calls
2012-01-24 06:29:17 +01:00
.exti = {
.init = {
.EXTI_Line = EXTI_Line3, // matches above GPIO pin
.EXTI_Mode = EXTI_Mode_Interrupt,
.EXTI_Trigger = EXTI_Trigger_Rising,
.EXTI_LineCmd = ENABLE,
},
},
};
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
static const struct pios_mpu6000_cfg pios_mpu6000_cfg = {
.exti_cfg = &pios_exti_mpu6000_cfg,
.Fifo_store = PIOS_MPU6000_FIFO_TEMP_OUT | PIOS_MPU6000_FIFO_GYRO_X_OUT | PIOS_MPU6000_FIFO_GYRO_Y_OUT | PIOS_MPU6000_FIFO_GYRO_Z_OUT,
Fixed comment on coptercontrol's pios_board.c OP-780
2012-12-28 23:04:57 +01:00
// Clock at 8 khz, downsampled by 16 for 500 Hz
Add MPU6000 accel range to config structure. Also put in correct values.
2012-04-03 08:53:21 +02:00
.Smpl_rate_div = 15,
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
.interrupt_cfg = PIOS_MPU6000_INT_CLR_ANYRD,
.interrupt_en = PIOS_MPU6000_INTEN_DATA_RDY,
Correct comment in CC settings for MPU6000 and disable I2C support
2012-05-12 05:08:44 +02:00
.User_ctl = PIOS_MPU6000_USERCTL_FIFO_EN | PIOS_MPU6000_USERCTL_DIS_I2C,
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
.Pwr_mgmt_clk = PIOS_MPU6000_PWRMGMT_PLL_X_CLK,
Add MPU6000 accel range to config structure. Also put in correct values.
2012-04-03 08:53:21 +02:00
.accel_range = PIOS_MPU6000_ACCEL_8G,
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
.gyro_range = PIOS_MPU6000_SCALE_500_DEG,
PIOS_MPU6000: Make the driver perform the rotation to bring it into the OP coordinate system Previously there were hacks spread throughout to deal with various ways of positioning the chips. Now the driver structure specifies the rotation of the chip relative to the board layout and the output X/Y/Z are already in OP convention. This flag seems to do the right thing for Revolution, CC3D, and RevoMini
2012-09-11 08:45:15 +02:00
.filter = PIOS_MPU6000_LOWPASS_256_HZ,
.orientation = PIOS_MPU6000_TOP_180DEG
Set up the SPI interface to the l3gd20
2012-01-20 21:14:57 +01:00
};
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
#endif /* PIOS_INCLUDE_MPU6000 */
Set up the SPI interface to the l3gd20
2012-01-20 21:14:57 +01:00
Flash: Because most of the commands are a JEDEC standard rename this file pios_flash_jedec and abstract out the methods that can vary between chips.
2012-01-25 07:23:24 +01:00
static const struct flashfs_cfg flashfs_w25x_cfg = {
Flashfs: Separate out the sector sizes and magic values into a runtime configurable structure. This makes it easier to deal with different chip layouts.
2012-01-25 06:56:36 +01:00
.table_magic = 0x85FB3C35,
.obj_magic = 0x3015AE71,
.obj_table_start = 0x00000010,
.obj_table_end = 0x00001000,
.sector_size = 0x00001000,
Add the chip size to the flashfs configuration (should probably go in the chip configuration)
2012-06-02 18:00:42 +02:00
.chip_size = 0x00080000,
Flashfs: Separate out the sector sizes and magic values into a runtime configurable structure. This makes it easier to deal with different chip layouts.
2012-01-25 06:56:36 +01:00
};
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
Flash: Because most of the commands are a JEDEC standard rename this file pios_flash_jedec and abstract out the methods that can vary between chips.
2012-01-25 07:23:24 +01:00
static const struct pios_flash_jedec_cfg flash_w25x_cfg = {
.sector_erase = 0x20,
.chip_erase = 0x60
};
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
static const struct flashfs_cfg flashfs_m25p_cfg = {
.table_magic = 0x85FB3D35,
.obj_magic = 0x3015A371,
.obj_table_start = 0x00000010,
.obj_table_end = 0x00010000,
.sector_size = 0x00010000,
Add the chip size to the flashfs configuration (should probably go in the chip configuration)
2012-06-02 18:00:42 +02:00
.chip_size = 0x00200000,
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
};
static const struct pios_flash_jedec_cfg flash_m25p_cfg = {
.sector_erase = 0xD8,
.chip_erase = 0xC7
};
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
#include <pios_board_info.h>
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
/**
* PIOS_Board_Init()
* initializes all the core subsystems on this specific hardware
* called from System/openpilot.c
*/
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
int32_t init_test;
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
void PIOS_Board_Init(void) {
/* Delay system */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_DELAY_Init();
Initialize the LEDs early in the bootup process
2012-01-24 21:37:04 +01:00
const struct pios_board_info * bdinfo = &pios_board_info_blob;
#if defined(PIOS_INCLUDE_LED)
hw_defs: hide board-rev differences in LED definitions Every board has at least one LED (HEARTBEAT). Not all users of LEDs need to be directly aware of which LED configuration to choose when there may be more than one possible configuration. Hide the details of the differences between LEDs used in the different HW revs for CC. This will allow generic code to run on CC and CC3D without being exposed to the details of the different pins used for the LEDs.
2012-05-23 06:22:11 +02:00
const struct pios_led_cfg * led_cfg = PIOS_BOARD_HW_DEFS_GetLedCfg(bdinfo->board_rev);
PIOS_Assert(led_cfg);
PIOS_LED_Init(led_cfg);
Initialize the LEDs early in the bootup process
2012-01-24 21:37:04 +01:00
#endif /* PIOS_INCLUDE_LED */
Got CC running again although with altitude and bmp085 disabled as well as the CC3D drivers.
2012-01-24 17:32:42 +01:00
#if defined(PIOS_INCLUDE_SPI)
hwinit: Convert SPI drivers to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2772 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:50 +01:00
/* Set up the SPI interface to the serial flash */
CC3D and CC use different CS lines for the flash chip. Add a second cfg structure for each SPI interface.
2012-01-24 23:21:34 +01:00
switch(bdinfo->board_rev) {
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC:
CC3D and CC use different CS lines for the flash chip. Add a second cfg structure for each SPI interface.
2012-01-24 23:21:34 +01:00
if (PIOS_SPI_Init(&pios_spi_flash_accel_id, &pios_spi_flash_accel_cfg_cc)) {
PIOS_Assert(0);
}
break;
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC3D:
CC3D and CC use different CS lines for the flash chip. Add a second cfg structure for each SPI interface.
2012-01-24 23:21:34 +01:00
if (PIOS_SPI_Init(&pios_spi_flash_accel_id, &pios_spi_flash_accel_cfg_cc3d)) {
PIOS_Assert(0);
}
break;
default:
PIOS_Assert(0);
hwinit: Convert SPI drivers to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2772 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:50 +01:00
}
CC3D and CC use different CS lines for the flash chip. Add a second cfg structure for each SPI interface.
2012-01-24 23:21:34 +01:00
Got CC running again although with altitude and bmp085 disabled as well as the CC3D drivers.
2012-01-24 17:32:42 +01:00
#endif
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
switch(bdinfo->board_rev) {
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC:
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
PIOS_Flash_Jedec_Init(pios_spi_flash_accel_id, 1, &flash_w25x_cfg);
PIOS_FLASHFS_Init(&flashfs_w25x_cfg);
break;
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC3D:
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
PIOS_Flash_Jedec_Init(pios_spi_flash_accel_id, 0, &flash_m25p_cfg);
PIOS_FLASHFS_Init(&flashfs_m25p_cfg);
break;
default:
PIOS_DEBUG_Assert(0);
}
OP-22 Flight/PiOS: Spektrum fix, OP tested on ground not flown yet, CC not tested. pios_rcinput.[ch] outdated git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2775 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-13 14:10:02 +01:00
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
/* Initialize UAVObject libraries */
EventDispatcherInitialize();
UAVObjInitialize();
leds: use boot-time config for PiOS LED layer LEDs are now configured based on a board-specific initialization in PIOS_BOARD_Init(). LEDs are now named: PIOS_LED_HEARTBEAT PIOS_LED_ALARM
2012-01-23 00:22:59 +01:00
#if defined(PIOS_INCLUDE_RTC)
/* Initialize the real-time clock and its associated tick */
PIOS_RTC_Init(&pios_rtc_main_cfg);
#endif
Need to initialize the HwSettings before using them.
2011-07-31 02:42:15 +02:00
HwSettingsInitialize();
bootfault: add support for recovery from init failures After 3 failed warm start attempts, the init sequence will force the RAM version of the HWSettings object to its defaults. This should allow a user to regain connectivity to a board that is continually faulting during init. This is accomplished by: - Incrementing a boot counter that is stored in the STM32 BKP registers. These registers survive a warm start but are cleared on a cold start (ie. powerup). - On multiple failures, force hwsettings to defaults and raise the (new) BootFault alarm to prevent arming. - Resetting the boot counter whenever the system manages to successfully run the System Module task. NOTE: This does not actually change the hwsettings object in flash. That's up to the user. This is intended to catch ONLY faults during early initialization. It should not be used to recover from faults after the application is up and running.
2011-12-30 19:26:54 +01:00
#ifndef ERASE_FLASH
/* Initialize watchdog as early as possible to catch faults during init */
PIOS_WDG_Init();
rtc: allow registration of callbacks on RTC tick This separates the RTC device and interrupt handling from the devices that rely on the tick notifications. Drivers can now register tick notification functions that will be called on each RTC tick event.
2011-07-03 01:25:35 +02:00
#endif
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
/* Initialize the alarms library */
AlarmsInitialize();
bootfault: add support for recovery from init failures After 3 failed warm start attempts, the init sequence will force the RAM version of the HWSettings object to its defaults. This should allow a user to regain connectivity to a board that is continually faulting during init. This is accomplished by: - Incrementing a boot counter that is stored in the STM32 BKP registers. These registers survive a warm start but are cleared on a cold start (ie. powerup). - On multiple failures, force hwsettings to defaults and raise the (new) BootFault alarm to prevent arming. - Resetting the boot counter whenever the system manages to successfully run the System Module task. NOTE: This does not actually change the hwsettings object in flash. That's up to the user. This is intended to catch ONLY faults during early initialization. It should not be used to recover from faults after the application is up and running.
2011-12-30 19:26:54 +01:00
/* Check for repeated boot failures */
PIOS_IAP_Init();
uint16_t boot_count = PIOS_IAP_ReadBootCount();
if (boot_count < 3) {
PIOS_IAP_WriteBootCount(++boot_count);
AlarmsClear(SYSTEMALARMS_ALARM_BOOTFAULT);
} else {
/* Too many failed boot attempts, force hwsettings to defaults */
HwSettingsSetDefaults(HwSettingsHandle(), 0);
AlarmsSet(SYSTEMALARMS_ALARM_BOOTFAULT, SYSTEMALARMS_ALARM_CRITICAL);
}
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
/* Initialize the task monitor library */
TaskMonitorInitialize();
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
/* Set up pulse timers */
PIOS_TIM_InitClock(&tim_1_cfg);
PIOS_TIM_InitClock(&tim_2_cfg);
PIOS_TIM_InitClock(&tim_3_cfg);
PIOS_TIM_InitClock(&tim_4_cfg);
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#if defined(PIOS_INCLUDE_USB)
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
/* Initialize board specific USB data */
PIOS_USB_BOARD_DATA_Init();
usb: remove run-time selectable device descriptors BL images now always use hid-only. FW images can use hid-only or hid+vcp but this is selected ONLY at compile time based on whether PIOS_INCLUDE_USB_CDC is defined. CC uses HID+VCP by default now.
2012-05-10 04:27:52 +02:00
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
/* Flags to determine if various USB interfaces are advertised */
bool usb_hid_present = false;
bool usb_cdc_present = false;
usb: remove run-time selectable device descriptors BL images now always use hid-only. FW images can use hid-only or hid+vcp but this is selected ONLY at compile time based on whether PIOS_INCLUDE_USB_CDC is defined. CC uses HID+VCP by default now.
2012-05-10 04:27:52 +02:00
#if defined(PIOS_INCLUDE_USB_CDC)
if (PIOS_USB_DESC_HID_CDC_Init()) {
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
PIOS_Assert(0);
}
usb: remove run-time selectable device descriptors BL images now always use hid-only. FW images can use hid-only or hid+vcp but this is selected ONLY at compile time based on whether PIOS_INCLUDE_USB_CDC is defined. CC uses HID+VCP by default now.
2012-05-10 04:27:52 +02:00
usb_hid_present = true;
usb_cdc_present = true;
#else
if (PIOS_USB_DESC_HID_ONLY_Init()) {
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
PIOS_Assert(0);
}
usb: remove run-time selectable device descriptors BL images now always use hid-only. FW images can use hid-only or hid+vcp but this is selected ONLY at compile time based on whether PIOS_INCLUDE_USB_CDC is defined. CC uses HID+VCP by default now.
2012-05-10 04:27:52 +02:00
usb_hid_present = true;
#endif
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
uint32_t pios_usb_id;
USB: Update the USB configuration structure to include the GPIO that is used for sensing and then load different config for CC and CC3D. Updated the bootloader as well. Also changed the PIOS_USB_CheckAvailability function to only return the sense signal and not the transfer_possible flag as this is not set in time for the bootloader on CC3D for some reason.
2012-01-25 05:15:43 +01:00
switch(bdinfo->board_rev) {
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC:
USB: Update the USB configuration structure to include the GPIO that is used for sensing and then load different config for CC and CC3D. Updated the bootloader as well. Also changed the PIOS_USB_CheckAvailability function to only return the sense signal and not the transfer_possible flag as this is not set in time for the bootloader on CC3D for some reason.
2012-01-25 05:15:43 +01:00
PIOS_USB_Init(&pios_usb_id, &pios_usb_main_cfg_cc);
break;
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC3D:
USB: Update the USB configuration structure to include the GPIO that is used for sensing and then load different config for CC and CC3D. Updated the bootloader as well. Also changed the PIOS_USB_CheckAvailability function to only return the sense signal and not the transfer_possible flag as this is not set in time for the bootloader on CC3D for some reason.
2012-01-25 05:15:43 +01:00
PIOS_USB_Init(&pios_usb_id, &pios_usb_main_cfg_cc3d);
break;
default:
PIOS_Assert(0);
}
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#if defined(PIOS_INCLUDE_USB_CDC)
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
uint8_t hwsettings_usb_vcpport;
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
/* Configure the USB VCP port */
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
HwSettingsUSB_VCPPortGet(&hwsettings_usb_vcpport);
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
if (!usb_cdc_present) {
/* Force VCP port function to disabled if we haven't advertised VCP in our USB descriptor */
hwsettings_usb_vcpport = HWSETTINGS_USB_VCPPORT_DISABLED;
}
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
switch (hwsettings_usb_vcpport) {
case HWSETTINGS_USB_VCPPORT_DISABLED:
break;
case HWSETTINGS_USB_VCPPORT_USBTELEMETRY:
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
#if defined(PIOS_INCLUDE_COM)
{
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
uint32_t pios_usb_cdc_id;
if (PIOS_USB_CDC_Init(&pios_usb_cdc_id, &pios_usb_cdc_cfg, pios_usb_id)) {
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
PIOS_Assert(0);
}
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_USB_RX_BUF_LEN);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_USB_TX_BUF_LEN);
PIOS_Assert(rx_buffer);
PIOS_Assert(tx_buffer);
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
if (PIOS_COM_Init(&pios_com_telem_usb_id, &pios_usb_cdc_com_driver, pios_usb_cdc_id,
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
rx_buffer, PIOS_COM_TELEM_USB_RX_BUF_LEN,
tx_buffer, PIOS_COM_TELEM_USB_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_COM */
break;
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
case HWSETTINGS_USB_VCPPORT_COMBRIDGE:
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#if defined(PIOS_INCLUDE_COM)
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
{
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
uint32_t pios_usb_cdc_id;
if (PIOS_USB_CDC_Init(&pios_usb_cdc_id, &pios_usb_cdc_cfg, pios_usb_id)) {
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
PIOS_Assert(0);
}
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_BRIDGE_RX_BUF_LEN);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_BRIDGE_TX_BUF_LEN);
PIOS_Assert(rx_buffer);
PIOS_Assert(tx_buffer);
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
if (PIOS_COM_Init(&pios_com_vcp_id, &pios_usb_cdc_com_driver, pios_usb_cdc_id,
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
rx_buffer, PIOS_COM_BRIDGE_RX_BUF_LEN,
tx_buffer, PIOS_COM_BRIDGE_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
console: add debug console via USB CDC/VCP interface The USB VCP Port has a new DebugConsole setting that routes all output destined for PIOS_COM_DEBUG to the emulated serial port. To enable this in your build, you'll have to build like: - make fw_coptercontrol_clean - make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES You can then output formatted text to the console like this: #if defined(PIOS_INCLUDE_DEBUG_CONSOLE) PIOS_COM_SendFormattedString(PIOS_COM_DEBUG, "foo is %u\r\n", foo); #endif /* PIOS_INCLUDE_DEBUG_CONSOLE */ Please ensure that all of your debug output is wrapped with these macros so that your debug code doesn't bloat the firmware image.
2012-10-11 06:51:09 +02:00
#endif /* PIOS_INCLUDE_COM */
break;
case HWSETTINGS_USB_VCPPORT_DEBUGCONSOLE:
#if defined(PIOS_INCLUDE_COM)
#if defined(PIOS_INCLUDE_DEBUG_CONSOLE)
{
uint32_t pios_usb_cdc_id;
if (PIOS_USB_CDC_Init(&pios_usb_cdc_id, &pios_usb_cdc_cfg, pios_usb_id)) {
PIOS_Assert(0);
}
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN);
PIOS_Assert(tx_buffer);
if (PIOS_COM_Init(&pios_com_debug_id, &pios_usb_cdc_com_driver, pios_usb_cdc_id,
NULL, 0,
tx_buffer, PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_DEBUG_CONSOLE */
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#endif /* PIOS_INCLUDE_COM */
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
break;
}
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#endif /* PIOS_INCLUDE_USB_CDC */
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#if defined(PIOS_INCLUDE_USB_HID)
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
/* Configure the usb HID port */
uint8_t hwsettings_usb_hidport;
HwSettingsUSB_HIDPortGet(&hwsettings_usb_hidport);
usb: allow runtime selection of USB descriptors via hwsettings
2012-01-14 20:17:06 +01:00
if (!usb_hid_present) {
/* Force HID port function to disabled if we haven't advertised HID in our USB descriptor */
hwsettings_usb_hidport = HWSETTINGS_USB_HIDPORT_DISABLED;
}
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
switch (hwsettings_usb_hidport) {
case HWSETTINGS_USB_HIDPORT_DISABLED:
break;
case HWSETTINGS_USB_HIDPORT_USBTELEMETRY:
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
#if defined(PIOS_INCLUDE_COM)
{
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
uint32_t pios_usb_hid_id;
if (PIOS_USB_HID_Init(&pios_usb_hid_id, &pios_usb_hid_cfg, pios_usb_id)) {
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
PIOS_Assert(0);
}
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_USB_RX_BUF_LEN);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_USB_TX_BUF_LEN);
PIOS_Assert(rx_buffer);
PIOS_Assert(tx_buffer);
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
if (PIOS_COM_Init(&pios_com_telem_usb_id, &pios_usb_hid_com_driver, pios_usb_hid_id,
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
rx_buffer, PIOS_COM_TELEM_USB_RX_BUF_LEN,
tx_buffer, PIOS_COM_TELEM_USB_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_COM */
break;
hid joystick: emulate a USB HID joystick using RC Transmitter Adds a new RCTransmitter setting for the USB HID interface which emulates a USB HID joystick. The scaled RC receiver channels from any RCVR protocol are passed through to the various emulated joystick controls. The main use for this feature is to allow you to use your own RC transmitter with any RC simulator on a PC. This is known to work with CRRCsim but should work with any simulator that supports joystick input.
2012-08-06 03:45:27 +02:00
case HWSETTINGS_USB_HIDPORT_RCTRANSMITTER:
#if defined(PIOS_INCLUDE_USB_RCTX)
{
if (PIOS_USB_RCTX_Init(&pios_usb_rctx_id, &pios_usb_rctx_cfg, pios_usb_id)) {
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_USB_RCTX */
break;
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
}
usb-hid: split apart hwsettings for HID and VCP ports This allows the HID and VCP functions to be configured separately so that additional functions can be more easily bound to the VCP port. This change also provides a safety net that forces either the HID or VCP to be configured for USB Telemetry. This safety net may vanish in the future once the GCS can check it. Disabling USB Telemetry entirely would save more than 400 bytes of RAM.
2011-12-28 22:16:29 +01:00
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
#endif /* PIOS_INCLUDE_USB_HID */
usb: major refactoring of USB descriptors, CDC and HID Summary of changes: * USB CDC and HID drivers are completely split apart. * This will allow different max buffer sizes for HID and CDC. * USB descriptors have been overhauled: * Proper structs/macros/enums declared for USB (see pios_usb_defs.h) * Two common descriptor definitions. One for HID+CDC another for HID only. See pios_usb_desc_{hid_cdc,hid_only}.c for details. * Long standing bugs in OP USB descriptors became much more obvious with the new struct definitions. * Board specific USB initialization is now in pios_usb_board_data.h in each build target. * Definition of USB descriptors is now entirely indpendent of STM32 libs. Glue into STM32 libs is provided by pios_usbhook.c. * Removed a lot of stale/irrelevant USB #defines throughout the tree. * Improved naming consistency throughout USB code: * PIOS_USB_HID_* now refers to the HID endpoint code. * PIOS_USB_CDC_* now refers to the CDC endpoint code. * PIOS_USB_* now refers to the low-level USB code. * PIOS_USB_BOARD_* now refers to board-specific USB data * PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs. * struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec. * Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM. * Made a few more USB related variables static to save some RAM.
2012-01-02 20:03:15 +01:00
#endif /* PIOS_INCLUDE_USB */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
/* Configure the main IO port */
DSMx_binder, hw setting 0 disabled, 1-10 bind pulses. Manual disable after successful bind. Only for flexiport.
2011-08-06 21:16:47 +02:00
uint8_t hwsettings_DSMxBind;
HwSettingsDSMxBindGet(&hwsettings_DSMxBind);
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
uint8_t hwsettings_cc_mainport;
HwSettingsCC_MainPortGet(&hwsettings_cc_mainport);
switch (hwsettings_cc_mainport) {
case HWSETTINGS_CC_MAINPORT_DISABLED:
break;
case HWSETTINGS_CC_MAINPORT_TELEMETRY:
usart: serial telemetry can be disabled to free USART It was tested being merged with OP-472_CorvusCorax_CopterControl-Guidance_v3 branch, Spektrum on USART3 and GPS on USART1 and seems to work. Currently defaults mimic original behavior, that is, if USE_SPEKTRUM is not defined - define USE_PWM and USE_GPS. Thsi should be refactored later to make it configurable from the Makefile. Also it was not ported to the OP MB: it currently does not support the S.Bus hardware and still has original behavior with the patch. But this is one more step to dynamic configuration of ports.
2011-06-16 14:06:01 +02:00
#if defined(PIOS_INCLUDE_TELEMETRY_RF)
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
{
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_main_cfg)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_RF_RX_BUF_LEN);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_RF_TX_BUF_LEN);
PIOS_Assert(rx_buffer);
PIOS_Assert(tx_buffer);
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
if (PIOS_COM_Init(&pios_com_telem_rf_id, &pios_usart_com_driver, pios_usart_generic_id,
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
rx_buffer, PIOS_COM_TELEM_RF_RX_BUF_LEN,
tx_buffer, PIOS_COM_TELEM_RF_TX_BUF_LEN)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_TELEMETRY_RF */
break;
case HWSETTINGS_CC_MAINPORT_SBUS:
#if defined(PIOS_INCLUDE_SBUS)
{
uint32_t pios_usart_sbus_id;
if (PIOS_USART_Init(&pios_usart_sbus_id, &pios_usart_sbus_main_cfg)) {
PIOS_Assert(0);
}
com: Move buffering out of USART/HID layer and into COM layer This allows the spektrum and sbus receiver drivers to bind directly to the usart layer using a properly exported API rather than overriding the interrupt handler. Bytes are now pushed directly from the usart layer into the com layer without any buffering. The com layer performs all of the buffering. A further benefit from this approach is that we can put all blocking/non-blocking behaviour into the COM layer and not in the underlying drivers. Misc related changes: - Remove obsolete .handler field from irq configs - Adapt all users of PIOS_COM_* functions to new API - Fixup callers of PIOS_USB_HID_Init()
2011-07-26 06:27:03 +02:00
uint32_t pios_sbus_id;
sbus: better frame syncronization, some cosmetic changes In the previous version the decoder could in rare cases get synced from the middle of data stream in case of data byte equal to the S.Bus start of frame (SOF) byte (wrong data will be rejected but it was not perfect). Now it waits for the real start of frame and then checks the SOF byte.
2011-10-21 23:44:09 +02:00
if (PIOS_SBus_Init(&pios_sbus_id, &pios_sbus_cfg, &pios_usart_com_driver, pios_usart_sbus_id)) {
com: Move buffering out of USART/HID layer and into COM layer This allows the spektrum and sbus receiver drivers to bind directly to the usart layer using a properly exported API rather than overriding the interrupt handler. Bytes are now pushed directly from the usart layer into the com layer without any buffering. The com layer performs all of the buffering. A further benefit from this approach is that we can put all blocking/non-blocking behaviour into the COM layer and not in the underlying drivers. Misc related changes: - Remove obsolete .handler field from irq configs - Adapt all users of PIOS_COM_* functions to new API - Fixup callers of PIOS_USB_HID_Init()
2011-07-26 06:27:03 +02:00
PIOS_Assert(0);
}
Input Configuration: fix S.Bus receiver in multi-receiver code
2011-09-12 00:52:30 +02:00
uint32_t pios_sbus_rcvr_id;
if (PIOS_RCVR_Init(&pios_sbus_rcvr_id, &pios_sbus_rcvr_driver, pios_sbus_id)) {
PIOS_Assert(0);
}
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_SBUS] = pios_sbus_rcvr_id;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
#endif /* PIOS_INCLUDE_SBUS */
break;
case HWSETTINGS_CC_MAINPORT_GPS:
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
#if defined(PIOS_INCLUDE_GPS)
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
{
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_main_cfg)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_GPS_RX_BUF_LEN);
PIOS_Assert(rx_buffer);
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
if (PIOS_COM_Init(&pios_com_gps_id, &pios_usart_com_driver, pios_usart_generic_id,
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
rx_buffer, PIOS_COM_GPS_RX_BUF_LEN,
NULL, 0)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
}
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
#endif /* PIOS_INCLUDE_GPS */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
break;
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
case HWSETTINGS_CC_MAINPORT_DSM2:
case HWSETTINGS_CC_MAINPORT_DSMX10BIT:
case HWSETTINGS_CC_MAINPORT_DSMX11BIT:
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
#if defined(PIOS_INCLUDE_DSM)
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
{
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
enum pios_dsm_proto proto;
switch (hwsettings_cc_mainport) {
spektrum: code style fixes accoring to OPReview-122
2011-11-01 17:48:07 +01:00
case HWSETTINGS_CC_MAINPORT_DSM2:
proto = PIOS_DSM_PROTO_DSM2;
break;
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
case HWSETTINGS_CC_MAINPORT_DSMX10BIT:
proto = PIOS_DSM_PROTO_DSMX10BIT;
break;
case HWSETTINGS_CC_MAINPORT_DSMX11BIT:
proto = PIOS_DSM_PROTO_DSMX11BIT;
break;
default:
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
break;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
com: Move buffering out of USART/HID layer and into COM layer This allows the spektrum and sbus receiver drivers to bind directly to the usart layer using a properly exported API rather than overriding the interrupt handler. Bytes are now pushed directly from the usart layer into the com layer without any buffering. The com layer performs all of the buffering. A further benefit from this approach is that we can put all blocking/non-blocking behaviour into the COM layer and not in the underlying drivers. Misc related changes: - Remove obsolete .handler field from irq configs - Adapt all users of PIOS_COM_* functions to new API - Fixup callers of PIOS_USB_HID_Init()
2011-07-26 06:27:03 +02:00
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
uint32_t pios_usart_dsm_id;
if (PIOS_USART_Init(&pios_usart_dsm_id, &pios_usart_dsm_main_cfg)) {
com: Move buffering out of USART/HID layer and into COM layer This allows the spektrum and sbus receiver drivers to bind directly to the usart layer using a properly exported API rather than overriding the interrupt handler. Bytes are now pushed directly from the usart layer into the com layer without any buffering. The com layer performs all of the buffering. A further benefit from this approach is that we can put all blocking/non-blocking behaviour into the COM layer and not in the underlying drivers. Misc related changes: - Remove obsolete .handler field from irq configs - Adapt all users of PIOS_COM_* functions to new API - Fixup callers of PIOS_USB_HID_Init()
2011-07-26 06:27:03 +02:00
PIOS_Assert(0);
}
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
uint32_t pios_dsm_id;
if (PIOS_DSM_Init(&pios_dsm_id,
&pios_dsm_main_cfg,
&pios_usart_com_driver,
pios_usart_dsm_id,
proto, 0)) {
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
PIOS_Assert(0);
}
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
uint32_t pios_dsm_rcvr_id;
if (PIOS_RCVR_Init(&pios_dsm_rcvr_id, &pios_dsm_rcvr_driver, pios_dsm_id)) {
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
PIOS_Assert(0);
}
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_DSMMAINPORT] = pios_dsm_rcvr_id;
rcvr: convert PWM, PPM, SBUS and Spektrum to use PIOS_RCVR All receivers now fall under the same driver API provided by pios_rcvr.c. This is part of a larger sequence of commits that will switch the receiver selection over to boot time dynamic configuration via UAVObjects.
2011-06-25 15:27:28 +02:00
}
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
#endif /* PIOS_INCLUDE_DSM */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
break;
console: add support for serial debug consoles Serial ports now have a new HW setting called DebugConsole which can be used to dump internal state to a serial port for debug. To enable this feature, you need to: - make fw_coptercontrol_clean - make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES - configure one of the serial ports as DebugConsole in the GCS - save settings - power-cycle your board Things to note: - The console is at 57600,8N1. - This is not currently configurable via the GCS. - You can only have a single console enabled at a time.
2012-10-11 06:06:28 +02:00
case HWSETTINGS_CC_MAINPORT_DEBUGCONSOLE:
#if defined(PIOS_INCLUDE_COM)
#if defined(PIOS_INCLUDE_DEBUG_CONSOLE)
{
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_main_cfg)) {
PIOS_Assert(0);
}
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN);
PIOS_Assert(tx_buffer);
if (PIOS_COM_Init(&pios_com_debug_id, &pios_usart_com_driver, pios_usart_generic_id,
NULL, 0,
tx_buffer, PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_DEBUG_CONSOLE */
#endif /* PIOS_INCLUDE_COM */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
break;
com-bridge: add usart to usb vcp bridge
2011-12-22 03:04:29 +01:00
case HWSETTINGS_CC_MAINPORT_COMBRIDGE:
{
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_main_cfg)) {
PIOS_Assert(0);
}
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_BRIDGE_RX_BUF_LEN);
PIOS_Assert(rx_buffer);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_BRIDGE_TX_BUF_LEN);
PIOS_Assert(tx_buffer);
if (PIOS_COM_Init(&pios_com_bridge_id, &pios_usart_com_driver, pios_usart_generic_id,
rx_buffer, PIOS_COM_BRIDGE_RX_BUF_LEN,
tx_buffer, PIOS_COM_BRIDGE_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
break;
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
}
sbus: some code cleanup (no functional changes)
2011-06-19 13:30:13 +02:00
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
/* Configure the flexi port */
uint8_t hwsettings_cc_flexiport;
HwSettingsCC_FlexiPortGet(&hwsettings_cc_flexiport);
switch (hwsettings_cc_flexiport) {
case HWSETTINGS_CC_FLEXIPORT_DISABLED:
break;
case HWSETTINGS_CC_FLEXIPORT_TELEMETRY:
#if defined(PIOS_INCLUDE_TELEMETRY_RF)
{
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_flexi_cfg)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_RF_RX_BUF_LEN);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_TELEM_RF_TX_BUF_LEN);
PIOS_Assert(rx_buffer);
PIOS_Assert(tx_buffer);
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
if (PIOS_COM_Init(&pios_com_telem_rf_id, &pios_usart_com_driver, pios_usart_generic_id,
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
rx_buffer, PIOS_COM_TELEM_RF_RX_BUF_LEN,
tx_buffer, PIOS_COM_TELEM_RF_TX_BUF_LEN)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_TELEMETRY_RF */
break;
com-bridge: add support for bridging to flexiport
2011-12-28 22:17:10 +01:00
case HWSETTINGS_CC_FLEXIPORT_COMBRIDGE:
{
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_flexi_cfg)) {
PIOS_Assert(0);
}
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_BRIDGE_RX_BUF_LEN);
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_BRIDGE_TX_BUF_LEN);
PIOS_Assert(rx_buffer);
PIOS_Assert(tx_buffer);
if (PIOS_COM_Init(&pios_com_bridge_id, &pios_usart_com_driver, pios_usart_generic_id,
rx_buffer, PIOS_COM_BRIDGE_RX_BUF_LEN,
tx_buffer, PIOS_COM_BRIDGE_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
break;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
case HWSETTINGS_CC_FLEXIPORT_GPS:
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
#if defined(PIOS_INCLUDE_GPS)
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
{
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_flexi_cfg)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
uint8_t * rx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_GPS_RX_BUF_LEN);
PIOS_Assert(rx_buffer);
init: collapse usart definitions for generic usage Telemetry and GPS usarts are generic users of the uart devices. This collapses the duplicated usart configuration structs into a single generic one.
2011-12-22 03:03:41 +01:00
if (PIOS_COM_Init(&pios_com_gps_id, &pios_usart_com_driver, pios_usart_generic_id,
com: allow run-time allocation of buffers
2011-07-29 16:04:55 +02:00
rx_buffer, PIOS_COM_GPS_RX_BUF_LEN,
CopterControl: Fix GPS buffer sizes
2011-08-25 15:37:38 +02:00
NULL, 0)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_GPS */
break;
OP-814: Added PPM input on the FlexiPort for CC/CC3D.
2013-01-19 17:50:51 +01:00
case HWSETTINGS_CC_FLEXIPORT_PPM:
#if defined(PIOS_INCLUDE_PPM_FLEXI)
{
uint32_t pios_ppm_id;
PIOS_PPM_Init(&pios_ppm_id, &pios_ppm_flexi_cfg);
uint32_t pios_ppm_rcvr_id;
if (PIOS_RCVR_Init(&pios_ppm_rcvr_id, &pios_ppm_rcvr_driver, pios_ppm_id)) {
PIOS_Assert(0);
}
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_PPM] = pios_ppm_rcvr_id;
}
#endif /* PIOS_INCLUDE_PPM_FLEXI */
break;
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
case HWSETTINGS_CC_FLEXIPORT_DSM2:
case HWSETTINGS_CC_FLEXIPORT_DSMX10BIT:
case HWSETTINGS_CC_FLEXIPORT_DSMX11BIT:
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
#if defined(PIOS_INCLUDE_DSM)
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
{
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
enum pios_dsm_proto proto;
switch (hwsettings_cc_flexiport) {
spektrum: code style fixes accoring to OPReview-122
2011-11-01 17:48:07 +01:00
case HWSETTINGS_CC_FLEXIPORT_DSM2:
proto = PIOS_DSM_PROTO_DSM2;
break;
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
case HWSETTINGS_CC_FLEXIPORT_DSMX10BIT:
proto = PIOS_DSM_PROTO_DSMX10BIT;
break;
case HWSETTINGS_CC_FLEXIPORT_DSMX11BIT:
proto = PIOS_DSM_PROTO_DSMX11BIT;
break;
default:
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
spektrum: rework DSM2/DSMJ/DSMX driver for explicit DSMX resolution support - both CC serial ports are now disabled by default (no telemetry); - serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options; - ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options. For DSM2 protocol there is an explicit resolution bit in the stream, so the DSM2 should be selected. For DSMX there is no such bit, and user should choose the resolution from the list configuring the spektrum port. ReceiverGroups have single DSM option which is handled by the same driver. Downside: this implementation saves received frame first, unrolls by the end of frame. This should be ok, but may be improved by unrolling channels on the fly in the rx callback. Another minor difference is that a ChannelGroup is now bound to port: DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable solution in order to not have 6 DSM options for each ChannelGroup and even more in case of new DSM protocol variations. Known problem: it is not possible to choose same protocols like DSM2/DSM2 for two ports. It can be enabled by adding an exception to common rule, though. The DSMX throttle channel misbehavior (zero value) is not treated specially yet. It should trigger the failsafe being out of bounds. More info and data dumps are required to handle this properly.
2011-10-30 18:29:03 +01:00
break;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
com: Move buffering out of USART/HID layer and into COM layer This allows the spektrum and sbus receiver drivers to bind directly to the usart layer using a properly exported API rather than overriding the interrupt handler. Bytes are now pushed directly from the usart layer into the com layer without any buffering. The com layer performs all of the buffering. A further benefit from this approach is that we can put all blocking/non-blocking behaviour into the COM layer and not in the underlying drivers. Misc related changes: - Remove obsolete .handler field from irq configs - Adapt all users of PIOS_COM_* functions to new API - Fixup callers of PIOS_USB_HID_Init()
2011-07-26 06:27:03 +02:00
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
uint32_t pios_usart_dsm_id;
if (PIOS_USART_Init(&pios_usart_dsm_id, &pios_usart_dsm_flexi_cfg)) {
com: Move buffering out of USART/HID layer and into COM layer This allows the spektrum and sbus receiver drivers to bind directly to the usart layer using a properly exported API rather than overriding the interrupt handler. Bytes are now pushed directly from the usart layer into the com layer without any buffering. The com layer performs all of the buffering. A further benefit from this approach is that we can put all blocking/non-blocking behaviour into the COM layer and not in the underlying drivers. Misc related changes: - Remove obsolete .handler field from irq configs - Adapt all users of PIOS_COM_* functions to new API - Fixup callers of PIOS_USB_HID_Init()
2011-07-26 06:27:03 +02:00
PIOS_Assert(0);
}
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
uint32_t pios_dsm_id;
if (PIOS_DSM_Init(&pios_dsm_id,
&pios_dsm_flexi_cfg,
&pios_usart_com_driver,
pios_usart_dsm_id,
proto, hwsettings_DSMxBind)) {
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
PIOS_Assert(0);
}
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
uint32_t pios_dsm_rcvr_id;
if (PIOS_RCVR_Init(&pios_dsm_rcvr_id, &pios_dsm_rcvr_driver, pios_dsm_id)) {
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
PIOS_Assert(0);
}
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_DSMFLEXIPORT] = pios_dsm_rcvr_id;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
spektrum: rename Spektrum to DSM (DSM2/DSMJ/DSMX used by Spektrum and JR radios) No code changes, just file, variable and define names are changed. First, it better describes the serial protocol used by DSMx satellite receivers. Second, many people using Spektrum radio, assume Spektrum protocol. This is the attempt to address those inaccuracies.
2011-11-04 20:40:34 +01:00
#endif /* PIOS_INCLUDE_DSM */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
break;
console: add support for serial debug consoles Serial ports now have a new HW setting called DebugConsole which can be used to dump internal state to a serial port for debug. To enable this feature, you need to: - make fw_coptercontrol_clean - make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES - configure one of the serial ports as DebugConsole in the GCS - save settings - power-cycle your board Things to note: - The console is at 57600,8N1. - This is not currently configurable via the GCS. - You can only have a single console enabled at a time.
2012-10-11 06:06:28 +02:00
case HWSETTINGS_CC_FLEXIPORT_DEBUGCONSOLE:
#if defined(PIOS_INCLUDE_COM)
#if defined(PIOS_INCLUDE_DEBUG_CONSOLE)
{
uint32_t pios_usart_generic_id;
if (PIOS_USART_Init(&pios_usart_generic_id, &pios_usart_generic_flexi_cfg)) {
PIOS_Assert(0);
}
uint8_t * tx_buffer = (uint8_t *) pvPortMalloc(PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN);
PIOS_Assert(tx_buffer);
if (PIOS_COM_Init(&pios_com_debug_id, &pios_usart_com_driver, pios_usart_generic_id,
NULL, 0,
tx_buffer, PIOS_COM_DEBUGCONSOLE_TX_BUF_LEN)) {
PIOS_Assert(0);
}
}
#endif /* PIOS_INCLUDE_DEBUG_CONSOLE */
#endif /* PIOS_INCLUDE_COM */
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
break;
case HWSETTINGS_CC_FLEXIPORT_I2C:
#if defined(PIOS_INCLUDE_I2C)
{
altitude: add optional altitude module
2012-01-14 21:17:24 +01:00
if (PIOS_I2C_Init(&pios_i2c_flexi_adapter_id, &pios_i2c_flexi_adapter_cfg)) {
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
PIOS_Assert(0);
}
rcvr: convert PWM, PPM, SBUS and Spektrum to use PIOS_RCVR All receivers now fall under the same driver API provided by pios_rcvr.c. This is part of a larger sequence of commits that will switch the receiver selection over to boot time dynamic configuration via UAVObjects.
2011-06-25 15:27:28 +02:00
}
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
#endif /* PIOS_INCLUDE_I2C */
break;
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
}
rcvr: convert PWM, PPM, SBUS and Spektrum to use PIOS_RCVR All receivers now fall under the same driver API provided by pios_rcvr.c. This is part of a larger sequence of commits that will switch the receiver selection over to boot time dynamic configuration via UAVObjects.
2011-06-25 15:27:28 +02:00
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
/* Configure the rcvr port */
uint8_t hwsettings_rcvrport;
Mainboard config: The rcvr port is used for PPM/PWM/Spektrum so make these one setting that is mutually exclusive.
2011-09-10 21:19:12 +02:00
HwSettingsCC_RcvrPortGet(&hwsettings_rcvrport);
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
switch (hwsettings_rcvrport) {
Mainboard config: The rcvr port is used for PPM/PWM/Spektrum so make these one setting that is mutually exclusive.
2011-09-10 21:19:12 +02:00
case HWSETTINGS_CC_RCVRPORT_DISABLED:
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
break;
Mainboard config: The rcvr port is used for PPM/PWM/Spektrum so make these one setting that is mutually exclusive.
2011-09-10 21:19:12 +02:00
case HWSETTINGS_CC_RCVRPORT_PWM:
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
#if defined(PIOS_INCLUDE_PWM)
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
{
uint32_t pios_pwm_id;
PIOS_PWM_Init(&pios_pwm_id, &pios_pwm_cfg);
uint32_t pios_pwm_rcvr_id;
if (PIOS_RCVR_Init(&pios_pwm_rcvr_id, &pios_pwm_rcvr_driver, pios_pwm_id)) {
rcvr: specify drivers for groups of channels Each channel was previously tracking a separate driver. Now, channels are grouped within a channel group to save RAM used for tracking and to better reflect how channels are actually mapped.
2011-07-15 03:52:07 +02:00
PIOS_Assert(0);
}
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_PWM] = pios_pwm_rcvr_id;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
#endif /* PIOS_INCLUDE_PWM */
break;
Mainboard config: The rcvr port is used for PPM/PWM/Spektrum so make these one setting that is mutually exclusive.
2011-09-10 21:19:12 +02:00
case HWSETTINGS_CC_RCVRPORT_PPM:
CC: rename ReceiverPort PPM+Servo (Servo) options to PPM+Outputs (Outputs)
2011-12-11 21:52:51 +01:00
case HWSETTINGS_CC_RCVRPORT_PPMOUTPUTS:
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
#if defined(PIOS_INCLUDE_PPM)
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
{
uint32_t pios_ppm_id;
PIOS_PPM_Init(&pios_ppm_id, &pios_ppm_cfg);
uint32_t pios_ppm_rcvr_id;
if (PIOS_RCVR_Init(&pios_ppm_rcvr_id, &pios_ppm_rcvr_driver, pios_ppm_id)) {
rcvr: specify drivers for groups of channels Each channel was previously tracking a separate driver. Now, channels are grouped within a channel group to save RAM used for tracking and to better reflect how channels are actually mapped.
2011-07-15 03:52:07 +02:00
PIOS_Assert(0);
}
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_PPM] = pios_ppm_rcvr_id;
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
#endif /* PIOS_INCLUDE_PPM */
break;
rcvr: Support PPM and PWM at the same time on CC Adds a new mode for the receiver port (PPM+PWM) which will allow simultaneous use of 1 pin for PPM and the rest of the pins for PWM inputs.
2012-09-30 01:09:27 +02:00
case HWSETTINGS_CC_RCVRPORT_PPMPWM:
/* This is a combination of PPM and PWM inputs */
#if defined(PIOS_INCLUDE_PPM)
{
uint32_t pios_ppm_id;
PIOS_PPM_Init(&pios_ppm_id, &pios_ppm_cfg);
uint32_t pios_ppm_rcvr_id;
if (PIOS_RCVR_Init(&pios_ppm_rcvr_id, &pios_ppm_rcvr_driver, pios_ppm_id)) {
PIOS_Assert(0);
}
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_PPM] = pios_ppm_rcvr_id;
}
#endif /* PIOS_INCLUDE_PPM */
#if defined(PIOS_INCLUDE_PWM)
{
uint32_t pios_pwm_id;
PIOS_PWM_Init(&pios_pwm_id, &pios_pwm_with_ppm_cfg);
uint32_t pios_pwm_rcvr_id;
if (PIOS_RCVR_Init(&pios_pwm_rcvr_id, &pios_pwm_rcvr_driver, pios_pwm_id)) {
PIOS_Assert(0);
}
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_PWM] = pios_pwm_rcvr_id;
}
#endif /* PIOS_INCLUDE_PWM */
break;
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
}
rcvr: Add GCS receiver driver for rcvr via telemetry This allows the GCS to emulate a receiver device via the telemetry link. Select "GCS" as your input type in the manualcontrol config screen and calibrate it as normal. Note: The expected values for the channels are in microseconds just like a PWM or PPM input device. The channel values are validated against minimum/maximum pulse lengths just like normal receivers.
2011-07-28 14:22:47 +02:00
#if defined(PIOS_INCLUDE_GCSRCVR)
Initialize GCSReceiver object if it is being used
2011-08-27 22:57:09 +02:00
GCSReceiverInitialize();
Added failsafe to GCS Receiver device.
2012-02-03 03:58:42 +01:00
uint32_t pios_gcsrcvr_id;
PIOS_GCSRCVR_Init(&pios_gcsrcvr_id);
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
uint32_t pios_gcsrcvr_rcvr_id;
Added failsafe to GCS Receiver device.
2012-02-03 03:58:42 +01:00
if (PIOS_RCVR_Init(&pios_gcsrcvr_rcvr_id, &pios_gcsrcvr_rcvr_driver, pios_gcsrcvr_id)) {
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
PIOS_Assert(0);
bootcfg: use UAVobj to control boot-time HW config This should mark an end to the compile-time selection of HW configurations. Minor changes in board initialization for all platforms: - Most config structs are marked static to prevent badly written drivers from directly referring to config data. - Adapt to changes in .irq fields in config data. - Adapt to changes in USART IRQ handling. Major changes in board initialization for CC: - Use HwSettings UAVObj to decide which drivers to attach to the "main" port and the flexi port, and select the appropriate device configuration data. - HwSettings allows choosing between Disabled, Telemetry, SBUS, Spektrum,GPS, and I2C for each of the two ports. - Use ManualControlSettings.InputMode to init/configure the appropriate receiver module, and register its available rx channels with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM at board init time. PPM driver is broken, and SBUS will work once it is added to this UAVObj as an option. - CC build now includes code for SBUS, Spektrum and PWM receivers in every firmware image. PIOS_USART driver: - Now handles its own low-level IRQs internally - If NULL upper-level IRQ handler is bound in at board init time then rx/tx is satisfied by internal PIOS_USART buffered IO routines which are (typically) attached to the COM layer. - If an alternate upper-level IRQ handler is bound in at board init then that handler is called and expected to clear down the USART IRQ sources. This is used by Spektrum and SBUS drivers. PIOS_SBUS and PIOS_SPEKTRUM drivers: - Improved data/API hiding - No longer assume they know where their config data is stored which allows for boot-time alternate configurations for the driver. - Now registers an upper-level IRQ handlerwith the USART layer to decouple the driver from which USART it is actually attached to.
2011-07-06 02:21:00 +02:00
}
rcvr: support multiple simultaneous receivers Now also supports multiple instances of the Spektrum driver. These are configured as Spektrum1 and Spektrum2.
2011-07-30 21:04:24 +02:00
pios_rcvr_group_map[MANUALCONTROLSETTINGS_CHANNELGROUPS_GCS] = pios_gcsrcvr_rcvr_id;
#endif /* PIOS_INCLUDE_GCSRCVR */
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
bootfault: add support for recovery from init failures After 3 failed warm start attempts, the init sequence will force the RAM version of the HWSettings object to its defaults. This should allow a user to regain connectivity to a board that is continually faulting during init. This is accomplished by: - Incrementing a boot counter that is stored in the STM32 BKP registers. These registers survive a warm start but are cleared on a cold start (ie. powerup). - On multiple failures, force hwsettings to defaults and raise the (new) BootFault alarm to prevent arming. - Resetting the boot counter whenever the system manages to successfully run the System Module task. NOTE: This does not actually change the hwsettings object in flash. That's up to the user. This is intended to catch ONLY faults during early initialization. It should not be used to recover from faults after the application is up and running.
2011-12-30 19:26:54 +01:00
/* Remap AFIO pin for PB4 (Servo 5 Out)*/
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
GPIO_PinRemapConfig( GPIO_Remap_SWJ_NoJTRST, ENABLE);
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
#ifndef PIOS_DEBUG_ENABLE_DEBUG_PINS
CC: When receiver port is set to PPM_SERVO use the spare pins as outputs
2011-10-11 07:17:21 +02:00
switch (hwsettings_rcvrport) {
case HWSETTINGS_CC_RCVRPORT_DISABLED:
case HWSETTINGS_CC_RCVRPORT_PWM:
case HWSETTINGS_CC_RCVRPORT_PPM:
rcvr: Support PPM and PWM at the same time on CC Adds a new mode for the receiver port (PPM+PWM) which will allow simultaneous use of 1 pin for PPM and the rest of the pins for PWM inputs.
2012-09-30 01:09:27 +02:00
case HWSETTINGS_CC_RCVRPORT_PPMPWM:
CC: When receiver port is set to PPM_SERVO use the spare pins as outputs
2011-10-11 07:17:21 +02:00
PIOS_Servo_Init(&pios_servo_cfg);
break;
CC: rename ReceiverPort PPM+Servo (Servo) options to PPM+Outputs (Outputs)
2011-12-11 21:52:51 +01:00
case HWSETTINGS_CC_RCVRPORT_PPMOUTPUTS:
case HWSETTINGS_CC_RCVRPORT_OUTPUTS:
CC: When receiver port is set to PPM_SERVO use the spare pins as outputs
2011-10-11 07:17:21 +02:00
PIOS_Servo_Init(&pios_servo_rcvr_cfg);
break;
}
Make PWM/PPM and Servo drivers play nicely together PWM and PPM can now coexist in the same load and be selected at boot time via the hwsettings UAVObject. This is basically a complete restructuring of the way the drivers interact with the TIM peripheral in the STM32. As a side effect, the PWM and PPM drivers are now ready to support multiple instances of each. This also provides the first step toward being able to reassign some of the PWM input pins to be servo output pins. Still more work required, but this is a good start.
2011-08-13 05:23:16 +02:00
#else
PIOS_DEBUG_Init(&pios_tim_servo_all_channels, NELEMENTS(pios_tim_servo_all_channels));
#endif /* PIOS_DEBUG_ENABLE_DEBUG_PINS */
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
Unfortunately for now hardcoding new LED configuration. Need to generalize LED out to a proper run-time configuration. This unfortunately breaks a general firmware for now.
2012-01-20 22:45:22 +01:00
switch(bdinfo->board_rev) {
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC:
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
// Revision 1 with invensense gyros, start the ADC
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
#if defined(PIOS_INCLUDE_ADC)
PiOS ADC: This could still use a lot of cleanup and needs to be implemented in the non-FreeRTOS case but now the ADC device is allocated dynamically which means CC3D won't waste heap on it.
2012-05-01 18:11:31 +02:00
PIOS_ADC_Init(&pios_adc_cfg);
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
#endif
Got CC running again although with altitude and bmp085 disabled as well as the CC3D drivers.
2012-01-24 17:32:42 +01:00
#if defined(PIOS_INCLUDE_ADXL345)
Fix small bugs in pios_board.c relating to adxl345 spi configuration
2012-01-24 08:25:53 +01:00
PIOS_ADXL345_Init(pios_spi_flash_accel_id, 0);
Got CC running again although with altitude and bmp085 disabled as well as the CC3D drivers.
2012-01-24 17:32:42 +01:00
#endif
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
break;
cc: use defines for board revisions instead of hard-coded numbers
2012-05-23 06:29:12 +02:00
case BOARD_REVISION_CC3D:
Fix small bugs in pios_board.c relating to adxl345 spi configuration
2012-01-24 08:25:53 +01:00
// Revision 2 with L3GD20 gyros, start a SPI interface and connect to it
Unfortunately for now hardcoding new LED configuration. Need to generalize LED out to a proper run-time configuration. This unfortunately breaks a general firmware for now.
2012-01-20 22:45:22 +01:00
GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
#if defined(PIOS_INCLUDE_MPU6000)
Fix small bugs in pios_board.c relating to adxl345 spi configuration
2012-01-24 08:25:53 +01:00
// Set up the SPI interface to the serial flash
if (PIOS_SPI_Init(&pios_spi_gyro_id, &pios_spi_gyro_cfg)) {
PIOS_Assert(0);
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
}
Switch the MPU6000 driver to using a FreeRTOS queue. Need to update Revo code to take advantage of this.
2012-03-26 10:03:38 +02:00
PIOS_MPU6000_Init(pios_spi_gyro_id,0,&pios_mpu6000_cfg);
Get the MPU6000 CC3D working. Right now the ADC system is commented out, which will break regular CC.
2012-03-26 07:22:59 +02:00
init_test = PIOS_MPU6000_Test();
#endif /* PIOS_INCLUDE_MPU6000 */
Fix small bugs in pios_board.c relating to adxl345 spi configuration
2012-01-24 08:25:53 +01:00
Switch the gyro driver loaded based on the board revision flag from the bootloader
2012-01-20 21:52:05 +01:00
break;
default:
PIOS_Assert(0);
}
Fix small bugs in pios_board.c relating to adxl345 spi configuration
2012-01-24 08:25:53 +01:00
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
PIOS_GPIO_Init();
bootfault: fail initialization if no telemetry link is configured This detects a locked out state and fails the init. The new bootfault detection code will automatically drop to default hwsettings after 3 consecutive boot failures. That will put the board back into an unlocked state where the user can now enable a telemetry link using the GCS and everything will be OK. NOTE: Any configured telemetry link will be considered enough to boot up. If you only configure a serial telemetry link but don't know how to hook anything up to it, this will not save you. As the ultimate recovery, you can always load firmware on the board that wipes the settings entirely and start over.
2011-12-31 19:08:30 +01:00
/* Make sure we have at least one telemetry link configured or else fail initialization */
PIOS_Assert(pios_com_telem_rf_id || pios_com_telem_usb_id);
hwinit: Convert COM and USART to dynamic init git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2771 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 23:19:43 +01:00
}
OP-265 Flight reorganization of UAVObjects and Modules up a directory git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2415 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-14 02:38:19 +01:00
/**
* @}
*/
Reference in New Issue Copy Permalink