codeblocks v3.0 problems

Known Issues and Problems with BCI2000
Locked
gdimitri
Posts: 10
Joined: 23 Jun 2010, 09:36

codeblocks v3.0 problems

Post by gdimitri » 23 Jul 2010, 09:21

Hello guys,

I have been trying to compile v3.0 with mingw under the codeblocks IDE and I have been facing some problems, some of which I solved some not.

To begin with I realized that I shouldn't have used the mingw that comes with the codeblocks binary because this is v4.x.x and your system doesn't support this. One must use the mingw-get.exe (download from the mingw webpage) to install a v3.x.x of mingw and put that in the system path variable as the mingw compiler.
Secondly when one uses codeblocks the 'Settings->Compiler and debugger settings-> Other settings->Compiler logging' must be set to 'Full command only'. This is something that the CB project created by your bat file doesn't set and if it is wrong the CMake will not properly see the source directories.

In src/core/tools/BCI2000LauncherQt/MainWindow.cpp in line 702 the compiler returns an error about not understanding the copy function. I am assuming you meant command instead of copy. With that change the code will compile. Of course I haven't followed your code in detail and I don't know if this is what you meant. the Launcher though seems to work in run-time.

Finally the problem I haven't managed to solve. Everything compiles ok but when I run the Launcher the Operator returns an error (encountered a problem and needs to close).
When I debug with gdb in CB I get
Program received signal SIGFPE, Arithmetic exception.
In msvcrt!_control87 () (C:\WINDOWS\system32\msvcrt.dll)
Can you please help me, since I need to have a working version of v3.0 compiled under mingw.


Thanks for your time

P.S. I run a win xp professional with SP2 system

mellinger
Posts: 1065
Joined: 12 Feb 2003, 11:06

Post by mellinger » 27 Jul 2010, 08:38

Thank you for your helpful comments.
The compiling error in BCI2000Launcher has been fixed, and the runtime error in the Operator module has been fixed as well.

With codeblocks 8.02, I could not reproduce an effect of the "Compiler logging" preference on the compilation.

Best regards,
Juergen

gdimitri
Posts: 10
Joined: 23 Jun 2010, 09:36

Post by gdimitri » 05 Aug 2010, 10:19

Dear Juergen,

The compiler logging error must have been something related to the setup of my windows system. I now have a new installation of win 7 (using CB 10) and everything works quite nicely (I don't get that Compiler logging related error).


I have run though into an another error, this time a run time one. As I have mentioned in another post (relating to how to make windows see dlls... thanks for the help and for not mentioning that it was a stupid question) I am implementing the Neuralynx Digital Lynx into BCI2000 V3.
I need to make a thread that will be capturing Neuralynx data and creating the buffer and then the idea is to read that buffer from the Process(). I am following the implementation design of gUSBampADC creating a child class of OSThread as a member of my NeuralynxADC class which itself has as a member an instance of the NeuralynxADC class.

I can call the Neuralynx commands in Initialize() in order to connect to the amp and get all the necessary info (channel number, names and types, sampling freq etc). After that I initialize a new thread instance and call thread->Start() which puts me into the Thread::Execute() part of the code. The moment this happens though BCI2000 stops and gives me a fatal error.

My CB debugger doesn't even reach the first line of the thread::Execute() function and gives me a SIGFPE arithmetic exception error. The call stack reads as follows:
#0 00000000 0x004768be in DataIOFilter::Downsample()
#1 00000000 0x00496129 in DataIOFilter::Resting()
#2 00000000 0x00419a70 in GenericFilter::CallResting()
#3 00000000 0x0041af1b in GenericFilter::RestingFilters()
#4 00000000 0x00409e90 in CoreModule::ProcessBCIAndGUIMessages()
#5 00000000 0x00410a98 in CoreModule::Run()
#6 00000000 0x004191b1 in CoreModuleQT::Run()
#7 00000000 0x004a889b in WinMain@16()
#8 00000000 0x00ceb366 in main()

I hope you will be able to trace the problem and solve it because the way neuralynx drivers call for data makes imperative the use of a seperate thread. We currently have an implementation where neuralynx is read in a fieldtrip buffer thread running outside BCI2000 and then that feeds as a signal source module (Stefan Klanke working with Robert Ostenvelt wrote that) but it is not a very elegant solution and I would like BCI2000 to have full control of the amp.

Thanks for your time

George

mellinger
Posts: 1065
Joined: 12 Feb 2003, 11:06

Post by mellinger » 05 Aug 2010, 11:58

Dear George,

could it be that your ADC class' Preflight() function sets its output signal's number of samples to zero? In this case, a division by zero would occur in the Downsample() function.

Best regards,
Juergen

Locked

Who is online

Users browsing this forum: No registered users and 1 guest