Thanks
Bruce
As part of making this next step in wireless codecs and modems, we are
asking for a different hardware environment than you might be used to.
Your proprietary code: If your system has proprietary code that you can not allow users to access, or if you feel that locked-down code is required for regulatory type approval, put that code in a separate CPU from the one where our software will live.
User programmable in C: Our codec and modems are not standing still, and our over-the-air protocols change frequently as we innovate. We don't want them cast in concrete in your product. Thus, we specify a user-programmable microprocessor as the host of the Codec2 and FreeDV software. You will find that all of the necessary embedded systems programming software is available in Open Source form, and we strongly suggest that you do not use any proprietary software tools at all. Our low-level code including the codec and modems are written in C, while applications are in C++ or Java (depending on the platform). GCC and LLVM are both fine compilers and are already available for the processor architectures we would have you use.
Hardware floating point: We appreciate that most of the embedded wireless world are coding in fixed point on specialized DSP chips. However, we find that there is a large people-time cost to creating good fixed-point code over that of its floating-point equivalent. We would pay this cost in several ways: longer time to develop, fewer programmers participating, greater complexity of resulting code. People are much more expensive than microprocessors, and hardware floating-point processors capable of handling our software are available in chips costing less than USD$4. Thus, we require hardware floating point.
Intellectual property: Publicly disclose your programming documentation. Do not embed a proprietary operating system or other proprietary software that would create intellectual property hassles when combined with our Open Source code. Make sure that any headers required for programming your product are released under a minimally-restrictive Open Source license such as the BSD license, so that they can be combined with any software. Libraries should be available in source-code form and placed under an Open Source license that allows linking with any software, such as BSD or LGPL3. Don't require developer agreements, Open Source licensing is easier to deal with than such things.
DAC and ADC: A 48K sampling rate is required as this is the common speed on PC sound cards, add as many other optional sampling rates as you wish. 16 bits minimum per sample are required, more bits are better. At a minimum we require inputs for microphone and receive audio, outputs for speaker/headphone and transmit audio.
CPU Clock Precision: Quartz crystal or better.Interfaces: The best FLASH loader would be for your hardware to load a file from an inserted USB storage device using the VFAT or FAT filesystem. All relevant host operating systems can deal with that format, it's most easy for users, and it doesn't require that your device and the computer be cabled together. The exFAT filesystem is strongly discouraged due to its actively-enforced patent restrictions. Other USB protocols are OK as long as Open Source software is provided to drive them.
Debugging: serial console terminal, JTAG, and in-system debugging interfaces are encouraged. All of the modern microprocessors that we would have you use provide some such interface. Please make them available on an internal PC board if you can't bring them to an outside connector. Consider standard pinouts such as the ones given for Cortex-M at http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf
<<attachment: bruce.vcf>>
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
