- Jun 22, 2016
-
-
Cedric Roux authored
-
Cedric Roux authored
stuff put in there is of lower quality / coding standard / whatever and serves as example to do quick debugging taks using the T infrastructure
-
Cedric Roux authored
-
Cedric Roux authored
the current version is very specific to PUSCH IQ data, where the input buffer has a special format to be rewritten cleanly at some point
-
Cedric Roux authored
-
Cedric Roux authored
-
- Jun 20, 2016
-
-
Cedric Roux authored
XY_LOOP_MODE: replace old points with new ones, using the maximum size of the view XY_FORCE_MODE: append_forced sets those and only those points and we crash if we pass too much points
-
Cedric Roux authored
-
Cedric Roux authored
-
- Jun 17, 2016
-
-
Cedric Roux authored
-
Cedric Roux authored
to be used in conjunction with another tracer so conceptually it's more a tracee than a tracer
-
Cedric Roux authored
-
Cedric Roux authored
-
- Jun 16, 2016
-
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
- Jun 10, 2016
-
-
Cedric Roux authored
very basic, to be refined, find a nice way to display (plot? text?) protocol data movement
-
Cedric Roux authored
to be refined, it's rough
-
- Jun 09, 2016
-
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
3 pixels wide look better than 1
-
Cedric Roux authored
- update T_messages.txt - update call sites of the T for thoses traces
-
Cedric Roux authored
more readable, still not satisfying though
-
Cedric Roux authored
-
- Jun 08, 2016
-
-
Cedric Roux authored
-
Cedric Roux authored
events are accepted by the logger if the filter accepts them the filter is optional (no filter means to accept all events)
-
Cedric Roux authored
this is like timeview but the plotting is done at frame/subframe resolution of a given reference clock signal, let's say. The realtime information of the events is not used. It's all logical. It will be used to log harq processes for the moment.
-
- Jun 06, 2016
-
-
Cedric Roux authored
this may be removed at some point, it's very brutal. But when you write some code, it may happen (it "may"!!) that *sometimes* the code does not work and crashes. In thoses cases I prefer the local tracer (or the tracee) to go away immediately without even thinking about it maybe still running in the background. In case of monitoring (as opposed to debugging) maybe it's preferable to let the process live its life as it wants. Time will tell.
-
Cedric Roux authored
and also start to use the PHY textview
-
Cedric Roux authored
-
Cedric Roux authored
always a good idea to crash in unknown situations...
-
- Jun 05, 2016
-
-
Cedric Roux authored
enb.c will then try to reconnect.
-
Cedric Roux authored
-
Cedric Roux authored
it may legitimately happen when the tracee is ctrl+c'ed. Let's print something though because read may fail for other reasons. Why not?
-
Cedric Roux authored
write() on a socket with the other end closed throws a SIGPIPE. Let's ignore this signal. write() will return an error anyway...
-
Cedric Roux authored
fullread has been changed, so get_event too, and the callers also for the moment the callers crash, enb.c will be a bit more clever, the others to see...
-
Cedric Roux authored
The application (enb.c basically) will now monitor the socket and reconnect if it dies. See following commits.
-
- Jun 04, 2016
-
-
Cedric Roux authored
It was wrong. Plus it is starting work so as to make enb.c not crashing if the tracee goes away (maybe also textlog and vcd, but those are of less importance).
-