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]] > Sent: Wednesday, August 24, 2016 3:33 AM > To: [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] > 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
