I have written an G code interpreter/control app for a cnc machine in objective C. Everything runs fine for the first 20 - 30 secs but after that the whole thing stops for an other 20 sec and resumes super slow. I made a video so you can see for your self:
video (about a minute). As far as I can tell it doesn't skip steps or something like that it just goes really slow.
In my X-code console I can see that code is interpreted at the normal speed (using a NSLog every time a byte is written).
I use the IOkit from the Arduino Cocoa reference to communicate. I have tried a lot of different Baudrates and sometimes that will prolong the time it keeps working correctly but eventually it always slows down.
I some thing after this line needs to clean up the serial buffer or something
// send a byte to the serial port
void writeByte(char val) {
write(serialFileDescriptor, [[NSString stringWithFormat:#"%c" , val] cStringUsingEncoding:NSUTF8StringEncoding], 1);
}
Update: I am developing the app on my 17"MBP running OS X 10.9, I tried this on a other 13"MBP running 10.9.1 same thing happens but when I use yet an other 13"MBP running 10.6.8 it works fine!
Any ideas on what is happening here?
Probably you are writing faster than baudrate, but you will slow down only when output buffere will be full, because you need to wait to write. This can be solved or worked around in many ways
As it turned out there was a rogue Serial.Write() some were in the Arduino code (I placed there to find an other bug, and just forgot about it) The statement slowly filled the serial buffer.
Related
I'm trying to build a quadcopter flight controller from scratch using an ESP32, BNO055 IMU, and Turnigy TGY-i6 Transmitter/Receiver. So far I've been able to get everything to work together and give me reasonable data using PID control loops, filters, and various libraries. Previously I was using an Arduino Nano in place of the ESP32 because it was what I had at the time and I thought it worked well with it.
After doing some (very rough) flight testing I ended up coming to the conclusion that the code was not executing fast enough with the Nano to sustainably keep the quadcopter in the air. I decided to measure the loop time by setting a t1 and t2 at the beginning and end of the loop, and took the difference to find the time it took to execute one loop of the code. With the Nano, it took roughly 80000 microseconds exactly with little deviation.
Seeing this, I bought the ESP32 knowing that it had a much faster CPU clock speed and overall performance compared against the Nano. After getting the code to work on the ESP32 with a few changes, I ran a speed test again, and got the same 80ms. I was a bit confused at first but I decided to try and isolate the problem by taking out chunks of the code to see if the loop time would change - and it did not. After reading about some specific inefficencies of Arduino IDE [such as digitalWrite()] I kept trying to take away specific parts of the code, and no difference arose as I kept measuring the clock speed. It kept at roughly 80000 microseconds no matter the changes I made.
This leads me to believe that there is something quite important that I'm unaware about in my code that is causing it to run so slow. Ideally, I would like to be able to lower the loop time to at most 10ms so that the quadcopter can autolevel with little to no oscillation.
I've used Arduino for a few years now, but by no means am an expert - so any help on optimizing the code and/or solving this odd problem would be very much appreciated, Thank you.
Note: I have a suspicion that it may be something related to the IMU (BNO055) because that is one part of the hardware and software I know very little about.
These are the libraries I'm using:
#include "ESC.h" //ESC
#include <ESP32Servo.h> //ESC
#include <Wire.h>
#include <Adafruit_Sensor.h> //IMU
#include <Adafruit_BNO055.h> //IMU
#include <utility/imumaths.h> //IMU
#include <PID_v1.h> //PID
Here is the rest of the code.
After reviewing the code and segmenting it further, I discovered the problem was coming from the pulseIn() functions I use to read the PPM signal from the receiver.
The function works by:
Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go from LOW to HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds or gives up and returns 0 if no complete pulse was received within the timeout. Link
Looking back, this clearly causes a delay in the code.
Thank you to dimich for putting me on the right path to solve the problem.
Edit: How you can solve this:
Rather than use pulseIn(), you can use interrupts to solve the problem. I did this by attaching an interrupt to the pin that is sending the PPM signal and listening for a CHANGE to happen on it. You then check whether the pin is HIGH or LOW and either begin or stop your timer. This avoids using delays in the program and allows for a clean signal to be read.
Note: Some receivers use a PPMsum on one pin rather than individual pins. On my receiver, I use 4 different channels and 4 different GPIO pins for each axis + throttle.
I've written a small single-line oriented UDP based display service to support raspberry pi projects I frequently work on, where it would be nice to see the results of sensor data being captured. This is a rewrite of that program using GTK3 V3.18.9, and GLIB2 V2.46.2. I'm developing on OSX El Capitan
It seems to double in real memory size every 30 minutes or so based on traffic; so I'm presuming I have a memory leak somewhere. But for the life of me I can't see where in the code it could possible be. Val grind did not initially work for me, so I've got some studying to do to resolve what ever issue that is.
Meanwhile I was hoping that different eyes might be able to suggest a coding cause for a traffic based (at least I think so) memory leak. Here is the program and test client.
It starts up using about 10MB of real memory, then jumps when it has received 64 total messages to 14MB, than slowly grows from there. At 64 message, I start deleting the 65th message off the end of the list, presuming I should be saving memory; as this program might run for weeks.
Here is the code for the test client and the display service:
https://gist.github.com/skoona/c1218919cf393c98af474a4bf868009f
I recently I came across an error that I cannot understand. The game I'm developing using Cocos2D just freezes at a certain random point -- it gets a SIGSTOP -- and I cannot find the reason. What tool can I use (and how do I use it) to find out where the error occurs and what's causing it?
Jeremy's suggestion to stop in the debugger is a good one.
There's a really quick way to investigate a freeze (or any performance issue), especially when it's not easy to reproduce. You have to have a terminal handy (so you'll need to be running in the iOS simulator or on Mac OS X, not on an iOS device).
When the hang occurs pop over to a terminal and run:
sample YourProgramName
(If there are spaces in your program name wrap that in quotes like sample "My Awesome Game".) The output of sample is a log showing where your program is spending time, and if your program is actually hung, it will be pretty obvious which functions are stuck.
I disagree with Aaron Golden's answer above as running on a device is extremely useful in order to have a real-case scenario of where the app freezes. The simulator has more memory and does not reproduce the hardware of the device in an accurate way (for example, the frame rate is in certain cases lower).
"Obviously", you need to connect your device (with a developer profile) on Xcode and look at the console terminal to look for traces that user #AaronGolden suggested.
If those are not enough you might want to enable a general exception breakpoint in Xcode to capture more of the stacktrace messages.
When I started learning Cocos2D my app often frooze. This is a list of common causes:
I wasn't using sprite sheets and hence the frame rate was dropping drammatically
I was using too much memory (too many high-definition sprites. Have a look at TexturePacker and use pvr.ccz or pvr.gz format; it cuts memory allocation in half)
Use instruments to profile your app for memory warnings (for example, look at allocation instruments and look for memory warnings).
My friend is currently making a game in gamemaker, but whenever I test it out for him my computer seems to just completely lock up. My PC that I am testing on is no way underpowered, it has a 2500k, Radeon 6950 and 8GB RAM. My RAM, GPU and CPU usage is barely touched during the freeze. If I am playing music at the time of the freeze the speakers just buzz. Whenever is occurs a full system reboot is always required, nothing at all responds. The image of the game stays on the screen, mouse, keyboard and restart button don't respond. This question may be better suited for the Gamemaker forums, but it could be an issue with my computer. I am unsure. I can play MW2 and Crysis for hours without it crashing, so it is either a software problem or something weird. All of my temps are normal. Others have suggested checking while loops, but wouldn't an infinite loop cause the CPU usage to rise?
In any of your loops that have a potential of running infinitely, put io_handle(); (I think thats the command) This command somehow keeps windows from thinking a program has frozen. If that isn't the case... then try to play the music through an extension like fMod or another one. Furthermore, try it on another computer is it just your computer? Your computer doesn't sound underpowered at all... but what about your operating system? If you're using xp it may not support the Directx that GM requires. I believe that its very easy to make gm games very directx intensive, so check that out. Good luck! I love Game Maker!
It's most likely an infinite loop in your code. Try stripping away your code, compile, and test if your computer freezes again. Then build back up to where you started from.
This kind of issue is probably due to something internally in game maker, OR it could be an issue with a listener or script you may have bound to a sprite or object. Begin removing things, one by one, until you find the culprit.
Try to strip out pieces of code part by part and isolate the function / code that is causing the freeze. Then come back here and tell us the status.
I've kind of seen this before on another Gamemaker game. Do you have any infinite loops or shaders in your game? The last game that had this problem was caused by a bad shader.
I have a VB.NET application that crashes on a client's computer with a BSOD error... KERNEL_DATA_INPAGE_ERROR.
This error occurs at a point where my program does two things:
Locks the computer
Plays a sound in BackgroundLoop mode
For locking the work station, I am just using this:
<DllImport("user32")> _
Public Shared Sub LockWorkStation()
End Sub
For playing the sound, I am doing this:
My.Computer.Audio.Play(My.Resources.ResourceManager.GetStream("somesound"), AudioPlayMode.BackgroundLoop)
Now, this sound loops until the user logs back in. My software detects the session state switch and stops playing the sound. Sometimes when I log back in, the sound card plays garbage data for a split second, instead of the rest of the audio buffer. I get the impression that this has something to do with session switching.
Could my client be having an issue where there is memory corruption occurring at the point of locking the computer?
I apologize for the vagueness of this post... I am not sure where to begin as I cannot reproduce the problem myself.
Edit: If the sound is left to play on its own, even without locking the computer, eventually the computer will lock up and then bluescreen. Playing the sound while locking at the same causes it to happen sooner.
Edit #2: So I've seen it fail now. The sound loop starts playing correctly but quickly switches to looping of garbage data. It's as if it is just reading a random location in memory and looping that. Very strange behavior!
Solved!: It was hardware all along afterall. Apparently this particular model of laptop has a problem where the speaker is installed right on top of the hard drive. When playing sounds loudly, it creates all sorts of problems.
A blue screen is almost certainly related to defective hardware or drivers. Softwarewise, there's really not much you can do about this apart from putting together a workaround.
You can perform a memory dump and try to determine what specifically went wrong, or with some clever debugging see where it bombs out in order to try to avoid it.
Otherwise, you're probably talking about doing some maintenance work on the machine in question.