There's probably a firewall in the way blocking you. This is something you'll have to take up with your company's IT department to allow you access to it from the outside world. Most companies I know wouldn't allow this because it's a monster of a secuirty risk and an FTP server exposed to the outside world is a great target for idiots to try and store their 'warez on a "free" FTP server. Dave Kreskowiak Microsoft MVP - Visual Basic

Thanks for the info... will try to implement this as easy as I can.. -Pavan.

Nice article... thanks..:)

You can try an NPN transistor... try 10k going into the base, then put a Schottky (like a 1N5817) with the cathode directly on the base and anode connected to ground. Then connect a 4.7k from collector to 5v supplied by you. The RS232 ground would have to tie to your logic ground. The 5v signal should be present on the collector of the transistor.

An easy way to see is create an MFC multiple document project using the project wizard and look at what is in the application class' InitInstance() override. I just did one and it creates the frame like this: CMDIFrameWnd* pFrame = new CMainFrame; if (!pFrame) return FALSE; m_pMainWnd = pFrame; // create main MDI frame window if (!pFrame->LoadFrame(IDR_MAINFRAME)) return FALSE; // try to load shared MDI menus and accelerator table //TODO: add additional member variables and load calls for // additional menu types your application may need HINSTANCE hInst = AfxGetResourceHandle(); m_hMDIMenu = ::LoadMenu(hInst, MAKEINTRESOURCE(IDR_TestMDITYPE)); m_hMDIAccel = ::LoadAccelerators(hInst, MAKEINTRESOURCE(IDR_TestMDITYPE)); // The main window has been initialized, so show and update it pFrame->ShowWindow(m_nCmdShow); pFrame->UpdateWindow(); 2)3) Once you have the image size you can use MoveWindow to resize and reposition the child window within the parent frame. 4) CStatusBar::SetPaneText() can be used to set the text of the status bar in response to WM_MOUSEMOVE messages. For each message calculate the cursor position relative to the image, convert the results to a string, and display the string in the status bar.

Yes, you can. Intel's Integrated Performance Primitives has a library for signal and image processing. It is implemented using SIMD and supports multi-core processors as well. The library is vast, and contains many types of filters in spatial and freq domain. It also has morphological functions too. In fact, matlab is using IPPI to accelerate some image processing operations. You can check for the presence of IPP in your matlab by typing the ippl command in the console; [T b ] = ippl Matlab 2006a usese version 2.0 of IPP, the latest version is version 5.1 (and 5.2 beta if you want to try out.) http://www.intel.com/software/products/ipp/beta.htm By the way, programming with IPP requires you to handle all sorts of memory management, alignment etc, unlike the simplicity of Matlab. Good luck,

Thanks for explaining in detail. I think I would go with the second approach. I am not worried about the server side program as its a basic c++ console application (I can even end up executing exe files depending on the message it receives), but on the client side, I have to send messages from both MFC based application and also from basic c++ application DLL. But I can try both of the approaches that you suggested and see which one is more feasible within my application. thanks, -Pavan.

Why not use typedef unsigned __int64 uint64; typedef __int64 int64; Which gives you easy to use 64 bit types just like unsigned/signed ints of other sizes, and then use unions as shown above to deal with the component parts? Steve S Developer for hire

You're somewhat confused on terminology at a minimum. The PCIe bus runs at a flat 100hmz, 1x, 2x, etc refer to how wide the bus is, a 1x PCIe card runs at the same speed as a 16x card, it just has higher bandwidth. That said, while a PCIe4x bus might have the same bandwidth as a PCIX133-64 bus (I'm taking your word for it), the signaling details are different, at a minimum 4 PCI-X 64bit words would need converted into 3 PCIe words before being sent onto the PCIe bus. This would require a processor of some sort to do the conversions in near realtime, and would likely still result in some degree of increased bus latency. You'd also have the problem of the card in the adaptor being raised higher than the other cards and not being able to screw into the backplate properly, so I very much doubt any such device would exist. -- Rules of thumb should not be taken for the whole hand.

Hi... I managed to use the library provided over here. Thanks for that great library... -Pavan

See these past threads: http://www.codeproject.com/lounge.asp?msg=1715374&stype=1#xx1715374xx[^] http://www.codeproject.com/lounge.asp?msg=1719788&stype=1#xx1719788xx[^] "Approved Workmen Are Not Ashamed" - 2 Timothy 2:15 "Judge not by the eye but by the heart." - Native American Proverb

Pick a few and call them??? ASK THEM QUESTIONS?? Dave Kreskowiak Microsoft MVP - Visual Basic

I see, ok, well thanks.. It's an interesting little program anyway. If I come across a fujitsu scsi drive, in the near future I'll drop you an email on what I find out. Wish I could be of more help. It's interesting issue.. Progload

You could try posting to hardforum.com. While thier overall focus is on highend gaming systems there's enough overlap with other highend hardware that you should be able to get some input. Overall relyability of SuperMicro if nothing else. PCI-X is an obsolescent standard, so finding support for it on new boards is going to be an issue.

Firstly you need to understand that Windows allocates processor time to threads, not to processes or programs. Each time the scheduler is called upon to reschedule which threads are running, it looks at only the set of threads which are runnable - not blocked waiting for some event to occur. GUI threads are typically waiting for the user to press a key or move the mouse over the window, or for some other window message to arrive. This can also be a timer event created by the SetTimer function. Whenever you call a synchronous I/O function such as ReadFile, if the data isn't already buffered in the system's cache, the OS begins a read from the disk, then blocks the thread until the data arrives, and it's not runnable. If you use the WaitForSingleObject or {Msg}WaitForMultipleObjects{Ex} functions, your thread blocks until one of the conditions is satisfied. Blocking for I/O can happen without any specific command from the programmer if the program references data that isn't currently in memory (whether to be read in from the original program files or from the page file). The scheduler considers the set of runnable threads in priority order, from highest priority (31) to lowest (0). It only considers threads from the highest priority at which there are runnable threads, unless there are fewer threads at the highest priority than there are processors, in which case it will consider threads at the next lowest priority level which has runnable threads. This means that if a high priority thread never blocks (and therefore stops being runnable), it can prevent lower priority threads from getting CPU time. Best practice is to simply use the Normal priority, the default. The scheduler maintains a queue of threads at each priority level, and simply (if all default values are used) assigns the first N threads in the queue to each of the N logical processors in the system. The scheduler is invoked when one of three things happen: a running thread's quantum (time permitted to run) expires; a running thread blocks; some other event in the system causes a higher-priority thread to unblock. Windows raises priorities for some unblocking events which cause a thread to temporarily have a higher priority, which increases responsiveness. This is complicated by affinity (where a thread can be prevented from running on certain logical processors), and by the fact that Windows allocates an ideal processor for each thread, and remembers the last process

I did time comparison between the two functions fwrite and writefile for writing 800000 bytes of data and they both take same amount of time (among 20 trails). I tried using 1 thread for writing all the 3 channels data using 10 buffers for each channel (once the IO records data into 1 buffer, it updates the corresponding buffer flag and as soon as it updates the write thread writes the corresponding 3 channels buffers to file and updates the correspoding flags to false. I tried this for 10 times for acquiring data about 5sec, in those 3 times it gave out files of same size and 3 times it gave out different size files (so I think it is missing some data in between while writing). Will check and try different methods of implementation and see if I can acheive it. thanks, -Pavan

Thanks for all your replies. Yep, I think my question should state as 'Parallel/simultaneous processing of multiple threads'. Synchronization is more related to resource sharing between threads. The problem is to run both threads exactly at same speed and at the same time (which assures the frame rate). I have tried several ways by defining the priority classes to both threads to HIGH_PRIORITY_CLASS and setting their priority to PRORITY_TIME_CRITICAL, but still 'sometimes' I am getting a difference of one frame between 2 threads. I am running my application on a Dell Precision 670 (Dual xeon processors) with 2 threads on each core. Here is how my application works- I am having 2 waveform generating boards on 2 of my 64-bit PCI slots. In my application I am generating waveforms on both of these boards and each thread generates waveforms on each of these boards. These boards will have on-board buffers where we can store the data to be generated as waveforms. Since these buffers are to be in multiples of 1024 and my data is not in multiples of 1024, as usual, I am using rotating buffers. The board buffers, data buffers are completely independent for both threads (each thread is having its own buffers), so no data is shared between these threads except the intial flag variable which initiates the starting loop in the thread. Neither of these threads change the flag. They just use it to start their wave form generating loop (just like as a trigger signal). At last I would like to know how we can make sure these threads run at the same rate and speed and at any given instant of time they both should be at the same point of execution (one more thing is both these threads have exact and same number of instructions). thanks, -Pavan

Hi, Yeh your are right, that is why I want to incorporate memcpy()/memmove() functions in my code, but as I have explained, I am not sure how to implement them efficiently in my tricky buffer allocations. I am working on this from 2 days now to get it working. It would be great if anyone can come up with generalized solution for my problem :). thanks, -Pav