view src/cs/riviera/rv_template/xxx_state_i.h @ 629:3231dd9b38c1

armio.c: make GPIOs 8 & 13 outputs driving 1 on all "classic" targets Calypso GPIOs 8 & 13 are pinmuxed with MCUEN1 & MCUEN2, respectively, and on powerup these pins are MCUEN, i.e., outputs driving 1. TI's code for C-Sample and earlier turns them into GPIOs configured as outputs also driving 1 - so far, so good - but TI's code for BOARD 41 (which covers D-Sample, Leonardo and all real world Calypso devices derived from the latter) switches them from MCUEN to GPIOs, but then leaves them as inputs. Given that the hardware powerup state of these two pins is outputs driving 1, every Calypso board design MUST be compatible with such driving; typically these GPIO signals will be either unused and unconnected or connected as outputs driving some peripheral. Turning these pins into GPIO inputs will result in floating inputs on every reasonably-wired board, thus I am convinced that this configuration is nothing but a bug on the part of whoever wrote this code at TI. This floating input bug had already been fixed earlier for GTA modem and FCDEV3B targets; the present change makes the fix unconditional for all "classic" targets. The newly affected targets are D-Sample, Leonardo, Tango and GTM900.
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 02 Jan 2020 05:38:26 +0000
parents 945cf7f506b2
children
line wrap: on
line source

/**
 * @file	xxx_state_i.h
 * 
 * Internal definitions for XXX state machine, 
 * i.e. the states and the functions corresponding to the states.
 *
 * The messages are declared in xxx_message.h, since they can 
 * be seen from outside.
 *
 * @author	Your name here (your_email_here)
 * @version 0.1
 */

/*
 * History:
 *
 *	Date       	Author					Modification
 *	-------------------------------------------------------------------
 *	//							Create.
 *
 * (C) Copyright 2001 by Texas Instruments Incorporated, All Rights Reserved
 */

#ifndef __XXX_STATE_I_H_
#define __XXX_STATE_I_H_


#include "rv/rv_general.h"


/**
 * XXX states.
 *
 * XXX instance is a state machine with several possible states.
 * Based on the current state, XXX handle different kind of messages/events.
 * States are listed in the order they should normally be sequenced.
 *
 * See the Readme file for a description of the state machine.
 */
typedef enum
{
	XXX_STATE_1,
	XXX_STATE_2
} T_XXX_INTERNAL_STATE;


/*
 * Optional but	recommanded, define a function for the processing
 * in each state, like:
 *   T_XXX_RETURN xxx_state_1					(T_RV_HDR * message_p);
 *   T_XXX_RETURN xxx_state_2					(T_RV_HDR * message_p);
 */

#endif /* __XXX_STATE_I_H_ */