I just started working on the CP7 display. Without Glide everything is running fine and I have all possible touch events raised.
Also this example http://www.tinyclr.com/codeshare/entry/512 is running very well (Mike’s Gadgeteer Video Poker for CP7 Display)
When I switch to CP7 + Glide as is shown here http://www.tinyclr.com/forum/topic?id=8563&page=2
I have copied the source code exactly and I receive the I2C error shown above.
I downloaded Glide version 1.0.5 today and compiled without any errors.
The initial displays shows fine.
What board are you using? Are you using external power? Is this a Gadgeteer project? Could you post your code is it is any different to what you linked to?
I was just logging on to post exactly the same question as JdV as I am seeing the same error. I am fairly new to the platform so assumed that the issue was in my code but having worked through the same post regarding CP7 and Glide as well some other diagnostics don’t see anything wrong.
I am using a Spider with Firmware v4.2.4.0, SDK v4.2 QFE2, GHI RC2 24-8-2012 currently powered through the USB. The project was created from scratch with Framework 4.2, I also downloaded Glide (18667) and compiled after changing to Framework v4.2.
The project initialises without an issue but the error is raised when the screen is touched in any location, I see multiple instances of the error which then appear to stop for a while.
Any help would be greatly appreciated, if I can provide any further diagnostic information please let me know.
Can you check the back of your display? On the back, there will be two connectors, one wider one for the display signals, and one small one for the touch controller. We have found that the touch cable on the back of the display can be easily disconnected. If it is disconnected, you will receive the “Failed to perform I2C transaction” error in the output window.
I have FEZ Spider with USB client dp module externally powered with 12 V DC
I created a Gadgeteer 4.2 project from scratch, Glide 18667 downloaded today
Upon reset it reports emx version 4.2.4.0. The code is exactly the same as I referred to.
I just checked the back of the display. Looked allright. Took the smaller one out and put it back in. Makes no difference.
Checked the behaviour once more.
The poker application runs fine, with the display reacting properly to touch inputs as it should.
Running the Glide application as discussed below still gives the same behaviour.
First the I cable was connected to socket #10 and in the designer as well.
Based on your response, I figured the behaviour might have something to do with the socket the I cable is connected to.
So I moved the cable to socket #4. To my surprise, the error disappeared and I am receiving ScreenPressed events.
The ‘I’ cable is definitely plugged into the correct socket, I have also reseated the touch cable on the back of the display and I have the same results. The touch cable is held in but definitely does not offer much scope for movement. I have also tested the Poker application which works perfectly.
Today I created a new solution (.net gadgeteer application NETMF 4.2)
Connected just the CP7 display using sockets 10/12/13/14 for IBGR, both in the designer and on the board
My program only initialises GlideTouch and defines a toucheventhandler as shown below.
As soon as I touch the display debug output shows [quote] Failed to perform I2C transaction[/quote]
Out of curiousity I moved the I cable from socket 10 to socket 4. In this case, Debug output shows no error
using System;
using System.Collections;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Touch;
using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using Gadgeteer.Modules.GHIElectronics;
using GHIElectronics.NETMF.Glide;
using GHIElectronics.NETMF.Glide.Display;
using GHIElectronics.NETMF.Glide.UI;
namespace GTAPP42
{
public partial class Program
{
// This method is run when the mainboard is powered up or reset.
void ProgramStarted()
{
/*******************************************************************************************
Modules added in the Program.gadgeteer designer view are used by typing
their name followed by a period, e.g. button. or camera.
Many modules generate useful events. Type +=<tab><tab> to add a handler to an event, e.g.:
button.ButtonPressed +=<tab><tab>
If you want to do something periodically, use a GT.Timer and handle its Tick event, e.g.:
GT.Timer timer = new GT.Timer(1000); // every second (1000ms)
timer.Tick +=<tab><tab>
timer.Start();
*******************************************************************************************/
GlideTouch.Initialize();
display_CP7.ScreenPressed += new Display_CP7.TouchEventHandler(display_CP7_ScreenPressed);
// Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
Debug.Print("Program Started");
}
static int lastX = 0;
static int lastY = 0;
static int x;
static int y;
static bool isTouched = false;
void display_CP7_ScreenPressed(Display_CP7 sender, Display_CP7.TouchStatus touchStatus)
{
GHIElectronics.NETMF.Glide.Geom.Point touches;
if (touchStatus.numTouches > 0)
{
touches.X = touchStatus.touchPos[0].xPos;
touches.Y = touchStatus.touchPos[0].yPos;
x = 0;
y = 0;
if (isTouched == false)
{
GlideTouch.RaiseTouchDownEvent(null, new TouchEventArgs(touches));
lastX = x;
lastY = y;
isTouched = true;
}
else
{
if (lastX != touches.X && lastY != touches.Y)
{
touches.X = lastX;
touches.Y = lastY;
GlideTouch.RaiseTouchUpEvent(null, new TouchEventArgs(touches));
isTouched = false;
}
}
}
else
{
if (isTouched == true)
{
touches.X = lastX;
touches.Y = lastY;
GlideTouch.RaiseTouchUpEvent(null, new TouchEventArgs(touches));
isTouched = false;
}
}
}
}
}
I am afraid I was out all day to and have only just had time to run some further tests. I have created a sample identical to the one above and have the same results :
Test 1 - Sockets 10/12/13/14, code for 10/12/13/14 gives ‘Failed to perform I2C transaction’ as soon as the screen is touched
Test 2 - Sockets 10/12/13/14, code for 4/12/13/14 gives no response at all (As I would expect)
Test 3 - Sockets 4/12/13/14, code for 4/12/13/14 gives Debug Output from Screen Pressed Event
Test 4 - Sockets 3/12/13/14, code for 3/12/13/14 gives Debug Output from Screen Pressed Event
Test 4 was for interest given the Gadgeteer shows 1, 3, 4 and 10 as available options (The ClientDP is connected to 1).
The original project I was working on now shows the Glide keyboard from the Screen Pressed Event using Socket 4, I haven’t been able to get this working further than simply showing the keyboard yet so might be asking for a little more help but suspect one subject per thread makes sense for now !
Is there any further debugging or tests that can provide more information ?
@ Steven - I have the same behavious as EngageTech with sockets 4/12/13/14.
No errors on Debug Output and I receive ScreenPressed and ScreenReleased Events.
However, it seems to me there is something wrong with the ScreenPressed and ScreenReleased events.
It looks like sometimes the ScreenPressed and ScreenReleased Events are not generated.
I have periods that I receive events properly everytime I touch the screen and as long as I touch the screen.
But at other moments I don’t receive any event at all although the program is running well (I check this by updating a field on the display every second).
It looks like the display doesn’t always “know” there is a touch.
Any news on the “Failed to perform I2C transaction” error yet?
Can you tell me what this error means? Under which circumstances could this error be caused?
Could it have to do with the touch experience I have?
We can’t seem to reproduce here. The error is caused by the module not being able to communicate over I2c, but we cannot find a reason why it fails in the way it does for you. Could you check the continuity between the I2C pins on the ‘I’ type sockets?
I switched to using socket 3 for the touchscreen which has been working fine, the problem is not solved for me but the workaround is running ok.
Steven, apologies I haven’t tested the continuity and provided feedback as requested, I have just done this on sockets 3 and 10 and don’t have continuity on either. The schematic shows pins 8 and 9 as the I2C pins, was I correct in checking continuity between these 2 ?