1
0
mirror of https://bitbucket.org/librepilot/librepilot.git synced 2024-11-30 08:24:11 +01:00
LibrePilot/flight/PiOS/inc/pios_i2c.h

79 lines
2.3 KiB
C
Raw Normal View History

/**
******************************************************************************
* @addtogroup PIOS PIOS Core hardware abstraction layer
* @{
* @addtogroup PIOS_I2C I2C Functions
* @{
*
* @file pios_i2c.h
* @author The OpenPilot Team, http://www.openpilot.org Copyright (C) 2010.
* @brief I2C functions header.
* @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
*/
#ifndef PIOS_I2C_H
#define PIOS_I2C_H
#define PIOS_I2C_DIAGNOSTICS
PiOS/I2C: Lots of small changes. Added a few weird bus events that are sometimes thrown, and made errors not lock it up by default. It works for me, but since this has historically been associated with lots of lock ups please check your systems carefully. PiOS/I2C: Make the bus by default try to recover from errors instead of locking up PiOS/I2C: After a bus error and clocking all previous data create a STOP condition to make sure bus is released (note, this also requires creating a START condition first) PiOS/I2C: If the same event hits the I2C bus twice in a row then disregard second one, there is no situation where we should get the same event multiple times that matters and this gets us out really quickly to catch the real events. I was seeing this with repeated 0x70084 which means byte transmitted. This is related to STM32 bugs in the IRQ timings I believe. PiOS/I2C: 1) Mask out some bits we don't care about in the event flags 2) Don't lock up if the give semaphore fails, although why it does is strange 3) Recover from bus failure through the "auto" state path instead of just coding state PiOS/I2C: Change the reset bus code to follow http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf (thanks for the reference Neontangerine). Although this may actually NOT clear the bus the first time through, subsequent bus errors should eventually clock it out. The up side is it is less likely to clock a bunch of 1s into an ESC and make it run up. PiOS/I2C: Some cleaned up code for getting a snippet of the history when something strange happens PiOS/I2C: Export logging information from I2C through a UAV object PiOS/I2C: Improve the diagnostic information PiOS/I2C: Need to handle the event 0x30084. This seems to happen between a byte transmitted and new byte started PiOS/I2C: Handle the NACK condition by simply going to the stopping state. PiOS/I2C: Add a new NACK state to handle sending the STOP signal after a NACK following the STM documentation. Other error conditions still are not dealt with. PiOS/I2C: Should handle the NACK condition from all the write cases. Need to think about read cases git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2239 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-12-17 08:01:58 +01:00
#include <stdbool.h>
/* Global Types */
enum pios_i2c_txn_direction {
PIOS_I2C_TXN_READ,
PIOS_I2C_TXN_WRITE
};
struct pios_i2c_txn {
const char *info;
uint16_t addr;
enum pios_i2c_txn_direction rw;
uint32_t len;
uint8_t *buf;
};
2011-08-13 14:13:21 +02:00
#define I2C_LOG_DEPTH 20
PiOS/I2C: Lots of small changes. Added a few weird bus events that are sometimes thrown, and made errors not lock it up by default. It works for me, but since this has historically been associated with lots of lock ups please check your systems carefully. PiOS/I2C: Make the bus by default try to recover from errors instead of locking up PiOS/I2C: After a bus error and clocking all previous data create a STOP condition to make sure bus is released (note, this also requires creating a START condition first) PiOS/I2C: If the same event hits the I2C bus twice in a row then disregard second one, there is no situation where we should get the same event multiple times that matters and this gets us out really quickly to catch the real events. I was seeing this with repeated 0x70084 which means byte transmitted. This is related to STM32 bugs in the IRQ timings I believe. PiOS/I2C: 1) Mask out some bits we don't care about in the event flags 2) Don't lock up if the give semaphore fails, although why it does is strange 3) Recover from bus failure through the "auto" state path instead of just coding state PiOS/I2C: Change the reset bus code to follow http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf (thanks for the reference Neontangerine). Although this may actually NOT clear the bus the first time through, subsequent bus errors should eventually clock it out. The up side is it is less likely to clock a bunch of 1s into an ESC and make it run up. PiOS/I2C: Some cleaned up code for getting a snippet of the history when something strange happens PiOS/I2C: Export logging information from I2C through a UAV object PiOS/I2C: Improve the diagnostic information PiOS/I2C: Need to handle the event 0x30084. This seems to happen between a byte transmitted and new byte started PiOS/I2C: Handle the NACK condition by simply going to the stopping state. PiOS/I2C: Add a new NACK state to handle sending the STOP signal after a NACK following the STM documentation. Other error conditions still are not dealt with. PiOS/I2C: Should handle the NACK condition from all the write cases. Need to think about read cases git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2239 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-12-17 08:01:58 +01:00
enum pios_i2c_error_type {
PIOS_I2C_ERROR_EVENT,
PIOS_I2C_ERROR_FSM,
PIOS_I2C_ERROR_INTERRUPT
};
struct pios_i2c_fault_history {
enum pios_i2c_error_type type;
uint32_t evirq[I2C_LOG_DEPTH];
uint32_t erirq[I2C_LOG_DEPTH];
uint8_t event[I2C_LOG_DEPTH];
uint8_t state[I2C_LOG_DEPTH];
PiOS/I2C: Lots of small changes. Added a few weird bus events that are sometimes thrown, and made errors not lock it up by default. It works for me, but since this has historically been associated with lots of lock ups please check your systems carefully. PiOS/I2C: Make the bus by default try to recover from errors instead of locking up PiOS/I2C: After a bus error and clocking all previous data create a STOP condition to make sure bus is released (note, this also requires creating a START condition first) PiOS/I2C: If the same event hits the I2C bus twice in a row then disregard second one, there is no situation where we should get the same event multiple times that matters and this gets us out really quickly to catch the real events. I was seeing this with repeated 0x70084 which means byte transmitted. This is related to STM32 bugs in the IRQ timings I believe. PiOS/I2C: 1) Mask out some bits we don't care about in the event flags 2) Don't lock up if the give semaphore fails, although why it does is strange 3) Recover from bus failure through the "auto" state path instead of just coding state PiOS/I2C: Change the reset bus code to follow http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf (thanks for the reference Neontangerine). Although this may actually NOT clear the bus the first time through, subsequent bus errors should eventually clock it out. The up side is it is less likely to clock a bunch of 1s into an ESC and make it run up. PiOS/I2C: Some cleaned up code for getting a snippet of the history when something strange happens PiOS/I2C: Export logging information from I2C through a UAV object PiOS/I2C: Improve the diagnostic information PiOS/I2C: Need to handle the event 0x30084. This seems to happen between a byte transmitted and new byte started PiOS/I2C: Handle the NACK condition by simply going to the stopping state. PiOS/I2C: Add a new NACK state to handle sending the STOP signal after a NACK following the STM documentation. Other error conditions still are not dealt with. PiOS/I2C: Should handle the NACK condition from all the write cases. Need to think about read cases git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2239 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-12-17 08:01:58 +01:00
};
/* Public Functions */
extern int32_t PIOS_I2C_Transfer(uint32_t i2c_id, const struct pios_i2c_txn txn_list[], uint32_t num_txns);
extern int32_t PIOS_I2C_Transfer_Callback(uint32_t i2c_id, const struct pios_i2c_txn txn_list[], uint32_t num_txns, void *callback);
extern void PIOS_I2C_EV_IRQ_Handler(uint32_t i2c_id);
extern void PIOS_I2C_ER_IRQ_Handler(uint32_t i2c_id);
extern void PIOS_I2C_GetDiagnostics(struct pios_i2c_fault_history * data, uint8_t * error_counts);
#endif /* PIOS_I2C_H */
/**
* @}
* @}
*/