|
Nope, that does not work either.
Once again, I looked at the Driver Code for serial port, and the method for setting the EV_TXEMPTY flag is passed into the WdfInterruptSynchronize method, so it get called once the ISR is completed. It does not reflect the UARTS Line status register from what I can tell.
I think the only way to do it reliably is to write a driver that does not use ISR's.
|
|
|
|
|
You are right. The event is signaled when the last data byte has been copied from the TX buffer (transmitter holding register) to the transmit line register. What you need is the transmitter holding register and transmitter line register empty status. This is indicated by bit 6 of the line status register. Unfortunately, this event is not supported by the Windows SDK.
If you can live with a wait function, you may use the EV_TXEMPTY event and wait until the data byte has been trasnmitted (start + parity + data + stop) / baud. Because transmission is done by the UART hardware, the time is constant .
|
|
|
|
|
Had another idea. The Line Status Register is sent when IOCTL_SERIAL_LSRMST_INSERT is used, and this IS the actual UART Line Status Register. Bit 6 of the LSR, THR is empty, and line is idle, looks like it may be interesting. Will try this out today.
|
|
|
|
|
Andrew Pearson wrote: When I look at the standard serial port driver supplied with the WDK, I see that IOCTL_SERIAL_SET_LINE_CONTROL uses WdfInterruptSynchronize to set the Line Control Register,
Hmm, not sure if Microsoft actualy rewrote serial.sys to use WDF or not, so it cold just be a sample driver.
The older DDK with WDM source code actually IS serial.sys on those older machines (XP and older) so it might be a more informative source since WDF can hide stuff.
As the other poster says, watch out for the FIFO. I would make it 1 byte, that way you know that after any change you make to the parity bit settings will take effect immediately, and you might also like to have a slight delay, and possibly prod the UART before sending data. (You cold prod it by doing a disable/enable for example, or a flush, or toggling DTR...).
A UART programming sheet could be useful, it will tell you exactly what is going on at the chip when you run the various IOCTL calls.
How are you determining the value of the parity bit? DO you have a line sniffer? If not you might need to wire up the chip to a logic analyser to see what is actually on the wire. They are very useful, as well as scopes, in really getting HW to work as you want.
==============================
Nothing to say.
|
|
|
|
|
I am looking at the code from the latest DDK, but not sure if its WDF. I dont know a whole lot about MS drivers (although I am about to learn!). I am just referring to the sample. I have not looked in great detail yet, still feeling my way through it.
I actually disabled FIFO, I know that the code worked, because if I wrote 5 bytes to the port, only the last byte was transmitted! However, as before it never worked, and I should have realised that doing this provided yet another clue as the what was happening. When using WriteFile without overlapped, it is supposed to block until its completed, which I am sure it does. But what does completed mean?? Judging by the observations I made, and after thinking about it a little more, it obviously blocks until the data is written to the driver, not the UART! So I am guessing that the driver buffers what you write to it, and waits for an interrupt before writing the data to the UART, or something along those lines. On Monday, I shall be looking back at the driver code again!
So what I know now is:
Setting parity is immediate.
Transmitting the data is not immediate.
I also tried IOCTL_SERIAL_IMMEDIATE_CHAR command with no luck. I have since talked to another developer who has had the same issue. He gave me a tip late friday which I will try on monday.
I am using my own app to determine the value of the parity, setting space parity and using IOCTL_SERIAL_LSRMST_INSERT to get parity errors. This works really well actually. I was questioning weather there was a bug in this code too, but I came to the conclusion that it was fine after testing it against the hardware that uses this protocol. Was almost going to put the cro on it for my own sanity.
BTW, will be posting this project on code project once its all working ok.
|
|
|
|
|
can someone help me?
I have a variable declared as
CArray<CmyData *, CmyData*> myDataArray;
then I try the following:
CmyData** pData = (CmyData **) myDataArray.GetData();
qsort(pData, numItems, sizeof(CmyData *), Compare);
Something is whacky with how Compare() function receives the information from pData. Pointers go off to neverland??
Thank you.
RESOLVED:
My Compare function had to be adjust to handle array of pointers:
myClass::Compare(const void* pEle1, const void* pEle2)
{
CmyData* pData1 = *(CmyData **) pEle1;
CmyData* pData2 = *(CmyData **) pEle2;
}
modified 17-Feb-12 16:35pm.
|
|
|
|
|
Perhaps you should give more detail, like exactly what goes wrong, error message, etc..
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Sorry, i think the brackets watered down my description.
I have declared a CArray as:
CArray<CmyData *, CmyData *> myDataArray;
I fill myDataArray correctly using CArray::SetAtGrow(). This is done correctly because I test by iterating through the CArray after i fill it and check all the items in the CmyData object.
Then i attempt:
CmyData** pData = (CmyData **) myDataArray.GetData();
qsort(pData, numItems, sizeof(CmyData *), Compare);
Then when i look in my Compare() function, the 2 parameters have invalid values.
I don't know if there is a problem passing pData like i do OR if my Compare() function is not resolving the 2 parameters correctly.
(PS, thanks for the other posts on articles to read..)
|
|
|
|
|
Excellent article here[^], the examples should help.
|
|
|
|
|
And another relevant article, with examples here[^]
Gee, Google is a great tool, you should use it
|
|
|
|
|
Thanks! the first link you provided as a reference looks exactly like the setup i am using.
I also updated my post under one of the first replys - the < and > brackets may have corrupted my original question.
JJM
|
|
|
|
|
Do any working libraries exist for the latest version of the WebSockets used in Chrome? I found a library called libwebsockets but I could not get it to work. I kept getting a error about the Key mismatch. I found a C# one called Alchemy that I can use in managed C++. And that does work fine. Though, I would rather use non-managed C++ for my project.
What non-managed C++ options are there for WebSockets that work in the latest Chrome browser?
Thanks.
Nothing is impossible, It's merely a matter of finding an answer to the question of HOW? ... And answering that question is usually the most difficult part of the job!!!
|
|
|
|
|
Just hoping you could clarify this statement (particularly the italicized part):
Fred Ackers wrote: What non-managed C++ options are there for WebSockets that work in the latest Chrome browser?
Don't WebSockets work in whichever application they're compiled into? I don't understand the reference to Chrome. I understand if the desire is to use the same library that Chrome uses, in your own application.
However, I cannot for the life of me make heads or tails of the quoted part of your post.
|
|
|
|
|
Chrome uses a version of the WebSockets protocol that is different than provided by some of the libraries i tested. The protocol is RFC 6455 and the standard is (draft-ietf-hybi-thewebsocketprotocol-10 as of August 2011. I am not sure which version they use in the new Chrome browser, but either way, the libraries do not work with it.
The reference to Chrome comes me wanting WebSockets and not Sockets. I want WebSockets to use with HTML5. Hence the reference to Chrome with does in fact support HTML5. I do not want to make a websockets server as a javascript/php/python script that will serve the HTML5 WebSocket application I am making. I need it done in C++.
Once again, I do not need BSD style sockets! I need a websockets library for the WebSockets protocol that correctly performs the Handshake used by Chrome and possibly other HTML5 supporting browsers.
Nothing is impossible, It's merely a matter of finding an answer to the question of HOW? ... And answering that question is usually the most difficult part of the job!!!
|
|
|
|
|
|
enhzflep wrote: I'd also be keen to consider modifying a non-working library such that the handshake operation mirrored that exhibited by the C# code you already have (but prefer not to use)
Thank you for the idea about modifying the existing library based on code from another language that works. I was able to get the libwebsockets working in C++ now so I no longer need to use managed C++ or C# for the project. I found that there were a few problems, one being that the SHA1 and Base64 encoding schemes were not functioning correctly for some reason. Once I fixed those, and re-ordered the way the packets is sent, the library works wonderfully. So, thanks for the idea. The links really helped to understand how I needed to modify the existing code to get it working.
Nothing is impossible, It's merely a matter of finding an answer to the question of HOW? ... And answering that question is usually the most difficult part of the job!!!
|
|
|
|
|
It's a pleasure. I thought my idea would prove unpopular, though have read RFCs and modified code to conform in the past. The value of what I learned far exceeds the value of the time taken to do it, sure beats simply downloading a working implementation.
On a side note - nice sig! I've said for a long time "Everything's easy.... You just have to know how. Building a nuclear bomb is easy - _if_ you know how"
|
|
|
|
|
Hello,
I have a dialog that contains some radio buttons and a list box I wondered how can I pass a message to another object that the user chaghed his selection by press one of the redio buttons, I need to call to a method of the second object accordeing the user selction .
thanks
|
|
|
|
|
What is the second object?
"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
|
|
|
|
|
Object of a non dialog class
|
|
|
|
|
It depends how the objects are subclassed (or derived) and who their parent is. Just about all buttons in MFC are CWnd derived, but their event handlers are usually managed by the parent window (usually some CDialog or some sort of form).
If the second object that you're referring to is another button type of object, that is owned by the same parent window, then it's ok to make direct calls to access the other object. On the other hand, if that other object is in a separate dialog or form, then you should pass a message using SendMessage or PostMessage to the parent window and let it handle the event.
It's going to make quite a big difference as to what these "objects" you are talking about are and who the owner is. A number of different solutions will probably work, but you should be careful and follow framework guidelines as you may end up with an unstable solution.
|
|
|
|
|
Its a simple process with a number of small steps.
1. Wire-up the message handling of the radio buttons so that you get a WM_NOTIFY (or whatever the pertinent message is) whenever the active radio-button in the group changes.
2. Call method of object 2 with the selected option passed in as a variable somehow - either as text, or (preferably) as an INT that represents the choice number.
Here's a dialog-based app that demonstrates the principle. Whether you call the method of the second object when the selection changes or when an 'action' button is pressed, is up to you.
(And yes, I do realize that as they're radio-buttons, one of the options should be checked by default - just can't remember how just this minute - it was easier and quicker to add a test case to check if an option had been selected yet or not  )
resource.rc
// Generated by ResEdit 1.5.8
// Copyright (C) 2006-2011
// http://www.resedit.net
#include <windows.h>
#include <commctrl.h>
#include <richedit.h>
#include "resource.h"
//
// Dialog resources
//
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
DLG_MAIN DIALOGEX 6, 5, 194, 106
STYLE DS_3DLOOK | DS_CENTER | DS_SETFONT | WS_CAPTION | WS_VISIBLE | WS_GROUP | WS_THICKFRAME | WS_SYSMENU
CAPTION "Code::Blocks Template Dialog App"
FONT 8, "Tahoma", 0, 0, 1
{
PUSHBUTTON "&Test", IDC_BTN_TEST, 138, 5, 46, 15
PUSHBUTTON "&Quit", IDC_BTN_QUIT, 138, 29, 46, 15
GROUPBOX "Static", IDC_STATIC, 13, 16, 114, 68
AUTORADIOBUTTON "Radio Button 1", IDC_RADIO1, 38, 32, 63, 8
AUTORADIOBUTTON "Radio Button 2", IDC_RADIO2, 38, 45, 63, 8
AUTORADIOBUTTON "Radio Button 3", IDC_RADIO3, 38, 59, 63, 8
}
resource.h
#ifndef IDC_STATIC
#define IDC_STATIC (-1)
#endif
#define DLG_MAIN 101
#define IDC_BTN_TEST 1000
#define IDC_BTN_QUIT 1001
#define IDC_RADIO1 1002
#define IDC_RADIO2 1003
#define IDC_RADIO3 1004
main.cpp
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>
#include "resource.h"
HINSTANCE hInst;
int curRadioOption = -1;
BOOL CALLBACK DialogProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
char msgBuffer[1024];
switch(uMsg)
{
case WM_INITDIALOG:
return TRUE;
case WM_CLOSE:
EndDialog(hwndDlg, 0);
return TRUE;
case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDC_BTN_QUIT:
EndDialog(hwndDlg, 0);
return TRUE;
case IDC_BTN_TEST:
if (curRadioOption != -1)
sprintf(msgBuffer, "You clicked the \"test\" button\nCurrent radio selection: #%d", curRadioOption);
else
sprintf(msgBuffer, "No radio-button option selected...\nPlease select an option then try again");
MessageBox(hwndDlg, msgBuffer, "Information", MB_ICONINFORMATION);
return TRUE;
case IDC_RADIO1:
curRadioOption = 1;
return true;
case IDC_RADIO2:
curRadioOption = 2;
return true;
case IDC_RADIO3:
curRadioOption = 3;
return true;
}
}
return FALSE;
}
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
hInst = hInstance;
return DialogBox(hInstance, MAKEINTRESOURCE(DLG_MAIN), NULL, (DLGPROC)DialogProc);
}
|
|
|
|
|
Thanks for your replay , I didnt understand where is the calling to the method of object 2,
if you can mark this section it will be helpfull for me.
by the way I forgot to specify that I am using MFC but as I realized it doesnt matter.
thanks
|
|
|
|
|
That's okay. In fact - I didn't make any call to the method of object 2. Please accept my apology for being unclear.
As I alluded to earlier, I can see two places where such a call would make sense.
In the first case, there would be action immediately after a radio button was pressed.
I imagine you would not have the same need to keep track of the currently selected option, so I've omitted that code from the following case statements.
Example 1: Immediate response
case IDC_RADIO1:
object2.handleSelectedRadioButton(1);
return true;
case IDC_RADIO2:
object2.handleSelectedRadioButton(2);
return true;
case IDC_RADIO3:
object2.handleSelectedRadioButton(3);
return true;
In this second example, you'll need to remember which radio-button is selected somewhere, before taking the appropriate action when the trigger is received (in this case, the pressing of the button labelled Test)
Example 2: Action taken in response to another input
case IDC_BTN_TEST:
if (curRadioOption == -1)
MessageBox(hwndDlg, "Select a radio button first!", "Error", MB_ICONERROR);
else
object2.handleSelectedRadioButton(curRadioOption);
return TRUE;
Something else I should mention, is that MFC will most likely allow the state of any control to be quickly and easily queried (not sure if there's an object used to represent a group of radio buttons - I'd imagine that there was) This will make my global variable curRadioOption redundant.
|
|
|
|
|
Pass a pointer to the object you want to notify in the constructor of the dialog, and have the dialog save that in a member variable.
Then when events occur, make a call to that object.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
