FreeEMS communications stress testing

A place for small project requests from the team to exist and grow into something fully fledged and useful to the masses.
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: freeems communications stress testing

Post by EssEss »

I just did a clean build:

Code: Select all

[sean@mikoyan build]$ make
Scanning dependencies of target fe
[ 14%] Building CXX object src/CMakeFiles/fe.dir/encoder.cpp.o
[ 28%] Building CXX object src/CMakeFiles/fe.dir/decoder.cpp.o
Linking CXX static library ../lib/libfe.a
[ 28%] Built target fe
Scanning dependencies of target cst
[ 42%] Building CXX object src/CMakeFiles/cst.dir/main.cpp.o
Linking CXX executable ../bin/cst
[ 42%] Built target cst
Scanning dependencies of target cst-test0
[ 57%] Building CXX object test/CMakeFiles/cst-test0.dir/cst-test0.cpp.o
Linking CXX executable ../bin/cst-test0
[ 57%] Built target cst-test0
Scanning dependencies of target cst-test2
[ 71%] Building CXX object test/CMakeFiles/cst-test2.dir/cst-test2.cpp.o
Linking CXX executable ../bin/cst-test2
[ 71%] Built target cst-test2
Scanning dependencies of target decoder-test
[ 85%] Building CXX object test/CMakeFiles/decoder-test.dir/decoder-test.cpp.o
Linking CXX executable ../bin/decoder-test
[ 85%] Built target decoder-test
Scanning dependencies of target encoder-test
[100%] Building CXX object test/CMakeFiles/encoder-test.dir/encoder-test.cpp.o
Linking CXX executable ../bin/encoder-test
[100%] Built target encoder-test
[sean@mikoyan build]$ 
try starting over, or pull first before making again.
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: freeems communications stress testing

Post by nitrousnrg »

sorry, installing:
libboost1.42-all-dev

and doing

Code: Select all

cmake freeems-cst
make
it compiles nicely. I was doing "cmake freeems-cst/src". Could you modify the "<path to src>" on the README file? pointing to src/ won't work.
Marcos
User avatar
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

Post by SleepyKeys »

Yep vector is pretty sweet, I need to update my c-ish stuff to cpp soon.

On another note Fred was talking about a std lib that we could all use for comms purposes. If it had some functions similar to the SerialMonitor like read and write block it I could use it for doing advanced loading like partial loads etc. The only down side I can think of is that the comms functions would need to be copied to RAM in-order to overwrite all flash areas. NOT a high priority.
You snooze, you lose!
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: freeems communications stress testing

Post by EssEss »

I think a lib will shake out of this .. but its not my inital goal so I don't have a timeline.

It would be event driven internally and the working of those internals would be wrapped in commands which will be blocking. If you need async command operation just spin off the command into a worker thread. I know the description of it all sounds wishy-washy and hand-wavy, but I don't want to have your eyes glaze over with a bunch of specifics.

It should all end up being wrapped into a series of tests too ..
If anyone wants to work on a simple script (py/perl/bash/whatever), how about something like this:

Code: Select all

# from the ./bin dir:
foreach( file ending in test )
    run it and grab the return value
    fail on anything !0
... until I can get this automated by cmake as part of the build. Right now, decoder-test and encoder-test are the only real tests that exist currently. I intend on all of my tests to be the ultimate documentation until I can get doxygen automated from cmake too.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeems communications stress testing

Post by Fred »

@SeanK My idea was for you to talk to running old firmware through this lib over FreeEMS protocol, interrogate the data available, grab a copy and save it with all the meta data right along side the raw image you are already planning to rip. The use a map file and the meta data to modify the image you're about to load after asking the user which things to keep and which to not keep from a check list (or config) and load normally through the SM. There are not and never will be generic write block memory access functions available in the firmware, that would be irresponsible from a reliability point of view. A much later goal might be to preload a ram firmware with freeems protocol and its own set of firmware specific memory write commands and then reliably load through that instead of the SM, but that's way down the line. You could use the same lib for that, though.

@EssEss is there any good reason why they are all stand alone binaries? Why not one monolithic app? It's all your decision, but I don't understand, fill me in if you have time/desire.

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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeems communications stress testing

Post by Fred »

nitrousnrg wrote:it compiles nicely. I was doing "cmake freeems-cst/src". Could you modify the "<path to src>" on the README file? pointing to src/ won't work.
I don't understand this. I did "cmake CMakeLists.txt" and it works fine. Are you saying I could have done "cmake ." and it will find the lists file? If so, why is that not the default behaviour like it is for make... In any case, if freeems-cst is the name of your external directory, do NOT count on that being the same on everyone's machines...
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!
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: freeems communications stress testing

Post by EssEss »

Fred wrote:is there any good reason why they are all stand alone binaries? Why not one monolithic app? It's all your decision, but I don't understand, fill me in if you have time/desire.
it provides flexibility at a time I need it most. the main app is there and the rest are my sandboxes for things I don't know how to do yet or for feeling out ideas. yes, I can work locally and not pollute the prj with junk, but if my laptop disappears tonight then no work is lost.

someday, as time dictates, there's no reason that the only things left standing are 'cst' and 'test' in the bin dir. I'm only one person who knows little about cpp/boost. If I had people beating down my door to help, I still don't know where I would place them since there is so much more I need to figure out. Until it gets painful to manage (and my threshold is low) then I'm not going to waste any time on it .. I'll spend my time learning what I need to get to the next step. :lol:

I'm working on slots/signals and threading right now so I can start stripping off stx/etx's from the raw stream and emit pkts for the decoder.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeems communications stress testing

Post by Fred »

OK, so it's just temporary, sweet.

Slots and signals are QT, is this thing getting a GUI?

I endorse checking in such work in this case (not that you care), it's not a big deal dirty wise, esp if you're pulling in code from the experimental stuff.

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!
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: freeems communications stress testing

Post by EssEss »

boost's slots/signals are the same abstraction as qt .. if you know any .net paradigms, think delegates.

boost is really letting me down at the moment, I think I may search out a different serial lib (or go straight for the throat).

if anyone knows boost, i really need some answers:
what do I use to timeout on a read ? there are about 15 different ways to read a 'up to' a certain byte count. Even if I do single byte reads which is ridiculously inefficient, there is no guarantee that a pend will ever timeout unless there is an error. Therefore, I need to wrap their (boost) stuff with another thread to timeout independently on their (io_service) read thread so I can destroy it (since I can't ask it to stop). This is starting to get a bit out of hand .. their abstractions are not flexible enough for what I want to do and I'm not about to implement my own io_service on their stuff to perpetuate an insufficient abstraction. I don't think boost::asio::serial_port was ever intended for binary data which is why their api is lacking this ability.

in a nutshell - I want select() functionality as dave uses in mtx. hitting some raw api's look easier every day I stare at this: http://www.easysw.com/~mike/serial/serial.html. I may have to abandon any cross-platform dreams for the time being.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeems communications stress testing

Post by Fred »

Dave's stuff is GPL also, you can just grab it and stuff it into yours if it speeds you up.

Is there a boost forum, and if so, can you post on it and see if you can get the API improved or at least get a definite no from someone in the know?

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!
Post Reply