|
prathapkumar334 wrote: I am doing a project in college... What class?
What does the frame look like? What code have you put together so far?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
prathapkumar334 wrote: I am doing a project
This means you are expected to do it, people here will not write your code for you. However, if you have specific technical questions people will try to help you.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Extracting bits from a group of bytes it is the daily delight of the C programmer. However without knowing what your data structure (that is the frame) and what are the bits you're interested in, we can't help a lot.
Veni, vidi, vici.
|
|
|
|
|
What a pathetic request.
Have you thought of looking on line at the ethernet protocol, and the various other protocols that could be caried by it?
So is it Ethernet IP? Then what? TCP? UDP? RTP....
See, you havent even started yet. Grow a pair and go out find the info yourself. After that its a simple case of writing a few structs and casting the data packet to access whats inside...
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: What a pathetic request.
let me refer you to this : HOW-TO-ANSWER-A-QUESTION[^]
Watched code never compiles.
|
|
|
|
|
Sorry, a quick slap acorss the face can do wonders for peoples attitude.
==============================
Nothing to say.
|
|
|
|
|
Here's a bit of a hint...
0. Define a structure that is representative of the data that you're expecting.
1. Take data from your socket.
2. Cast your data bytes onto your data structure.
3. Interpret and use data however you need to.
4. Do it all over again for any number of packets transferred.
|
|
|
|
|
You might want to have a look at this link.
http://simplestcodings.blogspot.in/2010/10/create-your-own-packet-sniffer-in-c.html
Moreover there are a few open source libraries (pcap libraries). I would suggest you to use open source libraries for capturing packets. For your project do something which has not been done before. Packet capturing has been done earlier. In Windows you have the WireShark Tool which does it.
--Edwin.
|
|
|
|
|
You might want to have a look at the following open source libraries.
Separating bits from the ethernet is already done by many. So open source libraries are available.
I came across a good looking solution though. The links is given below.
http://www.binarytides.com/blog/packet-sniffer-code-in-c-using-linux-sockets-bsd/
Thanks,
Edwin.
|
|
|
|
|
|
I have installed a PCI digital card which provides an interrupt every 20 msec.
Now I would like to be able to call procedures within my MFC aplication from this routine.
Are they any way I can call - exampe
CTest1::Timer1()
from
DigitalInt(); I am not an expert on Namespace, but I think thats the problem.
Andy.
|
|
|
|
|
The best way to pass information from interrupt handlers to your application is to use user defined messages. This requires that you pass the handle of a window to the interrupt handler (usually the main window, but may be also a view or dialog window) and the handler then uses PostMessage(hWnd, WM_MY_APP_EVENT, wParam, lParam) . The receiving window requires a handler for the WM_MY_APP_EVENT message: ON_MESSAGE(WM_MY_APP_EVENT, OnMyAppEvent) . WM_MY_APP_EVENT is a place holder for a definition like #define WM_MY_APP_EVENT WM_APP+0 .
When not using your main window, you should use WM_USER as base rather than WM_APP .
|
|
|
|
|
OK Jochen, thanks for the info.
I remember using EVENTS a few years ago (this is similar?), but if you have a link or example that would be great as very out of date hear.
Searching through old code to see what I did in the past regarding events.
Andy
|
|
|
|
|
No, it has not to do with other events. I just choosed the word because it matches when using an interrupt routine. I can't give you a working example, because I don't know about your current implementation and requirements. But I can try to give you short implementation list:
- Decide where to handle the messages (main frame or other window).
- Pass the handle of the window to your interrupt service class using the
m_hWnd member of your CWnd derived class. The service class should contain a member var for the handle. - Add the message definition to a header file (project header file or those of the window class).
- Add the user message handler to your window class.
- Call
PostMessage from your interrupt handler.
|
|
|
|
|
Wauw! It's been a long, long, LONG time since I've written an interrupt handler. Perhaps 15 years or more - back when I started windows from the command prompt, since I didn't have win95 yet.
I'm light-years away from being any kind of expert on the matter, however, the very fact that you want to call a software routine in response to a hardware event screams DEVICE DRIVER to me.
In fact, one of the very reasons I avoided coding windows programs for quite a while was the fact that it was considerably more difficult to write code that would interact with hardware directly.
My guess is that you'll have to download & use the windows DDK.
I'll be waiting and watching this thread closely, in the hope that I'm wrong.
|
|
|
|
|
I suppose you are right.
Veni, vidi, vici.
|
|
|
|
|
Thanks for the information and direction. I got it working now.
My application was a MFC C++ Dialog based program using VS2008.
The most difficult part was getting the first parameter in the PostMessage() call.
This was the HWND hWnd of the main window. I used a global variable g_hMainHWND so that it was available in both the interrupt and main program.
Code as follows:-
#define Digital_Event 1
afx_msg LRESULT OnDigitalInterrupt(UINT wParam, LONG lParam);
const UINT WM_INTERRUPT_DIGITAL = WM_APP + 1;
HWND g_hMainHWND;
BEGIN_MESSAGE_MAP(CDigitalPnPDlg, CDialog)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_MESSAGE(WM_INTERRUPT_DIGITAL, OnDigitalInterrupt)
g_hMainHWND = this->GetSafeHwnd();
LRESULT CDigitalPnPDlg::OnDigitalInterrupt(UINT wParam, LONG lParam)
{
if(wParam == Digital_Event)
manage_timers();
return 0;
}
PostMessage(g_hMainHWND, WM_INTERRUPT_DIGITAL, Digital_Event, NULL);
Note I was using the interrupt to provide a timer facility as the card was providing this every 20 msec.
Andy
|
|
|
|
|
It's a pleasure.
Brilliant! So glad it's worked for you. Thank-you also for the confirmation that this can be achieved just from user-mode. I've got the ddk somewhere, though felt disinclined to experiment too much.
Your post has given me some fresh ideas too.
|
|
|
|
|
You cant pick up an interrupt from user mode. What Andy has is a card that comes with a driver and communicates with a dll over the IO manager, and that dll is imported into his app.
So the driver completes an outstanding IOCTL sent down by the dll and on completion any registered 'interrupt' handlers are called.
I dont know why an app would need notification every 20ms, the windows timer goes to about 10ms at the quickest, and if Andy is only using it as a timer then why not use the built in windows one?
If it is for transfering data the driver should asemble it into meaningfull packets andx send big chunks to user mode.
Andy is also going to get a massive performance hit switching contexts form kernel to user mode every 20ms.
==============================
Nothing to say.
|
|
|
|
|
Yes indeed, reading some of the other posts filled in the details. I should have been less accepting - my suspicion-meter never did quite allow the idea to sit easily with me. I'd come at it from the angle that no such DLL was provided - it was certainly never mentioned until later in the discussion.
Thanks for the quick primer!
|
|
|
|
|
Yeah, Andy didnt describe it that well, but if you know the kernel its obvious how it is structured, it hasnt changed since NT3.5 that much.
==============================
Nothing to say.
|
|
|
|
|
This looks good, but you have not shown how you get to register your app so the interrupt routine will call it.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I assume he is using a driver kit for his device that provides a callback mechanism from the interrupt service.
|
|
|
|
|
Yes, the card comes with a good API and I just need to install the interrupt handler at the start with a call-back routine and uninstall as the program ends.
You do get a 'blue screen of death' from time to time; buts thats down to developing code and debugging - to be expected until the code is mature.
Andy
|
|
|
|
|
Why do you need notificaiton every 20ms and why not use the windows timer?
If in fact you are geting data every 20ms why isnt it packaged up and sentf less frequently?
You are going to get a massive performance hit if you really are getting kernel to user transitions every 20ms.
==============================
Nothing to say.
|
|
|
|