Hydra Analog Inputs slow/unresponsive on socket 14

taylorza · September 15, 2012, 2:53pm

Hi,

The analog input on socket 14 seems to be very laggy, this is observed with the Joystick module.

I moved the Rally-X game over to the Hydra and the scrolling is buttery smooth, but the Joystick was unresponsive especially in the X direction. Initially I thought that I was missing readings because I only read the joystick once every frame update, but increasing the number of reads did not help the situation at all. As a last ditch effort I moved the joystick to socket 13 and surprisingly, to me anyway, the joystick response is perfect.

Is there a known issue using one or more of the analog inputs on the Hydra socket 14? I believe my Hydra is fully up to date


DeviceInfo:
  HAL build info: 4.2.0.0, Microsoft Copyright (C) Microsoft Corporation.  All rig
  OEM Product codes (vendor, model, SKU): 255, 0, 65535
  Serial Numbers (module, system):
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  Solution Build Info: 4.2.3.0, Copyright (C) GHI Electronics, LLC
  AppDomains:
    default, id=1
  Assemblies:
    mscorlib,4.2.0.0
    Microsoft.SPOT.Native,4.2.0.0
    Microsoft.SPOT.Hardware,4.2.0.0
    Microsoft.SPOT.Graphics,4.2.0.0
    Microsoft.SPOT.TinyCore,4.2.0.0
    Microsoft.SPOT.IO,4.2.0.0
    System.IO,4.2.0.0
    Microsoft.SPOT.Hardware.Usb,4.2.0.0
    Microsoft.SPOT.Hardware.SerialPort,4.2.0.0
    Microsoft.SPOT.Touch,4.2.0.0
    Microsoft.SPOT.Ink,4.2.0.0
    Microsoft.SPOT.Hardware.PWM,4.2.0.1
    Microsoft.SPOT.Hardware.OneWire,4.2.0.0
    System.Xml,4.2.0.0
    Microsoft.SPOT.Time,4.2.0.0
    Microsoft.SPOT.Net,4.2.0.0
    System,4.2.0.0
    Microsoft.SPOT.Net.Security,4.2.0.0
    System.Net.Security,4.2.0.0
    Gadgeteer,2.42.0.0
    GTM.GHIElectronics.Joystick,1.0.1.0
    GTM.GHIElectronics.Display_T35,1.0.0.0
    System.Http,4.2.0.0
    GHI.OSHW.Hardware,4.2.3.0
    dotnetwarrior.NetMF.Game,1.0.0.0
    RallyX,1.0.0.0
    dotnetwarrior.NetMF,1.0.0.0
    GHIElectronics.Gadgeteer.FEZHydra,1.0.6.0

ianlee74 · September 15, 2012, 4:01pm

Interesting. This could explain why I suck at the Pacman game…

taylorza · September 15, 2012, 6:27pm

@ ianlee74 - I have not tried Pacman, could I bother you to try changing the socket that the joystick is using to confirm if there is indeed a difference.

ianlee74 · September 15, 2012, 6:41pm

I can’t at the moment. I’m fighting a fire at work. I’ll try to give it a go later this evening. I have experienced lag in the joystick controls. I just assumed it was the code.

taylorza · September 15, 2012, 6:45pm

I appreciate your help. Good luck with the issue at work!

taylorza · September 16, 2012, 5:58am

OK, I am able to reproduce the issue in a small test application. The issue is not related to socket 13 vs socket 14 but rather to whether the T35 Display’s touch socket is connected in the designer or not. When the T35 Touch is initialized, it seems to interfere with the analog readings on socket 14, specifically the pin used to read the X position of the joystick.

The following code code below shows the problem, run it with with joystick module connected to socket 14 and the T35 Display touch connected, then disconnect the touch socket in the designer and test again.


using System.Threading;
using Microsoft.SPOT;
using GT = Gadgeteer;

namespace HydraAnalogPerfTest
{
  public partial class Program
  {    
    void ProgramStarted()
    {      
      new Thread(() =>
        {
          uint x = 160;
          uint y = 120;

          while (true)
          {
            var pos = joystick.GetJoystickPosition();

            if (pos.X < 0.3) x--;
            if (pos.X > 0.7) x++;
            if (pos.Y < 0.3) y++;
            if (pos.Y > 0.7) y--;

            display_T35.SimpleGraphics.DisplayEllipse(GT.Color.Red, x, y, 5, 5);
          }
        }).Start();           
    }
  }
}

taylorza · September 17, 2012, 1:29pm

@ Gus, do you guys have any insight into this issue?

taylorza · September 20, 2012, 2:45pm

Sorry to harp on this point, but I would like to know if GHI is aware of the issue, is the issue a firmware issue or is it somethig easy to remedy? The thing is that at this point it seems using touch screen with a connected joystick or any other analog device will be problematic.

Aron_Phillips · September 20, 2012, 3:42pm

We ran your code and have indeed found the same anomaly. I did however put another joystick in the designer on Socket 13 (A T Y) and the X position worked as expected. The issue would appear to be connected to the touch on Gadgeteer. We are investigating the issue.

taylorza · September 20, 2012, 4:10pm

Hi Aron, thank you for the update. I hope you are able to identify the issue.

Skewworks · September 21, 2012, 7:37pm

I can confirm it is related to touch. For some reason port 14 is sending signals to the touch interface…this really shouldn’t be, but it is.

taylorza · September 23, 2012, 10:07am

@ Aron/Gus

I had a little time this morning and decided to take a look at the code for the Touch implementation. Now I am not yet setup to build and make changes etc. so everything I see is based on my interpretation of the code so I appologize if I am way off track, but it is an interesting to me to read the code and try understand what is going on. So with the disclaimer out of the way

The function AT_ReadXY() in ‘touchpanel_FEZ_Hydra_functions.cpp’ seems to be using Analog Channel 2 to read the XA, however as far as I can see Analog Channel 2 is “mapped” to socket 14 and not socket 13.

Lines : 93 - 106


//GHI_OSH_HAL_AnalogIn_Init(_pins.XA);
AD_Initialize((ANALOG_CHANNEL)2, 0); // XA --- .NetMF Analog Channel 2 *** 0 is not used
HAL_Time_Sleep_MicroSeconds_InterruptEnabled(_ANALOG_SETUP_DELAY);
*y = AD_Read((ANALOG_CHANNEL)2);
//GHI_OSH_HAL_AnalogIn_Read(_pins.XA, (UINT32*)y);

total = 0;
for(int i = 0; i < AT_AVERAGE_COUNT;i++)
{
  *y = AD_Read((ANALOG_CHANNEL)2);
  //GHI_OSH_HAL_AnalogIn_Read(_pins.XA, (UINT32*)y);
  total += *y;
}
*y = total / AT_AVERAGE_COUNT;

If this is the case I suspect this is what is causing the issue on socket 14 with the Joystick input (and presumably with any analog input). I would appreciate it if someone can confirm my conclusion or if I have misunderstood the code then point me in the right direction.

Gus_Issa · September 23, 2012, 10:10am

Touch is not compiled in yes on 4.2 so I doubt this is it. Of course, I am do not know enough, Aron will be able to check more.

Skewworks · September 23, 2012, 12:17pm

I have noticed (even in 4.1) that reading from Socket 14 seems to occasionally interfere with touch by having touch pick up signals that aren’t actually present.

taylorza · September 23, 2012, 3:39pm

I see, I was actually quite hopeful because by my understanding, which is admittedly still limited, the Hydra’s analog channel 2 is tied to the pin 4 on socket 14 which is the pin used to read the ‘x’ value of the joystick which is coincidently the problematic input. But it sounds like this might just be a misleading series of coincidences.

Thank you for the feedback, and if you guys do not mind I would be very interested in knowing the cause of the issue if and when it is identified. The more information I have the better I am able to learn and understand the details.

taylorza · September 29, 2012, 11:06am

I decided to do a custom build of the Hydra Firmware using the GCC 4.6.2 tool chain from ARM. Interestingly the custom build had less of an issue than the official firmware, but I did get the sporadic touch events from the analog input on Socket 14 (touch is on socket 13).

After a few modifications to the AT_ReadXY() function in ‘touchpanel_FEZ_HydraFunctions.cpp’ the issue seems to be resolved, the Analog input from socket 14 are working as expected even when the touch interface is initialized on socket 13 and there are no sporadic touch events being generated by the input on socket 14.

It looks like the wrong channels are being used and disabled in the AT_ReadXY() function.

Skewworks · September 29, 2012, 11:54am

@ taylorza - you should post the hanged you made so GHI can get it in the next build and we can use it while we wait.

taylorza · September 29, 2012, 12:11pm

@ Skewworks - Once I have done more testing I will do that. I need to test that the changes I have made are not affecting something else.

Gus_Issa · September 29, 2012, 12:21pm

I think Aron had this fixed but it is always good to have 2 inputs. Thank you for helping.

taylorza · September 29, 2012, 12:33pm

I would be very interested to hear what the fix is. These boards are the most fun I have had with software in many years…

Here are the naive changes that I made. I am not sure they are right, but they made a positive difference, of course it could have just moved the issue to another location because I might be disabling the wrong channels. Since GHI already has the fix, posting this code poses minimal risk. Maybe Aron can post the correct fix here so that I can update the custom build I have.

I did not fix comments, I was using them as a reference to what I had changed.

C:\MicroFrameworkPK_v4_2\Solutions\FEZ_Hydra\DeviceCode\TouchPanel_HAL\touchpanel_FEZ_Hydra_functions.cpp


void AT_ReadXY(int *x, int *y)
{
	int total, i;

	// setup X
	CPU_GPIO_EnableOutputPin(_pins.XL, _pins.XL_state);
	CPU_GPIO_EnableOutputPin(_pins.XR, !_pins.XL_state);

	//if(GHI_OSH_HAL_AnalogIn_GetPin(_pins.YA) != _pins.YU)
	if(AD_GetPinForChannel((ANALOG_CHANNEL)1) != (unsigned int)_pins.YU) // YA --- .NetMF Analog Channel 1
		CPU_GPIO_EnableInputPin(_pins.YU, FALSE, NULL, GPIO_INT_NONE, RESISTOR_DISABLED);
	else
		CPU_GPIO_EnableInputPin(_pins.YD, FALSE, NULL, GPIO_INT_NONE, RESISTOR_DISABLED);

	//GHI_OSH_HAL_AnalogIn_Init(_pins.YA);
	AD_Initialize((ANALOG_CHANNEL)1, 0); // YA --- .NetMF Analog Channel 1 *** 0 is not used 
	HAL_Time_Sleep_MicroSeconds_InterruptEnabled(_ANALOG_SETUP_DELAY);
	*x = AD_Read((ANALOG_CHANNEL)1);
	//GHI_OSH_HAL_AnalogIn_Read(_pins.YA, (UINT32*)x);
	
	total = 0;
	for(i = 0; i < AT_AVERAGE_COUNT; i++)
	{
		*x = AD_Read((ANALOG_CHANNEL)1);
		//GHI_OSH_HAL_AnalogIn_Read(_pins.YA, (UINT32*)x);
		total += *x;
	}
	*x = total / AT_AVERAGE_COUNT;

	CPU_GPIO_DisablePin(_pins.YA, RESISTOR_PULLUP, 0, GPIO_ALT_PRIMARY);
	TOUCHSCREEN_ADC_CONTROLLER_CHANNEL_DISABLE_REGISTER = (1 << 1); // Disables the channel in the register | 4 is Actual Processor Channel
	//GHI_OSH_HAL_AnalogIn_Uninit(_pins.YA);

	// setup Y
	CPU_GPIO_EnableOutputPin(_pins.YU, _pins.YU_state);
	CPU_GPIO_EnableOutputPin(_pins.YD, !_pins.YU_state);

	//if(GHI_OSH_HAL_AnalogIn_GetPin(_pins.XA) != _pins.XL)
	if(AD_GetPinForChannel((ANALOG_CHANNEL)3) != (unsigned int)_pins.XL) // XA --- .NetMF Analog Channel 2
		CPU_GPIO_EnableInputPin(_pins.XL, FALSE, NULL, GPIO_INT_NONE, RESISTOR_DISABLED);
	else
		CPU_GPIO_EnableInputPin(_pins.XR, FALSE, NULL, GPIO_INT_NONE, RESISTOR_DISABLED);

	//GHI_OSH_HAL_AnalogIn_Init(_pins.XA);
	AD_Initialize((ANALOG_CHANNEL)3, 0); // XA --- .NetMF Analog Channel 2 *** 0 is not used
	HAL_Time_Sleep_MicroSeconds_InterruptEnabled(_ANALOG_SETUP_DELAY);
	*y = AD_Read((ANALOG_CHANNEL)3);
	//GHI_OSH_HAL_AnalogIn_Read(_pins.XA, (UINT32*)y);

	total = 0;
	for(int i = 0; i < AT_AVERAGE_COUNT;i++)
	{
		*y = AD_Read((ANALOG_CHANNEL)3);
		//GHI_OSH_HAL_AnalogIn_Read(_pins.XA, (UINT32*)y);
		total += *y;
	}
	*y = total / AT_AVERAGE_COUNT;

	CPU_GPIO_DisablePin(_pins.XA, RESISTOR_PULLUP, 0, GPIO_ALT_PRIMARY);
	TOUCHSCREEN_ADC_CONTROLLER_CHANNEL_DISABLE_REGISTER = (1 << 3); // Disables the channel in the register | 2 is Actual Processor Channel

	// was pressed??
	if(*x < AT_MIN_POINT_VALID || *y < AT_MIN_POINT_VALID)
	{
		*x = *y = -1;
	}

	//GHI_OSH_HAL_AnalogIn_Uninit(_pins.XA);
}