If/when you get around to testing the firmware specific payload stuff, the metadata lookup service can be crosschecked against itself somewhat.
address values or lack of vs flags saying so
editability of indexiable/non blocks
verification of tables, send bad shit and look for errors
use parent flag and memory details to check that data matches between the two ways of accessing it.
That's all i can think of for now. Irrelevant at this stage, I know, but recorded for prosperity.
Fred.
FreeEMS communications stress testing
Re: freeems communications stress testing
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: freeems communications stress testing
...still researching my serial port options. I'm contemplating doing it from windows since I already know how to do it. So I'm also researching how something like that would work in Wine.
- nitrousnrg
- LQFP144 - On Top Of The Game
- Posts: 468
- Joined: Tue Jun 24, 2008 5:31 pm
Re: freeems communications stress testing
why not qextserialport?
afaik, you are already using qt
afaik, you are already using qt
Marcos
Re: freeems communications stress testing
No, he's not, either he or boost stole the slot/signal terminology from QT, though.
EssEss, you're being crazy now! You'd be better off fixing boost :-p
How hard is it to just wrap the lib in a nicer way than it currently allows for? It can't be THAT hard can it? Even if it seems wrong to propogate the wrongness. Once you have it working nice you could make your case to the boost people and maybe get it upstreamed.
Fred.
EssEss, you're being crazy now! You'd be better off fixing boost :-p
How hard is it to just wrap the lib in a nicer way than it currently allows for? It can't be THAT hard can it? Even if it seems wrong to propogate the wrongness. Once you have it working nice you could make your case to the boost people and maybe get it upstreamed.
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!
Re: freeems communications stress testing
its not really that simple ... and I don't have those kinds of cpp skills yet. I'd just rather wrap read/write/select and have 70% of my code doing work, then 70% wrapping/managing the work of something else. I know why dave uses read/write/select - its the same reason I want to use it. In the windows world we call it overlapped i/o.
qextserialport suffers the same problem and appears to introduce a new dependency on top of it.. if everything was send-n-wait like ms, then it works fine (anything works fine really). when you have streams mixed in - you need async io (which is easily solved). at the very bottom of the stack to feed all those aync threads I need select() like functionality which I may only get through going straight for the throat and hitting up the raw linux system functions like I would in windows.
I know how to do all of this stuff in windows but I'm still feeling my way around linux and this projects main purpose (for me) was an attempt to start reversing my knowledge imbalance. So it's slow right now, and I completely expected that. If we need it faster, then I need to revert back to what I know which is why I'm also looking into what Wine can support (and even Mono) .. and it's not looking very good. I'm a windows person trying to cater to non-windows people. If this isn't lining up with what people are expecting from me and this project I have no problems defaulting to the easy path![Smile :)](./images/smilies/icon_e_smile.gif)
qextserialport suffers the same problem and appears to introduce a new dependency on top of it.. if everything was send-n-wait like ms, then it works fine (anything works fine really). when you have streams mixed in - you need async io (which is easily solved). at the very bottom of the stack to feed all those aync threads I need select() like functionality which I may only get through going straight for the throat and hitting up the raw linux system functions like I would in windows.
I know how to do all of this stuff in windows but I'm still feeling my way around linux and this projects main purpose (for me) was an attempt to start reversing my knowledge imbalance. So it's slow right now, and I completely expected that. If we need it faster, then I need to revert back to what I know which is why I'm also looking into what Wine can support (and even Mono) .. and it's not looking very good. I'm a windows person trying to cater to non-windows people. If this isn't lining up with what people are expecting from me and this project I have no problems defaulting to the easy path
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: freeems communications stress testing
Stick with it, raw linux is fine by me :-)
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!
Re: freeems communications stress testing
I'd rather build efficiency than bloat at this level. Sounds like a plan, and is probably something easily abstracted for future windows support. I'll start looking through dave's code for guidance.
Re: freeems communications stress testing
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: freeems communications stress testing
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!
- SleepyKeys
- LQFP144 - On Top Of The Game
- Posts: 549
- Joined: Mon Feb 11, 2008 10:52 pm
- Location: Arizona
- Contact:
Re: freeems communications stress testing
EssEss wrote:So I'm new to cpp and I'm already in love:
Code: Select all
/** * @public * @brief encode a flattened packet * @param[in] p reference to flattened packet * @retval vector<uint8_t> packet encoded in accordance with the freeems ......[/quote] Checkout boost::array too.
You snooze, you lose!