I'm generating an experiment in PsychoPy (v1.84.2 on Windows 7), which requires a short tone.
The lines of code around the sound generation are:
print '1'
startTone = sound.Sound(value='B', secs=0.15, octave=5, sampleRate=44100, bits=16, name='', autoLog=False)
print '2'
instructions_text_stim = visual.TextStim(win, text='Press any key to start.', pos = [0,0], height=2)
print '3'
instructions_text_stim.draw()
print '4'
win.flip()
print '5'
PsychoPy crashes as soon as the visual.TextStim is drawn (I get 1-3 in the output window). The crash is a "pythonw.exe has stopped working" popup, which forces the window to be closed.
Without the sound generation, the experiment runs without a hitch. The tone is played elsewhere in the script, but the crash is at the assignment. Additionally, the code runs on OSX.
I've seen people have had issues with pyo compatibility before, as well as the pythonw.exe crash. Has anyone had the combination, or found a work-around?
Thanks
Updating to PsychoPy v1.85.0 and using the audio library "sounddevice" fixed this issue.
Related
Currently i am trying to get the STM32F405 to jump to bootloader from application code without the use of the boot0 and boot1 pins.
I did already try multiple things to get that done but it always ended with the the firmware jumping to the bootloader (at least it seems like it) and after approximate 18 seconds the firmware restarts (no Watchdog or similar things that could wake the chip up again are used as far as i know).
During those 18 seconds if i try to update the firmware the bootloader doesn't get found.
I tested things like:
1. (STM32F4 Jump to Bootloader via SoftReset and without BOOT0 and BOOT1 Pin)
Set a value in SRAM
Restart the STM32F405 with NVIC_SystemReset() to get the STM32F405 to close reset condition
Check for value in SRAM ( if it's set do the following )
Move stackpointer to bootloader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
2.
During runtime call function JumpToBootloader()
Within that function disable interupts, reset SysTick, reset SYSCLK, call RCC_DeInit()
Move stackpointer to bootlader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
One approach i found but couldn't test yet was to do basically what i discribed in try 1. but using assembler code within the STM32F4xx startup file.
The problem here is that the tutorial i found uses the KEIL assembler syntax which i cant use because i use the Atollic TrueSTUDIO and i have not enough knowlege about assembler to change the KEIL syntax to standard assembler syntax.
The thing that confuses me the most is that in an other project i use an STM32F3xx (cant remeber the correct number) and i do basically the same thing as in try 2. but with the the bootloader address of the STM32F3xx (0x1FFFD800) and it works perfectly fine and i can update the firmware via USB.
So the questions i have:
What could i try next to get the bootloader running?
What could be the cause in my current situation for the firmware to restart after X seconds?
A few days ago i found the cause of the problem i had.
Within the "system_stm32f4xx.c" the I2S clock got configurated and in my project that clocks doesnt get used.
Im not 100% sure why, but after removing this block of code everything works perfectly fine.
(sorry for late answer, kind of forgot about the post :D)
After three days of intensive googleing and stackoverflowing I more or less got my program to work. I tried a lot of stuff and found a lot of answers somehow connected to my problem, but no working solution. Sry should I have missed the right page!! I'm looking forward to comments and recommendations.
Task:
Send binary data (floats) from python to C++ program, get few floats back
Data is going to be 20ms soundcard input, latency is a bit critical
Platform: Windows (only due to drivers for the soundcard...)
Popen with pipes, but without communicate, because I want to keep the C++ program opened
The whole thing worked just fine on ubuntu with test data. On Windows I ran into the binary stream problem: Windows checks the float stream for EOF character and finds it randomly. Then everything freezes, waiting for instream data which is just behind the "eof" wall. Or so I picture it.
In the end these two things were necessary:
#include <io.h>
#include <fcntl.h>
and
if (_setmode(_fileno(stdin), _O_BINARY) == -1)
{cout << "binary mode problem" << endl; return 1;};
in C++ as described here: https://msdn.microsoft.com/en-us/library/aa298581%28v=vs.60%29.aspx.
cin.ignore() freezes using binary mode! Guess since there's no eof anymore. Did not try/think about this too thoroughly though
cin.read(mem,sizeof(float)*length) does the job, since I know the length of the data stream
Compiled with MinGW
and in the Python code same thing! (forgot this first, cost me a day):
if sys.platform.find("win") > -1:
import msvcrt,os
process = subprocess.Popen("cprogram.exe",stdin=subprocess.PIPE,stdout=subprocess.PIPE,bufsize=2**12)
msvcrt.setmode(process.stdin.fileno(), os.O_BINARY)
and
process.stdin.write(data.tostring())
I have a Core Data iOS app that uses private queue concurrency in a background process. I'm getting a deadlock that makes the UI freeze up from time to time (fairly regularly, to be honest) - but all the info I get from the debugger (LLDB) is that it is stuck on pthread_mutex_lock. The stack trace is no longer than that, which makes debugging near on impossible:
thread #1: tid = 0x2503, 0x3b5060fc libsystem_kernel.dylib`__psynch_mutexwait + 24, stop reason = signal SIGSTOP
frame #0: 0x3b5060fc libsystem_kernel.dylib`__psynch_mutexwait + 24
frame #1: 0x3b44f128 libsystem_c.dylib`pthread_mutex_lock + 392
The XCode process pane is similarly only showing those two entries on the stack.
I'm quite new to this multithreading stuff so am at a total loss where to begin with fixing the issue. Any suggestions for how to go about debugging this?
Your stack is obviously longer than two frames, you can't start a thread with pthread_mutex_lock. So the truncation of the stack frame is pretty clearly just a bug in the lldb unwinder. If you have an ADC account, please file a bug about this at bugreporter.apple.com. Also if you're not using the most recent version of lldb you can get your hands on you might want to try that, maybe it fixed whatever bug you are seeing. You can install multiple Xcode's side by side so you don't have to remove the one you are currently using to try a newer one.
You might also try another tool that will give you a backtrace (e.g. the Instruments time profiler) when your app gets into this state, since it uses a different unwinder. That will at least let you see what the full backtrace is.
In a wxPython application, which i am porting to Mac OSX, I set title of app frame every 500msec in update UI event, and due to that all the panels and windows are refreshed. That seems strange to me and almost halts my application which has many custom drawn controls and screens.
I wanted to know what could be the reason behind it, is it normal for MAC?
Here is a self-constrained script which replicates the scenario using timers. It keeps on printing "on paint" every 500ms because in timer I set title every 500ms.
import wx
app = wx.PySimpleApp()
frame = wx.Frame(None, title="BasePainter Test")
painter = wx.Panel(frame)
def onPaint(event):
dc = wx.PaintDC(painter)
print "onPaint"
painter.Bind(wx.EVT_PAINT, onPaint)
def loop():
frame.SetTitle(frame.GetTitle())
wx.CallLater(500, loop)
loop()
frame.Show(True)
app.SetTopWindow(frame)
app.MainLoop()
My system details:
>>> sys.version
'2.5 (r25:51918, Sep 19 2006, 08:49:13) \n[GCC 4.0.1 (Apple Computer, Inc. build 5341)]'
>>> wx.VERSION
(2, 8, 10, 1, '')
>>> os.uname()
('Darwin', 'agyeys-mac-mini.local', '9.8.0', 'Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386', 'i386')
Alas, I'm not sure of the specific issue. However, when you have a sample which demonstrates the problem but are stumped, I've always had great luck by emailing the wxpython-users mailing list and attaching the sample. You should get a response pretty quickly on if there is something you can do to fix it, or if not, that you should file a bug in the tracker.
I have had plenty of problems solved this way, and when I do have to file bugs, they are usually resolved quite speedily. Hope this helps!
It is a bug in wxPython (OSX-Carbon).
Filed a bug http://trac.wxwidgets.org/ticket/11920
Discussion:
http://groups.google.com/group/wxpython-users/browse_thread/thread/2430e0ef7ff1fb8/8f384968a42136d7
I am using Matlab to operate a camera. It is an IDT SharpVision camera, and I am using the Matlab interface provided by the company. When I try to acquire an image, I get a segmentation fault. I have tried preallocating memory by creating an empty array for the image, but this does not work.
This is the line of code that causes the seg fault:
[nResult, x] = sharpML('IdtSvAcquire',cameraId);
sharpML.dll includes a MEX file for controlling the camera.
Here is a selection from the error message stack trace:
[0] QCamChildDriver.dll:0x160fdde4(0x0f99ef08, 15, 0x00ced938, 0x00ced938)
[1] QCamDriver.dll:0x0f9c1dd8(4146, 0x00ced938, 0x00ced924, 0x11283430)
[2] sharpML.dll:0x0f991d8c(2, 0x00cedf88, 2, 0x00cedfe8)
[3] sharpML.dll:0x0f991448(2, 0x00cedf88, 2, 0x00cedfe8)
...
[35] MATLAB.exe:0x00403bd2(1109972, 0, 0x7ffd9000, 0x805512fa)
[36] kernel32.dll:0x7c817077(0x00403daf, 0, 0x78746341, 32)
Any suggestions? The company that makes the camera has since gone out of business.
~ Adam
This sounds like a driver issue since the fault is occurring here:
QCamChildDriver.dll:0x160fdde4(0x0f99ef08, 15, 0x00ced938, 0x00ced938)
One possible issue - the driver might be in conflict with your OS, especially if you are running Vista or any 64 bit OS.
If it is a driver issue, you might be able to find updated drivers somewhere on line, even if the company is gone.
Other than that you might be up a creek, unless you can find the C-source for scratchML and/or the driver.
Problem solved:
I reinstalled the camera software and relevant QCam drivers, along with cleaning up a few other bugs.
If your camera uses firewire, you could try to use this tool.