Thank you for your reply. Sorry for my delayed response. I have sorted out the not being notified going forward of replies aspect.
I have had a matrix for few months time that has allowed me to know what the uC requirements are prior to screen the pin out map of the uC. This allows me to screen and shortlist possible uCs. Then I consider board size, compatiability with libraries, et al. This matrix has alos allowed be to consider using I2C based ADCs as you also suggested as consideration.
WRT your reply
I read the FreeRTOS link
you provided. Insightful points and requirements to consider. Your points on "programming paradigm shifts a bit" and the memory (I will assume mostly RAM) added overhead for sure apply. I may have a few simple to implement in the application and in logic of that may allow me to acheive what I wish for "multitasking". There is one chip I can add that a great side effect will be to make one aspect of any multitasking a bit easier. The primary purpose of the chip I like to use is it allows much better control, behaviour, consistancy and far more devices than the challenges of the multiple devices via GPIO pins 99.9% use. Not to mention the risk of damage to the MCU using the latter 99.9% approach has.
You are correct that my analog requirements limit my uC choices. I have considered an ADC via the I2C. The ADS1115 is one easy choice in terms of cost, availability, and well known. An ADS1115 adds 4 single ADC channels per ADS1115 with a limit of 4 ADS1115s based on I2C addresses the ADS1115 can have. Some STM32s have 16 ADCs. More than I need, but higher than the 8 or 9 ADC pins of STM32F103C8 like Maple Mini or similar that may be a bit too low for my finial needs.
I like to have SD card and RTC as well. I recently received some SPI SD boards and SPI RTC based on the DS3231. My research says the STM32 RTCs are quite "accurate". The drift of the DS3231 is still too much for my needs. There are libraries that allow the drift that is chip/crystal specific to be reduced greatly. I will test the STM32 RTC to see if close to or better than a DS3231 and decide which I will use. Having the battery for the STM32 RTC on board like a SD just simplifies the physical and weather (protected in weatherproof case, but we have winter here!) elements of the design.
As you know manySTM32 boards SD is SDIO based and not SPI based. So far there is no stm32duino.com
SDIO SD library. This of course is due to what is needed in libraries and time allows for priority. This means I either see if I can write a SDIO library and not be certain of bugs I may have to find and work out. This factors in when the important data is then logging to the SDIO SD card vs what seems to be a well tested SPI SD. There is a balance of time vs stability. I am likely to side on the SPI SD card implementaion on STM32 board already or added via an SD board I have currently. I will already need to have a "few" other boards that will feed the analog signals and parallel digital signals (in many cases). I am trying to keep as much as can of the hand wiring mess this will sort of create so as not to get way out of hand (for number of sensors with boards or circuits I DIY build from existing schematics). I am trying not to create what may be a one of custom board design (cost and itteration factors inclusive) that would enable a better physical/weather and signal related relaibility considerations. That may be a loger term consideration, perhaps a must. For now I like to avoid custom daughter board(s).
This project will need to handle more than 80% of the 20% part of the 80/20 rule, meaning I have a 80/80 rule for this project. I allready know I have some challenges in making the sensors robust for weather (temperature, physical, salt, precipitation, et al. I learned that quickly in the proof of concept of one sensor that will be used. The sensor is fine, the physical protection design was not, but has been just fine for 10 years the design was created for and will for years to come. Eathquake, tornadoes, hurricanes, et al are currently not a factor in the physical considerations. The usual day to day varied humid summers to winters rain to snow are some of the primary physical considerations for this project.
As there may be a need for more than 20K RAM of a STM32F103C8 like uC, the increase RAM requirements, especially if I need to consider FreeRTOS, goes hand in had with having 16 ADC pins. I may have found a SPI based uC, but is based on a STM32F103C8T6 uC. That holds me to 20K RAM. The application design for the uC will push close to the 20K limit, but I may be able to use some techniques and other considerations to reduce perhaps more to a 4-5K (perhaps less) RAM footprint before libraries are factored into the RAM use. I have no idea if the 128K Flash will be a limit consideration if I need to use a FreeRTOS, or similar approach. I will assume the Maple Mini that has been shipped will be one way for me to figure out the sizing vs if I need to use a RTOS or not.
malloc or similar are not issues in the code I have written effect on RAM use simply beacuse malloc is not used by my code. I cannot speak for uC libraries linked to my code use or not of malloc and usual memory hole effects that can result.
Another side plus of more pins is having more than one I2C Uc channel and more than one SPI channel. This has some future considerations I like that are not pin requirements for more sensors. These could allow me to implement a couple unique simple elements that would be a small and great plus.
I now have some framework code I created over about a week as of about a week+ ago that allows me to have a better idea of the Flash/RAM requirement for the base framework code. Once a few other items arrive I can add in actual code for the devices. This will lead to the binary sizes and how much of the binary uses Flash and RAM. Then I can see if I can make futher code changes to reduce the Flash and RAM requirements of the code. Add in the suggestions from Rick for compiler and linker options to reduce or eliminate dead code from libraries and maybe a STM32F103F8 device with 20K RAM will be more possible and with room to spare for growth elements such as mybe a display if battery requirements will allow for. A display is not high on my requirements list, but could be helpful not being able to read the bits with my eyes written to the SD at time.
I hope my articulated reply and some prior one has now given a sense of the process and thinking that is being taken into account in the design/uC selection process that is of course WIP. For sure I have learned much in my research and part of the WIP since the Spring months before I discovered stm32duino.com
As always Ray, you have excellent points and suggestions. I find your thoughts and suggestions not just with replies to me, the replies you have made to others and the points and thoughts you make in some of the projects you have built that you have posted. Yes, I have seen a few and read most of what I have discovered. Time at he time was the only reason for my not reading those posts I have not yet.
The same goes for many other that have posted replies to me as well. It also applies to the many posts I have read, many, but really is only fraction of posts on stm32duino.com
. Lots of good information and considerations to think about. Some excellent of those points and thoughts of other posts not made by me or as result of reply to me have already factored in to the current design/consideration state of my project. Of course many are not aware they have helped at least me in regards to and are to be thanked as well by me for helping me.
John L. Males
08 November 2016 04:05 - 05:44/06:09