David Brown


Biography has not been added

David Brown

's contributions
    • "It is clear the author is a bit mixed up about C and C++, as well as the standards versions. By \"If you are using an older version of C11\", he means \"an older version of C++\". And templates and exceptions are not exactly new features of C++11 !\n\nRegarding templates, it is a common misconception that they necessarily mean larger code in C++. That will depend on how they are defined and used. Inlining, constant propagation, common code merging, and various other compiler techniques can mean code is shorter with templates - especially compared to the alternative of trying to write \"generic\" functions.\n\nAnd while there are good reasons for choosing not to use exceptions, especially in embedded programming, run-time speed is not one of them. Enabling exceptions usually has very little or no impact on the speed of the code, and indeed is often faster than using error returns or similar alternative techniques. However, it can sometimes involve substantial increase in code size for the stack unwind tables."

    • "If you are writing floating point code for embedded systems, be \/very\/ careful about your floating point literals. If you write 5.0, then you have a double-precision \"double\". If you want a single-precision \"float\", then write 5.0f. On a microcontroller with software floating point, double-precision operations are typically about 3 or 4 times slower than single-precision. If the microcontroller has 32-bit hardware floating point (like a Cortex M4F), the difference is a factor of several hundred.\n\nSo don't write \"float y; ...; y \/= 2.0;\". You might find your compiler bumps this up to an operation on doubles and then converts back down to singles. Write \"y \/= 2.0f\", or even better, just write \"y \/= 2;\". That is the natural way to write it.\n\nAnd if your compiler supports it, don't forget warnings to catch mistakes like this:\n\n -Wfloat-equal\n -Wfloat-conversion\n -Wdouble-promotion\n\n \n"

    • "As Matthew says, use types from stdint.h. Don't make your own typedefs for size-specific types (unless you are stuck with tools from last century). Of course, use typedefs freely for making your own types for other purposes - just don't use them to duplicate standard types.\n\nAnd if you want your code to be portable across a range of target architectures while being optimal, go beyond the basic types like uint32_t. For the example above, comparing 8-bit and 32-bit code, the correct type to use is \"int_fast8_t\". This says \"give me a signed integer, at least 8-bits in size, whatever works fastest on this platform\". On an 8-bit AVR, it will be 8-bit in size. On a 32-bit ARM, it will be 32-bit. On both platforms you get the best results.\n\nDon't \/ever\/ use \"char\" for an aritmetic type!\n\nAnd the article is incorrect in saying that signed types are more expensive than unsigned types - precisely because signed types can have more optimisations than unsigned types. It is possible that IAR's compilers are different here and don't optimise signed types as freely as the C standards allow, but a C compiler can ignore the possibility of overflow for signed types. This gives it more opportunities for optimisation, not less. Sometimes there can be particular operations that are faster with unsigned types than signed types on particular cores, however. And unsigned types should always be used for bitwise operations.\n"

    • Your first example will fail in most cases, because you have not declared "flag" to be "volatile" (or alternatively, you have not used volatile accesses on it in the main loop). I expect you will cover "volatile" in detail in later parts, but it should be in your examples here too. The idea that you should have a "default" statement in a switch to "help recover from an undefined state" is laughable. Write your code correctly so that it will not /have/ undefined states. If you have bugs in the code (or perhaps hardware problems), then a default statement is not going to help significantly - it just means you have added more code and therefore more complexity, on a code path that you almost certainly will never test. "Default" switch clauses are there for when you want a general case rather than just specific ones - never as a "just in case something goes wrong".

    • A smaller RTOS with less cache misses will mean it runs faster and more consistent. But contrary to what some people here have been saying, "real-time" is /not/ about having consistent or predictable times for anything. It is about having guarantees on deadlines. If a task has to be completed within 100 ms, then it doesn't matter if it is done in 1 us or 99.9 ms, or that cycles vary over this whole range - it is correct and real-time. Having predictable and consistent timings means you can match tighter deadlines, and you can use a greater proportion of your processing power for real-time tasks. But on a typical Linux system, you have lots of non-real-time tasks too (if not, you would be better off with a small dedicated system rather than Linux). So you have the real-time tasks with real-time scheduling so that they get the time they need, when they need it - and let everything else run when it gets the chance. Regarding FreeRTOS, you /are/ mistaken. It is totally unrelated to the Linux kernel, and targets a completely different size of system.

    • If you want to sample as fast as possible, and the number of samples is not too excessive, then you can simply unroll the loop. That way you get one sample every 3 clock cycles, with no need to use an interrupt or timer to end it.

    • Most "big name" toolchain vendors can provide you with older versions of their tools without too much fuss or extra cost (though typically without much support). But that's a good reason to pick open source toolchains as well as having the source for the application itself.

    • A free market only works when there is significant competition and alternative suppliers, and when there is clear knowledge about the products and suppliers. Do you know which scope manufacturers are going to support their models in four years' time? Do you have a choice between different scopes with roughly similar characteristics and price, but differentiated in their expected support time? If not, then a "free market" does not exist for supported scopes.

    • The scaling of electronics does not work like that. With smaller feature width on the chips, you get more features and more processing power for the same die space and the same money - but that does not translate into saying you can get the old features for less money. Chips cost money to design, produce, test and distribute - there are minimum prices. I'm guessing the bottom end is something like 20-30 cents. The 4-bit market is close to dead - even the simplest rice cookers will use 8-bit devices these days. As the price (and size and power requirements) of 8-bitters has come down to within a few cents of 4-bit devices, there is no longer a good reason for a "rice cooker" company to use them - they need the 8-bit chips for their "high-end" rice cookers, and dropping the 4-bitters means less inventory and one less development team. The same thing will happen with 8-bitters pushed out by 20-30 cent 32-bit devices, though it will take a bit of time. (There are no 16-bit devices of significance left, except the msp430 - which is best grouped with 8-bit devices.)

    • I learned most of the programming languages and paradigms (but not Forth or Python) I mentioned in a 3 year university course, of which the "computing" part was only about 30% - the rest was maths. And most of the "computing" didn't involve real programming languages at all - it was theoretical. The point is, you don't need to be fluent in all these languages, or learn the more advanced features. You need to understand the principles, not the details, and that can be done in a much shorter time. Once you have learned enough about the principles of programming, you can pick up the basics of a new language in a couple of days, and be confidently using it for development well within a week.