Page 3 of 5
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 5:19 pm
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.
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 6:06 pm
by nitrousnrg
sorry, installing:
libboost1.42-all-dev
and doing
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.
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 6:49 pm
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.
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 8:03 pm
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.
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 8:56 pm
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.
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 9:00 pm
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...
Re: freeems communications stress testing
Posted: Wed Jan 05, 2011 10:03 pm
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.
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.
Re: freeems communications stress testing
Posted: Thu Jan 06, 2011 3:29 am
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.
Re: freeems communications stress testing
Posted: Thu Jan 06, 2011 6:40 am
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.
Re: freeems communications stress testing
Posted: Thu Jan 06, 2011 7:11 am
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.