Jamil Weatherbee

image
Research & Development Engineering

Biography has not been added

Weatherbee

's contributions
Articles
Comments
    • Ada is sweet, but it is unfortunately not the answer. Ada is also almost 40 years old too and it is about 10 years late to the "debunk C/C++ in critical systems" party. The problem is that we shouldn't be *writing* code in the first place. Model Based Design (e.g. UML, SysML, Simulink etc.) are a much more effective and modern mechanism for constructing software of high criticality.

    • Frankly, I'm beginning to get slightly annoyed by the Ada articles. Ada 2012 and SPARK 2014 are awesome, no doubt about it --- I've looked at them front to back. So is model based design. Embedded developers should definitely make the effort to escape from their Assembly/C/C++ paradigm. The central issue with all of the above tools is cost. If you can't sell executive management and/or clients on an "exotic" toolset/language suite then the hemming and hawing about their awesomeness is all for naught. Also, "old-timers" and other developers that don't want to learn any knew tricks will resist you tooth and nail in my experience. From what I've seen commercial Ada and Model Based Design tools run anywhere from $25,000 upfront and $5,000/yr in maintenance to $35,000/yr on subscription to start for some run of the mill platform commoditized bare metal platform like the ARM Cortex M3/M4. Please point me to an alternative, royalty free, commercial (meaning I can target a closed source platform) legal means of applying tools outside of the C/C++ domain that will cost no more then $5,000 up front and $2,000/yr and I think the uptake of these kind of tools will be much more rapid. Otherwise this will remain fabled magic fairy dust.

    • Hi Bernard, Does anyone want to chime in on the availability of Ada compilers/run time environments for the Cortex-M and Cortex-R micro-controllers running bare iron or with common uC RTOSes (FreeRTOS, RTX, etc.)? Is this not practical? Seeing that the ARM architecture now represents the lion's share of the 32-bit micro-controller industry and is supported by a number of well developed C/C++ toolchains it would seem to me that simply having native shrink-wrapped commercial Ada support for those architectures would definitely increase interest. Maybe I'm missing something as I see that "in theory" gnat could somehow be adapted but in practice I haven't been able to locate a commercial example of such a thing. Before transitioning to assembly and then C/C++ for bare iron embedded and Unix like environments, I was an enthusiastic Pascal/Object-Pascal PC desktop developer back in the Borland heydays. For that era they had very fast, efficient and effective IDEs and compilers and I certainly remember enjoying the strongly-typed nature of Pascal and so between that and the knowledge that VHDL is partially derived from Ada conventions I think that if practical compilers were available it would be something to seriously consider. It's too bad though that Model Based Design tools are generally generating straight ANSI-C or C++. Model Based Design tools of the Simulink-like nature are yet another trend in embedded that you ought to consider investigating also. MBD plus C/C++ (for a certain subset of common embedded problems) may prove to be a more viable solution to developing large structured projects in the long term then Ada.

    • Furthermore the tiers of knowledge run something like: 1. Mathematics 2. Physics 3. Electrical Engineering 4. Mechanical Engineering 5. Astronomy 6. Chemistry 7. Biology 8. Medicine 9. Law 10. Geology 11. Computer Science 12. Psychology 13. Business 14. Economics 15. Music 16. History 17. Politics

    • Regarding the right-hand-side evaluation first: don't forget that you could evaluate the left hand side as a pointer a[i++]: ptr =(void *)a + (i * sizeof(a[0])); then increment i; then evaluate i (which has been incremented) and move it to the memory location pointed to by ptr. There might be some good machine level optimization reason for the compiler to do it this way. The *bigger* question is: who the hell writes code where the index of the array is assigned as the content of the array elements without the use of an outer loop anyway? (Where the increment could be performed). A lot of the potential for error actually just simply arises from poor architecture as opposed to language traps. Of course, expressing "C code" in reverse polish notation would fix all of this since the order of operation is then explicit. a[i++] = i 'a' i i PUT 'i' INCR DROP

    • It is far *more* important that a developer can understand the tool that they use in its entirety then that their tool does entirely everything.

    • I totally disagree with the last rule "DON'T expose the internal format of any module-specific data structure passed to or returned from one or more of the module's interface functions." This is just not a reasonable thing to do in C while maintaining the ability to statically allocate structures outside of the module and I agree with others that it amounts to a solution looking for a problem. If you REALLY WANT TO HIDE the internal data structure don't even pass the struct pointers, rather use integer handles that have to be resolved to pointers internal to the functional module. That will prevent code outside the module from being able to even copy the data without using "accessor" functions in the module.

    • Abraxalito, The reason it makes no sense is because it is a poorly written article that doesn't follow a logical line of reasoning developed in a natural order. I am sure that the author is a really bright guy but what he needs is a technical editor. Anyway, what he is saying is that it might be desirable to measure power consumed by a system on a cycle-by-cycle basis, however the passive properties of the printed circuit board (e.g. trace resistance, capacitance and inductance) that a particular processor is mounted on along with the bypass capacitors that are used makes it impossible to do that because those act as low-pass networks smoothing out the power consumption with respect to time. This is desirable behavior in terms of power distribution and regulation but is undesirable in terms of measuring the power that is being consumed on a cycle-by-cycle basis. I hope that makes better sense.