First I wish to say sorry for my typo in the subject of thread name. If there is way to edit let me know.
Thanks for your reply. While wondering about after my post I happened on the command-line stm32duino
thread. Tiger762 really put in not just alot of effort to figure matters out, but the time and detail of the information was enlightning. As these microcountrolers and how source is build to make a binary is new to me it will take a bit for me to digest. I have not used any microcontroler yet. I have one here, Nano waiting for a prototype board. A Lenoard on way (I need lots of ADC pins, not ADC but you loose for SPI FD, I2C, et al as you all know about and based on MCU). So I have never even downloaded a MCU IDE, or Arduino yet.
Your point that the binary goes in the flash was interesting. I am assuming the binary has to run in RAM? Correct? If not that likely plays to the Flash/RAM sizing I am trying to determine. Flash/RAM sizing aside, CPU processing power is starting to look like a need for this important personal project. The proof of concept was last year about this time with me teathered to a 70foot RJ11 cable connected to a Thin Terminal running the software I have had and heavily modifided/enhanced since 2006. Memory/Processing power was not issue, but there is more need for what the device will need to do which brings up STM32 processing power. I know a Adafruit Father will draw about 12ma (was tested and published by Adafruit) for SD card writing. What I yet to figure out is if a STM32 will be similar. Device needs to be able to last at least 6-7 days on battery before another charge. Battery design translates to 3 days before charge so do not deep cycle battery.
The reason I asked about binary sizing and if anyone has seen a "magic multiplier" term Rick noted is knowing thre can be differences in size just on the CPU architecture alone exclusice of libraries, compilter options used for source and libraries, et al . I have seen many times with many different compilers (not just C) wide difference in code size not just for same source, but even a simple same net logic or for a exact same data type different code. Different so much to be way way different, as in several K to hundred MB different. I also know most C compilers have some basic flaws that have existed for years that a 10 line assember program does not have for exact same thing with regards to basic memory 101 of the Paper Tape days that is still true to this day. Such issues, bugs and assumptions in compiler design should not exist, not should I have to write a 10-30 line assembler program to avoid the basic compiler memory 101. Code generation/sequencing, well that is whole different discussion. In last few days I have hit some any compiler bugs just wring code and not testing (I did testing for years, compilers as well at personal level, agmonst my varied experiences).
I am familar with the assembler output GCC and some other compilers can generate. I started in IT as my first language being assembler and first personal project task to disassemble the OS and Compilers/Assembler manually to make major changes. The first goal for the IBM OS was an assember program to write a sysgen for the IBM systm to run in 30-40 minutes not the 4 hours IBM way. From scratch in assember as first entrance to computers. This means your link to the web pages about the assembler outpit to look at and maybe change I have done, but not for some time. Most are issues with Open Source so the "source be with you" does not need one to look at the assembler except when ones nose says something stinks.
I think you would agrees that despite Paper Tape days much has not really changed in many basic ways. Some things are coming full circle to those days. And yes I remember Paper Tape and even 026 Keypunch machines that used Vaccum tubes/Valves, relays and no transistors. At least you cannot "spill" Paper Tape. Lets just say there was a incident in parking lot to another site to do work where card trays of assembler programs spilled to the loading dock. Translate to how dinner was spend as friend's mother made diner for us afterwards.
I need to digest the command-line stm32duino
, your reply, and some of the things you have done I have looked at over last few months via various links on this site and from the links thereafter. Very interesting reading for sure and lots of practical reasoning as well. Once I get past the i2c issue or few pestering in code 98% ready then I can look at the cross cross compiling. If I can do this and make some 32 bit binaries needed then that helps all. I may be distracted again as someone wants me to test two different applications. Progress as I am testing and educating why testing is done way is done. I am sure you know that drill very well and the time it takes vs what many think takes.
John L. Males
25 October 2016 16:50 - 17:40
Opps, Famous jlm typos needed correction 25 October 2016 17:51