modulo and frame number in mframe_sched.c

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Max.Suraev at fairwaves.ru
Fri Oct 19 08:29:24 UTC 2012


19.10.2012 09:57, Sylvain Munaut пишет:
> He's talking about this structure :
> 
> struct mframe_sched_item {
>         const struct tdma_sched_item *sched_set;
>         uint16_t modulo;
>         uint16_t frame_nr;
>         uint16_t flags;
> };
> 

Yes, exactly. Pardon for being unclear.

> 
> However I don't see the gain of space as really that much of an
> advantage vs the potential time lost looking for bugs when playing
> with non-standard multiframes.
> 
I agree. Btw, is this non-standard multiframes experimentation available in some
public repo? Would love to have a look at the code.

> The fact that we are currently almost full memory is just because we
> still use the compal loader. We should just deprecate that and
> oompletely and only compile the chain loader and loader with that
> constrained memory layout.
> 
Indeed - I've got error about rssi.compalram.elf file which is too big to be used
without chainloading anyway.

Maybe we can make this configurable via something like
./configure --enable-compalram-rssi
./configure --enable-chainload-rssi
etc.

-- 
best regards,
Max, http://fairwaves.ru





More information about the baseband-devel mailing list