So this is fun: a war story
-
Update: I rebooted and now everything works fine. :laugh: :laugh: :laugh: X| I'm kind of rubber ducking you all, so bear with me (or skip) and thanks. It's the wee hours here. I don't know what I changed in my code, but one minute it was working. The next minute every time I start it it's like the procedure that builds all the windows exits halfway through without creating everything, and then the app doesn't exit. (It appears to, but you have to kill it in TaskMan) I should pack it in but that leaves me for want of something to do (I woke up recently), and code in a known bad state. All of this mess is to simply read and write serial ports in win32, but due to a sort of polarity mismatch between the Arduino and Win32 APIs I need to spin a thread to continually fetch data from the COM port. This seems to be what is causing the problem. It's not a race condition though - it's consistent. I need to do this due to the presence of a
peek()function which peeks the next character in the stream, and anavailable()function which returns the # of bytes waiting in the receive buffer. Win32 has no such facilities, so I need to emulate them. I'm wondering if I can't just cooperatively thread the whole thing. I already have my main application loop where I could poll each com port, but due to separation of the various parts of Winduino I need to expose an uncomfortable amount of serial functionality "publicly" to make that happen. It kind of makes me want to give up and play fallout, but I really don't want to leave my code in its present state.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Ok, without knowing the details of your coding. Here are some very dumb assumptions and a question. I assume that since you used taskman to kill the app that the CPU was not pegged and memory was not pegged. It sounds like a resource issue or a locking issue. Did you try rebooting and running the app on a fresh machine with nothing else running?
-
Ok, without knowing the details of your coding. Here are some very dumb assumptions and a question. I assume that since you used taskman to kill the app that the CPU was not pegged and memory was not pegged. It sounds like a resource issue or a locking issue. Did you try rebooting and running the app on a fresh machine with nothing else running?
Oh it's definitely a deadlock. I'm just not sure where, and I think a lot of it has to do with me misunderstanding the behavior when reading COM ports under win32.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Oh it's definitely a deadlock. I'm just not sure where, and I think a lot of it has to do with me misunderstanding the behavior when reading COM ports under win32.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Time to start adding some debugging output to narrow done where....
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
-
Update: I rebooted and now everything works fine. :laugh: :laugh: :laugh: X| I'm kind of rubber ducking you all, so bear with me (or skip) and thanks. It's the wee hours here. I don't know what I changed in my code, but one minute it was working. The next minute every time I start it it's like the procedure that builds all the windows exits halfway through without creating everything, and then the app doesn't exit. (It appears to, but you have to kill it in TaskMan) I should pack it in but that leaves me for want of something to do (I woke up recently), and code in a known bad state. All of this mess is to simply read and write serial ports in win32, but due to a sort of polarity mismatch between the Arduino and Win32 APIs I need to spin a thread to continually fetch data from the COM port. This seems to be what is causing the problem. It's not a race condition though - it's consistent. I need to do this due to the presence of a
peek()function which peeks the next character in the stream, and anavailable()function which returns the # of bytes waiting in the receive buffer. Win32 has no such facilities, so I need to emulate them. I'm wondering if I can't just cooperatively thread the whole thing. I already have my main application loop where I could poll each com port, but due to separation of the various parts of Winduino I need to expose an uncomfortable amount of serial functionality "publicly" to make that happen. It kind of makes me want to give up and play fallout, but I really don't want to leave my code in its present state.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
I need to spin a thread to continually fetch data from the COM port
Your thread can wait on an event flag using
SetCommMask (hComm, EV_RXCHAR);. It's not that straightforward because sometimes, on some COM ports, Windows fails to trigger the event, so your thread has to wait with a timeout and recheck if any character has arrived. You can see a piece of code here. It is probably more complicated than what you need because it supports multiple clients reading from the same port and also time-tags each incoming character. Code has been in use for eons and it's bulletproof. If you want a stripped down version let me know.Mircea
-
honey the codewitch wrote:
I need to spin a thread to continually fetch data from the COM port
Your thread can wait on an event flag using
SetCommMask (hComm, EV_RXCHAR);. It's not that straightforward because sometimes, on some COM ports, Windows fails to trigger the event, so your thread has to wait with a timeout and recheck if any character has arrived. You can see a piece of code here. It is probably more complicated than what you need because it supports multiple clients reading from the same port and also time-tags each incoming character. Code has been in use for eons and it's bulletproof. If you want a stripped down version let me know.Mircea
Oooh I'll take a look. Right now I'm getting a hang on open, which is unfortunate. I may need to reboot and start fresh, but I'll download what you linked to first. Thank you. There's obviously some black magic here, and COM ports have never been particularly friendly when they decide not to work.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
honey the codewitch wrote:
I need to spin a thread to continually fetch data from the COM port
Your thread can wait on an event flag using
SetCommMask (hComm, EV_RXCHAR);. It's not that straightforward because sometimes, on some COM ports, Windows fails to trigger the event, so your thread has to wait with a timeout and recheck if any character has arrived. You can see a piece of code here. It is probably more complicated than what you need because it supports multiple clients reading from the same port and also time-tags each incoming character. Code has been in use for eons and it's bulletproof. If you want a stripped down version let me know.Mircea
Okay, so now that I've looked at the code, I do have a question. I'm going to have to port the thread and crit sec code away from your mlib stuff, which is fine, but I was wondering why you use a crit sec when it seems to me a mutex might be more appropriate? (I haven't followed all of the code, I'm kind of basing this on my own attempts, plus it has been drilled into me to avoid crit secs)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Time to start adding some debugging output to narrow done where....
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
It's hanging on Opening the com port with
FileOpenW(L"\\\\.\\COM25"...)despite it being valid. I may need to reboot as prior crashes could have hung the COM port or something. Still, I wish it would time out.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Okay, so now that I've looked at the code, I do have a question. I'm going to have to port the thread and crit sec code away from your mlib stuff, which is fine, but I was wondering why you use a crit sec when it seems to me a mutex might be more appropriate? (I haven't followed all of the code, I'm kind of basing this on my own attempts, plus it has been drilled into me to avoid crit secs)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
plus it has been drilled into me to avoid crit secs
Not sure why you say that: critsects are lighter sync objects that can be used only inside a process. That might avoid an expensive context switch. That's my thinking at least.
Mircea
-
honey the codewitch wrote:
plus it has been drilled into me to avoid crit secs
Not sure why you say that: critsects are lighter sync objects that can be used only inside a process. That might avoid an expensive context switch. That's my thinking at least.
Mircea
Can't remember why now. Probably from some old Win32 programming book by Petzold or something. Could be that old win32 code they were inefficient. That's the problem with absorbing all the stuff that I have over the years, I only retain broad strokes, not details after awhile. :sigh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Can't remember why now. Probably from some old Win32 programming book by Petzold or something. Could be that old win32 code they were inefficient. That's the problem with absorbing all the stuff that I have over the years, I only retain broad strokes, not details after awhile. :sigh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Anyway it's not important. If you want to change to a mutex, that should work OK also :)
Mircea
-
Anyway it's not important. If you want to change to a mutex, that should work OK also :)
Mircea
I'll keep it as a crit sec i think. Performance isn't critical in this in any case. If anything the PC runs too fast for what I need it for, except when doing SPI and I2C emulation. It's basically a way to connect Arduino's HardwareSerial class instances like Serial, Serial1, Serial2 etc to actual COM ports. Eventually I plan to also expose a virtual COM port so that you can connect to the PC without a loopback (which I'm currently using for testing). Current attempts at that have gone... poorly. No BSOD, but given i have to enable test signing to even get the driver to install, I don't want to force that on people, so i may nix it unless there's an easy way to get a software cert. I haven't looked into it. Oh and when I did try to install the DDK sample, it installed, but didn't show up as a COM port and so I have no way to uninstall it that's apparent.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
honey the codewitch wrote:
plus it has been drilled into me to avoid crit secs
Not sure why you say that: critsects are lighter sync objects that can be used only inside a process. That might avoid an expensive context switch. That's my thinking at least.
Mircea
Unlike mutexes & semaphores, a critical section is not a Kernel object. Acquiring a mutex or semaphore always requires a switch into kernel mode, which is not necessarily true for critical sections. The major disadvantages of critical sections are: 1. They are not shareable between processes (unlike semaphores and mutexes) 2. They are not recursive (unlike mutexes)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Unlike mutexes & semaphores, a critical section is not a Kernel object. Acquiring a mutex or semaphore always requires a switch into kernel mode, which is not necessarily true for critical sections. The major disadvantages of critical sections are: 1. They are not shareable between processes (unlike semaphores and mutexes) 2. They are not recursive (unlike mutexes)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
That matches exactly what I knew. In my case I didn't need inter-process synchronization. I just needed to serialize access to a ring buffer between a producer and consumers.
Mircea
-
I'll keep it as a crit sec i think. Performance isn't critical in this in any case. If anything the PC runs too fast for what I need it for, except when doing SPI and I2C emulation. It's basically a way to connect Arduino's HardwareSerial class instances like Serial, Serial1, Serial2 etc to actual COM ports. Eventually I plan to also expose a virtual COM port so that you can connect to the PC without a loopback (which I'm currently using for testing). Current attempts at that have gone... poorly. No BSOD, but given i have to enable test signing to even get the driver to install, I don't want to force that on people, so i may nix it unless there's an easy way to get a software cert. I haven't looked into it. Oh and when I did try to install the DDK sample, it installed, but didn't show up as a COM port and so I have no way to uninstall it that's apparent.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
unless there's an easy way to get a software cert.
If you find one, please share it with us. I'm looking for the same.
Mircea
-
Oh it's definitely a deadlock. I'm just not sure where, and I think a lot of it has to do with me misunderstanding the behavior when reading COM ports under win32.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
found this on stack overflow: "Serial port causes deadlock after some non fixed number of writes (C++)" It is from 8 years ago. https://stackoverflow.com/questions/28438045/serial-port-causes-deadlock-after-some-non-fixed-number-of-writes-c[^]
-
Oooh I'll take a look. Right now I'm getting a hang on open, which is unfortunate. I may need to reboot and start fresh, but I'll download what you linked to first. Thank you. There's obviously some black magic here, and COM ports have never been particularly friendly when they decide not to work.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Are you running open loop (continuous polling the buffers)? Are hardware interrupts involved? It's been too long ago for clarity, but my serial port adventures usually ended up by running some sort raw polling routine and do all the character interpretation and buffering if needed in the same loop. But I may just understand your problem. I do sympathize with need for solution. couldn't sleep on it either. BTW I did not C file I/O opens and reads.
"A little time, a little trouble, your better day" Badfinger
-
Are you running open loop (continuous polling the buffers)? Are hardware interrupts involved? It's been too long ago for clarity, but my serial port adventures usually ended up by running some sort raw polling routine and do all the character interpretation and buffering if needed in the same loop. But I may just understand your problem. I do sympathize with need for solution. couldn't sleep on it either. BTW I did not C file I/O opens and reads.
"A little time, a little trouble, your better day" Badfinger
I am running a loop on a thread for each COM port, using non-overlapped I/O. It's primitive, but it works well enough. Well, it does now. It was freezing up on the call to
FileOpenW(L"\\\\.\\COM25",...)but a reboot fixed it and it's all working great now.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It's hanging on Opening the com port with
FileOpenW(L"\\\\.\\COM25"...)despite it being valid. I may need to reboot as prior crashes could have hung the COM port or something. Still, I wish it would time out.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You need something like this ... RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module : Amazon.com.au: Computers[^] but using a breadboard and LEDs would be far cheaper. Then you can see what is happening. It was one of most trusted testing tools, back in the day...
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
-
You need something like this ... RS232 Breakout Tester LED Monitor, DB9 Male to Female Breakout Module : Amazon.com.au: Computers[^] but using a breadboard and LEDs would be far cheaper. Then you can see what is happening. It was one of most trusted testing tools, back in the day...
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
A reboot fixed it. I guess a previous crash maybe left the com port in a bad state.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
A reboot fixed it. I guess a previous crash maybe left the com port in a bad state.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yeah, it can get stuck and confused... Glad it is sorted
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
