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, [email protected]: > 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:[email protected] <mailto:[email protected]>] Sent: Wednesday, August 24, 2016 3:33 AM To: [email protected] <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] <mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] Links: ------ [1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
