Hi all!
I would like to inform, that this task is almost finished! Just tested
my changes, and build was successful without any warnings. But I still
have a couple of unresolved issues:
I have some problems with understanding how to add a new item into the
convolutional codes generator (utils/conv_gen.py), so temporary I just
used a single file from OsmoBTS (gsm0503_conv.c) to check, if all the
rest forks fine. If someone (Max?) can help me to move missed tables
(mostly EGPRS specific, see 73cb583e5147a267a370c576e8ac77507de6d0d7),
I will be grateful, and the task will be completely finished soon.
Also, there are several external dependences from libosmocodec, such as:
- gsm620_unvoiced_bitorder
- gsm620_voiced_bitorder
- gsm660_bitorder
- gsm610_bitorder
They are some uint16_t arrays, related to GSM HR, FR and EFR. It's sadly,
that they cannot be included using exactly corresponding header files.
I think there are three possible ways to solve this problem:
1. Link gsm620.c, gsm660.c and gsm610.c to libosmogsm sources.
(I am not sure, that it is a good way...)
2. Copy required arrays to libosmogsm (also unlikely).
3. Add libosmocodec.la as dependence (I suggest exactly this solution):
- libgsmint_la_LIBADD = ../libosmocore.la
+ libgsmint_la_LIBADD = ../libosmocore.la ../codec/libosmocodec.la
All other problems was solved.
With best regards,
Vadim Yanitskiy.
2016-08-04 19:51 GMT+06:00 Vadim Yanitskiy <axilirator(a)gmail.com>om>:
Hi Max,
Thanks for your reply!
I think extending utils/conv_gen.py is the way to
go because it will
allow us to have concise description of the convolutional codes in one
place and as close to the description in standards as possible.
Ok, I will keep your opinion in my mind.
Could you specify which files exactly are you
referring to? Also you can
use 'git blame' to clarify authorship.
No problem, they are:
- gsm0503_conv.c
- gsm0503_interleaving.c
- gsm0503_mapping.c
- gsm0503_parity.c
- gsm0503_tables.c
Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
Thank you for this hint, this command is very usable! :)
I don't think library functions should do any
sort of logging by itself
(unless it's a logging functions of course :)
Instead they should return clearly distinguishable values and let caller
do the logging as they see fit.
I am agree with you. It's time to use return codes.
Have a nice day!
With best regards,
Vadim Yanitskiy.