I took over a GUI which has the purpose to communicate on USB (via a PEAK USB/CAN device) with an Electronic Control Unit. The problem is that, sometimes, when some Windows events take place (take the PC out of the docking station/ take the monitor out of the laptop, sometimes when plugging in a USB mem stick), my GUI (MainForm) gets stuck/ freezes in the background without any possibility to access it with the mouse, keyboard or from the Task Manger (only close it but not bring to front) but it is still working and updating values received from the PEAK system via USB.
Can you help me with this issue, please? Take into account that this project was not started by me I just took over in order to update it's features when the guy left. Can this issue appear due to the PCAN drivers? Can I find a work around?
Related
I make this post because I didn't find the answer (I made some searches with tag Shutdown, Reboot and SSH).
Since fews months, I've got 2 Corals (out of 3) that shutdown unexplicaly and then become unreachable.
When this occur, I'm forced to go the device (the serial connectivity doesn't work either and the fan doesn't works at this time), unplug and then re-plug the power in order to be able to reconnect through SSH.
What the best thing to do ?
Thanks a lot.
I've seen similar behavior with low power. Be sure you are connecting your board to a 2-3 A power supply. A couple indications that this might be your problem are:
Your board is connected to your computer USB power
Your board runs fine until you load it (i.e. start inferencing on the TPU)
That's the first things I would look for.
I ran into a very weird problem. I have a VB.NET program which calls another program which runs in the background. We're using a special software here to deliver this software over web. What this software basically does is, that i creates a new remote desktop connection, grabs the screen and opens up a web server.
While running the sub programm / sub process the screen does not react smooth anymore, it gets very low and then freezes. We figured out, that we're triggering too many screen updates at once so that we simply flood our connection which causes the crash in the browser.
Is there any simple way to determine how many screen updates were sent and which causes these updates? Best would be that we can identify the process so that we can investigate further.
The whole process is ran as a backgroundWorker which then creates another process.
Edit:
Could it have something to do with the CPU load (which is very high)? Although the subprocess is executed in the background - and is visible in the process list - is there any chance that this causes the UI Update?
Finally solved it. It was a Timer updating the View every microsecond becuase the Interval was not correctly set.
I have a VB.NET desktop application that I'm using to monitor events in another windows application running on my system. I need to respond to certain events in a matter of seconds. One of the events I'm monitoring instantly changes the window title of a child window within the main process (I'm not changing it, the application I'm monitoring causes the change in it's own child window title). I have a function that uses windows API's to iterate through the title text of all the process's child windows, and I'm checking for certain values in the titles.
Is it a bad idea to be running this timer/title check once every second? Are there performance issues associated with running a timer in windows every second 24/7? Is it also bad for performance to be calling the API's which retrieve the titles of all the application's child windows? Could I eventually cause that application to crash by sending requests to it so often?
Thanks!
You will have to benchmark it to see, but if I recall correctly, iterating through every window has significant overhead.
Can't you simply monitor a single window? If you do that, you should be fine.
Other than the possible lag issues, has anyone tried this? What are the pros or cons associated with this?
A lot of times for me it's the limitations of the remote desktop connection, be it VNC or RDP or whatever. For examples:
My workstation has two monitors. Remotely viewing my workstation reduces it to one.
Lag is tolerable in the IDE, but not with anything image-heavy. Everything from photoshopping to web browsing is done locally, not on the remote machine.
Adding to #2, when splitting up tasks between the local and remote machine, there's that extra layer of getting the two to play nice together that adds just a little bit of overhead per task, which adds up to a lot overall. Something as simple as saving a file from the web browser and opening it in the IDE takes more steps.
(I may think of more and add them later.)
All in all, it's fine if the setup can be adjusted properly. In my experience, the companies I've worked for have defined their remote connection capabilities by the needs of someone other than the software developers, and thus leave us with little pet peeves that make the process just slightly more difficult than it needs to be.
Here is my take on it from my experiences
PROS: Single dev environment, only need to license one set of tools (if applicable)
CONS: The lag got the best of me. Typing to only have it show up 1 - 3 seconds later...sometimes, other times works great. In VS, the popup notifications sometimes take forever to display as well. Other cons would include if you have to share your desktop with another employee and possible moving files to/from the dev machine as RDP does not natively allow you to drag/drop files.
same as other posters - lag when using tools that affect screen painting for vstudio (resharper,coderush) is a real problem - some stuff involving the mouse (dragging grid columns) is very difficult to use
I'd add that about every 10-15 times when I go to log back in on the physical workstation at work, it takes the stupid thing about 2 minutes to finally succeed in refreshing the displays
One of our current milestones on our (open source) project at the moment is to complete USB support, and as such we're working hard on drivers at the moment. Our current development focuses on EHCI on both x86 and ARM (OMAP35xx SoC specifically, EHCI-only in the silicon of the board). We have mostly everything running smoothly in a variety of emulators - VMware (free and non-free versions), QEMU, and VirtualBox.
When we do testing on real hardware however, we get absolutely nowhere. The basic routine for device enumeration in our system goes something like this:
Turn on port power (if the option is available) and wait for power to stabilise to the device
Perform a port reset (held for 50 ms) and then wait as long as needed for the reset to complete (while loop)
If the port has a device present, and is enabled, notify the system that a new USB device is available for initialisation.
Send the SET ADDRESS command to assign an address to the device. This is where we run into problems everywhere:
The SETUP transaction for this command completes without error
The zero-length IN transaction (status phase) throws a transaction error, halts the qTD, and disables the port.
Our timing delays are basically the same as Linux's driver (if anything, longer).
According to the USB 2.0 specification, this behaviour is a "Port Error" (section 11.8) but to be completely honest I don't see how to translate its description of a port error into a working solution for our driver. As we are an open source project we also don't have the money to go out and purchase a proper hardware USB protocol analyser to investigate exactly what's going on on the line either.
Has anyone faced a similar problem and knows a solution?
We have identified the cause of this problem has been a timing issue, but in our case the issue was too much of a delay.
By modifying our qTD/QH creation code to create a single QH with multiple linked qTDs associated with it, we've been able to get successful runs on physical hardware.
We also had to use te EHCI 64-bit data structures, which had not been implemented previously.