Stuart Longland
2015-10-25 00:01:36 UTC
Hi all,
I'm now starting to look at the 700B mode, since that would be the next
major advance for the SM1000. (All the little stuff that can be
practically achieved has been achieved.)
I put this off until I got a better understanding of how the code
worked. As I understand it, the structures for FreeDV are allocated on
the heap using malloc, and that to switch modes, I must first free the
existing instance and open a new one.
of the buffers used in encoding/decoding.
Interestingly, we seem to be passing an integer non-const variable in
the declaration of these arrays; didn't think that was allowed. (It
clearly is here, then again, I've seen some like the TI Code Composer
compiler which would definitely reject that bit of code.)
These arrays get declared on the stack, so are going to be hard to
change. We can pretend they are smaller, but not bigger.
To my way of thinking, we have a couple of options:
1. We can use malloc/free to allocate these on the heap, which means we
can re-allocate them later.
2. We can pick a size that will be big enough for both 700B and 1600,
and leave them fixed at that size.
3. We allocate two sets of buffers, one for 700B, the other for 1600.
Option 3 seems unwieldy in terms of code footprint and memory usage, so
probably not worth considering.
Option 2 would be the simplest, but I have no idea how big n_samples is,
or how much it changes.
Option 1 wouldn't be too hard, but I'm not sure what the implementation
of malloc/free permits. Some embedded versions have funny restrictions
like requiring you to free objects in the reverse order to their
allocations. Some don't actually implement free().
Then there's the game of dealing with memory fragmentation. Each of
those could bite us in unexpected ways.
The other option is we just forgo giving the user a choice at run-time.
The device stores the 700B/1600 mode selection in its configuration
settings, and to change it requires a power-cycle to reboot.
What's actually needed in order to switch from one mode to the other?
I'm now starting to look at the 700B mode, since that would be the next
major advance for the SM1000. (All the little stuff that can be
practically achieved has been achieved.)
I put this off until I got a better understanding of how the code
worked. As I understand it, the structures for FreeDV are allocated on
the heap using malloc, and that to switch modes, I must first free the
existing instance and open a new one.
/* Set up FreeDV modem */
f = freedv_open(FREEDV_MODE_700B);
n_samples = freedv_get_n_speech_samples(f);
n_samples_16k = 2*n_samples;
short adc16k[FDMDV_OS_TAPS_16K+n_samples_16k];
short dac16k[n_samples_16k];
short adc8k[n_samples];
short dac8k[FDMDV_OS_TAPS_8K+n_samples];
The n_samples bit concerns me though. That basically decides the sizef = freedv_open(FREEDV_MODE_700B);
n_samples = freedv_get_n_speech_samples(f);
n_samples_16k = 2*n_samples;
short adc16k[FDMDV_OS_TAPS_16K+n_samples_16k];
short dac16k[n_samples_16k];
short adc8k[n_samples];
short dac8k[FDMDV_OS_TAPS_8K+n_samples];
of the buffers used in encoding/decoding.
Interestingly, we seem to be passing an integer non-const variable in
the declaration of these arrays; didn't think that was allowed. (It
clearly is here, then again, I've seen some like the TI Code Composer
compiler which would definitely reject that bit of code.)
These arrays get declared on the stack, so are going to be hard to
change. We can pretend they are smaller, but not bigger.
To my way of thinking, we have a couple of options:
1. We can use malloc/free to allocate these on the heap, which means we
can re-allocate them later.
2. We can pick a size that will be big enough for both 700B and 1600,
and leave them fixed at that size.
3. We allocate two sets of buffers, one for 700B, the other for 1600.
Option 3 seems unwieldy in terms of code footprint and memory usage, so
probably not worth considering.
Option 2 would be the simplest, but I have no idea how big n_samples is,
or how much it changes.
Option 1 wouldn't be too hard, but I'm not sure what the implementation
of malloc/free permits. Some embedded versions have funny restrictions
like requiring you to free objects in the reverse order to their
allocations. Some don't actually implement free().
Then there's the game of dealing with memory fragmentation. Each of
those could bite us in unexpected ways.
The other option is we just forgo giving the user a choice at run-time.
The device stores the 700B/1600 mode selection in its configuration
settings, and to change it requires a power-cycle to reboot.
What's actually needed in order to switch from one mode to the other?
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
------------------------------------------------------------------------------
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
------------------------------------------------------------------------------