[Freetel-codec2] Fresh build of SM1000 firmware on a windows machine.

[e***@vk5kbb.com]

Firstly Hi to every one on the forum.

I've recently redesigned the SM1000 hardware so that I can fit the PCB
into a speaker mic. (or inside my FT-817)
That was the easy part, really!

The hardware now uses an equivalent 64pin STM32 device and so needs a
few pins reassigned.

This requires I rebuild the source code unfortunately I have had no
success.
If any body has done this on a Windows machine I would like to as for
some guidance.

What free IDE did you use?
Where did you out the libraries?
Any special configurations to generate the binary?

I currently have the Eclipse STM32 IDE and the Atollic IDE installed
with the GCC compiler.

The hardware comes up and connects in USB boot loader mode and the
analogue parts seem to work ok so now I just need to get the firmware to
build.

Any help would be appreciated.

Cheers
Eric
VK5KBB

[David Rowe]

Hi Eric,

Instructions for building the sm1000 firmware in codec2-dev/stm32/README.txt

We use gcc/Makefiles rather than an IDE.

Cheers,

David

On 22/08/16 20:09, ***@vk5kbb.com wrote:
> Firstly Hi to every one on the forum.
>
> I’ve recently redesigned the SM1000 hardware so that I can fit the PCB
> into a speaker mic. (or inside my FT-817)
> That was the easy part, really!
>
> The hardware now uses an equivalent 64pin STM32 device and so needs a
> few pins reassigned.
>
> This requires I rebuild the source code unfortunately I have had no success.
> If any body has done this on a Windows machine I would like to as for
> some guidance.
>
> What free IDE did you use?
> Where did you out the libraries?
> Any special configurations to generate the binary?
>
> I currently have the Eclipse STM32 IDE and the Atollic IDE installed
> with the GCC compiler.
>
> The hardware comes up and connects in USB boot loader mode and the
> analogue parts seem to work ok so now I just need to get the firmware to
> build.
>
> Any help would be appreciated.
>
> Cheers
> Eric
> VK5KBB
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Hi David and all on th list.

Took your advice to test the build and installed Ubuntu on a spare
machine.

After some head scratching and modifications to the Makefile, mainly for
the library directory's.

It appears to build (well doesn't come to a STOP error)

I think I may be able to get this working in an IDE now.

However-

The sm1000.bin file is only 212kB unlike some I have seen online that
are over 300kB.

There are other .bin files that I am unsure why they are generated.

Do I need them how do I combine them if needed.

Because I can not use the IDE J-Linker for programing I am using the
DFUSe USB bootloader and convert the .bin to .dfu.

Is there something else that needs to be included or do I append all the
.bin's into the one .dfu?

Thank you in advance everybody for the help.

Regards

Eric

VK5KBB.

On 2016-08-22 13:39, David Rowe wrote:

> Hi Eric,
>
> Instructions for building the sm1000 firmware in codec2-dev/stm32/README.txt
>
> We use gcc/Makefiles rather than an IDE.
>
> Cheers,
>
> David
>
> On 22/08/16 20:09, ***@vk5kbb.comwrote:
>
>> Firstly Hi to every one on the forum. I've recently redesigned the SM1000 hardware so that I can fit the PCB into a speaker mic. (or inside my FT-817) That was the easy part, really! The hardware now uses an equivalent 64pin STM32 device and so needs a few pins reassigned. This requires I rebuild the source code unfortunately I have had no success. If any body has done this on a Windows machine I would like to as for some guidance. What free IDE did you use? Where did you out the libraries? Any special configurations to generate the binary? I currently have the Eclipse STM32 IDE and the Atollic IDE installed with the GCC compiler. The hardware comes up and connects in USB boot loader mode and the analogue parts seem to work ok so now I just need to get the firmware to build. Any help would be appreciated. Cheers Eric VK5KBB ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Hi Eric,

The last time I compiled sm1000.bin was in June and it's 284632 bytes on
my machine.

The other bin files are for other stm32 programs such as unit tests, you
can ignore them for now although some might be useful for your hardware
bring up. For example I often start with dac_ut.bin, to play a sine
wave out of the DAC.

There are instructions for flashing the SM1000 via USB on the SM1000 web
page, from either Windows or Linux.

If you want to test your sm1000 bin files bring it around to my place
and we'll flash a sm1000 with it.

Cheers,

David

On 24/08/16 00:28, ***@vk5kbb.com wrote:
> Hi David and all on th list.
>
> Took your advice to test the build and installed Ubuntu on a spare machine.
>
> After some head scratching and modifications to the Makefile, mainly for
> the library directory's.
>
> It appears to build (well doesn't come to a STOP error)
>
> I think I may be able to get this working in an IDE now.
>
> However-
>
> The sm1000.bin file is only 212kB unlike some I have seen online that
> are over 300kB.
>
> There are other .bin files that I am unsure why they are generated.
>
> Do I need them how do I combine them if needed.
>
> Because I can not use the IDE J-Linker for programing I am using the
> DFUSe USB bootloader and convert the .bin to .dfu.
>
> Is there something else that needs to be included or do I append all the
> .bin's into the one .dfu?
>
> Thank you in advance everybody for the help.
>
> Regards
>
> Eric
>
> VK5KBB.
>
>
>
> On 2016-08-22 13:39, David Rowe wrote:
>
>> Hi Eric,
>>
>> Instructions for building the sm1000 firmware in codec2-dev/stm32/README.txt
>>
>> We use gcc/Makefiles rather than an IDE.
>>
>> Cheers,
>>
>> David
>>
>> On 22/08/16 20:09, ***@vk5kbb.com <mailto:***@vk5kbb.com>wrote:
>>> Firstly Hi to every one on the forum. I’ve recently redesigned the
>>> SM1000 hardware so that I can fit the PCB into a speaker mic. (or
>>> inside my FT-817) That was the easy part, really! The hardware now
>>> uses an equivalent 64pin STM32 device and so needs a few pins
>>> reassigned. This requires I rebuild the source code unfortunately I
>>> have had no success. If any body has done this on a Windows machine I
>>> would like to as for some guidance. What free IDE did you use? Where
>>> did you out the libraries? Any special configurations to generate the
>>> binary? I currently have the Eclipse STM32 IDE and the Atollic IDE
>>> installed with the GCC compiler. The hardware comes up and connects
>>> in USB boot loader mode and the analogue parts seem to work ok so now
>>> I just need to get the firmware to build. Any help would be
>>> appreciated. Cheers Eric VK5KBB
>>> ------------------------------------------------------------------------------
>>> _______________________________________________ Freetel-codec2
>>> mailing list Freetel-***@lists.sourceforge.net
>>> <mailto:Freetel-***@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> <mailto:Freetel-***@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Yes that is interesting. Mine is 210,080bytes.

Not sure why that is and until I find out why I guess there is still a
problem.

I've tried to get the USB programing direclty form Linux to work but
none of the resources out there for it actually build.

Unlike on the Windows machine I just downloaded and installed it and it
connected, so going that path right now although the full debug
environment that some of the ST loader's claim would be rather handy.

When I get something compiling of the correct size I will try it out on
one of your sm1000's.

Cheers

Eric

On 2016-08-23 21:34, David Rowe wrote:

> Hi Eric,
>
> The last time I compiled sm1000.bin was in June and it's 284632 bytes on
> my machine.
>
> The other bin files are for other stm32 programs such as unit tests, you
> can ignore them for now although some might be useful for your hardware
> bring up. For example I often start with dac_ut.bin, to play a sine
> wave out of the DAC.
>
> There are instructions for flashing the SM1000 via USB on the SM1000 web
> page, from either Windows or Linux.
>
> If you want to test your sm1000 bin files bring it around to my place
> and we'll flash a sm1000 with it.
>
> Cheers,
>
> David
>
> On 24/08/16 00:28, ***@vk5kbb.comwrote:
> Hi David and all on th list. Took your advice to test the build and installed Ubuntu on a spare machine. After some head scratching and modifications to the Makefile, mainly for the library directory's. It appears to build (well doesn't come to a STOP error) I think I may be able to get this working in an IDE now. However- The sm1000.bin file is only 212kB unlike some I have seen online that are over 300kB. There are other .bin files that I am unsure why they are generated. Do I need them how do I combine them if needed. Because I can not use the IDE J-Linker for programing I am using the DFUSe USB bootloader and convert the .bin to .dfu. Is there something else that needs to be included or do I append all the .bin's into the one .dfu? Thank you in advance everybody for the help. Regards Eric VK5KBB. On 2016-08-22 13:39, David Rowe wrote: Hi Eric, Instructions for building the sm1000 firmware in codec2-dev/stm32/README.txt We use gcc/Makefiles rather than an IDE. Cheers, David On
22/08/16 20:09, ***@vk5kbb.com <mailto:***@vk5kbb.com>wrote: Firstly Hi to every one on the forum. I've recently redesigned the SM1000 hardware so that I can fit the PCB into a speaker mic. (or inside my FT-817) That was the easy part, really! The hardware now uses an equivalent 64pin STM32 device and so needs a few pins reassigned. This requires I rebuild the source code unfortunately I have had no success. If any body has done this on a Windows machine I would like to as for some guidance. What free IDE did you use? Where did you out the libraries? Any special configurations to generate the binary? I currently have the Eclipse STM32 IDE and the Atollic IDE installed with the GCC compiler. The hardware comes up and connects in USB boot loader mode and the analogue parts seem to work ok so now I just need to get the firmware to build. Any help would be appreciated. Cheers Eric VK5KBB ------------------------------------------------------------------------------
_______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------
_______________________________________________ Freetel-codec2 mailing
list Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Steve]

Just a note, but on my Ubuntu 16 32-bit Virtual Box, it resulted in
1305108 for the sm1000.elf, and after the 'objcopy' conversion, the
.bin result was 305884. I had to download the V 1.7.1 ZIP file
manually, as the web site gave me a short version that was gimped and
wouldn't unzip. I just downloaded it manually after registering and
put it in the 'dl' directory.

Also the name changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped
the 'en.' before putting it in 'dl'.

I hope all that makes sense.

------------------------------------------------------------------------------

[Walter Holmes]

Steve,

I hope this doesn't just add more to the confusion, but the .bin file for
the SM1000 is about 227k that is flashed from Linux, but if I extract that
same code down to my Windows machine using the DFU program it's 1025k.

I am not part of the code team, so I have no idea why there is such a
difference, but that's just an observation I have witnessed.

I say this only so that you don't let the code size between environments
make you think it's not still correct. Try it out to see what happens.

I suspect the Windows side probably has a lot of extra overhead as do most
Windows apps, and clearly the Linux side is a great deal more efficient.

All the best,

Walter/K5WH

-----Original Message-----
From: Steve [mailto:***@gmail.com]
Sent: Wednesday, August 24, 2016 3:33 AM
To: freetel-***@lists.sourceforge.net
Subject: Re: [Freetel-codec2] Fresh build of SM1000 firmware on a windows
machine.

Just a note, but on my Ubuntu 16 32-bit Virtual Box, it resulted in
1305108 for the sm1000.elf, and after the 'objcopy' conversion, the .bin
result was 305884. I had to download the V 1.7.1 ZIP file manually, as the
web site gave me a short version that was gimped and wouldn't unzip. I just
downloaded it manually after registering and put it in the 'dl' directory.

Also the name changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the
'en.' before putting it in 'dl'.

I hope all that makes sense.

----------------------------------------------------------------------------
--
_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


------------------------------------------------------------------------------

[e***@vk5kbb.com]

No confusion and thanks for the input.

In the end looks like my windows DFuSe was not working correctly and I
found that DFU-UTILS could be installed with a simple apt-get function
and I didnt need to build it.

>From there DFU-UTILS happily installed the 210,080 byte .BIN (didnt need
to be converted) and I could immediately tell it worked because it took
roughly 30 seconds to down load to the hardware.

So the modified code for the new hardware works (although as the new
hardware uses different ADC pins the changes are not trivial).

Now I will go back to evaluating various IDE's because this is not an
environment that makes code development very easy or efficient.

Basically right now I am editing in an IDE on a windows machine via a
network drive and then making on the Ubuntu machine.

The hardware tested ok and I now have an SM1000 that fits into a match
box so I can put it inside a speaker microphone.

I am however now redesigning the PCB to reduce it a further 20% in size
(mainly removal of more un-needed parts, 5V reg, EEPROM, and speaker
amplifier) with the plan to graft it into my FT817 so that it is
activated when the digital mode is selected.

I am also putting the ADC pins back where they were so that people need
only change the sm1000_leds_switches.c code to reflect the pin changes.

I will eventually rewrite the code so that the ADC's and GPIO's are
defined in a single .h hardware definition to make the code hardware
portable.

I do this as a general rule of thumb so that for example in this case
every time the hardware changes the 56 (or more) instances of ADC1/2 all
dont need to be edited.

Cheers

Eric

On 2016-08-24 15:04, Walter Holmes wrote:

> Steve,
>
> I hope this doesn't just add more to the confusion, but the .bin file for
> the SM1000 is about 227k that is flashed from Linux, but if I extract that
> same code down to my Windows machine using the DFU program it's 1025k.
>
> I am not part of the code team, so I have no idea why there is such a
> difference, but that's just an observation I have witnessed.
>
> I say this only so that you don't let the code size between environments
> make you think it's not still correct. Try it out to see what happens.
>
> I suspect the Windows side probably has a lot of extra overhead as do most
> Windows apps, and clearly the Linux side is a great deal more efficient.
>
> All the best,
>
> Walter/K5WH
>
> -----Original Message-----
> From: Steve [mailto:***@gmail.com]
> Sent: Wednesday, August 24, 2016 3:33 AM
> To: freetel-***@lists.sourceforge.net
> Subject: Re: [Freetel-codec2] Fresh build of SM1000 firmware on a windows
> machine.
>
> Just a note, but on my Ubuntu 16 32-bit Virtual Box, it resulted in
> 1305108 for the sm1000.elf, and after the 'objcopy' conversion, the .bin
> result was 305884. I had to download the V 1.7.1 ZIP file manually, as the
> web site gave me a short version that was gimped and wouldn't unzip. I just
> downloaded it manually after registering and put it in the 'dl' directory.
>
> Also the name changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the
> 'en.' before putting it in 'dl'.
>
> I hope all that makes sense.
>
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Nice work Eric. Do you have any photos?

Good to see this sort of innovation happening with codec 2 and the open
hardware SM1000 platform.

Also it would be great if you can publish your hardware/software work
under the GPL/TAPR open hardware licenses for others to build upon.

Cheers,

David

On 28/08/16 09:37, ***@vk5kbb.com wrote:
> No confusion and thanks for the input.
>
> In the end looks like my windows DFuSe was not working correctly and I
> found that DFU-UTILS could be installed with a simple apt-get function
> and I didnt need to build it.
>
> From there DFU-UTILS happily installed the 210,080 byte .BIN (didnt
> need to be converted) and I could immediately tell it worked because it
> took roughly 30 seconds to down load to the hardware.
>
> So the modified code for the new hardware works (although as the new
> hardware uses different ADC pins the changes are not trivial).
>
> Now I will go back to evaluating various IDE's because this is not an
> environment that makes code development very easy or efficient.
>
> Basically right now I am editing in an IDE on a windows machine via a
> network drive and then making on the Ubuntu machine.
>
> The hardware tested ok and I now have an SM1000 that fits into a match
> box so I can put it inside a speaker microphone.
>
> I am however now redesigning the PCB to reduce it a further 20% in size
> (mainly removal of more un-needed parts, 5V reg, EEPROM, and speaker
> amplifier) with the plan to graft it into my FT817 so that it is
> activated when the digital mode is selected.
>
> I am also putting the ADC pins back where they were so that people need
> only change the sm1000_leds_switches.c code to reflect the pin changes.
>
> I will eventually rewrite the code so that the ADC's and GPIO's are
> defined in a single .h hardware definition to make the code hardware
> portable.
>
> I do this as a general rule of thumb so that for example in this case
> every time the hardware changes the 56 (or more) instances of ADC1/2 all
> dont need to be edited.
>
> Cheers
>
> Eric
>
>
>
>
>
> On 2016-08-24 15:04, Walter Holmes wrote:
>
>> Steve,
>>
>> I hope this doesn't just add more to the confusion, but the .bin file for
>> the SM1000 is about 227k that is flashed from Linux, but if I extract that
>> same code down to my Windows machine using the DFU program it's 1025k.
>>
>> I am not part of the code team, so I have no idea why there is such a
>> difference, but that's just an observation I have witnessed.
>>
>> I say this only so that you don't let the code size between environments
>> make you think it's not still correct. Try it out to see what happens.
>>
>> I suspect the Windows side probably has a lot of extra overhead as do most
>> Windows apps, and clearly the Linux side is a great deal more efficient.
>>
>> All the best,
>>
>> Walter/K5WH
>>
>> -----Original Message-----
>> From: Steve [mailto:***@gmail.com <mailto:***@gmail.com>]
>> Sent: Wednesday, August 24, 2016 3:33 AM
>> To: freetel-***@lists.sourceforge.net
>> <mailto:freetel-***@lists.sourceforge.net>
>> Subject: Re: [Freetel-codec2] Fresh build of SM1000 firmware on a windows
>> machine.
>>
>> Just a note, but on my Ubuntu 16 32-bit Virtual Box, it resulted in
>> 1305108 for the sm1000.elf, and after the 'objcopy' conversion, the .bin
>> result was 305884. I had to download the V 1.7.1 ZIP file manually, as the
>> web site gave me a short version that was gimped and wouldn't unzip. I just
>> downloaded it manually after registering and put it in the 'dl' directory.
>>
>> Also the name changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the
>> 'en.' before putting it in 'dl'.
>>
>> I hope all that makes sense.
>>
>> ----------------------------------------------------------------------------
>> --
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> <mailto:Freetel-***@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> <mailto:Freetel-***@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

I do have some pictures,

I wasn't sure if they could be added as attachments.

On this design to aid in layout simplicity and speed up the design (only
spent 2 or 3 hours on it on a lazy Sunday arvo) I had swapped ADC and
DAC pins.
I foolishly thought it would be a matter of changing a few defines in
the code to accommodate this (but was wrong).

As it turned out even after recording all the ADC1/2 and DAC1/2 in the
source I am not 100% convinced it worked as when I am feeding audio from
the PC the error LED cycles in and out when there is no modulation. As
soon as there is modulation on the audio to the PC the error light stays
off.

RT light stays on fine.

I thought initially that there may have been a porting issue with the
tuning and hence the slow cycling but since then I have modified the PCB
so that the inputs are reversed and can use the original firmware with
only changes of the GPIO's for the switches and LED's.

Acts the same way so I have to ask if this is normal when there is no
modulation on the data stream?

As for circuits I am now re-hashing the board layout to remove the
speaker amp, 5volt regulator and EEPROM to save space as none of these
are needed when installed into a radio.

I am also returning the ADC and DAC pins to original so that the only
code that needs changing is that for the switches and LED's

That will make the hardware generic and then I will get a quote for
having it made cheaply in China if people are interested.

Cheers

Eric.

On 2016-08-31 00:24, David Rowe wrote:

> Nice work Eric. Do you have any photos?
>
> Good to see this sort of innovation happening with codec 2 and the open
> hardware SM1000 platform.
>
> Also it would be great if you can publish your hardware/software work
> under the GPL/TAPR open hardware licenses for others to build upon.
>
> Cheers,
>
> David
>
> On 28/08/16 09:37, ***@vk5kbb.comwrote:
> No confusion and thanks for the input. In the end looks like my windows DFuSe was not working correctly and I found that DFU-UTILS could be installed with a simple apt-get function and I didnt need to build it. From there DFU-UTILS happily installed the 210,080 byte .BIN (didnt need to be converted) and I could immediately tell it worked because it took roughly 30 seconds to down load to the hardware. So the modified code for the new hardware works (although as the new hardware uses different ADC pins the changes are not trivial). Now I will go back to evaluating various IDE's because this is not an environment that makes code development very easy or efficient. Basically right now I am editing in an IDE on a windows machine via a network drive and then making on the Ubuntu machine. The hardware tested ok and I now have an SM1000 that fits into a match box so I can put it inside a speaker microphone. I am however now redesigning the PCB to reduce it a further 20% in size (mainly
removal of more un-needed parts, 5V reg, EEPROM, and speaker amplifier) with the plan to graft it into my FT817 so that it is activated when the digital mode is selected. I am also putting the ADC pins back where they were so that people need only change the sm1000_leds_switches.c code to reflect the pin changes. I will eventually rewrite the code so that the ADC's and GPIO's are defined in a single .h hardware definition to make the code hardware portable. I do this as a general rule of thumb so that for example in this case every time the hardware changes the 56 (or more) instances of ADC1/2 all dont need to be edited. Cheers Eric On 2016-08-24 15:04, Walter Holmes wrote: Steve, I hope this doesn't just add more to the confusion, but the .bin file for the SM1000 is about 227k that is flashed from Linux, but if I extract that same code down to my Windows machine using the DFU program it's 1025k. I am not part of the code team, so I have no idea why there is such a difference, but
that's just an observation I have witnessed. I say this only so that you don't let the code size between environments make you think it's not still correct. Try it out to see what happens. I suspect the Windows side probably has a lot of extra overhead as do most Windows apps, and clearly the Linux side is a great deal more efficient. All the best, Walter/K5WH -----Original Message----- From: Steve [mailto:***@gmail.com <mailto:***@gmail.com>] Sent: Wednesday, August 24, 2016 3:33 AM To: freetel-***@lists.sourceforge.net <mailto:freetel-***@lists.sourceforge.net> Subject: Re: [Freetel-codec2] Fresh build of SM1000 firmware on a windows machine. Just a note, but on my Ubuntu 16 32-bit Virtual Box, it resulted in 1305108 for the sm1000.elf, and after the 'objcopy' conversion, the .bin result was 305884. I had to download the V 1.7.1 ZIP file manually, as the web site gave me a short version that was gimped and wouldn't unzip. I just downloaded it manually
after registering and put it in the 'dl' directory. Also the name changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the 'en.' before putting it in 'dl'. I hope all that makes sense. ---------------------------------------------------------------------------- -- _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Hi Eric,

Yes I think occasional false syncs on noise is normal. You could
compare with a SM1000. If the error light stays off when it has a
strong rx signal (like a wave file from a PC) then it's looking good.

Cheers,

David

On 31/08/16 09:47, ***@vk5kbb.com wrote:
> I do have some pictures,
>
> I wasn't sure if they could be added as attachments.
>
> On this design to aid in layout simplicity and speed up the design (only
> spent 2 or 3 hours on it on a lazy Sunday arvo) I had swapped ADC and
> DAC pins.
> I foolishly thought it would be a matter of changing a few defines in
> the code to accommodate this (but was wrong).
>
> As it turned out even after recording all the ADC1/2 and DAC1/2 in the
> source I am not 100% convinced it worked as when I am feeding audio from
> the PC the error LED cycles in and out when there is no modulation. As
> soon as there is modulation on the audio to the PC the error light stays
> off.
>
> RT light stays on fine.
>
> I thought initially that there may have been a porting issue with the
> tuning and hence the slow cycling but since then I have modified the PCB
> so that the inputs are reversed and can use the original firmware with
> only changes of the GPIO's for the switches and LED's.
>
> Acts the same way so I have to ask if this is normal when there is no
> modulation on the data stream?
>
> As for circuits I am now re-hashing the board layout to remove the
> speaker amp, 5volt regulator and EEPROM to save space as none of these
> are needed when installed into a radio.
>
> I am also returning the ADC and DAC pins to original so that the only
> code that needs changing is that for the switches and LED's
>
> That will make the hardware generic and then I will get a quote for
> having it made cheaply in China if people are interested.
>
>
>
> Cheers
>
> Eric.
>
>
>
> On 2016-08-31 00:24, David Rowe wrote:
>
>> Nice work Eric. Do you have any photos?
>>
>> Good to see this sort of innovation happening with codec 2 and the open
>> hardware SM1000 platform.
>>
>> Also it would be great if you can publish your hardware/software work
>> under the GPL/TAPR open hardware licenses for others to build upon.
>>
>> Cheers,
>>
>> David
>>
>> On 28/08/16 09:37, ***@vk5kbb.com <mailto:***@vk5kbb.com>wrote:
>>> No confusion and thanks for the input. In the end looks like my
>>> windows DFuSe was not working correctly and I found that DFU-UTILS
>>> could be installed with a simple apt-get function and I didnt need to
>>> build it. From there DFU-UTILS happily installed the 210,080 byte
>>> .BIN (didnt need to be converted) and I could immediately tell it
>>> worked because it took roughly 30 seconds to down load to the
>>> hardware. So the modified code for the new hardware works (although
>>> as the new hardware uses different ADC pins the changes are not
>>> trivial). Now I will go back to evaluating various IDE's because this
>>> is not an environment that makes code development very easy or
>>> efficient. Basically right now I am editing in an IDE on a windows
>>> machine via a network drive and then making on the Ubuntu machine.
>>> The hardware tested ok and I now have an SM1000 that fits into a
>>> match box so I can put it inside a speaker microphone. I am however
>>> now redesigning the PCB to reduce it a further 20% in size (mainly
>>> removal of more un-needed parts, 5V reg, EEPROM, and speaker
>>> amplifier) with the plan to graft it into my FT817 so that it is
>>> activated when the digital mode is selected. I am also putting the
>>> ADC pins back where they were so that people need only change the
>>> sm1000_leds_switches.c code to reflect the pin changes. I will
>>> eventually rewrite the code so that the ADC's and GPIO's are defined
>>> in a single .h hardware definition to make the code hardware
>>> portable. I do this as a general rule of thumb so that for example in
>>> this case every time the hardware changes the 56 (or more) instances
>>> of ADC1/2 all dont need to be edited. Cheers Eric On 2016-08-24
>>> 15:04, Walter Holmes wrote:
>>>> Steve, I hope this doesn't just add more to the confusion, but the
>>>> .bin file for the SM1000 is about 227k that is flashed from Linux,
>>>> but if I extract that same code down to my Windows machine using the
>>>> DFU program it's 1025k. I am not part of the code team, so I have no
>>>> idea why there is such a difference, but that's just an observation
>>>> I have witnessed. I say this only so that you don't let the code
>>>> size between environments make you think it's not still correct. Try
>>>> it out to see what happens. I suspect the Windows side probably has
>>>> a lot of extra overhead as do most Windows apps, and clearly the
>>>> Linux side is a great deal more efficient. All the best, Walter/K5WH
>>>> -----Original Message----- From: Steve
>>>> [mailto:***@gmail.com <mailto:***@gmail.com>
>>>> <mailto:***@gmail.com <mailto:***@gmail.com>>]
>>>> Sent: Wednesday, August 24, 2016 3:33 AM To:
>>>> freetel-***@lists.sourceforge.net
>>>> <mailto:freetel-***@lists.sourceforge.net>
>>>> <mailto:freetel-***@lists.sourceforge.net
>>>> <mailto:freetel-***@lists.sourceforge.net>> Subject: Re:
>>>> [Freetel-codec2] Fresh build of SM1000 firmware on a windows
>>>> machine. Just a note, but on my Ubuntu 16 32-bit Virtual Box, it
>>>> resulted in 1305108 for the sm1000.elf, and after the 'objcopy'
>>>> conversion, the .bin result was 305884. I had to download the V
>>>> 1.7.1 ZIP file manually, as the web site gave me a short version
>>>> that was gimped and wouldn't unzip. I just downloaded it manually
>>>> after registering and put it in the 'dl' directory. Also the name
>>>> changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the 'en.'
>>>> before putting it in 'dl'. I hope all that makes sense.
>>>> ----------------------------------------------------------------------------
>>>> -- _______________________________________________ Freetel-codec2
>>>> mailing list Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________ Freetel-codec2
>>>> mailing list Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>> ------------------------------------------------------------------------------
>>> _______________________________________________ Freetel-codec2
>>> mailing list Freetel-***@lists.sourceforge.net
>>> <mailto:Freetel-***@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> <mailto:Freetel-***@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[David Rowe]

Hello List,

Recently I've been working off-list with the mcHF team, who are
integrating FreeDV with their STM32F4 based radio.

They have sent me some very nice generic C patches which I have checked
into SVN, and are now looking at using platform specific optimisations
such as ARM library calls. These are tricker to tests, as they need to
run on target harwdare, then dump files to a PC host for evaluation.

To test the patches I have resurrected the tfdmdv Octave code that I
broke last year while working on the cohpsk modem. This is a C/octave
framework for verifying the operation of the fdmdv modem against the
reference Octave code, more in this blog post:

http://www.rowetel.com/blog/?p=3427

It's also a useful test framework for any ports of the fdmdv code to
other languages.

I still need to fix the other Octave fdmdv utilties.

Cheers,

David


------------------------------------------------------------------------------

[David Rowe]

Further to the email below, Danilo and the mCHF team have submitted the
first of some ARM-specific patches to the fdmdv modem used from FreeDV 1600.

They worked hard to get a version of the tfdmdv framework running on a
STM32 target platform. This means they can carefully check nothing has
broken as they try other changes.

The changes have been checked into SVN. The x86 code checks out. I
have built, but not tried the resulting sm1000 binary. If someone would
like to try just email me and I will send you the binary, or feel free
to build and try it yourself.

Thanks,

David

On 31/08/16 10:25, David Rowe wrote:
> Hello List,
>
> Recently I've been working off-list with the mcHF team, who are
> integrating FreeDV with their STM32F4 based radio.
>
> They have sent me some very nice generic C patches which I have checked
> into SVN, and are now looking at using platform specific optimisations
> such as ARM library calls. These are tricker to tests, as they need to
> run on target harwdare, then dump files to a PC host for evaluation.
>
> To test the patches I have resurrected the tfdmdv Octave code that I
> broke last year while working on the cohpsk modem. This is a C/octave
> framework for verifying the operation of the fdmdv modem against the
> reference Octave code, more in this blog post:
>
> http://www.rowetel.com/blog/?p=3427
>
> It's also a useful test framework for any ports of the fdmdv code to
> other languages.
>
> I still need to fix the other Octave fdmdv utilties.
>
> Cheers,
>
> David
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Ok,

Slightly modified SM1000 code. Basically all menu functions removed so
it only powers up in DV mode.

GPIO pins changed to a few different pins and DAC1/2 transposed.

ADC's have not been changed because there is no easy way of doing that.

Appears to modulate fine.

Decode/RX has a good solid RT LED but anywhere from 3-20 seconds after
RT light coming on during a receive of a good signal. (ie this mornings
broadcast) The ERR LED stars flashing frantically like almost solid on.

Audio becomes garbage.

25% of the time it will recover after 10-20 seconds other times I get
frustrated and need to PTT, power cycle or hit the reset.

Then it is almost instantly up and running fine again.

I noticed this originally when running audio from the PC directly into
the modem and thought it may be because the computer is glitching as its
quite a slow computer.

I expect glitches to happen but I am not sure on causes of lack of
recovery.

Have tested at various levels and this does not seem to effect it.

Any thoughts?

Or has any one seen this before?

Cheers

Eric

[Steve]

Maybe scope the A/D input and see if somethings amiss. DC level
rising, power supply noise??

------------------------------------------------------------------------------

[David Rowe]

Hi Eric,

Never been reported as far as I know. I just tried a few tests on a
SM1000 I have in front of me. In each test I'm replaying 120 seconds of
this mornings broadcast to the SM1000 from a laptop:

i) Stock firmware from factory. Played 120s no problem.

ii) Reflashed using stock sm1000.bin firmware from link on sm1000 page.
Played 120s no problem.

iii) Latest sm1000.bin. This includes the menu system Stuart developed
late last year, some recent patches, lots development of (non sm100
specific) FreeDV over the last year or so. Towards the end of a 120s
session I'm occasionally hearing a problem very similar to what you
report, e.g. garbled speech and errors and then recovers after 20s or so.

iv) Back to stock firmware, Played 120s x 3 - no problems.

So looks like it's not yr hardware. Tricky one to track down, as it
takes so long to occur (at least for me). Guess a first step would be
back track to earlier versions of SVN, find out if it's sm1000 specific,
or if it also occurs on x86 versions. Might be interesting to monitor
the free cpu cycles, stack, or try to trap the problem in some way.

Can anyone else repeat this problem on their sm1000 with any version of
firmware? Best to test with a wave file played from a PC, rather than
an off-air signal.

Thanks for the report,

David

On 11/09/16 16:55, ***@vk5kbb.com wrote:
> Ok,
>
> Slightly modified SM1000 code. Basically all menu functions removed so
> it only powers up in DV mode.
>
> GPIO pins changed to a few different pins and DAC1/2 transposed.
>
> ADC's have not been changed because there is no easy way of doing that.
>
> Appears to modulate fine.
>
> Decode/RX has a good solid RT LED but anywhere from 3-20 seconds after
> RT light coming on during a receive of a good signal. (ie this mornings
> broadcast) The ERR LED stars flashing frantically like almost solid on.
>
> Audio becomes garbage.
>
> 25% of the time it will recover after 10-20 seconds other times I get
> frustrated and need to PTT, power cycle or hit the reset.
>
> Then it is almost instantly up and running fine again.
>
> I noticed this originally when running audio from the PC directly into
> the modem and thought it may be because the computer is glitching as its
> quite a slow computer.
>
> I expect glitches to happen but I am not sure on causes of lack of recovery.
>
> Have tested at various levels and this does not seem to effect it.
>
> Any thoughts?
>
> Or has any one seen this before?
>
> Cheers
>
> Eric
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Thank you very much for the thorough investigation David.

I'd been pulling may hair out a bit on it to the point where modified
the PCB to get the signals back in on the correct ADC inputs just in
case I screwed something up in the code and its still doing it.

I will go back to the source files on the SM1000 page and give it
another go.

And Steve, I'll check again in case there is a DC offset occurring some
where? I checked early on but have not done so recently. That is a good
point.

Thank you for the feedback.

Regards

Eric.

On 2016-09-11 12:05, David Rowe wrote:

> Hi Eric,
>
> Never been reported as far as I know. I just tried a few tests on a
> SM1000 I have in front of me. In each test I'm replaying 120 seconds of
> this mornings broadcast to the SM1000 from a laptop:
>
> i) Stock firmware from factory. Played 120s no problem.
>
> ii) Reflashed using stock sm1000.bin firmware from link on sm1000 page.
> Played 120s no problem.
>
> iii) Latest sm1000.bin. This includes the menu system Stuart developed
> late last year, some recent patches, lots development of (non sm100
> specific) FreeDV over the last year or so. Towards the end of a 120s
> session I'm occasionally hearing a problem very similar to what you
> report, e.g. garbled speech and errors and then recovers after 20s or so.
>
> iv) Back to stock firmware, Played 120s x 3 - no problems.
>
> So looks like it's not yr hardware. Tricky one to track down, as it
> takes so long to occur (at least for me). Guess a first step would be
> back track to earlier versions of SVN, find out if it's sm1000 specific,
> or if it also occurs on x86 versions. Might be interesting to monitor
> the free cpu cycles, stack, or try to trap the problem in some way.
>
> Can anyone else repeat this problem on their sm1000 with any version of
> firmware? Best to test with a wave file played from a PC, rather than
> an off-air signal.
>
> Thanks for the report,
>
> David
>
> On 11/09/16 16:55, ***@vk5kbb.comwrote:
>
>> Ok, Slightly modified SM1000 code. Basically all menu functions removed so it only powers up in DV mode. GPIO pins changed to a few different pins and DAC1/2 transposed. ADC's have not been changed because there is no easy way of doing that. Appears to modulate fine. Decode/RX has a good solid RT LED but anywhere from 3-20 seconds after RT light coming on during a receive of a good signal. (ie this mornings broadcast) The ERR LED stars flashing frantically like almost solid on. Audio becomes garbage. 25% of the time it will recover after 10-20 seconds other times I get frustrated and need to PTT, power cycle or hit the reset. Then it is almost instantly up and running fine again. I noticed this originally when running audio from the PC directly into the modem and thought it may be because the computer is glitching as its quite a slow computer. I expect glitches to happen but I am not sure on causes of lack of recovery. Have tested at various levels and this does not seem to effect
it. Any thoughts? Or has any one seen this before? Cheers Eric ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Some more very fine work from Danilo and the mcHF team, here's an email
from Danilo:

"I think we're done now with FreeDV :-) :-)

We achieved our goal: The first clean QSO has been taking place between
2 mcHF using FreeDV yesterday.

We found a few performance hotspots and could eliminate some of these.
We lost about 3ms more per 20ms in total which now allows us to run the
mcHF normal code plus FreeDV 1600 RX and TX in real-time."

So they have a fully embedded SDR/FreeDV system up and running. Well
done guys :-)

These guys have taught me a few tricks about STM32 optimisation! Mostly
through C code changes - the latest patches have no ARM library calls.
The changes are documented and now checked into codec2-dev.

They have worked hard to build the tfdmdv framework for their target
platform, which allowed us to carefully check all changes against the
reference Octave modem. This is a crucial step for any ARM-specific
optimisations.

It's been a pleasure to work with Danilo and the mcHF team.

Thanks,

David

On 09/09/16 08:34, David Rowe wrote:
> Further to the email below, Danilo and the mCHF team have submitted the
> first of some ARM-specific patches to the fdmdv modem used from FreeDV 1600.
>
> They worked hard to get a version of the tfdmdv framework running on a
> STM32 target platform. This means they can carefully check nothing has
> broken as they try other changes.
>
> The changes have been checked into SVN. The x86 code checks out. I
> have built, but not tried the resulting sm1000 binary. If someone would
> like to try just email me and I will send you the binary, or feel free
> to build and try it yourself.
>
> Thanks,
>
> David
>
> On 31/08/16 10:25, David Rowe wrote:
>> Hello List,
>>
>> Recently I've been working off-list with the mcHF team, who are
>> integrating FreeDV with their STM32F4 based radio.
>>
>> They have sent me some very nice generic C patches which I have checked
>> into SVN, and are now looking at using platform specific optimisations
>> such as ARM library calls. These are tricker to tests, as they need to
>> run on target harwdare, then dump files to a PC host for evaluation.
>>
>> To test the patches I have resurrected the tfdmdv Octave code that I
>> broke last year while working on the cohpsk modem. This is a C/octave
>> framework for verifying the operation of the fdmdv modem against the
>> reference Octave code, more in this blog post:
>>
>> http://www.rowetel.com/blog/?p=3427
>>
>> It's also a useful test framework for any ports of the fdmdv code to
>> other languages.
>>
>> I still need to fix the other Octave fdmdv utilties.
>>
>> Cheers,
>>
>> David
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[David Rowe]

Further to this work Danilo has just submitted a rather large patch. It
builds OK on x86 and stm32. I have tested on x86, but not a sm1000 (I'm
temporarily out of stock). Danilo has tested on the mcHF.

From svn log "Large patch from Danilo to (i) change some #define names
to make them codec2-specific (ii) add an abstraction layer for ffts
(iii) add ARM-specific FFTs for stm32 that doesn't reduce CPU load but
helps memory".

There's an issue with the stm32 Makefile not working first time around.
This Makefile really needs some attention (perhaps conversion to cmake)
- anyone like to work on this?

Fine work again Danilo - thanks!

- David

On 15/09/16 07:56, David Rowe wrote:
> Some more very fine work from Danilo and the mcHF team, here's an email
> from Danilo:
>
> "I think we're done now with FreeDV :-) :-)
>
> We achieved our goal: The first clean QSO has been taking place between
> 2 mcHF using FreeDV yesterday.
>
> We found a few performance hotspots and could eliminate some of these.
> We lost about 3ms more per 20ms in total which now allows us to run the
> mcHF normal code plus FreeDV 1600 RX and TX in real-time."
>
> So they have a fully embedded SDR/FreeDV system up and running. Well
> done guys :-)
>
> These guys have taught me a few tricks about STM32 optimisation! Mostly
> through C code changes - the latest patches have no ARM library calls.
> The changes are documented and now checked into codec2-dev.
>
> They have worked hard to build the tfdmdv framework for their target
> platform, which allowed us to carefully check all changes against the
> reference Octave modem. This is a crucial step for any ARM-specific
> optimisations.
>
> It's been a pleasure to work with Danilo and the mcHF team.
>
> Thanks,
>
> David
>
> On 09/09/16 08:34, David Rowe wrote:
>> Further to the email below, Danilo and the mCHF team have submitted the
>> first of some ARM-specific patches to the fdmdv modem used from FreeDV 1600.
>>
>> They worked hard to get a version of the tfdmdv framework running on a
>> STM32 target platform. This means they can carefully check nothing has
>> broken as they try other changes.
>>
>> The changes have been checked into SVN. The x86 code checks out. I
>> have built, but not tried the resulting sm1000 binary. If someone would
>> like to try just email me and I will send you the binary, or feel free
>> to build and try it yourself.
>>
>> Thanks,
>>
>> David
>>
>> On 31/08/16 10:25, David Rowe wrote:
>>> Hello List,
>>>
>>> Recently I've been working off-list with the mcHF team, who are
>>> integrating FreeDV with their STM32F4 based radio.
>>>
>>> They have sent me some very nice generic C patches which I have checked
>>> into SVN, and are now looking at using platform specific optimisations
>>> such as ARM library calls. These are tricker to tests, as they need to
>>> run on target harwdare, then dump files to a PC host for evaluation.
>>>
>>> To test the patches I have resurrected the tfdmdv Octave code that I
>>> broke last year while working on the cohpsk modem. This is a C/octave
>>> framework for verifying the operation of the fdmdv modem against the
>>> reference Octave code, more in this blog post:
>>>
>>> http://www.rowetel.com/blog/?p=3427
>>>
>>> It's also a useful test framework for any ports of the fdmdv code to
>>> other languages.
>>>
>>> I still need to fix the other Octave fdmdv utilties.
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Freetel-codec2 mailing list
>>> Freetel-***@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

[Richard Shaw]

On Mon, Oct 10, 2016 at 1:49 AM, David Rowe <***@rowetel.com> wrote:

>
> There's an issue with the stm32 Makefile not working first time around.
> This Makefile really needs some attention (perhaps conversion to cmake)
> - anyone like to work on this?


I've started working on a rudimentary conversion to cmake but the makefile
is pretty long and may take me a while.

Looking at the toolchain options I found this:

https://developer.mbed.org/cookbook/mbed-cmake

Looks like a decent approach to cross-compiling but I'll admit I don't
fully understand it.

I'll let you know when I have something worth committing.

Thanks,
Richard

[David Rowe]

Oh yes and picture can be added as attachments, just keep them to a few
100k. Or link to a URL. I'm happy to write a blog post on yr project
if you like, might get others interested.

Can think of other applications for yr module too - like in radio
modems/FSK work.

Cheers,

David

On 31/08/16 09:47, ***@vk5kbb.com wrote:
> I do have some pictures,
>
> I wasn't sure if they could be added as attachments.
>
> On this design to aid in layout simplicity and speed up the design (only
> spent 2 or 3 hours on it on a lazy Sunday arvo) I had swapped ADC and
> DAC pins.
> I foolishly thought it would be a matter of changing a few defines in
> the code to accommodate this (but was wrong).
>
> As it turned out even after recording all the ADC1/2 and DAC1/2 in the
> source I am not 100% convinced it worked as when I am feeding audio from
> the PC the error LED cycles in and out when there is no modulation. As
> soon as there is modulation on the audio to the PC the error light stays
> off.
>
> RT light stays on fine.
>
> I thought initially that there may have been a porting issue with the
> tuning and hence the slow cycling but since then I have modified the PCB
> so that the inputs are reversed and can use the original firmware with
> only changes of the GPIO's for the switches and LED's.
>
> Acts the same way so I have to ask if this is normal when there is no
> modulation on the data stream?
>
> As for circuits I am now re-hashing the board layout to remove the
> speaker amp, 5volt regulator and EEPROM to save space as none of these
> are needed when installed into a radio.
>
> I am also returning the ADC and DAC pins to original so that the only
> code that needs changing is that for the switches and LED's
>
> That will make the hardware generic and then I will get a quote for
> having it made cheaply in China if people are interested.
>
>
>
> Cheers
>
> Eric.
>
>
>
> On 2016-08-31 00:24, David Rowe wrote:
>
>> Nice work Eric. Do you have any photos?
>>
>> Good to see this sort of innovation happening with codec 2 and the open
>> hardware SM1000 platform.
>>
>> Also it would be great if you can publish your hardware/software work
>> under the GPL/TAPR open hardware licenses for others to build upon.
>>
>> Cheers,
>>
>> David
>>
>> On 28/08/16 09:37, ***@vk5kbb.com <mailto:***@vk5kbb.com>wrote:
>>> No confusion and thanks for the input. In the end looks like my
>>> windows DFuSe was not working correctly and I found that DFU-UTILS
>>> could be installed with a simple apt-get function and I didnt need to
>>> build it. From there DFU-UTILS happily installed the 210,080 byte
>>> .BIN (didnt need to be converted) and I could immediately tell it
>>> worked because it took roughly 30 seconds to down load to the
>>> hardware. So the modified code for the new hardware works (although
>>> as the new hardware uses different ADC pins the changes are not
>>> trivial). Now I will go back to evaluating various IDE's because this
>>> is not an environment that makes code development very easy or
>>> efficient. Basically right now I am editing in an IDE on a windows
>>> machine via a network drive and then making on the Ubuntu machine.
>>> The hardware tested ok and I now have an SM1000 that fits into a
>>> match box so I can put it inside a speaker microphone. I am however
>>> now redesigning the PCB to reduce it a further 20% in size (mainly
>>> removal of more un-needed parts, 5V reg, EEPROM, and speaker
>>> amplifier) with the plan to graft it into my FT817 so that it is
>>> activated when the digital mode is selected. I am also putting the
>>> ADC pins back where they were so that people need only change the
>>> sm1000_leds_switches.c code to reflect the pin changes. I will
>>> eventually rewrite the code so that the ADC's and GPIO's are defined
>>> in a single .h hardware definition to make the code hardware
>>> portable. I do this as a general rule of thumb so that for example in
>>> this case every time the hardware changes the 56 (or more) instances
>>> of ADC1/2 all dont need to be edited. Cheers Eric On 2016-08-24
>>> 15:04, Walter Holmes wrote:
>>>> Steve, I hope this doesn't just add more to the confusion, but the
>>>> .bin file for the SM1000 is about 227k that is flashed from Linux,
>>>> but if I extract that same code down to my Windows machine using the
>>>> DFU program it's 1025k. I am not part of the code team, so I have no
>>>> idea why there is such a difference, but that's just an observation
>>>> I have witnessed. I say this only so that you don't let the code
>>>> size between environments make you think it's not still correct. Try
>>>> it out to see what happens. I suspect the Windows side probably has
>>>> a lot of extra overhead as do most Windows apps, and clearly the
>>>> Linux side is a great deal more efficient. All the best, Walter/K5WH
>>>> -----Original Message----- From: Steve
>>>> [mailto:***@gmail.com <mailto:***@gmail.com>
>>>> <mailto:***@gmail.com <mailto:***@gmail.com>>]
>>>> Sent: Wednesday, August 24, 2016 3:33 AM To:
>>>> freetel-***@lists.sourceforge.net
>>>> <mailto:freetel-***@lists.sourceforge.net>
>>>> <mailto:freetel-***@lists.sourceforge.net
>>>> <mailto:freetel-***@lists.sourceforge.net>> Subject: Re:
>>>> [Freetel-codec2] Fresh build of SM1000 firmware on a windows
>>>> machine. Just a note, but on my Ubuntu 16 32-bit Virtual Box, it
>>>> resulted in 1305108 for the sm1000.elf, and after the 'objcopy'
>>>> conversion, the .bin result was 305884. I had to download the V
>>>> 1.7.1 ZIP file manually, as the web site gave me a short version
>>>> that was gimped and wouldn't unzip. I just downloaded it manually
>>>> after registering and put it in the 'dl' directory. Also the name
>>>> changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the 'en.'
>>>> before putting it in 'dl'. I hope all that makes sense.
>>>> ----------------------------------------------------------------------------
>>>> -- _______________________________________________ Freetel-codec2
>>>> mailing list Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________ Freetel-codec2
>>>> mailing list Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>> ------------------------------------------------------------------------------
>>> _______________________________________________ Freetel-codec2
>>> mailing list Freetel-***@lists.sourceforge.net
>>> <mailto:Freetel-***@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> <mailto:Freetel-***@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Actually now have downloaded the latest code form Sourceforge. (only
found that by accident)

Was using the download from your website Dave and with a few changes it
now seems to be more stable.

I'm feeding voice audio into FreeDV on the PC and then demodulating
that.
I think now it looses sync when the PC glitches but it usually wont
recover with out intervention like a quick PTT.

I've been exploring the whole FreeDV thing for about 3 years now as I
want the STM32 to generate I/Q signals for a SDR I am making, and have
been using dsPIC in that for a while but wanted to generate the I/Q
signals and decode them all in the one micro.

Primarily for data more so than voice.

I think now that this is working I can migrate it quite easily and will
probably end up sticking with the ARM, as there is not much of a cost
difference.

The next build of the PCB attached has had the 5 Volt reg, Audio amp and
EEPROM removed and looks at coming in at 50x26mm It can easily fit into
the FT-817 on the main PCB with some double sided tape and by
interrogating the radio via serial determine the mode of operation so no
need for holes or buttons..

As you point out the modem/FSK Datapump is actually what I am more
interested in for that use and will provide some more scope for
experimentation.

This PCB design was a quick proof of concept and now that it seems to
work ok I will have a look at cost effective manufacture if there is
interest in it.

Cheers

Eric.

On 2016-08-31 03:15, David Rowe wrote:

> Oh yes and picture can be added as attachments, just keep them to a few
> 100k. Or link to a URL. I'm happy to write a blog post on yr project
> if you like, might get others interested.
>
> Can think of other applications for yr module too - like in radio
> modems/FSK work.
>
> Cheers,
>
> David
>
> On 31/08/16 09:47, ***@vk5kbb.comwrote:
> I do have some pictures, I wasn't sure if they could be added as attachments. On this design to aid in layout simplicity and speed up the design (only spent 2 or 3 hours on it on a lazy Sunday arvo) I had swapped ADC and DAC pins. I foolishly thought it would be a matter of changing a few defines in the code to accommodate this (but was wrong). As it turned out even after recording all the ADC1/2 and DAC1/2 in the source I am not 100% convinced it worked as when I am feeding audio from the PC the error LED cycles in and out when there is no modulation. As soon as there is modulation on the audio to the PC the error light stays off. RT light stays on fine. I thought initially that there may have been a porting issue with the tuning and hence the slow cycling but since then I have modified the PCB so that the inputs are reversed and can use the original firmware with only changes of the GPIO's for the switches and LED's. Acts the same way so I have to ask if this is normal when there
is no modulation on the data stream? As for circuits I am now re-hashing the board layout to remove the speaker amp, 5volt regulator and EEPROM to save space as none of these are needed when installed into a radio. I am also returning the ADC and DAC pins to original so that the only code that needs changing is that for the switches and LED's That will make the hardware generic and then I will get a quote for having it made cheaply in China if people are interested. Cheers Eric. On 2016-08-31 00:24, David Rowe wrote: Nice work Eric. Do you have any photos? Good to see this sort of innovation happening with codec 2 and the open hardware SM1000 platform. Also it would be great if you can publish your hardware/software work under the GPL/TAPR open hardware licenses for others to build upon. Cheers, David On 28/08/16 09:37, ***@vk5kbb.com <mailto:***@vk5kbb.com>wrote: No confusion and thanks for the input. In the end looks like my windows DFuSe was not working correctly and I found
that DFU-UTILS could be installed with a simple apt-get function and I didnt need to build it. From there DFU-UTILS happily installed the 210,080 byte .BIN (didnt need to be converted) and I could immediately tell it worked because it took roughly 30 seconds to down load to the hardware. So the modified code for the new hardware works (although as the new hardware uses different ADC pins the changes are not trivial). Now I will go back to evaluating various IDE's because this is not an environment that makes code development very easy or efficient. Basically right now I am editing in an IDE on a windows machine via a network drive and then making on the Ubuntu machine. The hardware tested ok and I now have an SM1000 that fits into a match box so I can put it inside a speaker microphone. I am however now redesigning the PCB to reduce it a further 20% in size (mainly removal of more un-needed parts, 5V reg, EEPROM, and speaker amplifier) with the plan to graft it into my FT817 so that
it is activated when the digital mode is selected. I am also putting the ADC pins back where they were so that people need only change the sm1000_leds_switches.c code to reflect the pin changes. I will eventually rewrite the code so that the ADC's and GPIO's are defined in a single .h hardware definition to make the code hardware portable. I do this as a general rule of thumb so that for example in this case every time the hardware changes the 56 (or more) instances of ADC1/2 all dont need to be edited. Cheers Eric On 2016-08-24 15:04, Walter Holmes wrote: Steve, I hope this doesn't just add more to the confusion, but the .bin file for the SM1000 is about 227k that is flashed from Linux, but if I extract that same code down to my Windows machine using the DFU program it's 1025k. I am not part of the code team, so I have no idea why there is such a difference, but that's just an observation I have witnessed. I say this only so that you don't let the code size between environments make
you think it's not still correct. Try it out to see what happens. I suspect the Windows side probably has a lot of extra overhead as do most Windows apps, and clearly the Linux side is a great deal more efficient. All the best, Walter/K5WH -----Original Message----- From: Steve [mailto:***@gmail.com <mailto:***@gmail.com> <mailto:***@gmail.com <mailto:***@gmail.com>>] Sent: Wednesday, August 24, 2016 3:33 AM To: freetel-***@lists.sourceforge.net <mailto:freetel-***@lists.sourceforge.net> <mailto:freetel-***@lists.sourceforge.net <mailto:freetel-***@lists.sourceforge.net>> Subject: Re: [Freetel-codec2] Fresh build of SM1000 firmware on a windows machine. Just a note, but on my Ubuntu 16 32-bit Virtual Box, it resulted in 1305108 for the sm1000.elf, and after the 'objcopy' conversion, the .bin result was 305884. I had to download the V 1.7.1 ZIP file manually, as the web site gave me a short version that was gimped and wouldn't unzip.
I just downloaded it manually after registering and put it in the 'dl' directory. Also the name changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the 'en.' before putting it in 'dl'. I hope all that makes sense. ---------------------------------------------------------------------------- -- _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> <mailto:Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> <mailto:Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-***@lists.sourceforge.net <mailto:Freetel-***@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------
_______________________________________________ Freetel-codec2 mailing
list Freetel-***@lists.sourceforge.net
<mailto:Freetel-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
------------------------------------------------------------------------------
_______________________________________________ Freetel-codec2 mailing
list Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[glen english]

For a low-tech PCB, very impressive PCB density Eric !



On 31/08/2016 2:15 PM, ***@vk5kbb.com wrote:
>
> Actually now have downloaded the latest code form Sourceforge. (only
> found that by accident)
>
> Was using the download from your website Dave and with a few changes
> it now seems to be more stable.
>



------------------------------------------------------------------------------

[e***@vk5kbb.com]

My basic design brief for all my boards is simple.

1 if your PCB has space with no components or tracks put something on it
or shift stuff to occupy it.

2 if you have to put anything on the bottom layer other than ground
plane your not thinking enough about your components placement!

that's it and I do this for a living.

Cheers

Eric

On 2016-08-31 06:46, glen english wrote:

> For a low-tech PCB, very impressive PCB density Eric !
>
> On 31/08/2016 2:15 PM, ***@vk5kbb.comwrote:
>
>> Actually now have downloaded the latest code form Sourceforge. (only found that by accident) Was using the download from your website Dave and with a few changes it now seems to be more stable.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[glen english]

Hi Eric
I've been trying to send you a direct email.. but your server does not
like something about me just FYI :

(and my hostname is existent and has dots)


cheers

The following recipient(s) could not be reached:

***@vk5kbb.com
Error Type: SMTP
Remote server (27.124.118.245) issued an error.
hMailServer sent: RCPT TO:<***@vk5kbb.com>
Remote server replied: 550 HOSTNAME cannot be non existent or be without dots!






------------------------------------------------------------------------------

[e***@vk5kbb.com]

Not sure why that is Glenn,

You could perhaps try email to ***@tecy.com.au.

Regards

Eric

On 2016-08-31 14:09, glen english wrote:

> Hi Eric
> I've been trying to send you a direct email.. but your server does not
> like something about me just FYI :
>
> (and my hostname is existent and has dots)
>
> cheers
>
> The following recipient(s) could not be reached:
>
> ***@vk5kbb.com
> Error Type: SMTP
> Remote server (27.124.118.245) issued an error.
> hMailServer sent: RCPT TO:<***@vk5kbb.com>
> Remote server replied: 550 HOSTNAME cannot be non existent or be without dots!
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Nice work Eric, great looking board.

The codec2-dev SVN repository is the best place to work from for the
stm32 code, check-out details on the Codec 2 page.

It should recover automatically from loss of sync without any
intervention PTT, maybe cross check with a sm1000 and earlier firmware.

Cheers,

David

On 31/08/16 13:45, ***@vk5kbb.com wrote:
> Actually now have downloaded the latest code form Sourceforge. (only
> found that by accident)
>
> Was using the download from your website Dave and with a few changes it
> now seems to be more stable.
>
> I'm feeding voice audio into FreeDV on the PC and then demodulating that.
> I think now it looses sync when the PC glitches but it usually wont
> recover with out intervention like a quick PTT.
>
> I've been exploring the whole FreeDV thing for about 3 years now as I
> want the STM32 to generate I/Q signals for a SDR I am making, and have
> been using dsPIC in that for a while but wanted to generate the I/Q
> signals and decode them all in the one micro.
>
> Primarily for data more so than voice.
>
> I think now that this is working I can migrate it quite easily and will
> probably end up sticking with the ARM, as there is not much of a cost
> difference.
>
> The next build of the PCB attached has had the 5 Volt reg, Audio amp and
> EEPROM removed and looks at coming in at 50x26mm It can easily fit into
> the FT-817 on the main PCB with some double sided tape and by
> interrogating the radio via serial determine the mode of operation so no
> need for holes or buttons..
>
> As you point out the modem/FSK Datapump is actually what I am more
> interested in for that use and will provide some more scope for
> experimentation.
>
> This PCB design was a quick proof of concept and now that it seems to
> work ok I will have a look at cost effective manufacture if there is
> interest in it.
>
> Cheers
>
> Eric.
>
> On 2016-08-31 03:15, David Rowe wrote:
>
>> Oh yes and picture can be added as attachments, just keep them to a few
>> 100k. Or link to a URL. I'm happy to write a blog post on yr project
>> if you like, might get others interested.
>>
>> Can think of other applications for yr module too - like in radio
>> modems/FSK work.
>>
>> Cheers,
>>
>> David
>>
>> On 31/08/16 09:47, ***@vk5kbb.com <mailto:***@vk5kbb.com>wrote:
>>> I do have some pictures, I wasn't sure if they could be added as
>>> attachments. On this design to aid in layout simplicity and speed up
>>> the design (only spent 2 or 3 hours on it on a lazy Sunday arvo) I
>>> had swapped ADC and DAC pins. I foolishly thought it would be a
>>> matter of changing a few defines in the code to accommodate this (but
>>> was wrong). As it turned out even after recording all the ADC1/2 and
>>> DAC1/2 in the source I am not 100% convinced it worked as when I am
>>> feeding audio from the PC the error LED cycles in and out when there
>>> is no modulation. As soon as there is modulation on the audio to the
>>> PC the error light stays off. RT light stays on fine. I thought
>>> initially that there may have been a porting issue with the tuning
>>> and hence the slow cycling but since then I have modified the PCB so
>>> that the inputs are reversed and can use the original firmware with
>>> only changes of the GPIO's for the switches and LED's. Acts the same
>>> way so I have to ask if this is normal when there is no modulation on
>>> the data stream? As for circuits I am now re-hashing the board layout
>>> to remove the speaker amp, 5volt regulator and EEPROM to save space
>>> as none of these are needed when installed into a radio. I am also
>>> returning the ADC and DAC pins to original so that the only code that
>>> needs changing is that for the switches and LED's That will make the
>>> hardware generic and then I will get a quote for having it made
>>> cheaply in China if people are interested. Cheers Eric. On 2016-08-31
>>> 00:24, David Rowe wrote:
>>>> Nice work Eric. Do you have any photos? Good to see this sort of
>>>> innovation happening with codec 2 and the open hardware SM1000
>>>> platform. Also it would be great if you can publish your
>>>> hardware/software work under the GPL/TAPR open hardware licenses for
>>>> others to build upon. Cheers, David On 28/08/16 09:37,
>>>> ***@vk5kbb.com <mailto:***@vk5kbb.com> <mailto:***@vk5kbb.com
>>>> <mailto:***@vk5kbb.com>>wrote:
>>>>> No confusion and thanks for the input. In the end looks like my
>>>>> windows DFuSe was not working correctly and I found that DFU-UTILS
>>>>> could be installed with a simple apt-get function and I didnt need
>>>>> to build it. From there DFU-UTILS happily installed the 210,080
>>>>> byte .BIN (didnt need to be converted) and I could immediately tell
>>>>> it worked because it took roughly 30 seconds to down load to the
>>>>> hardware. So the modified code for the new hardware works (although
>>>>> as the new hardware uses different ADC pins the changes are not
>>>>> trivial). Now I will go back to evaluating various IDE's because
>>>>> this is not an environment that makes code development very easy or
>>>>> efficient. Basically right now I am editing in an IDE on a windows
>>>>> machine via a network drive and then making on the Ubuntu machine.
>>>>> The hardware tested ok and I now have an SM1000 that fits into a
>>>>> match box so I can put it inside a speaker microphone. I am however
>>>>> now redesigning the PCB to reduce it a further 20% in size (mainly
>>>>> removal of more un-needed parts, 5V reg, EEPROM, and speaker
>>>>> amplifier) with the plan to graft it into my FT817 so that it is
>>>>> activated when the digital mode is selected. I am also putting the
>>>>> ADC pins back where they were so that people need only change the
>>>>> sm1000_leds_switches.c code to reflect the pin changes. I will
>>>>> eventually rewrite the code so that the ADC's and GPIO's are
>>>>> defined in a single .h hardware definition to make the code
>>>>> hardware portable. I do this as a general rule of thumb so that for
>>>>> example in this case every time the hardware changes the 56 (or
>>>>> more) instances of ADC1/2 all dont need to be edited. Cheers Eric
>>>>> On 2016-08-24 15:04, Walter Holmes wrote:
>>>>>> Steve, I hope this doesn't just add more to the confusion, but the
>>>>>> .bin file for the SM1000 is about 227k that is flashed from Linux,
>>>>>> but if I extract that same code down to my Windows machine using
>>>>>> the DFU program it's 1025k. I am not part of the code team, so I
>>>>>> have no idea why there is such a difference, but that's just an
>>>>>> observation I have witnessed. I say this only so that you don't
>>>>>> let the code size between environments make you think it's not
>>>>>> still correct. Try it out to see what happens. I suspect the
>>>>>> Windows side probably has a lot of extra overhead as do most
>>>>>> Windows apps, and clearly the Linux side is a great deal more
>>>>>> efficient. All the best, Walter/K5WH -----Original Message-----
>>>>>> From: Steve [mailto:***@gmail.com
>>>>>> <mailto:***@gmail.com> <mailto:***@gmail.com
>>>>>> <mailto:***@gmail.com>> <mailto:***@gmail.com
>>>>>> <mailto:***@gmail.com> <mailto:***@gmail.com
>>>>>> <mailto:***@gmail.com>>>] Sent: Wednesday, August 24,
>>>>>> 2016 3:33 AM To: freetel-***@lists.sourceforge.net
>>>>>> <mailto:freetel-***@lists.sourceforge.net>
>>>>>> <mailto:freetel-***@lists.sourceforge.net
>>>>>> <mailto:freetel-***@lists.sourceforge.net>>
>>>>>> <mailto:freetel-***@lists.sourceforge.net
>>>>>> <mailto:freetel-***@lists.sourceforge.net>
>>>>>> <mailto:freetel-***@lists.sourceforge.net
>>>>>> <mailto:freetel-***@lists.sourceforge.net>>> Subject: Re:
>>>>>> [Freetel-codec2] Fresh build of SM1000 firmware on a windows
>>>>>> machine. Just a note, but on my Ubuntu 16 32-bit Virtual Box, it
>>>>>> resulted in 1305108 for the sm1000.elf, and after the 'objcopy'
>>>>>> conversion, the .bin result was 305884. I had to download the V
>>>>>> 1.7.1 ZIP file manually, as the web site gave me a short version
>>>>>> that was gimped and wouldn't unzip. I just downloaded it manually
>>>>>> after registering and put it in the 'dl' directory. Also the name
>>>>>> changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the 'en.'
>>>>>> before putting it in 'dl'. I hope all that makes sense.
>>>>>> ----------------------------------------------------------------------------
>>>>>> -- _______________________________________________ Freetel-codec2
>>>>>> mailing list Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>>>
>>>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________ Freetel-codec2
>>>>>> mailing list Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>>> <mailto:Freetel-***@lists.sourceforge.net>>>
>>>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________ Freetel-codec2
>>>>> mailing list Freetel-***@lists.sourceforge.net
>>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________ Freetel-codec2
>>>> mailing list Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>
>>>> <mailto:Freetel-***@lists.sourceforge.net
>>>> <mailto:Freetel-***@lists.sourceforge.net>>
>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>> ------------------------------------------------------------------------------
>>> _______________________________________________ Freetel-codec2
>>> mailing list Freetel-***@lists.sourceforge.net
>>> <mailto:Freetel-***@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> <mailto:Freetel-***@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[Erich Heinzle]

I'm very interested in your compact board; I'd be interested in having one
or two to play with if you order a batch to defray your costs (I usually
use hackvana which does a minimum order of around 10).

If you plan to release your design under a TAPR or similar licence, I'd be
interested in converting the gerbers into footprints for use in gEDA PCB
and also Kicad, assuming you've not designed it in kicad or gEDA PCB.

Regards,

Erich
VK5HSE



>
> ------------------------------
>
> Message: 3
> Date: Sun, 28 Aug 2016 02:07:32 +0200
> From: ***@vk5kbb.com
> Subject: Re: [Freetel-codec2] Fresh build of SM1000 firmware on a
> windows machine.
> To: freetel-***@lists.sourceforge.net
> Message-ID: <***@vk5kbb.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> No confusion and thanks for the input.
>
> In the end looks like my windows DFuSe was not working correctly and I
> found that DFU-UTILS could be installed with a simple apt-get function
> and I didnt need to build it.
>
> >From there DFU-UTILS happily installed the 210,080 byte .BIN (didnt need
> to be converted) and I could immediately tell it worked because it took
> roughly 30 seconds to down load to the hardware.
>
> So the modified code for the new hardware works (although as the new
> hardware uses different ADC pins the changes are not trivial).
>
> Now I will go back to evaluating various IDE's because this is not an
> environment that makes code development very easy or efficient.
>
> Basically right now I am editing in an IDE on a windows machine via a
> network drive and then making on the Ubuntu machine.
>
> The hardware tested ok and I now have an SM1000 that fits into a match
> box so I can put it inside a speaker microphone.
>
> I am however now redesigning the PCB to reduce it a further 20% in size
> (mainly removal of more un-needed parts, 5V reg, EEPROM, and speaker
> amplifier) with the plan to graft it into my FT817 so that it is
> activated when the digital mode is selected.
>
> I am also putting the ADC pins back where they were so that people need
> only change the sm1000_leds_switches.c code to reflect the pin changes.
>
> I will eventually rewrite the code so that the ADC's and GPIO's are
> defined in a single .h hardware definition to make the code hardware
> portable.
>
> I do this as a general rule of thumb so that for example in this case
> every time the hardware changes the 56 (or more) instances of ADC1/2 all
> dont need to be edited.
>
> Cheers
>
> Eric
>

[Brady O'Brien]

It won't result in an audible click or glitch in the modulator output. The
DACs and ADCs are being driven by the STM32's DMA from 20ms buffers. Once a
buffer is half empty/full, the DMA peripheral triggers an interrupt, which
then copies to/from an 80ms FIFO. Once enough samples are on the incoming
FIFO (~40ms), freedv_tx or freedv_rx are called in main. Even if an
interrupt from the UART hits during the DMA service routine, it won't cause
any problems.

On Tue, Sep 6, 2016 at 11:39 PM, <***@vk5kbb.com> wrote:

> The main reason I said can't do a software FIFO is because it needs to be
> an interrupt and there is little documentation I have found on the main
> code structure, let alone a flow diagram.
> So I have no idea of code over heads or interrupt priority.
> Simply sticking in another interrupt could result in something as simple
> as an audible "tick" every time a char is received or worst case result in
> a loss of synchronization every time a char is received.
> Sort of reverse engineering all the code I haven't found a resource that
> lets me determine how and where to best implement the serial coms.
>
> On say a PIC24 I can just let it fill the buffer and then test the flags
> to see if chars are present.
> That would be easy to do and the test would be as simple in code as
> checking the switches.
>
> If you think there is so much over head then I will just give it a try in
> software and see what happens.
>
> Thanks.
>
> Eric
>
>
>
> On 2016-09-07 01:01, Bruce Perens wrote:
>
> > So, anything that happens in the usart interrupt handler is transparent
> to the codec encoder
>
> Except for timing. But Brady has already explained that it's
> timing-insensitive.
>
> On Tue, Sep 6, 2016 at 3:56 PM, glen english <***@cortexrf.com.au> wrote:
>
>> Eric. you said : "you can not implement a software FIFO on interrupt
>> because this would effect the other processes every time a byte is
>> received."
>>
>> That is not really the case .I'll explain.
>>
>> the interrupt handler will push the used registers, SP etc onto the
>> stack on entry to the IRQ handler, and restore them when it is done.
>> So, anything that happens in the usart interrupt handler is
>> transparent to the codec encoder- it wont ever know there was an
>> interrupt. The compiler will deal with all that for you. Yes I know in
>> asm days, life was different.
>>
>> but I guess you already know the above.. maybe the case of cycles
>>
>> There are plenty of online examples.
>>
>> Essentially on stm32
>>
>> on IRQ entry
>>
>> read USART->SR into a variable
>> if there are errors , read the DR.
>> this will clear errors. it will also get a char if there was one there.
>>
>> if there were no errors , but the RXNE / fifo flag was set, and you have
>> not read the DR already, read the DR and put your new char into your ram
>> buffer, increment the buffer ptr index, wrap as required and increment
>> the nChars variable so your app knows how many chars there are
>>
>> if the TXE flag was set, the usart wants another char, get from your ram
>> buffer and write to the DR, inc buffer ptr, and -- nChars to tx.
>>
>> done.
>>
>> now, in your application, you need sample the nchars waiting to tx, and
>> n chars ready to get from the buffer variables, and because the irq
>> context also has access to those registers, you need to guard
>> application access (ie non irq context) by using critial sections . in
>> the simplist form that is disabling and enablign interrupts around those
>> variables
>>
>> NOW !!!!!
>>
>> there are some very handy synchronization opcodes you can use in the ARM
>> instruction set to do this!!!
>> if you want- no need for critical sections and disabling interrupts.
>>
>> g
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Freetel-codec2 mailing listFreetel-***@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>

[e***@vk5kbb.com]

Also while I'm looking at adding and removing parts of the code.

Does any body have a list of essential files needed for building the
SM1000.bin and nothing else.

I can see a lot of test code and also now in the -DEV folder there is a
lot of SM2000 code.

I'd like to have a build folder with just the essential functions and
the dl library in it.

Cheers

Eric

[Bruce Perens]

Eric,

When you work with an Open Source project, you are not expected to need
documentation of the overall structure of the code, or a list of the
essential files, or a timing diagram, or an explanation of the interrupt
priority (we already told you it's a busy loop, which means there is no
interrupt priority).

You are expected to read the code and figure all of that out for yourself.
The code is actually not all that difficult.

Think of it as a test. You might not be ready to work on this sort of
project.

Sorry

Bruce

[glen english]

------------------------------------------------------------------------------

[Adrian Musceac]

Hi Bruce,
This kind of thinking is the reason open source projects are not taken seriously and are seen as little more than toys.
I am guilty myself of being lazy, fortunately there are people who don't apply the same reasoning.
I do get frustrated when I try to get people into open source and they all laugh at me.

Cheers,
Adrian

On 7 September 2016 06:09:04 GMT+01:00, Bruce Perens <***@perens.com> wrote:
>Eric,
>
>When you work with an Open Source project, you are not expected to need
>documentation of the overall structure of the code, or a list of the
>essential files, or a timing diagram, or an explanation of the
>interrupt
>priority (we already told you it's a busy loop, which means there is no
>interrupt priority).
>
>You are expected to read the code and figure all of that out for
>yourself.
>The code is actually not all that difficult.
>
>Think of it as a test. You might not be ready to work on this sort of
>project.
>
> Sorry
>
> Bruce
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freetel-codec2 mailing list
>Freetel-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freetel-codec2

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

------------------------------------------------------------------------------

[David Rowe]

SM1000_SRCS in codec2-dev/stm32/Makefile

On 07/09/16 14:17, ***@vk5kbb.com wrote:
> Also while I'm looking at adding and removing parts of the code.
>
> Does any body have a list of essential files needed for building the
> SM1000.bin and nothing else.
>
> I can see a lot of test code and also now in the -DEV folder there is a
> lot of SM2000 code.
>
> I'd like to have a build folder with just the essential functions and
> the dl library in it.
>
> Cheers
>
> Eric
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Do we know what the FreeDV input and output buffer service/cycle times
are approximately?

Thanks

Eric

On 2016-09-07 00:43, Brady O'Brien wrote:

> A couple hundred cycles of interrupt handler to fill a fifo in the middle of the signal processing really shouldn't be an issue for you. The FreeDV input and output are buffered through their own DMA-driven fifo and can handle a very small delay.
>
> On Tue, Sep 6, 2016 at 5:40 PM, <***@vk5kbb.com> wrote:
>
> I am aware of the peripherals and its not what I need to know.
>
> I was asking if any one had implemented the serial port peripheral with out interfering with the operation of the codec.
>
> The pinning is irrelevant because I am using my own hardware design and have access to what ever pins I want.
>
> Cheers
>
> Eric
>
> On 2016-09-06 22:35, Bruce Perens wrote:
> The STM32F405 peripheral set is richer than you realize:
>
> * 2x USB OTG (one with HS support)
> * Audio: dedicated audio PLL and 2 full duplex I²S
>
> * Up to 15 communication interfaces (including 6x USARTs running at up to 10.5 Mbit/s, 3x SPI running at up to 42 Mbit/s,
> 3x I²C, 2x CAN, SDIO) * Analog: two 12-bit DACs, three 12-bit ADCs reaching 2.4 MSPS or 7.2 MSPS in interleaved mode
> * Up to 17 timers: 16- and 32-bit running at up to 168 MHz
> * Easily extendable memory range using the flexible static memory controller supporting Compact Flash, SRAM, PSRAM, NOR and NAND memories
> * Analog true random number generator
>
> I haven't looked at what pins David has dedicated and whether you can get at undedicated pins at all.
>
> On Tue, Sep 6, 2016 at 1:20 PM, Shane Burrell <***@shaneburrell.com> wrote:
>
> For the STM32 it will be a software FIFO. Easiest way to do that is to interrupt at each byte and fill a buffer. Hence DMA is as easy and does the buffer fill for you.
>
> On Tue, Sep 6, 2016 at 4:17 PM, <***@vk5kbb.com> wrote:
>
> Yes I was hoping to use a FIFO as that how I do it on the PIC, however was looking at the datasheet and didnt see any implementation of one, just DMA.
>
> I will have to look closer.
>
> Thanks.
>
> Eric
>
> On 2016-09-06 19:14, Bruce Perens wrote:
>
> In sm1000? Since there is no OS you either have to hook into the busy loop or write interrupt code. If the FIFO is deep enough to queue a command, the code will not be time critical and you can do it in the loop. No DMA necessary.
>
> On Sep 6, 2016 7:51 AM, "Shane Burrell" <***@shaneburrell.com> wrote:
>
> You shouldn't have any problems doing that via DMA UART
>
> On Tue, Sep 6, 2016 at 9:52 AM, <***@vk5kbb.com> wrote:
>
> I'm wondering if any body has managed to implement the serial USART in a manner that does not interfere with the encode/decode process.
>
> Will be doing away with the switch menu and assume I can send and receive data to the USART in its place as the USART functions independently via DMA and hence shouldn't interfere with any thing I hope.
>
> I'm basically implementing the Yaesu CAT interface and want to send 5 bytes and receives 5 bytes once a second at 9600 baud.
>
> Thoughts?
>
> Cheers
>
> Eric
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[glen english]

------------------------------------------------------------------------------

[glen english]

------------------------------------------------------------------------------

[Bruce Perens]

Glenn, he wants to be a CAT target or host.

On Tue, Sep 6, 2016 at 2:51 PM, glen english <***@cortexrf.com.au> wrote:

> and furthermore to my previous USART post
>
> Eric, you are going to have to implement a USASRT interrupt handler anyway.
> why ?
> Because you need to handle an error condition as it happens. This is for
> any peripheral, DMA or not.
>
> So, using the usart, just have a single IRQ handler that does everything,
> and enable all IRQ flags
> so it is a catch all.
>
>
> Now, if you want fast SPI, so 42 Mbps (what I do on all four ports)
> I use DMA for transfer , but I still have a interrupt but have the IRQ
> flags only for errors- IE normal TXE or RXNE dont generate interrupts (they
> trigger a DMA xfer) in that case but ERR does.
>
> The peripherals are quite complex compared to the AVR days. And poorly
> behaved.
>
> Read the errata for the chip part number you have
> With 20 page errata, there will be something affecting what you are
> doing....
>
>
> glen
>
>
>
> On 7/09/2016 6:17 AM, ***@vk5kbb.com wrote:
>
> Yes I was hoping to use a FIFO as that how I do it on the PIC, however was
> looking at the datasheet and didnt see any implementation of one, just DMA.
>
> I will have to look closer.
>
> Thanks.
>
> Eric
>
>
>
> On 2016-09-06 19:14, Bruce Perens wrote:
>
> In sm1000? Since there is no OS you either have to hook into the busy loop
> or write interrupt code. If the FIFO is deep enough to queue a command, the
> code will not be time critical and you can do it in the loop. No DMA
> necessary.
>
> On Sep 6, 2016 7:51 AM, "Shane Burrell" <***@shaneburrell.com> wrote:
>
>> You shouldn't have any problems doing that via DMA UART
>>
>> On Tue, Sep 6, 2016 at 9:52 AM, <***@vk5kbb.com> wrote:
>>
>>> I'm wondering if any body has managed to implement the serial USART in a
>>> manner that does not interfere with the encode/decode process.
>>>
>>> Will be doing away with the switch menu and assume I can send and
>>> receive data to the USART in its place as the USART functions independently
>>> via DMA and hence shouldn't interfere with any thing I hope.
>>>
>>> I'm basically implementing the Yaesu CAT interface and want to send 5
>>> bytes and receives 5 bytes once a second at 9600 baud.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> Cheers
>>>
>>> Eric
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>>
>>> _______________________________________________
>>> Freetel-codec2 mailing list
>>> Freetel-***@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>>
>>>
>> ------------------------------------------------------------
>> ------------------
>>
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Freetel-codec2 mailing listFreetel-***@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Freetel-codec2 mailing listFreetel-***@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>

[glen english]

------------------------------------------------------------------------------

[e***@vk5kbb.com]

Thanks Glenn,

That is exactly what I wanted to know.

I may pick you brain if I have any issues.

I may also have a chat with you about the high data rates as I have
another project requiring those kinds of bit rates.

Thank you very much for the response.

Cheers

Eric

On 2016-09-07 00:31, glen english wrote:

> right.. so an interrupt handler that deals with USART ERR condix and buffer handling (about 4 lines of C) will be just fine.
>
> On 7/09/2016 8:05 AM, Bruce Perens wrote:
> Glenn, he wants to be a CAT target or host.
>
> On Tue, Sep 6, 2016 at 2:51 PM, glen english <***@cortexrf.com.au> wrote:
>
> and furthermore to my previous USART post
>
> Eric, you are going to have to implement a USASRT interrupt handler anyway.
> why ?
> Because you need to handle an error condition as it happens. This is for any peripheral, DMA or not.
>
> So, using the usart, just have a single IRQ handler that does everything, and enable all IRQ flags
> so it is a catch all.
>
> Now, if you want fast SPI, so 42 Mbps (what I do on all four ports)
> I use DMA for transfer , but I still have a interrupt but have the IRQ flags only for errors- IE normal TXE or RXNE dont generate interrupts (they trigger a DMA xfer) in that case but ERR does.
>
> The peripherals are quite complex compared to the AVR days. And poorly behaved.
>
> Read the errata for the chip part number you have
> With 20 page errata, there will be something affecting what you are doing....
>
> glen

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[e***@vk5kbb.com]

This is my point exactly you can not implement a software FIFO on
interrupt because this would effect the other processes every time a
byte is received.

I suspect DMA has been implemented as a more efficient form of buffering
in place of hardware buffer.

Cheers

Eric

On 2016-09-06 22:20, Shane Burrell wrote:

> For the STM32 it will be a software FIFO. Easiest way to do that is to interrupt at each byte and fill a buffer. Hence DMA is as easy and does the buffer fill for you.
>
> On Tue, Sep 6, 2016 at 4:17 PM, <***@vk5kbb.com> wrote:
>
> Yes I was hoping to use a FIFO as that how I do it on the PIC, however was looking at the datasheet and didnt see any implementation of one, just DMA.
>
> I will have to look closer.
>
> Thanks.
>
> Eric
>
> On 2016-09-06 19:14, Bruce Perens wrote:
>
> In sm1000? Since there is no OS you either have to hook into the busy loop or write interrupt code. If the FIFO is deep enough to queue a command, the code will not be time critical and you can do it in the loop. No DMA necessary.
>
> On Sep 6, 2016 7:51 AM, "Shane Burrell" <***@shaneburrell.com> wrote:
>
> You shouldn't have any problems doing that via DMA UART
>
> On Tue, Sep 6, 2016 at 9:52 AM, <***@vk5kbb.com> wrote:
>
> I'm wondering if any body has managed to implement the serial USART in a manner that does not interfere with the encode/decode process.
>
> Will be doing away with the switch menu and assume I can send and receive data to the USART in its place as the USART functions independently via DMA and hence shouldn't interfere with any thing I hope.
>
> I'm basically implementing the Yaesu CAT interface and want to send 5 bytes and receives 5 bytes once a second at 9600 baud.
>
> Thoughts?
>
> Cheers
>
> Eric
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]

------------------------------------------------------------------------------

_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1]



Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Bruce Perens]

It looks like do indeed have to do either DMA or interrupt handling to
handle more than one byte from USART receive.

[glen english]

------------------------------------------------------------------------------