Hi, i’ve a problem with an university’s project FEZ SPIDER II. I should deactivate DISPLAY TE35 from the FEZ to execute an operation in C# e then i should activate it. Can it be remove the Supply from the Display’s socket through a C# code? And can it be give back the Display’s supply after?
Thanks.
E.A.
@ erik992 - The power supply? If so nope. Does the display have a reset pin?
1 Like
@ Mr. John Smith - erik992
Never tried using it but…
Spider II LCD Socket BY has a Enable.
The pins of the display are shower in the attachments. @ willgeorge how to enable LCD_EN?
If you want just tirn off display, why not with backlight ?
@ Erik992, I suspect you’re doing the same course that another new poster is also doing, and they were seeing a performance hit on transfer when they were updating the display - I also suspect that you’ve jumped to the conclusion that you want to disable the display to improve your app’s performance, but I think you’ll find that’s not going to help. Can you please confirm why you’re trying to do what you are? There’s no reason you can’t write your code so that you do not UPDATE the display when critical functions are happening. I can tell you that I have a G120 running a real time time/temperature readout on a coffee roaster, and have no issues. I have complex sensors and multiple inputs and outputs, and the only timing constraint I hit was related to SD card performance but that was caused by an unchangeable receive window on a downstream application over a serial link. Otherwise, I run display updates (eg time updates) while I’m merrily taking readings, processing data, and sending that on it’s merry way.
@ Brett - Yes, we are in the same team doing the project on the FEZ.
As said in the other post, problem is to send a photo from FEZ to pc using socket programming. When display is connected, transfer is very slow.
Mi idea is that there is an ever-running thread to manage the display that removes CPUs while the transferring.
During a test with Wireshark we have seen that, without display transfer is linear, in the sense that FEZ send the packets, pc receive them, and so on. WITH display, FEZ send a lot of packets, but pc doesn’t receive them and ask to retransmitt some packets to the FEZ. The process continue in this way and the speed is so slow. I think that FEZ doesn’t send the packets in the right order or probably doesn’t send some packets, so server has difficult to receive and all of that cause a very slow transfer.
For my opinion, it’s very strange that a display can cause that, but, at the moment, the only chance I see is to try to stop the thread that manage the display during the transfer. I don’t care if display doesn’t responde during the transfer. The important thing is to reactivate the display when FEZ receive a reply from pc, because we have to show a String representing the result.
Just to complete the explanation, project consists in an application that allow to select an allergy from the display of the FEZ, and then while passing a product on a proximity sensor (inserted into a wooden box), a photo is taken and the photo, with the indication of allergy selected is sent to the server (my pc). On the server we used a library to read the barcode of the product. We search the bar code into a database and we check, with the list of ingredients, if product is compatible with allergy selected.
If product is not present into the database, we search the bar code using a web service but the check on the allergy is not made. After that, pc send to the FEZ the name of the product and, if check of compatibility was made, the result.
so there’s not much anyone else can do to assist without a socket client implementation for the remote end, and without you uncovering more of what your system configuration looks like, including what code you’re actually using to display content.
There’s nothing at the core of netmf that “runs the display” until such time as you start to do stuff with it. If you connect a display and never initialise it, or initialise it and never display anything to it, the hardware is doing all the hard work (pun intended) and it’s only when your software interacts with it that netmf gets involved.
It’s possible that there’s an electrical reason for the problems you’re seeing when the display is active. What sockets are you using for the network adapter (and which one) and what cables are you using? Do you only have access to the one hardware setup? Can you take a pic of cable layouts etc?
I don’t know for sure this will or will not work - Socket B Pin 8 and Socket G Pin 9 are both pins you could potentially look to create as a digital output pin, and turn on and off to affect the display. Relatively easy to test if it’ll work.
The backlight only switches of the PWM to the driver. The display driver is still running.
LCD_EN is done internally by the LCD driver. This is not actually an ENABLE as such for on an doff but more an enable for the clocking of the input data. Some LCD’s use this and some keep it at a fixed level.
The LCD driver is pretty constant if you have a fixed graphics etc on the display. It is simply a stream of data at whatever the LCD frequency setting it set for. The only time you would have any change in processing power is when you update the bitmap for the display but if you are not doing this, then you should not see any appreciable difference. If I run my G120 board with the LCD being refreshed, I can see the power input fluctuating as my code does all the graphics. If I put the code into a breakpoint and the display is left updating, the power is pretty much constant as there is no processing going on.
If you need more speed then you could try lowering the LCD dot clock frequency. It should still work but you may see some flickering.
I loaded the configuration of the FEZ.
I don’t know if there is an electrical reason or what.But we have to find a solution and we accept all the ideas you have to solve the problem.
In the other discussion I loaded the code of the socket transferring.
https://www.ghielectronics.com/community/forum/topic?id=24517
Consider that display is touchscreen so this means that also if nothing is displayed on the screen, a thread to capture the touch events has to be always active.
Do you think that desabling in some way the touchscreen can break the esecution of this thread?
We will try the possibilities you suggested.
In the meantime, I want also say that send picture to pc in an other way is a good way to solve problem.
I tried to send picture through usb with a code found online but it didn’t work.
Also reading the bar code directly on the FEZ is the perfect solution but there are a lot of problem in doing this.
Other suggestions?
could there be a power issue?
Hi all.
I’m wondering if this issue was solved somehow?
We have a similar problem with our commercial project based on G120E + T43 but with the transmission on Ethernet port. The project is RFID reader that reads Mifare card and sends to server IC number waiting for access granted/denied decision from the server (and some other details to show to user) We use the T43 display as HMI on which we display few screens with info for the user.
We observe that sending data by TCP socket takes several seconds before socket.send() command is executed.
App doesn’t stack on command .send(), it goes further, (all other tread work without dealay) but we observe on Wireshark running on the server side that nothing happens for second and then frames start reaching the server.
We also observing that pinging G120E results in serious delay and dropping packets
We also have same app but with no LCD methods and it works smoothly.
Can anybody help in tunning G120E to put more effort on Eth transmission?
This is how we send data:
private void Sender()
{
Logger.Instance.Write("Starting Sender() thread.",false);
while (isRunning)
{
try
{
sendEvent.Reset();
while (messagesToSend.Count > 0)
{
Message message = null;
lock (messagesToSend)
{
message = messagesToSend.Dequeue() as Message;
}
if (message != null)
Send(message);
}
sendEvent.WaitOne();
}
catch (Exception exception)
{
Logger.Instance.Write(exception.ToString(), false);
}
}
}//Sender
private void Send(Message message)
{
string serializedMessage = JsonSerializer.SerializeObject(message);
string paddedSerializedData = JsonHelpers.PadSerializedMessage(serializedMessage, Message.BUFFER_SIZE);
var buffer = Encoding.UTF8.GetBytes(paddedSerializedData);
if (!socket.Poll(5000 * 1000, SelectMode.SelectWrite))
{
Debug.Print("Could not send data to the client.");
}
int length = socket.Send(buffer, 0, buffer.Length, SocketFlags.None);
Logger.Instance.Write("Sent : "+ length.ToString()+" bytes; "+ message.ToString(), false);
}// Send
Did you try to lower the clock to your LCD and see if this makes any difference?
Yes, we have reduced timer to 50%. So what we observe now is after slowing it down.