|
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
|
|
|
|
|
 all is well that ends well.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
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
|
|
|
|
|
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. 
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
|
|
|
|
|
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
|
|
|
|
|
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:
- They are not shareable between processes (unlike semaphores and mutexes)
- 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
|
|
|
|
|
Hello guys,
We are into healthcare application development.
I see there's a good amount of Standardization of the healthcare data. Like HL7 / FHIR etc.
All these are needed for interops between different HC systems.
The question is, Should our App DB schema that will be used internally should also adhere to FHIR standards?
I see these options:
1. Store App Data in application domain schema - just plain JSON with our own attributes. Snappy format helps faster transfers between the Apps.
2. Store App Data in FHIR transformation-compatible format. (Make it easier for ETL later into FHIR std). Schema needs some effort.
3. Sore App Data in full FHIR format. This makes the json payloads heap up like a landslide. A lot of effort upfront and bloated transport all around.
What would you recommend?
modified 30-Sep-23 4:35am.
|
|
|
|
|
If you have a standard, use it.
It means your apps can be more flexible, more generic - and can interface with other manufacturers apps, which is why we have standards in the first place!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Healthcare implementations are complex.
If you notice, Azure FHIR architecture examples never insist we store our Application Data in FHIR standard.
They say just go with what our App needs and don't worry about interop with external systems.
When there's a need for interop, Azure FHIR adaptors can transform the app domain data into standard Healthcaredata.
This has been the recommendation from different corners. But still want to hear from you guys here.
|
|
|
|
|
Apps have a shelf life. One day, someone is going to need to migrate the data in your (presumably) massive vertical healthcare application to some other system.
Use the standard, even if it's a lot of extra work up front. You'll recoup some of it on the back end, because you won't have to do things like document every nook and cranny rather than refer to existing standard docs for your data format.
Gosh just reading your post feeds into my burnout. Ugh, not your fault, it's just, my days of coding monolithic enterprise applications is over.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
This.
Otherwise when it comes to interoperability, you're just creating [standards]+1.
|
|
|
|
|
dandy72 wrote: you're just creating [standards]+1 xkcd: Standards[^]
FTFY
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I was going to link to that, and that is exactly what I had in mind what I wrote my post...
|
|
|
|
|
You store it in the form that normalization dictates; taking into consideration access paths; which means buying off the DBA to forget theory for a minute.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I reject the premise of the question.
|
|
|
|
|
Why ?
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Nand32 wrote: All these are needed for interops between different HC systems....App DB schema
I guess you really mean something like 'data model' rather than 'database' which would be what I see when you say "DB".
Nand32 wrote: What would you recommend?
That requires much more detail about the architecture than what you presented here.
Given that there are different systems then who controls/owns those systems? That is important.
But other than that transforming data between systems on communication pipelines is always a given. Even if was a good idea to use the same standard for all each system must still serialize/deserialize the binary into data. So the transform layer will always exists.
And it depends on the systems on the pipe. It would seem really unlikely that you could create one template/definition to which every single system must conform when those systems must in fact be each doing something different. Not without adding unneeded complexity.
What happens if you provide one standard to which 100 systems must adhere and yet a change is needed so just 2 of those systems can be updated?
So ignoring all of that, if the existing external models can be easily broken down (important) to sub-models which mostly meet the communication needs of two systems, then you can use that between those two systems. But I suspect you will still need an envelope into which the sub-model is passed.
|
|
|
|
|
Wordle 833 5/6
🟨⬛⬛⬛⬛
⬛⬛🟨⬛⬛
🟩🟩⬛⬛🟩
🟩🟩⬛⬛🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 833 5/6
⬛⬛🟨⬛⬛
🟨⬛🟩⬛⬛
⬛🟩🟩⬛⬛
⬛🟩🟩🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 833 3/6
🟨🟨⬜⬜⬜
⬜⬜⬜🟨🟨
🟩🟩🟩🟩🟩
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
