There are two (at least) choices for the form factor and that will drive a lot of the rest of the design.
1) A small box that a user can pick up and use as the microphone. This limits the complexity (at reasonable build cost) and power dissipation. It also limits the user interface quite a bit. The built in mic and speaker will be rather limited too. 2) A small-ish box with connectors for the users choice of microphone and speaker, or headset... This can be much larger that the first option and still be easy to set on a desk or on top of a radio. It can still be nearly instant on and avoid all of the problems people have installing software on a desktop computer. I'd like to second the suggestion of using a dedicated real time OS like FreeRTOS, Chibios, etc. Maybe a very stripped down Linux would do as well I have not worked with that. I don't think the box should support local compiles or much stand-alone debugging. Build in an interface (Ethernet or USB) and do those things on a desktop system. I'd volunteer to help with the FPGA part, but I am afraid you will want to use VHDL and all of my experience is with Verilog :-) . Seriously, I have been wanting to do a Zynq project for quite a while and would be interested in working on that. I could probably even learn VHDL. I have built things like AXI bus interfaces, FIFO channels, and integrated DSP blocks. Those were for image processing not audio but a lot should carry over. I also agree with your comments about the current code being written for development in a PC environment. Not a bad thing, just what it is. There are many opportunities to streamline, reduce data size and copying, etc. That is how we got 700D into the SM1000. In my past work life we did 80% integer/fixed-point math and 10-15% "pseudo FP". That took a lot more work up front to verify behavior against the higher level models but there were also benefits. Besides smaller implementations it is pretty easy to compare an integer implementation to an integer model when you can expect an exact match bit for bit. So verification and debugging in simulations or on hardware is a lot simpler. Don Reid - W7DMR Oregon, USA _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
