Hi Stuart,
Rather than a debugger I'd just using a codec-dev release from March,
see if that works, then work fwd to see what changed. Much easier to
start with something that works.
I'll be looking at SM1000 firmware again later this year when a 700 mode
is ported. Would really appreciate some help with this if anyone is
interested!
Stuart - you approach and code for inserting audio looks fine to me, and
the fact that it works in analog mode is a good start.
To measure CPU load I use blinky GPIO pins and an oscilloscope.
It's great that you are experimenting with the SM1000 firmware.
Cheers,
David
On 13/09/15 18:09, Stuart Longland wrote:
> On 13/09/15 17:04, David Rowe wrote:
>> You may have hit the "colorful ring of death", which is where asserts()
>> end up on STM32F4 systems. I haven't tested a recent build of the
>> SM1000 firmware myself.
>
> Ahh that explains it. So I'll need a debugger to see what's going on.
> I've got something going using the gcc-arm-embedded toolchain, but it
> seems my own toolchain will have to wait.
>
>> For comparison I have posted the sm1000.bin image we built in March,
>> that is used for the current production SM1000s. See item 1 of "Testing,
>> Debugging, Development Notes" on the SM1000 page for the link.
>
> I've stashed that file for future reference, since it seems it's
> toolchain related. Thanks for that.
>
> I've got things going for now, at the moment I'm working on generating
> tones through the speaker by mixing in a sine.
>
> I figure that regardless of whether the audio comes from recordings or
> as morse, I'm going to have to figure out how to get them into the audio
> buffer.
>
> For now I've just created a simple structure:
>> struct buzzer_state {
>> /*! Number of samples remaining. */
>> unsigned short remain;
>> /*! Current buzzer sinewave sample. */
>> unsigned char sample;
>> };
>
> and two functions:
>> /*! Start the buzzer for the next len samples */
>> void buzzer_start(struct buzzer_state* bs, unsigned short len) {
>> bs->remain = len;
>> }
>>
>> /*! Get the next sample for the buzzer */
>> short buzzer_next_sample(struct buzzer_state* bs) {
>> if (!bs)
>> return 0;
>> if (!bs->remain)
>> return 0;
>> short sample = aSine[bs->sample] >> 1;
>> bs->sample = (bs->sample + 1) % SINE_SAMPLES;
>> bs->remain--;
>> return sample;
>> }
>
> So in theory, I can call buzzer_start, and give it a number of samples
> to count down. Each time buzzer_next_sample is called, it emits the
> next sample in the sine then decrements the counter. I simply need to
> add the output of this to the audio feed.
>
> There are two places that I see audio being written, basically in the
> receive path. So I tried the following:
>
>> if (ss.mode == ANALOG) {
>>
>> if (adc1_read(&adc16k[FDMDV_OS_TAPS_16K], n_samples_16k) ==
>> 0) {
>> fdmdv_16_to_8_short(adc8k, &adc16k[FDMDV_OS_TAPS_16K],
>> n_samples);
>> for(i=0; i<n_samples; i++)
>> dac8k[FDMDV_OS_TAPS_8K+i] = adc8k[i];
>> fdmdv_8_to_16_short(dac16k, &dac8k[FDMDV_OS_TAPS_8K],
>> n_samples);
>>
>> if (bs.remain) {
>> for(i=0; i < n_samples_16k; i++)
>> dac16k[i] += buzzer_next_sample(&bs);
>> }
>>
>> dac2_write(dac16k, n_samples_16k);
>> led_rt(0); led_err(0);
>> }
>> }
>> else {
>>
>> /* regular DV mode */
>>
>> nin = freedv_nin(f);
>> nout = nin;
>> freedv_zero_total_bit_errors(f);
>>
>> if (adc1_read(&adc16k[FDMDV_OS_TAPS_16K], 2*nin) == 0) {
>> GPIOE->ODR = (1 << 3);
>> fdmdv_16_to_8_short(adc8k, &adc16k[FDMDV_OS_TAPS_16K],
>> nin);
>> nout = freedv_rx(f, &dac8k[FDMDV_OS_TAPS_8K], adc8k);
>> fdmdv_8_to_16_short(dac16k, &dac8k[FDMDV_OS_TAPS_8K],
>> nout);
>>
>> nout *= 2;
>> if (bs.remain) {
>> for(i=0; i < nout; i++)
>> dac16k[i] += buzzer_next_sample(&bs);
>> }
>>
>> dac2_write(dac16k, nout);
>> led_rt(freedv_get_sync(f));
>> led_err(freedv_get_total_bit_errors(f));
>> GPIOE->ODR &= ~(1 << 3);
>> }
>> }
>
> The frequency sounds like a 500 Hz tone. When in analogue mode, it's
> clear, but in DV/TONE mode it is "broken", sounds like a string of
> high-speed morse "dits" and lasts twice as long. I can't quite figure
> out where the gaps are coming from.
>
> As I understand it, nout is the number of samples to be placed in the
> DAC output buffer, and dac16k is the array the samples come from.
>
> They're 16-bit integers that get scaled down to 12-bit. I'm iterating
> over that array and mixing my samples in, but it seems I'm not getting
> all of them: half get to the DAC un-mixed.
>
> I figure that the receive audio should be audible whilst in menu mode,
> that's what I'm shooting for right now, and I don't think it's infeasible.
>
> Is there some other area I've missed where DAC2 gets written to?
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
