Also, If you've got an STM32F4 Discovery (and probably other
stm32*discovery boards with stlink), you should be able to use the onboard
stlink debugger with the SM1000. SWD is broken out on header CN1 of the
SM1000D.


On Fri, Sep 18, 2015 at 7:04 PM, Brady O'Brien <[email protected]>
wrote:

>
> I'm pretty sure dac_write is nonblocking. If memory serves me correctly,
> it returns -1 if there's not enough free space in the fifo, 0 otherwise.
>
> On Fri, Sep 18, 2015 at 6:57 PM, Stuart Longland <
> [email protected]> wrote:
>
>> On 19/09/15 07:56, David Rowe wrote:
>> > Thank you Stuart - I think that's the first patch for the SM1000!  Well
>> > done.
>> >
>> > I'm camping this weekend at Mt Remarkable but will take a look at the
>> > patches early next week and figure out where they fit in.
>>
>> No problems there.  I've been tinkering around with that for a bit now.
>>  One thing I do notice is that timing seems to be off, I'm not sure why.
>>
>> Perhaps I'm overrunning a buffer somewhere?  Still getting to grips with
>> how the DAC code works.  I hacked up a version of the DAC unit test with
>> this:
>>
>> int main(void) {
>>
>>     struct tone_gen_t tone_gen;
>>
>>     dac_open(4*DAC_BUF_SZ);
>>
>>     while(1) {
>>         tone_reset(&tone_gen, 500, 400);
>>         while (tone_gen.remain) {
>>             int16_t buffer[800];
>>             int count;
>>             for (count = 0; (count < 800) && tone_gen.remain; count++)
>>                 buffer[count] = tone_next(&tone_gen);
>>             dac1_write(buffer, count);
>>             dac2_write(buffer, count);
>>         }
>>
>>         tone_reset(&tone_gen, 1000, 100);
>>         while (tone_gen.remain) {
>>             int16_t buffer[800];
>>             int count;
>>             for (count = 0; (count < 800) && tone_gen.remain; count++)
>>                 buffer[count] = tone_next(&tone_gen);
>>             dac1_write(buffer, count);
>>             dac2_write(buffer, count);
>>         }
>>     }
>> }
>>
>> That should be, a 1kHz tone every 500 msec with a 500Hz tone the rest of
>> the time.
>>
>> --------##--------##--------##--------## …
>>
>> Instead I get a burst of stuttery 1kHz beeps in amongst a drone of 500Hz.
>>
>> -----#-#-#-#-------#-#-#-#-------#-#-#-#----- …
>>
>> Not sure what's going on there.  It might need to wait until I pick up a
>> suitable STM32F4-based board that I can hook my JTAG to.
>>
>> If I write a quick C program on my host that `fwrite`s the samples to
>> stdout, and pipe that to `aplay`, it works fine.
>>
>> I also have a morse code generator (attached) that can take an arbitrary
>> string and play it as morse at any speed and frequency.  Speed is set by
>> the "dit" time.  I figure the user can set a preferred speed in WPM that
>> we translate to "dit milliseconds" using some standard like the PARIS
>> standard.  The word "PARIS" is 50 dits long → Wikipedia reckons that
>> equates to T=1200/W where T is in milliseconds and W is words per minute.
>>
>> An example program:
>>
>> #include <stdio.h>
>> #include "morse.h"
>>
>> int main(void) {
>>         struct morse_player_t mp;
>>         mp.freq = 800;
>>         mp.dit_time = 100;
>>         morse_play(&mp, "TESTING 1 2 3 4");
>>         while(mp.msg) {
>>                 int16_t sample = morse_next(&mp);
>>                 fwrite(&sample, sizeof(sample), 1, stdout);
>>         }
>>         return(0);
>> }
>>
>> This command plays nice clean morse on my host with the above code:
>>
>> gcc -I src -o test test.c src/tone.c src/sfx.c src/morse.c \
>>         && ./test | aplay -c 1 -f S16_LE -r 16000 -
>>
>> So the building blocks for a menu system are there.  More work is needed
>> on the playback side of things (as discussed) and of course, detecting
>> long vs short presses of buttons, but things are moving somewhat.
>>
>> A module that handles playback of pre-recorded Codec2 samples would be a
>> next step after getting some basic menu logic together, that would allow
>> for voice prompts (rather than morse).
>>
>> I'll look at that after I get something basic going.
>>
>> > If you, or anyone else reading, is interested, it would be great to have
>> > some help porting the cohpsk modem to the SM1000.  A first step would be
>> > to look at the memory usage, like I did for the fdmdv modem:
>> >
>> >    http://www.rowetel.com/blog/?p=3427
>>
>> Can't promise anything there, but I can have a look.
>>
>> Regards,
>> --
>> Stuart Longland (aka Redhatter, VK4MSL)
>>
>> I haven't lost my mind...
>>   ...it's backed up on a tape somewhere.
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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

Reply via email to