Ralph Moore


Ralph graduated with a degree in Physics from Caltech. He spent his early career in computer research. Then he moved into mainframe design in the 60's and became a consultant in the early 70's. He taught himself programming and became a microprocessor programmer. He founded Micro Digital in 1975, and many years of successful consulting lead into architecting and developing the smx kernel in 1987. For many years he managed the business and sales, but in recent years he has been focused almost solely on development of the smx multitasking kernel v4.

Ralph Moore

's contributions
    • This second article on achieving MPU security demonstrates that there is a feasible step-by-step process to incrementally improve the security of Cortex-M embedded systems that have MPUs and that this process can be performed on systems already released and by people who did not write the code.

    • Use of Memory Protection Units in Cortex-M MCUs is critical for security, but MPUs are often underutilized due to the difficulty of their use and tight project schedules. I set out a year and a half ago to devise a practical way to upgrade post- and late-development projects as well as new projects to use MPU security.

    • I agree that longer names are needed for larger projects. In general, I think less familiar names need to be longer, but they do not need to be super-long as some of the examples I gave. I think it is ridiculous that in these examples, the first 20 characters do nothing to differentiate the objects that they represent. In this case, I think is somebody is just doing "the right thing" without thinking. All of our names are prefixed with smx_ to keep them out of the user's namespace. Ralph

    • I fully agree. In my non-test code: u32 smx_bin_tries; /* bin tries counter for best fit */ BOOLEAN smx_heap_stats; /* enables heap stats */ BOOLEAN smx_chunk_merge; /* free chunk merge mode */ It is so easy in the editor or debugger to right click on a variable and go to its definition, where there is a good comment. Why carry excess baggage around in the name and obfuscate the code? Ralph

    • Glad we agree on local variables. I agree your formatting of the long version looks better, but I prefer the short version. I think there is nothing wrong with using operator precedence, within reason. For algebraic expressions, we write a*b + c*d, not (a*b) + (c*d). Why not the same with code? If nesting gets above 2 I have trouble associating ) with ( and need to use the editor to help me out. Ralph

    • Hi, I want to thank you and others for commenting. I probably picked a wrong example to illustrate the point I was trying to make. It is from a heap regression test. My two priorities when writing test code are: to make testing as complete as I can and to get it over with ASAP, so I don't get impatient and shortchange the first objective. I assume that you are following a coding standard for deliverable code. For me the first version is better for maintenance. It has only 3 lines of code vs 51 for your version. In the heap test, alone, there are about 100 of these sub-tests, which are all similar. Hence one gets accustomed to the pattern quickly. It would take me a long time to write so many extra lines of code. I think the point is that different naming standards are appropriate for different purposes. Ralph

    • This is a good point -- and a difficult one to address. Much depends upon the complexity of the project, the hardware resources available(especially RAM and processor speed), reliablilty requirements, etc. I have posted some detailed technical whitepapers on our website ( which may be helpful. It seems to me that to be truly useful, this kind of whitepaper needs to incorporate a good deal of example code, which I am considering doing for future whitepapers. I welcome suggestions concerning what topics are of main interest and how much detail is needed. Ralph Moore Author

    • This whitepaper is intended for recent Computer Science graduates who received very little practical exposure to RTOSs in their college curricula and are now faced with selecting an RTOS. It also is intended for engineers and managers who likewise have had little exposure to RTOSs, yet may be the RTOS decision makers for their next projects. It is not possible to cover the enormous variety of embedded system projects with a single check list, as the above reader suggests. Hence, this whitepaper focuses on general concepts in order to promote a better understanding of RTOSs. Future white papers will focus on specific RTOS topics. The author, Ralph Moore