not sure if this also sounds too simpistic, this is how I handle streaming vs polling (simultaneously) in my own code:
1) every msgs going out gets 'tagged' and waits for the response coming back with a matching 'tag' - if timeout the originator gets notified and then it gets pulled off the waiting list and goes on a backburner list - so I can pull it later for debug or dump it to log .. usually this means that I don't have support for the command in my firmware
2) anything that doesn't have a matching tag (most likely a streamed msg) gets delegated out to whoever wants to get a shot at parsing it .. this also allows me to dump to log too. think observer + chain of responsibility.
the above also lets me run different streams at different rates without increasing bandwidth needs. I can stream things like clt temp every 1s without having it get streamed in another higher freq stream.
the above also has other infrastructure required .. most of which I left out. I'll look over mtx code too.
Patching MTX for our use
Re: Patching MTX for our use
Yeah, something like that is perfect, i think. Nicely articulated too.
I don't think we'll have resources to do different streams interleaved. what we will have is the ability to filter the data sent back to a required subset in some fashion. thought out, but not quite implemented yet.
Fred.
I don't think we'll have resources to do different streams interleaved. what we will have is the ability to filter the data sent back to a required subset in some fashion. thought out, but not quite implemented yet.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
-
- LQFP112 - Up with the play
- Posts: 100
- Joined: Sun Apr 06, 2008 6:30 pm
Re: Patching MTX for our use
Sounds good to me, though since MS doesn't use this model (and MtX support MS still) it would probably need to be a compile time option, or a runtime setting to enable this sort of behavior. IT sounds good and I like the interleaving ability and the ability to provide feeds that other software could plugin to (logger, etc)
--
David A.
--
David A.
Re: Patching MTX for our use
Runtime option sounds a lot more attractive than having to have two mtx installs and downloads and and and if you happen to have customers or friends with both ms and FreeEMS. Somewhere I drew up a thing on how to do the discovery/interrogation without affecting the other platform. Maybe I should find it and link it here.
Fred.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
-
- LQFP112 - Up with the play
- Posts: 100
- Joined: Sun Apr 06, 2008 6:30 pm
Re: Patching MTX for our use
Fred wrote:MTX = C++
MLV = NON-FREE Java
I don't mind mlv and use it, but I know a few of our members are very anti it for a number of reasons.
Bzzt!!, Mtx == C NOT C++
-- David
Re: Patching MTX for our use
Fixed
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Patching MTX for our use
Nearly three years after the start of this thread, it is starting to come to reality, woo hoo :-)
Fred.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!